당신이 지불하는 것은 코드 생성이 아니라 컨텍스트(Context)입니다

AI의 숨겨진 비용은 코드를 생성하는 것이 아닙니다. 그것은 바로 당신의 코드베이스(Codebase)를 이해하는 것입니다.

오랫동안 저는 AI 코딩 도구들이 많은 코드를 생성하기 때문에 비용이 많이 드는 것이라고 가정해 왔습니다. 이러한 도구들은 컴포넌트(Components), 테스트(Tests), SQL 쿼리(SQL queries), 문서(Documentation), 그리고 때로는 요청에 따라 전체 기능(Features)까지 만들어낼 수 있습니다. 만약 비용이 상승하고 있다면, 출력량(Output volume)이 그 이유임이 틀림없다고 생각했습니다.

이 도구들을 더 많이 사용할수록, 제가 잘못된 것을 측정하고 있었다는 사실을 깨닫게 되었습니다. 비싼 부분은 코드를 작성하는 것이 아닙니다. 비싼 부분은 어떤 코드가 작성되어야 하는지를 이해하는 것이며 — 그 작업은 대부분 눈에 보이지 않습니다. 그 깨달음은 AI 보조 개발(AI-assisted development)에 대한 저의 생각을 완전히 바꾸어 놓았습니다.

두 개의 프롬프트(Prompt), 두 가지 매우 다른 문제

다음 두 가지 요청을 생각해 보십시오: _"날짜 형식을 지정하는 유틸리티 함수(Utility function)를 생성해줘"_와 "이 기능을 검토하고 개선 사항을 제안해줘." 언뜻 보기에 두 요청 모두 평범해 보입니다. 둘 다 짧은 답변을 내놓을 수도 있습니다. 하지만 이들은 완전히 다른 수준의 이해를 요구합니다.

첫 번째는 좁고 잘 정의되어 있습니다. AI는 유용한 답변을 생성하기 전에 아주 적은 정보만을 필요로 합니다. 두 번째는 개방형(Open-ended)입니다. 단 하나의 개선 사항을 제안하기 전에, AI는 여러 파일을 읽고, 의존성(Dependencies)을 이해하며, 기존 패턴을 따르고, 구현 사항을 비교하며, 해당 기능이 왜 존재하는지에 대한 멘탈 모델(Mental model)을 구축해야 할 수도 있습니다.

출력물은 여전히 작을 수 있습니다. 하지만 그 결과에 도달하기 위해 필요한 작업은 그렇지 않습니다.

에이전트 워크플로우(Agent Workflows)가 자동 완성(Autocomplete)과 다르게 느껴지는 이유

이 점은 제가 AI 에이전트(AI agents)를 사용하기 시작했을 때 훨씬 더 명확해졌습니다. 전통적인 자동 완성(Autocomplete)은 예측 방식입니다 — 당신이 타이핑하면, AI는 다음에 무엇이 올지 추측합니다. 그것은 빠르고, 저렴하며, 의도적으로 컨텍스트(Context)를 가볍게 유지합니다.

에이전트(Agents)는 다르게 행동합니다. 기능을 개선하거나 워크플로(Workflow)를 검토하라고 요청할 때, 에이전트는 즉시 코드 생성을 시작하지 않습니다. 대신 읽기부터 시작합니다. 임포트(Imports)를 따라가고, 관련 파일을 찾으며, 시스템을 건드리기 전에 이를 이해하려고 시도합니다. 이것이 바로 에이전트 워크플로가 자동 완성(Autocomplete)보다 더 느리고 자원 집약적으로 느껴지는 정확한 이유입니다. 즉, 이해하는 데 먼저 노력을 기울이는 것입니다.

이 지점에서 경제성이 가시화됩니다. 많은 에이전트 워크플로에서 모델은 권장 사항을 생성하는 출력 토큰(Output tokens)보다 코드베이스를 이해하는 데 훨씬 더 많은 입력 토큰(Input tokens)을 소비할 수 있습니다. 이 불균형은 놀라울 정도로 클 수 있습니다. 당신은 정답에 대해 비용을 지불하는 것이 아닙니다. 모델이 단 한 줄을 쓰기 위해 읽어야 했던 모든 것에 대해 비용을 지불하는 것입니다.

이는 구체적인 방식으로 나타납니다. 저장소 전체 인덱싱(Repository-wide indexing), 코드베이스 컨텍스트 고정(Codebase context pins), 에이전트 기반 터미널 실행(Agentic terminal executions) 등은 모두 첫 번째 생성된 라인에 손을 대기 전에 막대한 양의 컨텍스트(Context)를 소비합니다.

로그 파일의 함정 (The Log File Trap)

