기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# Gremlin 코드를 배포할 컨텍스트에서 테스트하세요.
<a name="best-practices-gremlin-console-glv-differences"></a>

Gremlin은 클라이언트가 서버에 쿼리를 제출하는 다양한 방법을 제공합니다. 이러한 제출 모드는 쿼리가 평가되는 방식과 트랜잭션이 작동하는 방식에 따라 다릅니다. 이러한 차이는 한 모드에서 개발하고 다른 모드에서 배포하는 경우 예상치 못한 결과를 초래할 수 있습니다.

**스크립트 모드(문자열 기반 제출)**  
스크립트 모드에서 클라이언트는 전체 쿼리를 텍스트 문자열로 서버에 전송합니다. 서버는 모든 *터미널 단계를* 포함하여 전체 문자열을 평가하고 결과를 클라이언트로 다시 스트리밍합니다. 다음 도구 및 메서드는 스크립트 모드를 사용합니다.
+ [Gremlin 콘솔](access-graph-gremlin-console.md) - `:remote` 명령을 사용하는 경우
+ [Neptune 그래프 노트북](graph-notebooks.md)
+ [AWS SDK 또는 AWS CLI를 사용한 HTTP](access-graph-gremlin-rest.md)
+ TinkerPop 드라이버를 통해 쿼리 문자열 제출(예: Java`client.submit("g.V().count()")`에서 사용)

스크립트 모드에서 클라이언트는 다음과 같은 쿼리를 서버에 전체 문자열로 전송합니다.

```
// Script mode – the entire string, including .next(), is sent to the server
// V('non-existing-id') yields nothing because no vertex with that ID exists
Cluster cluster = Cluster.build().addContactPoint("your-neptune-endpoint")
                         .port(8182).enableSsl(true).create();
Client client = cluster.connect();
client.submit("g.V('existing-id').addV('person').V('non-existing-id').next()");
```

서버는를 포함한 전체 쿼리를 평가합니다`.next()`. 가 결과를 `.next()` 찾지 못하면 서버가를 발생`NoSuchElementException`시키고 트랜잭션이 *롤백됩니다*.

**바이트코드 모드(GLV 순회 객체)**  
바이트코드 모드에서 클라이언트는 Gremlin 언어 변형(GLV)을 사용하여 로컬에서 순회 객체를 빌드합니다. 드라이버는 순회 단계를 바이트코드로 직렬화하여 서버로 전송합니다. `.toList()` 또는와 같은 터미널 단계는 *클라이언트 측*에서 `.next()` 실행되어 서버에서 반환된 결과를 반복합니다. [Java](access-graph-gremlin-java.md), [Python](access-graph-gremlin-python.md), [Go](access-graph-gremlin-go.md), [.NET](access-graph-gremlin-dotnet.md), [JavaScript](access-graph-gremlin-node-js.md) 및 사용된 Neptune 엔진 버전에 적합한 기타 타사 TinkerPop 호환 드라이버와 함께 바이트코드 모드를 사용할 수 있습니다.

바이트코드 모드에서는 동일한 쿼리가 다음과 같습니다.

```
// Bytecode mode – the driver sends the traversal steps as bytecode
// .next() executes on the client to iterate results
Cluster cluster = Cluster.build().addContactPoint("your-neptune-endpoint")
                         .port(8182).enableSsl(true).create();
GraphTraversalSource g = traversal().withRemote(
    DriverRemoteConnection.using(cluster));
g.V("existing-id").addV("person").V("non-existing-id").next();
```

드라이버는 순회 단계(`g.V().addV().V()`)만 바이트코드로 전송합니다. 서버는 순회를 성공적으로 평가하고 트랜잭션을 커밋하며 결과 세트를 반환합니다. 그런 다음 클라이언트는 `.next()` 로컬에서를 호출하여 결과 집합에서 읽습니다. 결과 집합이 비어 있는 경우 클라이언트는를 발생`NoSuchElementException`시키지만 트랜잭션이 *이미 서버에서 커밋*된 것입니다.

**트랜잭션 동작 차이**  
이러한 모드 간의 중요한 차이점은 터미널 단계가 트랜잭션에 미치는 영향입니다.
+ **스크립트 모드** - 서버가 터미널 단계를 평가합니다. 결과 집합이 비어 있어와 같은 터미널 단계가 `.next()` 실패하면 서버는 쿼리를 실패로 처리하고 트랜잭션을 *롤백합니다*. 서버는 동일한 순회(예: )에서 변형을 유지하지 않습니다`addV()`.
+ **바이트코드 모드** - 클라이언트가 터미널 단계를 평가합니다. 서버는 순회 단계만 평가하고 트랜잭션을 성공적으로 커밋하며 결과를 반환합니다. 그러면 클라이언트`NoSuchElementException`가 빈 결과 집합`.next()`에서를 호출하면 클라이언트 측 오류만 발생합니다. 트랜잭션이 이미 커밋되었으므로 서버는 변형을 *유지합니다*.

**터미널 단계**  
Gremlin에서 [터미널 단계는](https://tinkerpop.apache.org/docs/current/reference/#terminal-steps) 순회가 평가를 위해 Neptune에 제출되도록 하는 단계입니다. 바이트코드 모드에서는 터미널 단계가 드라이버를 트리거하여 순회를 직렬화하고 전송합니다. 스크립트 모드에서 터미널 단계는 서버에서 평가된 쿼리 문자열의 일부입니다. 터미널 단계는 다음과 같습니다.
+ `hasNext()` - 결과를 사용할 수 있는 `true` 경우를 반환하고, `false` 그렇지 않으면를 반환합니다.
+ `next()` - 다음 결과를 반환합니다. 결과가 없는 `NoSuchElementException` 경우 발생합니다.
+ `next(n)` - 다음 {{n}}개의 결과를 목록으로 반환합니다.
+ `toList()` - 모든 결과를 목록으로 반환합니다. 결과가 없는 경우 빈 목록을 반환합니다.
+ `toSet()` - 모든 결과를 집합으로 반환합니다. 결과가 없는 경우 빈 세트를 반환합니다.
+ `iterate()` - 반환하지 않고 모든 결과를 반복합니다. 반환 값이 필요하지 않은 변형에 사용합니다.

**참고**  
개별 언어 GLVs 구현과 관련된 추가 터미널 단계를 제공할 수 있습니다. 자세한 내용은 언어별 페이지를 참조하세요.

한 컨텍스트에서 코드를 개발하고 테스트하는 경우 문제가 발생할 수 있습니다. 예를 들어 Gremlin 콘솔은 쿼리를 스크립트로 제출합니다. 바이트코드를 사용하는 Java 드라이버를 통해 다른 컨텍스트에 코드를 배포하는 경우 프로덕션 환경에서 코드가 다르게 작동할 수 있습니다.

**중요**  
예기치 않은 트랜잭션 동작을 방지하려면 배포되는 것과 동일한 제출 모드를 사용하여 Gremlin 코드를 테스트해야 합니다.