AI가 내 맘을 몰라줄 때: 더 적은 토큰으로 더 좋은 결과를 내는 4가지 기법
바이브 코딩 결과물이 마음에 들지 않을 때 보통 어떻게 하시나요? 혹시 화를 내며 혼내거나, 잘못된 동작을 지적하며 끝없이 토큰을 태우고 있으시진 않나요?
코딩 에이전트에게 더 만족스러운 결과를 얻어내기 위해, 특히 레거시 코드베이스에서 제가 자주 쓰지만 초보 바이브 코더들은 상대적으로 덜 쓰는 컨텍스트 엔지니어링 기법 몇 가지를 공유드립니다. (물론 일반적인 LLM 활용법으로 쓰셔도 좋습니다)
왜 또 컨텍스트 엔지니어링인가 하면, 모델의 컨텍스트 윈도우가 아무리 커져도 정보를 많이 넣으면 썩기 때문입니다. AI가 원하는 부분을 제대로 찾지도 알아듣지도 못해요. 즉 이 모든 기법은 '컨텍스트에 어떻게 하면 의도대로 구현하는 데 꼭 필요한 것만 넣을 것인가?'에 대한 고민의 산물입니다.
따라서 모델이 더 발전하면 불필요해질지도 모르지만, 그래도 지금 당장은 돈과 시간을 모두 아낄 수 있는 방법이라고 봅니다. 모델 성능을 크게 타지 않는다는 장점도 있습니다.
1. 구현 전에 탐색과 이해부터 하기
저는 풀려고 하는 문제의 도메인, 또는 수정하려는 코드베이스에 대한 이해가 부족할수록 나 자신이 똑똑해지는 데 더 많은 시간을 씁니다. 이는 프롬프트에 더 정확한 기술/도메인 용어를 포함하고, 더 정확한 파일을 참조시켜 정밀타격하기 위함입니다.
이는 비개발자에게도 마찬가지입니다. 오히려 비개발자가 개발 용어를 익힐 때 얻는 효용이 훨씬 크죠. 저는 AI로 인해 모든 사람이 개발자가 될 수 있는 '개발의 민주화' 시대가 열렸다고 보기 때문에, 지식노동자라면 어차피 해야 할 공부를 미리 하는 거라고 생각하셔도 됩니다.
탐색 + 이해 단계에서는 코드베이스를 수정하지 않는 게 좋습니다. 그래서 예전에는 커서 Ask 모드나 클로드 코드의 read-only 서브에이전트를 썼었는데 코덱스는 이런 모드가 아직 없더군요. 그래도 gpt-5 는 프롬프트를 그대로 따르는 경향이 강해, '질문'에 대해서는 대체로 코드 수정 없이 답만 해주는 편이라 괜찮습니다.
2. 따라할 코드를 보여주기
LLM은 기본적으로 평균에 수렴하는 존재입니다. 입력 토큰이 일반적이면 출력 토큰도 일반적일 수밖에 없죠. 그래서 조금이라도 더 나은 가능성을 끌어내기 위해 입력 내에 정확한 기술용어를 쓰고, 파일을 참조하고, 오타를 최소화하고, 정확한 마크다운 문법을 지키고, 어려운 작업은 영어로 쓰는 등의 노력을 합니다.
여기에 화룡점정을 찍어주는 게 예시 코드입니다. 이러저러한 코드 컨벤션을 따르라고 AGENTS.md에 넣어두는 것보다 '이 함수, 이 컴포넌트처럼 짜라'고 하는 게 더 효과적입니다. 역사와 전통의 few-shot 프롬프팅이죠.
이는 특히 마이그레이션에서 빛을 발합니다. 옮겨야 하는 패턴이 ABC고 패턴별 파일이 100개씩 있다면 ABC에서 파일 1-2개씩만 먼저 신중하게 옮겨보세요. 그리고 AI에게 이것들을 따라서 나머지를 변환하게 하면 정말 잘 합니다. 이렇게 예시 코드를 직접 짜는 일 때문에 커서의 Tab 자동완성을 떠나지 못하고 있네요.
3. 스크립트를 도구로 쥐어주기
AI의 창의성은 상방이 높은 대신 하방도 낮은데, 다양한 정적 분석 도구를 붙이면 하방이 굉장히 빠르게 높아집니다. 강규영님의 글 AI 시대의 소스코드 품질에서는 코드 품질을 높이는 다양한 도구를 소개합니다.
- 정적 타입 검사, 코드 중복 검사, 죽은 코드 검사
- 파일/함수의 최대 길이와 인지복잡도 제약
- 테스트 커버리지, 테스트-프로덕션 코드 비율 검사
여기에 더해 프로젝트에 맞는 스크립트를 작성하는 것도 큰 도움이 됩니다. 예를 들어 i18n에서는 백날 'key 빼먹지 마라'고 한들 꼭 실수가 나오고 테스트도 어려운데, 'en.json을 기준으로 ko.json에 없는 key 찾는 스크립트'를 구현시키고 pre-push hook에 넣으면 확실하게 잡을 수 있습니다.
배휘동
이는 코딩 외의 작업에서도 마찬가지입니다. 추출/변환 등 명확한 패턴이 반복되는 작업이라면 LLM에게 직접 시키기보다는, 스크립트를 짜게 해서 실행하는 게 (개발자라면 직접 실행, 비개발자라면 LLM이 실행하도록) 훨씬 정확한 결과를 얻을 수 있습니다.
4. 강의 상류를 고치기
'프롬프트 - 코드 - 결과물'이라는 바이브 코딩의 생산 라인에서, 결과물을 보고 이상하면 대개 이렇게들 합니다.
(결과물 스샷 찍고) 여기가 이래야 하는데 요렇게 동작해. 고쳐줘
또는, 개발 지식이 있다면 직접 코드를 보며 원인을 파악한 다음 이렇게 요청하기도 하죠.
(스샷 + 코드 참조해서) 여기가 이래야 하는데 요렇게 동작해. 고쳐줘
이렇게 하는 게 썩 나쁜 방식은 아닙니다만, 저는 이게 두 가지 측면에서 불리하다고 생각해요.
- 모델 성능에 지나치게 의존한다: 모델이 알잘딱하게 컨텍스트 찾아서 + 내 의도를 이해해서 고쳐주지 않으면 핑퐁이 지속되고, 컨텍스트가 갈수록 더 오염되고, 토큰이 무한 소모됨
- 운에 지나치게 의존한다: 고쳐져도 왜 고쳐졌는지 잘 모르고, 다음에 비슷한 일이 벌어지면 또 똑같은 과정을 거칠 가능성이 높음
대신 저는 이런 접근들이 더 유리하다고 생각합니다.
- 프롬프트를 개선: "지금 이런 문제가 있는데, 내가 어떤 정보와 함께 뭐라고 요청했으면 네가 처음부터 더 잘 했을까?" 물어본 다음 롤백해서 재시도
- 프롬프트를 만든 프로세스를 개선: 이 구현을 도와줄 스크립트부터 구현하기, 예시 코드부터 구현하기, 테스트코드부터 구현하기 등
- 프로세스를 만든 뇌를 개선: 지난번에 AI와 핑퐁이 길어졌던 이유를 회고하기, 탐색과 이해로 내 이해도를 높이기, 언제 내가 직접 개입하고 언제 스크립트를 쓰고 언제 MCP를 쓰고 언제 LLM을 쓸지 의사결정하는 능력을 키우기 등
맺으며
서두에 "모델이 더 발전하면 불필요해질지도 모르지만"이라고 쓴 건 사실 페이크였습니다.
에이전트의 주요 벤치마크 중 하나는 '얼마나 오랫동안 일할 수 있는가'인데, 현실적으로 (저를 포함한) 대다수의 사용자들에게는 에이전트의 한계만큼 일을 시킬 수 있는 역량이 아직 없습니다.
저는 '에이전트에게 맡길 만한 일을 찾고, 적절한 도구를 쥐어주고, 적절한 프롬프트팅으로 오랫동안 일을 시킬 수 있는' 사람이 AI 시대의 최고급 인재가 될 거라고 봅니다. 이 글에서 소개한 기법들이 그런 인재가 되기 위한 훈련에 도움이 되길 바랍니다.
Member discussion