[Wavbridge X AI] EP3. 컨텍스트 윈도우의 함정: AI 개발자가 알아야 할 3가지

편집자의 말: 2025년 말, 웨이브릿지 개발자들이 한 자리에 모였다. AI가 불러온 바람을 웨이브릿지 크루들 또한 함께 하기 위해, AI툴을 어떻게 하면 잘 활용할 수 있는지를 위한 세션이었다. 나(편집자: 레베카)는 비개발자이지만 매우 관심이 있는 영역이고, 우리 시대를 살아간다면 누구나 알아야 할 것들 아닌가. 그 자리에 함께 하며 들었던 내용을 2화에 걸쳐 나눠보고자 한다. 아래로 세미나 주요 내용을 전한다.

코딩을 넘어, 오케스트레이션으로

"이제는 코드 라이팅에 집중하지 마세요."

에릭(Head of AI)이 사내 개발팀에 던진 첫 마디는 다소 도발적이었다. 26년 경력의 개발자가 '코딩하지 말라'니. 

"쓰기는 툴이 할 겁니다. 우리는 잘 썼나를 볼 겁니다."

이 세션 전, 개발팀은 일주일간 AI 코딩 툴을 직접 사용해봤다. 불편사항 1번 목록은 ‘컨텍스트 유지가 어렵다’는 것이었다.

"일주일 동안 쓰시면서 저런 걸 스스로 느끼셔야 돼요. 안 그러면 제가 하는 말 중에 아주 중요한 얘기를 놓치실 수 있습니다. 부딪쳐봐야 자전거 운전할 수 있는 걸 배우겠죠."

웨이브릿지는 전사 차원의 AI 네이티브 전환을 진행하고 있다. 이 과정에서 에릭이 강조한 핵심은 일관되게 반복됐다. 개발자는 이제 코드를 '작성하는 Writer'가 아니라, AI의 작업을 '지휘하는 Conductor'가 되어야 한다는 것.

"여러분은 코딩하는 사람이 아니에요. 동작을 보장해주는 사람입니다."

AI는 왓슨이다: 똑똑하지만, 지시가 필요하다

"잘못된 질문이 잘못된 대답을 얻게 됩니다. 잘못된 프롬프트가 잘못된 결과를 만듭니다."

영화 '올드보이'의 명대사처럼, AI 시대에는 무엇을 물어야 하는지 아는 것이 핵심이다.

에릭은 AI를 셜록 홈즈 시리즈의 왓슨에 비유했다. 드라마 속 왓슨은 멍청한 조연처럼 나오지만, 원작 소설의 왓슨은 다르다. 의사이자 전직 군인으로, 홈즈의 추리를 돕는 똑똑한 파트너다. 하지만 홈즈의 명확한 지시와 방향이 없다면 그 능력을 제대로 발휘할 수 없다.

"AI도 마찬가지입니다. 지시한 것만 잘해요."

초기 바이브 코딩 때, 에릭 또한 AI를 주니어 혼내듯 짜증낸적이 많았다고 했다. 사실 문제는 AI가 아니었다. 컨텍스트를 제대로 주지 않았기 때문이었다.

LLM의 3가지 약점: 알아야 지배한다

AI를 효과적으로 활용하려면 그 한계를 명확히 이해해야 한다. 에릭이 짚어낸 LLM의 핵심 약점은 세 가지다.

1. 컨텍스트 윈도우의 함정

"LLM은 모든 게 다 텍스트예요. 텍스트를 한 번에 처리하고 끝이에요."

트랜스포머 구조의 LLM은 입력된 텍스트를 한 번에 처리한 후, 그 내용을 '기억'하지 못한다. 대화를 이어갈 수 있는 이유는 매번 전체 내용을 다시 입력하기 때문이다. (단, 2025년 1월 구글이 발표한 Titan 아키텍처는 다르다. 추론 중에도 학습이 가능해 "이제는 정말로 존댓말을 써야 할" 수준이라는 게 에릭의 평가다.)

문제는 여기서 시작된다. ChatGPT나 Claude 같은 AI 애플리케이션을 열면:

• 시스템 프롬프트가 먼저 들어간다
• MCP 툴 정의가 그 다음 들어간다 (각 툴의 기능 설명, 파라미터 정의 등)
• 그 후에야 유저의 프롬프트가 들어간다

"내가 쓰는 게 컨텍스트 윈도우를 다 점유하는 게 아니구나라는 걸 인식하셔야 돼요."

