AI는 내 질문에 어떻게 대답하는가? Context의 이해

개발자라면 누구나 한 번쯤 겪어봤을 상황이다.

Cursor나 Claude 같은 AI 툴과 함께 신나게 기능을 구현하던 중, 갑자기 AI가 방금 전까지 잘 알던 변수명을 까먹거나, 뜬금없이 레거시 코드를 부활시키고, 심지어는 전혀 상관없는 라이브러리를 가져와 코드를 엉망으로 만들어버리는 순간 말이다.

많은 개발자가 이를 두고 “AI가 멍청해졌다”라고 표현한다.

나 역시 그랬다.

하지만 며칠간 AI의 작동 원리를 파고든 끝에 내린 결론은 다르다.

AI는 멍청해진 게 아니다. 내가 멍청하게 질문했을 뿐. 정확히 말하면 ‘문맥(Context)’ 관리에 실패했기 때문이다.

1. AI는 ‘기억’이 없는 금붕어다

먼저 오해를 풀어야 할 것이 있다. LLM(거대언어모델)은 인간처럼 뇌 속에 지속적인 기억을 저장하지 않는다. AI는 근본적으로 ‘상태가 없는(Stateless)’ 존재다.

우리가 챗봇과 대화를 이어나갈 수 있는 이유는, AI가 기억력이 좋아서가 아니다.

시스템이 매번 질문을 던질 때마다 [지금까지의 대화 전체 + 시스템 설정 + 현재 질문]을 통째로 묶어서 다시 AI에게 주입하기 때문이다.

이 데이터 묶음이 바로 문맥(Context)이다.

실패의 원리: 컨텍스트 윈도우 (Context Window)

모든 LLM은 한 번에 처리할 수 있는 정보의 양(토큰 수)에 제한이 있다.

이를 ‘컨텍스트 윈도우’라고 한다. 대화가 길어져 이 윈도우가 꽉 차면?

AI는 새로운 정보를 받아들이기 위해 가장 오래된 정보부터 삭제한다.

마치 3초 기억력의 금붕어처럼 말이다.

• 증상: 프로젝트 초반에 설정해 둔 “A 라이브러리는 쓰지 마”라는 규칙이 대화 20번 만에 삭제된다. AI는 그 규칙이 존재했다는 사실조차 모른 채, 다시 A 라이브러리를 제안한다.

2. 내가 겪은 ‘Status Bar’ 대참사 (문맥 오염)

단순히 기억이 지워지는 것보다 더 큰 문제는 ‘문맥 오염(Context Pollution)‘이다.

최근 혼자 서비스를 개발하다 겪은 일이다. 모바일 뷰에서 상단 Status Bar와 콘텐츠가 겹치는 문제가 발생했다. SafeAreaView 설정이나 패딩 한 줄만 수정하면 되는 간단한 문제였다.

귀찮았던 나는 Cursor에게 @Codebase로 프로젝트 전체를 던져주고 “이거 겹치는 거 해결해줘”라고 했다. 그리고 AI가 뱉어낸 코드는 충격적이었다.

/* AI가 제안한 해결책 */
.header {
  position: absolute;
  top: 0;
  z-index: 9999;
  padding-top: calc(constant(safe-area-inset-top) + 20px);
  height: ...
  /* ...수십 줄의 불필요한 스타일 코드 */
}

AI는 문제의 핵심을 파악하지 못한 채, z-index를 9999로 올리고 position: absolute로 떡칠을 해놨다.

코드는 더러워졌고, 유지보수는 불가능해졌다.

원인은 ‘정보의 과잉’이었다. 프로젝트 전체 파일, 수천 줄의 코드가 문맥에 섞여 들어가니(Noise), AI는 정작 중요한 “이건 단순한 UI 수정이야”라는 의도를 파악하지 못하고 허둥지둥 가장 방어적인(하지만 멍청한) 코드를 짜낸 것이다.

3. AI의 금붕어화를 막는 ‘문맥 다이어트’ 전략

AI가 멍청해지는 것을 막으려면, 개발자가 능동적으로 문맥을 관리해야 한다. 핵심은 “AI에게 필요한 정보만, 가장 선명하게 제공하는 것”이다.

전략 1: 세션의 원자화 (Atomicity)

가장 강력하면서도 간과하기 쉬운 방법이다. 하나의 채팅 세션에서 모든 것을 해결하려 하지 마라.

• Action: 기능(Feature) 하나 구현이 끝나거나 버그 수정이 완료되면, 미련 없이 새로운 채팅(New Chat)을 열어라.
• Why: 이전 대화의 불필요한 노이즈와 실패했던 시도(Error Trials)들을 제거하여, AI의 컨텍스트 윈도우를 깨끗한 상태로(Clean Slate) 확보해야 한다.

전략 2: 명시적 큐레이션 (@Files over @Codebase)

AI에게 “알아서 찾아봐(@Codebase)“라고 하는 것은 게으른 짓이다. RAG(검색 증강 생성) 기술은 완벽하지 않다.

• Action: 전체를 훑게 하는 대신, 수정해야 할 파일과 참조해야 할 파일을 정확히 @File 태그로 지정하라.
• Why: AI가 봐야 할 정보의 범위를 물리적으로 제한함으로써, 엉뚱한 파일을 참조하거나 환각(Hallucination)을 일으킬 확률을 원천 차단한다.

전략 3: 불변의 규칙 심기 (.cursorrules)

대화가 길어져도 절대 잊지 말아야 할 규칙은 대화 로그가 아닌, 시스템 프롬프트 영역에 박아둬야 한다.

• Action: 프로젝트 루트에 .cursorrules 파일을 생성하고 기술 스택, 코딩 컨벤션, 금지 사항을 명시하라.
• Why: 이 파일의 내용은 대화의 길이와 상관없이 항상 ‘최우선 순위 지침’으로 AI에게 주입된다.

금붕어에게 ‘장기 기억’을 이식하는 셈이다.

전략 4: 생각의 사슬 (Chain of Thought) 유도

곧바로 코드를 뱉게 하지 말고, 먼저 계획을 말하게 하라.

• Action: “코드 짜줘” 대신 “이 문제를 해결하기 위한 단계별 계획을 먼저 말해줘”라고 요청하라.
• Why: 계획을 세우는 과정에서 AI는 스스로 문맥을 재정비하고 논리적 오류를 검증(Self-Correction)하게 된다.

맺음말: 코딩하는 조종사가 되어야 한다

생성형 AI 시대의 개발자는 더 이상 코드를 직접 타이핑하는 ‘타이피스트’가 아니다.

우리는 AI라는 고성능 엔진을 탑재한 비행기의 ‘조종사’다.

조종사가 계기판을 읽고 항로를 수정하듯, 개발자는 AI가 현재 어떤 문맥을 보고 있는지, 문맥이 오염되지는 않았는지 끊임없이 모니터링해야 한다.

AI가 엉뚱한 코드를 짠다면, 그것은 AI의 잘못이 아니라 불분명하고 오염된 문맥을 제공한 우리의 잘못일 가능성이 99%다.

깨끗한 문맥(Clean Context)이 깨끗한 코드(Clean Code)를 만든다.

이것이 AI 네이티브 개발자가 기억해야 할 제1원칙이다.