AI 에이전트와 '말싸움'하는 기술 — 더 나은 결과를 끌어내는 법

에이전트 시대, 새로운 스킬이 필요하다

요즘 AI 코딩 에이전트를 안 쓰는 개발자를 찾기가 더 어려워졌어요. GitHub Copilot, Cursor, Claude Code 같은 도구들이 코드를 대신 써주는 시대가 됐으니까요. 그런데 이 에이전트들을 쓰다 보면 한 가지 공통된 경험을 하게 돼요. "내가 원하는 게 이게 아닌데..." 하면서 결과물을 보고 한숨 쉬는 순간이요.

최근 한 개발자가 이 문제에 대해 아주 흥미로운 글을 썼어요. 핵심 주장은 이거예요: AI 에이전트와 효과적으로 일하려면, 에이전트와 '논쟁'하는 법을 배워야 한다. 여기서 논쟁이란 싸운다는 게 아니라, 에이전트가 내놓은 결과가 마음에 안 들 때 그냥 받아들이거나 처음부터 다시 시작하는 대신, 왜 그게 아닌지를 설명하고 더 나은 방향으로 이끄는 대화 기술을 말하는 거예요.

에이전트는 왜 엉뚱한 결과를 내놓을까

먼저 AI 에이전트가 왜 종종 우리가 원하지 않는 코드를 만들어내는지 이해할 필요가 있어요. 에이전트는 우리의 프롬프트(요청)를 받아서 "가장 그럴듯한" 코드를 생성하거든요. 문제는 "가장 그럴듯한"과 "내가 정확히 원하는"이 같지 않다는 거예요.

예를 들어 "사용자 인증 기능 만들어줘"라고 요청하면, 에이전트는 가장 일반적인 패턴으로 JWT 기반 인증을 만들 수 있어요. 그런데 내 프로젝트에서는 세션 기반 인증이 필요한 상황이라면? 에이전트는 잘못한 게 아니에요. 충분한 맥락 없이 최선의 추측을 한 거죠. 이런 간극을 좁히는 게 바로 "에이전트와 논쟁하기"의 핵심이에요.

효과적으로 에이전트를 이끄는 방법

글에서 제시하는 핵심 전략들을 좀 더 풀어볼게요.

첫 번째는 "그냥 다시 해줘" 대신 "왜 이렇게 했어?"라고 물어보는 거예요. 에이전트가 예상과 다른 코드를 내놓았을 때, 무턱대고 "다시 해"라고 하면 비슷한 결과가 나올 확률이 높아요. 대신 "왜 이 접근 방식을 선택했어?"라고 물어보면 에이전트가 자신의 추론 과정을 설명하거든요. 그 설명을 보면 어디서 맥락이 빠졌는지 파악할 수 있고, 그 빠진 부분만 정확히 채워주면 훨씬 나은 결과를 얻을 수 있어요.

두 번째는 구체적으로 반박하는 거예요. "이거 별로야"보다 "이 방식은 N+1 쿼리 문제가 생길 수 있으니까, 대신 eager loading을 써서 다시 작성해줘"처럼 기술적 근거와 함께 대안을 제시하는 거죠. 이게 뭐냐면, 에이전트에게 더 좁은 범위의 솔루션 공간을 제공하는 거예요. 넓은 가능성 중에서 아무거나 고르게 두지 않고, "이 방향으로 가"라고 명확하게 안내하는 거죠.

세 번째는 점진적으로 요구사항을 쌓아가는 거예요. 한 번에 완벽한 결과를 기대하지 말고, 대화를 여러 턴으로 나누어서 조금씩 다듬어 가는 방식이에요. 마치 코드 리뷰를 하듯이 "여기는 좋은데, 이 부분은 이렇게 바꿔줘"라고 피드백을 주면서 최종 결과물을 만들어 가는 거예요. 실제로 이렇게 하면 에이전트가 이전 대화의 맥락을 유지하면서 더 정교한 코드를 만들어낼 수 있어요.

프롬프트 엔지니어링과 뭐가 다른가

"이거 그냥 프롬프트 엔지니어링 아닌가요?"라고 생각할 수 있는데, 미묘하지만 중요한 차이가 있어요. 프롬프트 엔지니어링은 처음에 좋은 질문을 만드는 기술이에요. 반면 에이전트와의 논쟁은 대화가 진행되면서 결과를 개선해 나가는 기술이죠. 시작점이 아니라 과정에 초점이 맞춰져 있는 거예요.

특히 요즘 코딩 에이전트들은 단순히 코드 한 조각을 생성하는 게 아니라, 파일을 읽고, 수정하고, 테스트를 돌리고, 디버깅까지 하는 복잡한 작업을 수행해요. 이런 멀티스텝 작업에서는 중간중간 방향을 교정해주는 "논쟁" 스킬이 더욱 중요해지는 거예요. 에이전트가 잘못된 방향으로 10단계를 진행한 다음에 "처음부터 다시"가 되면 시간 낭비가 크니까요.

실무에서 바로 적용할 수 있는 팁

이 글의 인사이트를 실무에 적용하려면 이런 습관들을 들여보면 좋아요.

에이전트에게 작업을 시키기 전에 프로젝트의 제약 조건을 먼저 알려주세요. "우리 프로젝트는 TypeScript strict 모드를 쓰고, React Query로 서버 상태를 관리하고, 테스트는 Vitest로 작성해"처럼요. 이러면 에이전트가 엉뚱한 방향으로 갈 확률이 크게 줄어들어요.

그리고 에이전트의 결과물을 무조건 수용하거나 무조건 거부하는 이분법에서 벗어나세요. "이 함수의 로직은 좋은데, 에러 핸들링 부분은 우리 프로젝트의 커스텀 에러 클래스를 써서 다시 작성해줘"처럼 좋은 부분은 인정하고 아쉬운 부분만 구체적으로 지적하는 거예요. 사람한테 코드 리뷰 피드백 주듯이요.

마지막으로, 에이전트가 틀렸을 때 그 이유를 기록해 두세요. "아, 이 에이전트는 데이터베이스 마이그레이션 작성할 때 항상 down 마이그레이션을 빠뜨리는구나" 같은 패턴을 발견하면, 다음부터는 미리 "down 마이그레이션도 꼭 포함해줘"라고 요청할 수 있죠. CLAUDE.md 같은 프로젝트 설정 파일에 이런 규칙을 적어두면 매번 말하지 않아도 돼요.