AI 코딩의 경고등이 켜졌다 — 그래서 우리는 어떻게 할 것인가

최근 개발자 커뮤니티에서 “Agentic Coding은 함정이다”, “인지 부채가 쌓이고 있다”, “토큰 비용이 지속 가능하지 않다” 같은 경고의 목소리가 빠르게 퍼지고 있다. GeepawHill의 글이 대표적이고, 여러 시니어 개발자들이 비슷한 우려를 제기한다.

이 경고들은 타당하다. 하지만 “그러니까 AI를 덜 쓰자”라는 결론에서 멈추면, 실제로 변화하고 있는 산업의 흐름을 놓치게 된다.

경계해야 할 것은 정확히 경계하되, 이 시대에 어떻게 성장할 것인가를 같이 이야기해보자.

경고가 말하는 것: 정확히 무엇이 위험한가

1. 감독의 역설 (Supervision Paradox)

AI를 많이 쓸수록, AI가 만든 코드를 감독할 능력이 줄어든다.

이건 진짜다. AI가 생성한 200줄의 코드를 “대충 맞는 것 같으니까” 머지하는 순간, 그 코드의 실제 소유자는 아무도 아니게 된다. 장애가 나면 AI에게 “이거 왜 이래?”라고 물어야 하는 상황이 벌어진다.

2. 기술 위축 (Skill Atrophy)

연구에 따르면 AI 도구를 과도하게 사용한 개발자의 디버깅 능력이 47% 감소했다는 결과가 있다. 주니어 개발자가 직접 코드를 작성해본 경험 없이 AI 출력물만 수정하는 패턴에 빠지면, “왜 이렇게 동작하는지”를 이해하는 근본적인 능력이 형성되지 않는다.

3. 토큰 비용 과열

현재 에이전틱 코딩의 토큰 소비량은 상당하다. 하나의 기능 구현에 수십만 토큰이 소모되기도 한다. 비용 최적화 전략 없이 무분별하게 사용하면 개인이든 조직이든 예산 문제에 직면한다.

4. 벤더 종속

Claude가 장애를 일으키면 팀 전체가 멈춘다 — 이런 상황이 실제로 일어나고 있다. 하나의 AI 서비스에 워크플로우 전체를 의존하는 것은 인프라 리스크다.

그런데, 경고만으로는 부족하다

이 비판들의 공통점이 있다. AI를 “나 대신 코드 쓰는 도구”로만 정의한다는 것이다.

에이전틱 코딩을 “요구사항을 던지면 AI가 구현해주는 것”으로 한정하면, 당연히 위험하다. 하지만 실제로 AI 코딩 도구를 잘 활용하는 개발자들을 관찰하면, 그들은 완전히 다른 방식으로 쓰고 있다.

비판이 놓치는 것들:

1. 피드백 루프 속도의 가치 — AI가 3초 만에 프로토타입을 만들어주면, “이 설계가 맞는지”를 3시간이 아니라 3분 만에 검증할 수 있다. 빠른 실패는 깊은 이해의 전제 조건이다.

2. 탐색 범위의 확장 — 혼자서는 시도해보지 않았을 접근 방식을 AI와 함께 빠르게 탐색할 수 있다. 이건 학습의 가속이지 대체가 아니다.

3. 인지 자원의 재배치 — 보일러플레이트에 쓰던 인지 자원을 아키텍처, 비즈니스 로직, 엣지 케이스에 집중할 수 있다. 단, 이걸 의식적으로 해야 한다.

실전 프레임워크: 무엇을 위임하고, 무엇을 지켜야 하는가

경고를 인식한 상태에서 실제로 적용할 수 있는 원칙들이다.

위임해도 좋은 것 (Low Cognitive Risk)

반드시 직접 해야 하는 것 (High Cognitive Risk)

개발자 인사이트

“위임의 기준은 되돌릴 수 있는가”이다. 되돌리기 쉬운 작업은 AI에게 맡기고 결과만 검증하라. 되돌리기 어려운 결정은 반드시 직접 내려라. 이 기준 하나로 인지 부채의 90%를 예방할 수 있다.

토큰 비용: 공포가 아닌 전략으로

토큰 비용에 대한 현재의 불안감은 2000년대 초반 클라우드 비용에 대한 불안감과 비슷하다. “서버를 빌려 쓴다고? 비용이 감당이 되나?”에서 시작해서, 결국 온프레미스보다 효율적인 사용 패턴을 찾아낸 것처럼.

흔히 보이는 안티패턴: “일단 다 붙여”

요즘 자주 보이는 장면이 있다. MCP 서버, 커스텀 도구, RAG, 웹 검색, 코드베이스 인덱싱 — 가능한 모든 기능을 전부 활성화해놓고 “왜 이렇게 토큰이 빨리 빠지지?”라고 한다.