디버깅(Debugging)은 이러한 패턴이 가장 명확하게 드러나는 지점입니다. 빌드가 실패하고, 테스트가 깨지기 시작하며, 배포가 잘못될 때 — 자연스러운 반응은 모든 것을 AI에 붙여넣고 무엇이 잘못되었는지 묻는 것입니다. 저 또한 수백 줄의 로그, 스택 트레이스(Stack traces), 터미널 출력, 설정 스니펫(Configuration snippets)을 한꺼번에 쏟아부은 적이 있습니다.

대부분의 경우, 관련 정보는 중간 어딘가에 파묻혀 있습니다. 하지만 AI는 어쨌든 그 모든 것을 처리합니다. 집중되고 다듬어진 스택 트레이스는 전체 로그 덤프(Full log dump)와 동일한 답을 내놓는 경우가 많습니다. 차이점은 순수하게 AI가 그 답에 도달하기 위해 얼마나 많은 컨텍스트를 헤쳐 나가야 했느냐에 있습니다.

교훈은 AI를 덜 사용하라는 것이 아닙니다. 당신이 어떤 정보를 제공할지에 대해 더 의도적(Deliberate)이 되어야 한다는 것입니다.

나에게 일어난 변화 (What Changed for Me)

코드 생성 (Code generation)이 아닌 컨텍스트 (Context)에 대해 생각하기 시작하자, 저의 프롬프트 (Prompt)가 변했습니다. "이 기능을 검토해줘" 대신 _"이 두 파일에 있는 인증 로직 (Authentication logic)을 검토해줘"_라고 묻기 시작했습니다. "이 모듈을 리팩터링 (Refactor)해줘" 대신 _"퍼블릭 API (Public API)를 변경하지 않고 이 서비스 (Service)를 단순화해줘"_라고 요청했습니다. 전체 빌드 로그 (Build log)를 공유하는 대신, 관련 있는 섹션만을 공유했습니다.

가장 명확한 사례는 세 개의 파일을 대상으로 한 인증 리팩터링 (Authentication refactor)이었습니다. 모호한 프롬프트 (Prompt)를 사용했을 때는 에러 핸들링 (Error handling), 널 체크 (Null checks), 네이밍 (Naming)에 대한 일반적인 제안들—실제로 큰 변화를 주지는 않으면서 유용하게만 들리는 조언들—이 돌아왔습니다. 반면, 범위를 지정한 프롬프트 (Scoped prompt)를 사용했을 때는 제가 고려하지 못했던 세션 무효화 (Session invalidation) 엣지 케이스 (Edge case)가 즉시 드러났습니다. 이는 대화의 흐름을 단순한 정리 (Cleanup)에서 정확성 (Correctness)의 문제로 격상시켰습니다.

동일한 코드베이스 (Codebase). 동일한 AI. 입력값이 다르면 답변의 깊이도 달라집니다.

답변의 품질이 떨어지는 경우는 거의 없었으며, 많은 경우 오히려 향상되었습니다. 더 나은 프롬프트 (Prompt)는 단순히 AI를 돕는 것에 그치지 않았습니다. 그것은 제가 해결하려는 문제에 대해 더 명확하게 생각하도록 강제했습니다.

마치며 (Final Thoughts)

AI 비용에 관한 대부분의 논의는 출력 (Output)에 집중합니다. 얼마나 많은 코드가 생성되었는지, 얼마나 많은 요청 (Request)이 이루어졌는지와 같은 것들 말입니다. 이것들은 측정하기 쉬운 요소들입니다. 하지만 더 중요한 질문은 대개 숨겨져 있습니다. _"AI가 답변을 하기 위해 얼마나 많은 것을 이해해야 했는가?"_입니다.

목표는 컨텍스트 (Context)를 없애는 것이 아닙니다. 목표는 불필요한 컨텍스트 (Unnecessary context)를 없애는 것입니다. 이 차이는 들리는 것보다 훨씬 더 중요합니다. 대부분의 경우, 우리는 코드 생성 (Code generation)에 비용을 지불하는 것이 아닙니다. 우리는 이해 (Understanding)에 비용을 지불하고 있는 것입니다.

코드는 대개 쉬운 부분입니다. 문제를 이해하는 것이야말로 언제나 진정한 작업이 이루어지는 지점이었습니다.

AI 코딩 어시스턴트 (AI coding assistants)를 사용하면서 비슷한 패턴을 발견하셨나요? 여러분의 워크플로우 (Workflow)가 어떻게 변했는지 듣고 싶습니다.

저는 실제 프로젝트의 프론트엔드 (Frontend) 문제들에 대해 글을 씁니다 — 도움이 된다면 팔로우해 주세요.

이 글이 도움이 되었다면 ❤️를 남겨주세요 — 노출에 큰 도움이 됩니다.

저와 연결하기 (Connect with me):

• LinkedIn: Sanket Bhor
• 웹사이트: sanketbhor.dev