패턴이 결과를 결정한다
Claude Code를 몇 번 써보면 "같은 도구인데 왜 어떤 날은 잘 되고 어떤 날은 안 되지?"라는 질문이 생긴다. 모델의 역량 차이가 아니라, 지시 방식의 차이인 경우가 대부분이다. 실제 세션에서 반복적으로 확인된 패턴을 정리했다.
잘 작동하는 지시 방식
1. 목표와 제약을 함께 준다. "로그인 기능 만들어줘"보다 "JWT 토큰 기반 로그인 기능을 만들어줘. 외부 라이브러리는 최소화하고, 에러 처리도 포함해줘"가 결과가 낫다. 목표만 주면 에이전트가 알아서 채우고, 그 채움이 원하는 방향이 아닐 수 있다.
2. 하나씩 요청한다. 여러 기능을 한 번에 요청하면 하나씩 요청할 때보다 오류가 많이 난다. "A 만들어줘"가 완료되면 "이제 B 추가해줘"로 진행한다. 체크포인트를 짧게 유지하는 것이 전체 속도를 높인다.
3. 모르는 것은 물어보게 한다. "이걸 구현하는 방법이 여러 가지면 각각의 장단점을 먼저 알려줘"라고 하면 에이전트가 옵션을 제시하고 사람이 선택할 수 있다. 큰 선택 지점에서는 에이전트가 혼자 결정하게 두는 것보다 한 번 물어보는 편이 낫다.
4. 에러 메시지를 그대로 붙여넣는다. 에러가 나면 설명하려 하지 말고 에러 메시지 전체를 그대로 붙여넣는다. "이런 에러가 났어"보다 스택 트레이스 전체를 주는 쪽이 훨씬 정확한 수정이 나온다.
5. 작업 완료 기준을 미리 말해준다. "완료되면 어떤 상태여야 하는지"를 처음에 알려주면 에이전트가 스스로 검증할 수 있다. "테스트가 모두 통과하면 완료야" 또는 "이 URL에서 정상 응답이 오면 완료야"처럼 명확한 완료 조건을 준다.
자주 실패하는 방식
1. 요청이 너무 추상적이다. "더 좋게 만들어줘", "최적화해줘"처럼 기준이 없는 요청은 에이전트가 임의로 해석한다. 원하는 결과가 구체적일수록 지시도 구체적이어야 한다.
2. 기존 코드 설명 없이 수정 요청한다. 에이전트가 코드를 처음 보는 상황에서 "이 부분 고쳐줘"라고만 하면 전체 구조를 잘못 이해하고 수정할 수 있다. 수정 요청 전에 "이 코드의 역할을 먼저 설명해줘"라고 확인하는 단계가 있으면 실수가 줄어든다.
3. 세션을 너무 길게 이어간다. 초반에 정한 방향을 에이전트가 중간에 잊거나 바꾸는 일이 생긴다. 긴 세션보다 짧은 세션 여러 개가 일관성 면에서 낫다.
4. 생성된 코드를 확인하지 않고 다음 요청을 한다. 앞 단계 결과를 확인하지 않은 채 다음 요청을 하면 오류가 누적된다. 각 단계의 결과를 실행해보고 다음으로 넘어가는 습관이 중요하다.
5. 실패한 방식을 다시 시도한다. 같은 요청이 두 번 실패하면 요청 방식을 바꾼다. 에이전트에게 "왜 이렇게 했는지" 설명을 먼저 요청하면 다음 시도의 방향이 잡힌다.