이건 레스토랑에서 메뉴를 전부 시켜놓고 “왜 이렇게 비싸지?”라고 묻는 것과 같다. 모든 도구를 항상 연결해두면 매 요청마다 시스템 프롬프트와 도구 정의만으로 수천~수만 토큰이 기본으로 소모된다. 실제 작업에 쓰이는 토큰보다 도구를 설명하는 데 쓰이는 토큰이 더 많은 아이러니가 벌어진다.

더 심각한 문제는 토큰 한도에 도달했을 때다. “토큰이 막혀서 오늘 아무것도 못 합니다” — 이 문장이 나오는 순간, AI는 더 이상 생산성 도구가 아니라 생산성의 병목이 된 것이다. 마치 인터넷이 끊기면 이메일 하나 못 보내는 것처럼, AI 없이는 기본적인 코딩조차 할 수 없는 상태가 되어버린다.

현실적인 비용 전략

1. 계층화된 모델 사용 — 탐색과 프로토타입에는 빠르고 저렴한 모델(Haiku급), 핵심 설계와 복잡한 구현에는 고성능 모델(Opus급)을 쓴다.

2. 컨텍스트 위생 — 불필요한 파일을 컨텍스트에 넣지 않는다. 정확한 컨텍스트가 비용도 줄이고 품질도 높인다. 도구도 마찬가지다 — 지금 이 작업에 필요한 도구만 연결한다.

3. 프롬프트 자산화 — 반복되는 작업의 프롬프트를 정제하고 재사용한다. 매번 처음부터 설명하는 것은 토큰 낭비다.

4. ROI 측정 — “토큰을 얼마나 썼는가”보다 “이 토큰으로 몇 시간을 벌었는가”를 추적한다.

5. 토큰 소진 대비책 — 토큰 한도에 도달해도 업무가 멈추지 않는 워크플로우를 유지한다. AI가 없으면 아무것도 못 하는 상태는 그 자체로 기술 부채다.

보이지 않는 오버헤드: 매 요청마다 선불로 나가는 토큰

위의 전략은 “어떻게 쓸 것인가”에 대한 답이다. 하지만 실제로 세션을 계측해보면 더 근본적인 문제가 드러난다 — 프롬프트를 입력하기도 전에 이미 소모되는 토큰이 전체의 절반 이상을 차지한다는 것이다. 프롬프트를 아무리 잘 써도, 이 기저 오버헤드가 크면 효과가 제한적이다.

1. CLAUDE.md 비대화 — 프로젝트 규칙 파일이 5,000 토큰이면, 매 턴마다 5,000 토큰이 기본으로 나간다. 주 200턴이면 그것만으로 주당 100만 토큰이다. 실제로 필요한 규칙만 남기고, 프레임워크별 규칙은 프로젝트 레벨로 분리하고, 반복 패턴은 스킬로 추출하라. 합산 1,500 토큰 이하가 목표다.

2. 대화 히스토리 누적 — 후속 메시지를 보낼 때마다 이전 대화 전체가 재토큰화된다. 30번째 메시지의 비용은 1번째의 30배다. 대화는 20 메시지 이내로 유지하고, 연속성이 필요하면 /compact로 요약 후 재시작하라. 이전 메시지를 수정(↑ → 편집 → 재전송)하면 잘못된 교환이 쌓이지 않는다.

3. 훅·플러그인 인젝션 — UserPromptSubmit 훅이 여러 개 등록되어 있으면, 매 프롬프트마다 수천 토큰이 타이핑하기도 전에 주입된다. settings.json의 훅 목록을 주기적으로 감사하고, “이 훅이 매 프롬프트에 왜 필요한지” 설명할 수 없으면 비활성화하라.

4. 캐시 미스 — 프롬프트 캐시의 기본 수명은 5분이다. 커피 한 잔 마시고 돌아오면 시스템 프롬프트, CLAUDE.md, 도구 스키마 전체가 정가로 재계산된다. 잠시 자리를 비울 때 간단한 프롬프트 하나를 보내 캐시를 유지하는 것만으로 상당한 비용을 절약할 수 있다.

5. 잘못된 방향의 생성 멈추기 — AI가 긴 응답을 쓰기 시작했는데 처음 몇 줄에서 방향이 틀렸다면, 끝까지 기다리지 마라. Cmd+.(Mac) / Ctrl+.(Windows)로 즉시 중단하고 방향을 수정하라. 완성된 잘못된 응답은 출력 토큰 낭비이자 다음 턴의 히스토리 비용이 된다.

핵심 인식: 매 세션은 빈 슬레이트가 아니라 청구서다. CLAUDE.md + 훅 + 플러그인 + 도구 스키마 + 대화 히스토리가 매 턴마다 선불 과금된다. 프롬프트 최적화보다 이 기저 오버헤드를 줄이는 것이 ROI가 높다.

개발자 인사이트

토큰 비용은 떨어지고 있고, 계속 떨어질 것이다. GPT-4 급 성능의 비용이 2년 사이에 1/100로 떨어졌다. 지금의 비용 구조를 영원한 것으로 전제하고 전략을 짜면 안 된다. 하지만 “나중에 싸질 테니 지금은 무시하자”도 위험하다. 지금 합리적인 수준에서 쓰되, 비용 감소에 베팅하라. 그리고 무엇보다 — 토큰이 없어도 일할 수 있는 사람이어야 한다.

