'컨텍스트 인식(Context-Aware)'이라는 말이 AI 개발 도구 마케팅 어디에나 등장하는 요즘, 정작 그 말이 무엇을 뜻하는지 제대로 정의된 곳은 드물다. Cursor, GitHub Copilot, Claude Code—우리가 매일 쓰는 도구들이 정말로 우리 코드를 '이해'하고 있을까? 아니면 diff를 읽고 패턴을 매칭하는 정교한 자동완성에 불과할까?
diff는 시작점일 뿐이다
dev.to에 올라온 「What "Context-Aware Code Review" Actually Means」는 이 질문을 정면으로 다룬다. 대부분의 AI 코드 리뷰 도구는 풀 리퀘스트 diff에서 출발한다. 변경된 파일, 추가·삭제된 코드, 테스트 업데이트 여부—이 정보만으로도 상당수 리뷰는 충분히 처리된다. 타입 오류, 간단한 버그, 스타일 위반 같은 것들은 diff 안에 이미 답이 있기 때문이다.
문제는 변경이 수정된 파일 바깥의 동작에 영향을 줄 때 시작된다. 예를 들어 updatePaymentStatus(paymentId, status) 한 줄이 diff에 등장했다고 하자. 코드는 컴파일되고, 테스트는 통과하고, 표면적으로는 아무 이상이 없다. 하지만 이 서비스가 상태 변경 시 이벤트를 발행해야 하고, 감사 로그가 컴플라이언스 요건이며, 다른 서비스가 특정 사이드 이펙트에 의존하고 있다면? 그 정보는 diff 어디에도 없다.
'컨텍스트'는 단층이 아니다
이 글이 제시하는 분류가 유용하다. 컨텍스트는 적어도 네 층위로 나뉜다.
- 레포지토리 컨텍스트: 변경된 파일 주변의 관련 서비스, 공유 유틸리티, 유사 패턴
- 히스토리 컨텍스트: 이전 PR의 리뷰 코멘트, 팀 컨벤션, 과거 프로덕션 이슈로 굳어진 패턴
- 의존성 컨텍스트: 공유 라이브러리, 다운스트림 시스템, 외부 API
- 아키텍처 컨텍스트: 명시적으로 코드화되지 않은 설계 규칙—어떤 서비스가 어떤 도메인에 직접 접근하면 안 되는지, 어떤 워크플로우에서 이벤트가 반드시 필요한지
이 중 마지막이 가장 다루기 어렵다. 아키텍처 규칙은 파일에 쓰여 있지 않고, 팀의 암묵지에 살아 있기 때문이다. 그걸 AI가 추론해낼 수 있는지가 진짜 의미의 '컨텍스트 인식'을 판가름한다.
컨텍스트 인식 도구를 구별하는 실용적 기준
마케팅 문구 대신 실제 피드백 품질로 판단하는 방법이 있다. 좋은 리뷰 코멘트는 왜 그 문제가 중요한지를 설명한다. "이 구현을 수정하는 것을 고려하세요"는 피드백이 아니다. "유사한 업데이트 흐름은 상태 변경 후 이벤트를 발행합니다. 이 구현은 그렇지 않아 다운스트림 동작이 불일치할 수 있습니다"가 진짜 피드백이다. 수정된 코드 바깥을 참조하고, 팀 컨벤션을 반영하는 코멘트가 나온다면, 그 도구는 적어도 레포지토리와 히스토리 컨텍스트를 활용하고 있다는 신호다.
AI가 생성한 코드가 많아질수록 컨텍스트 인식의 무게는 커진다
AI 코딩 어시스턴트가 코드 생성 속도를 끌어올릴수록, 리뷰어의 부담도 함께 증가한다. 리뷰어는 이제 단순히 코드 품질을 확인하는 것이 아니라, AI가 생성한 코드가 기존 시스템·패턴·아키텍처 결정과 어떻게 맞물리는지를 판단해야 한다. 이건 diff를 빠르게 읽는 능력이 아니라 시스템 전체를 머릿속에 담아두는 능력이다. 코드베이스가 커질수록 그 부담은 선형이 아니라 기하급수적으로 늘어난다.
컨텍스트 인식의 실패는 조용히 쌓인다
흥미롭게도 같은 날 dev.to에는 이 문제의 다른 단면을 보여주는 글이 등장했다. 「My Publish Script Truncates Tags to 4. My MCP Tool That Does the Same Job Never Learned That Rule.」은 작지만 날카로운 사례다. 동일한 기능을 수행하는 두 코드 경로—배치 스크립트와 MCP 도구—가 같은 레포지토리 안에서 서로 다른 규칙을 조용히 적용하고 있었다. DEV.to가 태그를 4개까지만 허용한다는 제약은 publish_devto.py에는 [:4] 슬라이스로 인코딩되어 있었지만, 나중에 추가된 MCP 서버의 create_article에는 없었다.
이 버그의 본질은 같은 비즈니스 규칙이 두 곳에 따로 존재하고, 한쪽은 그 규칙을 배웠으나 다른 쪽은 배우지 못한 것이다. AI 도구도 마찬가지다. 컨텍스트 인식이 없는 도구는 코드를 작성할 때 레포지토리에 이미 인코딩된 암묵적 규칙을 발견하지 못하고, 같은 실수를 반복하거나 기존 패턴을 우회하는 코드를 생성한다.
파이프라인을 안정적으로 만드는 것: 컨텍스트의 다른 이름
「I Built a State Machine for My AI Agent's Publishing Pipeline」은 또 다른 각도를 제시한다. 이 글의 저자는 AI 에이전트가 파이프라인 중간에 크래시했을 때 "지금 어떤 단계에 있었는지"를 전혀 알 수 없는 문제에 부딪혔다. 매 실행이 blank slate였고, 그래서 중복 드래프트와 고아 파일이 쌓였다.
해결책은 상태를 디스크에 먼저 쓰고 핸들러를 실행하는 상태 머신 패턴이었다. 각 페이즈는 단일 책임을 가지고, 실행 전·후에 상태가 기록되며, 크래시 후 재시작하면 매니페스트 파일을 읽어 정확히 중단된 지점부터 재개한다. 각 페이즈 핸들러는 멱등성을 보장해 같은 작업을 두 번 수행하지 않는다.
이 패턴이 흥미로운 이유는 단순한 에러 핸들링이 아니기 때문이다. 이건 파이프라인이 자신의 컨텍스트를 명시적으로 유지하는 설계다. AI 에이전트가 외부 컨텍스트를 알아서 파악해주기를 기다리는 대신, 컨텍스트를 구조화된 상태로 직접 관리하는 것이다.
시사점: 컨텍스트는 도구가 가져다주는 것이 아니다
세 글감이 수렴하는 지점이 있다. AI 도구의 컨텍스트 인식은 연속 스펙트럼이고, 그 어떤 도구도 아직 아키텍처 컨텍스트를 완전히 해석하지 못한다. 그렇다면 우리가 해야 할 일은 두 가지다.
첫째, 도구를 평가할 때 마케팅 문구 대신 피드백의 구체성을 보라. 변경된 파일 밖을 참조하는가, 팀 컨벤션을 반영하는가, 아키텍처 위반을 감지하는가. 이것이 컨텍스트 인식의 실체다.
둘째, AI가 알 수 없는 컨텍스트는 설계로 명시화하라. 암묵지는 규칙 파일로, 파이프라인 상태는 매니페스트로, 공유 비즈니스 제약은 공통 헬퍼로. AI가 레포지토리를 '이해'하려면 이해할 수 있는 형태로 정보가 존재해야 한다. [:4]가 왜 거기 있는지를 주석 한 줄이라도 설명해두지 않으면, 나중에 추가되는 어떤 코드 경로도—사람이 짜든 AI가 짜든—그 규칙을 배우지 못한다.
전망: 이해와 생성 사이의 간극
지금 AI 코딩 도구가 가장 잘하는 것은 국소적 패턴 생성이다. 컨텍스트 창 안에 들어온 코드를 기반으로 그럴듯한 다음 코드를 만들어내는 것. 반면 가장 못하는 것은 시스템 전체의 불변 조건을 추론하는 것이다. 이 간극은 도구가 발전할수록 좁아지겠지만, 완전히 사라지지는 않을 것이다.
결국 진짜 컨텍스트 인식은 도구에 맡길 수 있는 것과 팀이 명시적으로 설계해야 하는 것을 구분하는 데서 시작한다. 'AI가 코드를 이해한다'는 말을 너무 빨리 믿는 팀은, 조용히 쌓이는 컨텍스트 드리프트를 프로덕션에서 발견하게 된다. 그리고 그건 항상 가장 나쁜 타이밍에 터진다.