대화가 길어질수록 상황은 더 악화된다. 이전 메시지들이 차곡차곡 쌓이면서 컨텍스트 윈도우를 빠르게 소모한다. Claude는 일정 수준이 되면 자동으로 요약을 시작하는데, 이 과정에서 디지털 풍화 현상이 발생한다.

"100라인을 50라인으로 줄이는데, 큰 틀에서는 맞지만 디테일이 완전히 뭉개져 버립니다."

Claude Code의 thinking 과정을 열어보면 요약된 정보가 보인다. 요약이 2~3번 반복되면 AI는 길을 잃기 시작한다. 컨텍스트가 날아갔으니까.

Claude 하단에 표시되는 컨텍스트 윈도우 사용량 바를 보면서 약간 식은땀이 나기 시작해야 정상이다. 윈도우 사용량 바를 보면서, ‘와 이제 어떡하지?’ 생각이 들어야 해결책을 스스로 생각할 수 있다.

2. MCP(Model Context Protocol)는 USB처럼: ‘필요한 것만’ 꽂아라

MCP는 AI가 외부 기능을 사용할 수 있게 하는 프로토콜이다. USB 장치처럼 필요한 기능을 연결할 수 있어 강력하지만, 그만큼 조심해야 한다.

"MCP 서버를 연결하는 순간, 무슨 기능이 있고 그 기능을 사용하려면 어떤 파라미터가 필요한지 설명이 잔뜩 들어가요."

Serena 같은 MCP를 사용하면 약 30개의 툴 정의가 기본으로 컨텍스트 윈도우에 담긴다. 채팅을 한 번 열 때마다. 사용하지도 않는데 말이다.

"무작정 쓰다 보면 난장판이 되는 상황이 벌어져요. 컨텍스트 윈도우를 나는 쓰지도 않았는데 엄청나게 잠식을 한 상태에서 시작하게 돼요."

결과는? 대화를 몇 번 주고받으면 운신의 폭이 급격히 좁아진다. 마치 김밥 만드는 대나무 틀처럼 "꾹 누르면 길어지긴 하는데 얇아지는" 느낌이다.

"꼭 필요한 것만 한두 가지 정도만 활성화시켜 놓고 쓰세요. 소위 장비빨을 세우면 여러분이 할 수 있는 일이 늘어납니다."

3. Mean Reversion: AI는 '평균'을 선택한다

가장 교묘한 함정은 Mean Reversion(평균 회귀) 현상이다. 트레이더라면 익숙한 개념인데, 가격이 이동평균선으로 회귀하려는 경향을 뜻한다. 

"LLM도 똑같아요. 확률적으로 가장 대중적인, 많은 선택이 일어나는 선택을 하게 됩니다."

AI는 최선이나 최적이 아니라 대중적인 것을 선택한다.

실제 사례를 보자. 

멀티스레드 환경에서 성능 최적화가 필요한 상황이 있었는데, 에릭은 이 때 특정 시나리오에서는 lock-free 방식이 훨씬 효율적이라고 판단했었다. 헌데, AI는 lock 버전을 선택했다. 

왜 그랬을까?

Java의 ConcurrentQueue를 생각해보면 이해가 쉽다. 일반적인 교육 자료나 책에서는 데이터 오염을 방지하는 관점에서 lock을 사용하는 waiting 방식을 주로 설명한다. 비효율적이더라도 안전한 선택이기 때문이다. 하지만 AI는 "일반적"이라는 표면적 패턴을 따라 lock 버전을 선택한 것이다. 실제로는 특정 시나리오에서 lock-free 방식이 훨씬 효율적임에도 말이다.

"이런 갈림길에서 '아니야, 이쪽 방향으로 가야 돼'라고 알려주는 게 여러분의 역량입니다."

에릭은 기존에 만들어둔 최적화된 코드를 제시하며 방향을 수정했더니, AI는 특유의 "정말 좋군요!"라며 (약간의 아부와 함께) 올바른 방향으로 작업을 진행하더라는 것이다.

능력의 증폭, 책임의 변화

"AI가 만드는 게 불안하다고요? 라이브러리 코드는 다 뜯어보세요?"

에릭의 질문은 날카로웠다. 우리는 이미 수많은 라이브러리를 '믿고' 사용한다.

• JSON 파서를 직접 만들어 쓰는 사람이 있나?
• HTTP를 TCP로 직접 구현해본 사람이 있나?
• x86이나 ARM CPU에서 돌아가는 머신 코드를 직접 확인하는 사람이 있나?