기술 위축을 막는 의식적 훈련법

AI를 쓰면서도 핵심 역량을 유지하는 것은 가능하다. 단, 의식적인 노력이 필요하다.

1. “AI 없는 30분” 규칙

하루에 최소 30분은 AI 없이 코드를 작성한다. 특히 디버깅은 직접 한다. 이건 운동과 같다 — 매일 하지 않으면 근육이 빠진다.

2. AI 출력물 “왜?” 습관

AI가 생성한 코드를 수락하기 전에 스스로에게 묻는다:

• 이 코드가 왜 이 방식으로 작성되었는가?
• 대안이 있다면 무엇이고, 왜 이게 더 나은가?
• 이 코드의 실패 지점은 어디인가?

답할 수 없으면, 수락하지 않는다.

3. 주간 “딥 다이브”

일주일에 한 번, AI가 생성한 코드 중 가장 복잡한 부분을 골라서 처음부터 직접 다시 작성해본다. 결과물을 비교하면서 AI가 놓친 것과 내가 놓친 것을 모두 학습한다.

4. 설명할 수 있어야 한다

코드 리뷰에서 “AI가 짰는데 잘 동작합니다”는 답이 될 수 없다. 팀원에게 해당 코드를 3분 안에 설명할 수 없다면, 그 코드는 이해하지 못한 것이다.

벤더 종속과 “AI 없으면 멈추는 팀” 문제

단일 AI 서비스에 대한 의존은 실제 운영 리스크다. 그리고 이건 조직 차원만의 문제가 아니다.

개인 레벨에서도 동일한 현상이 발생하고 있다. 월간 토큰 한도가 소진되거나, AI 서비스에 장애가 생기면 문자 그대로 코딩을 멈추는 개발자가 늘고 있다. “토큰 리셋될 때까지 기다리는 중”이라는 말은 농담이 아니라 실제 슬랙에서 오가는 메시지다.

이건 생산성 도구에 대한 의존이 아니다. 기본 능력의 외주화다. IDE의 자동완성이 고장 나면 타이핑이 느려지지만 코딩은 할 수 있다. 하지만 AI가 막히면 “뭘 해야 할지 모르겠다”는 상태가 되는 건, 도구 의존이 아니라 사고 능력의 위임이다.

이걸 줄이는 접근:

1. 워크플로우를 AI 서비스에 직접 결합하지 않는다 — 추상화 계층을 두고, AI 서비스는 교체 가능하게 유지한다.

2. 핵심 작업은 AI 없이도 가능하게 유지한다 — AI가 3시간 장애를 일으켜도 팀이 완전히 멈추지 않아야 한다. “느려지는 것”과 “멈추는 것”은 다르다.

3. 로컬 모델을 보조로 유지한다 — 모든 작업에 최고 성능이 필요하지 않다. 인터넷 장애 시에도 기본적인 자동완성과 코드 생성은 로컬 모델로 가능하다.

4. “AI 다운타임”에 할 일 목록을 준비한다 — 문서 정리, 수동 리팩터링, 코드 리뷰 등 AI 없이도 진행할 수 있는 작업을 항상 백로그에 둔다. 토큰이 막힌다고 하루를 날리는 건 전략 부재다.

결론: “덜 쓰자”가 아니라 “다르게 쓰자”

인지 부채 논쟁의 진짜 교훈은 “AI를 멀리하라”가 아니다. **“AI와의 관계를 의식적으로 설계하라”**이다.

Star Trek 비유를 빌리자면 — Ship’s Computer로만 쓰라는 조언도, Data처럼 전부 맡기라는 조언도 극단적이다. 현실적인 답은 이렇다:

AI는 내가 더 깊이 생각하기 위한 도구이지, 생각을 대신하는 도구가 아니다.

이 한 문장을 기준으로 삼으면, 무엇을 위임하고 무엇을 지킬지가 자연스럽게 결정된다.

변화하는 시대에 살아남는 개발자는 AI를 가장 많이 쓰는 사람도, 가장 적게 쓰는 사람도 아니다. 가장 의식적으로 쓰는 사람이다.

체크리스트: 내일부터 적용할 수 있는 것들

• 위임/직접 수행의 경계를 팀과 합의했는가?
• AI 생성 코드에 대한 리뷰 기준이 있는가?
• 토큰 비용을 추적하고 ROI를 측정하고 있는가?
• CLAUDE.md, 훅, MCP 연결을 주기적으로 감사하고 있는가?
• AI 없이도 핵심 업무를 수행할 수 있는 대안 경로가 있는가?
• 주기적으로 AI 없이 코딩하는 시간을 확보하고 있는가?
• “왜 이 코드인가”를 설명할 수 있는 상태로 머지하고 있는가?