"저는 15년 전에 어셈블리 쓰는 걸 마지막으로, 그 이후로 써본 적이 없어요. 그때는 C/C++ 개발에서 퍼포먼스를 위해 어셈블리가 필요한 경우가 있었죠."

심지어 공급망 공격 같은 사례도 있었지만, 우리는 '많은 사람이 검증했겠지'라는 믿음으로 군중 속에 숨는다. 이미 지정한 JSON 라이브러리가 있음에도 불구하고, 다른 라이브러리를 사용하는 샘플 코드를 그대로 가져오는 바람에, 결국 프로젝트 안에 JSON 라이브러리가 4~5개씩 쌓이는 상황을 용인하게 되기도 합니다.

"AI가 만든 건 불안한데, 왜 라이브러리는 괜찮나요?"

본질은 같다. 차이가 있다면, 이제는 내가 직접 검증자가 되어야 한다는 것.

"여러분은 동작을 보장해주는 사람입니다. 코딩하는 사람이 아니에요."

그리고 여기서 놀라운 일이 벌어진다. AI는 능력을 증폭시킨다. 1의 역량을 가진 사람이 AI로 100배를 얻으면 100이 되지만, 10의 역량을 가진 사람이 100배를 얻으면 1000이 된다.

그래서 개발자는 무엇을 해야 하나

"읽기 능력이 중요합니다."

에릭이 EP2. AI가 불러온 ‘평균의 종말’ 스타트업이 AI와 일하는 법에서 강조했던 메시지가 여기서 다시 등장한다. 코드를 작성하는 능력보다 코드를 이해하고 검증하는 능력이 핵심이 된다.

동시에 새로운 학습 방향이 필요하다.

"개발자라면 AI 애플리케이션을 개발해보셔야 합니다. 반드시."

AI API를 직접 다루면 자연스럽게 알게 된다:

• 처음 AI API 콜을 하려면 토크나이저부터 써야 한다
• 토크나이저를 쓰면서 토큰이 무엇인지 알게 된다
• 토큰을 다루다 보니 컨텍스트 윈도우의 중요성을 체감한다
• 벡터 DB를 사용하면서 벡터 핸들링을 익힌다

"저는 교육을 받아서 안 게 아니고, AI 애플리케이션 개발하다 보니 자연스럽게 알게 되는 내용들을 여러분께 공유하는 것 뿐이에요."

2019년 에릭이 웨이브릿지에 합류했을 때, 신입 개발자들에게 TCP로 HTTP를 구현하게 시켰다. 필요해서가 아니라 기본 원리를 알아야 하기 때문이었다. 유사하게, 지금 AI 시대의 기본 원리는 LLM 애플리케이션 개발에 있다.

Context가 곧 경쟁력이다

웨이브릿지의 AI 전환은 단순히 '도구를 바꾸는 것'이 아니다. 일하는 방식 자체를 재설계하는 작업이다.

"잘못된 질문이 잘못된 대답을 얻게 됩니다."

올드보이 영화의 명대사처럼, AI 시대에는 무엇을 물어야 하는지 아는 것이 핵심이다. 그리고 그 '질문의 품질'을 결정하는 것이 바로 **Context(맥락)**이다.

세션 말미, 에릭은 자신이 직접 개발한 2-File 시스템을 공개했다. 웨이브릿지 내부에서 이미 검증된 이 방법론은 "방법을 바꿈으로 인해서 이렇게 많은 거에 바뀌는 거구나"라는 감탄을 자아냈다.

"결국 프로세스예요. 어떤 프로세스로 어떻게 일을 시킬 것인가? 컨텍스트는 어떻게 줘서 일을 집중하게 할 것인가?"

다음 EP3-2에서는 에릭이 실전에서 검증한 Context Engineering 방법론의 구체적인 내용을 공개합니다. PRD-Tasks 2-File Symphony라는 이름의 이 프레임워크는, 컨텍스트 윈도우의 한계를 극복하고 AI와의 협업 효율을 극대화하는 실전 방법을 담고 있습니다.

"이 방법론 쓰면서 API 사용량 한도 다 찼다는 소리 한 번도 안 들었어요. 거의 서머라이즈가 안 일어나고, 심지어 스텝을 2~3개씩 붙여서 해도 문제가 없습니다."

다음 편 예고 EP3-2. 실전 Context Engineering: PRD-Tasks 2-File Symphony

• 마크다운(.md)이 새로운 표준인 이유
• PRD 중심 개발과 계층화된 Task 구조
• Execute-Review-Reset 루프와 실제 사례