AI 에이전트의 기억상실증 - 매일 제로에서 시작하는 개발의 문제점

해당 블로그는 Harjot Gill의 원저자의 글 'Your AI agent has amnesia'을 번역한 것입니다. 더 나은 이해를 위해서 약간의 의역이 반영되었습니다.

CodeRabbit 유저 그룹 카카오톡 오픈채팅방이 있습니다. 관심 있으신분들은 오셔서 함께 소통하면 좋을 것 같습니다.

소프트웨어 개발의 오래된 문제가 다시 고개를 들고 있습니다. 바로 팀원 간 소통 부족과 맥락 손실 문제입니다. 하지만 이번에는 AI 코딩 에이전트가 이 문제를 더욱 심화시키고 있습니다.

"일정 파탄과 시스템 버그가 발생하는 이유는 왼손이 하는 일을 오른손이 모르기 때문이다" — Fred Brooks, The Mythical Man-Month, IBM OS/360 프로젝트의 협업 실패를 설명하며

대규모 프로그래밍 프로젝트에서 소통 문제와 그 결과를 논의하는 텍스트

The Mythical Man-Month는 여전히 엔지니어링 관리 분야에서 가장 인기 있는 책 중 하나이자, 리더들의 서가에서 빠지지 않는 필독서입니다.

50년간의 SDLC 진화는 바로 그 실패 모드에 대한 긴 반론이었습니다. 애자일로 개발자와 제품팀이 한자리에 모였고, DevOps로 개발과 운영 간 장벽이 사라졌습니다. Git과 Pull Request로 팀은 무엇이 왜 변경되었는지 추적할 수 있게 되었고, CI로 빌드가 공동 책임이 되었죠. 플랫폼 팀은 부족 지식(tribal knowledge)을 신규 입사자마다 다시 학습할 필요 없도록 표준화된 길을 닦았습니다. 모든 주요 변화는 개인의 영웅주의 보다 공유된 이해 에 건 베팅이었습니다.

그런데 코딩 에이전트의 등장으로 우리는 다시 과거로 돌아가고 있습니다.

모든 엔지니어가 이제 개인 머신에서, 아무도 볼 수 없는 세션에서 사적인 에이전트를 실행합니다. 에이전트는 매일 아침 아무것도 모르는 상태에서 시작합니다. 어제 조립한 추론 과정, 검토한 대안들, 로드한 컨텍스트, 스탠드업에서 내린 결정들 — 모두 사라진 채. 프로세스가 무너지기 시작하면서도 "그 어느 때보다 빠르게 배포하고 있다!"라는 착각만 남습니다.

AI의 영향을 받은 개발자 지표들의 상대적 변화율을 보여주는 막대 차트

Brooks가 몇 주에 걸쳐 설명한 팀원 간 격차 문제를 우리는 하루 만에 겪고 있으면서, 그걸 높은 생산성이라고 부르고 있습니다. 신입 개발자라도 최소한 어제 배운 것은 기억하는데 말입니다.

컨텍스트 비용(Context Tax)

최근 한 시니어 엔지니어를 관찰해본 결과가 충격적이었습니다. 코딩 에이전트가 코드 한 줄을 작성하기 전에 무려 11분간 컨텍스트를 설정해야 했던 것입니다. 아키텍처 설명부터 시작해서 Postgres 선택 이유, 파일 세 개, Linear 티켓, 심지어 서비스 중단 예정에 대한 테크 리드의 Slack 메시지까지 붙여넣었죠.

개발자가 다양한 도구에서 정보를 수집해 에이전트가 코드를 생성하는 워크플로우를 보여주는 다이어그램

에이전트는 꽤 괜찮은 코드를 만들어냈습니다.

하지만 그 시니어 엔지니어가 나중에 한 말이 인상적이었습니다. 다음 날 아침이면 새 세션을 열고, 다른 컨텍스트를 위해 이 모든 과정을 처음부터 다시 해야 할 거라고요. 에이전트에게는 팀 수준의 통찰이 없으니까요.

이것이 2026년 AI 지원 개발의 현실입니다.

잘못 짚고 있는 문제

아무도 에이전트가 작업을 시작하기 전에 무엇을 알고 있는지에 대해 이야기하지 않습니다.

문제를 올바르게 프레이밍하면 평범한 사고력도 탁월한 수준으로 끌어올릴 수 있습니다. 적어도 인간에게는요. AI 에이전트에게 이 격차는 더 큽니다. 같은 모델에 같은 프롬프트를 주더라도, 자신이 작업하는 시스템을 이해하느냐 못 하느냐에 따라 완전히 다른 코드를 생성합니다.

에이전트에게 컨텍스트 없이 코드베이스만 주면, 그럴듯해 보이지만 팀이 2년간 쌓아온 모든 컨벤션을 무시하는 코드가 나옵니다. 같은 에이전트에게 코드베이스와 함께 아키텍처 결정, 티켓 히스토리, 온콜 런북, 그리고 팀이 기존 인증 서비스를 폐기하기로 한 Slack 스레드까지 주면, 팀원이 작성한 것 같은 코드가 나옵니다.

지금 현실은 개발자들이 매 세션마다 수동으로 그 컨텍스트를 조립하고 있다는 것입니다. 이미 알고 있어야 할 도구를 위해 자기 조직과 도구 사이의 통역사 역할을 하면서요.

다섯 가지 기억상실증

컨텍스트 문제가 가장 눈에 띄는 증상이지만, 질병은 더 체계적입니다. 현세대 에이전트가 잊어버리는 것은 최소 다섯 가지입니다.

시스템 지식의 손실

모든 새로운 세션은 시스템과 선택에 대한 컨텍스트 없이 시작됩니다. 에이전트는 파일을 열어도 팀이 큐잉에 Redis 대신 Postgres를 선택한 이유, 어떤 인증 서비스가 곧 중단되는지, 지난 분기에 에러를 언래핑하지 않고 전파하기로 결정한 배경을 전혀 모릅니다. 하지만 그 컨텍스트는 아무도 읽지 않는 PRD, 3월의 Slack 스레드, 시니어 엔지니어의 머릿속 어딘가에 있습니다. 개발자가 매일 아침 가장 먼저 하는 일은 그걸 찾아서 프롬프트로 번역하는 것입니다.

다시 말하지만, 개발자는 회사 어딘가에 이미 존재하는 정보를 재구성해서 개인 세션에 한정된 컨텍스트 윈도우에 넣고 있습니다.

자신의 과거 작업

어제 가르쳐준 에이전트와 오늘 쓰는 에이전트는 다른 존재입니다. 어제 청구 모듈을 함께 살펴봤죠. 겉보기에 잘못돼 보이지만 실제로는 올바른 재시도 로직, Stripe 웹훅의 멱등성 키를 신뢰할 수 없는 이유, 지난여름 실패한 리팩토링이 경고로서 git 히스토리에 남아있는 것까지. 에이전트는 좋은 코드를 만들어냈습니다.

탭을 닫았습니다. 남은 것은 커밋뿐이고, 그 코드가 나오게 된 추론 과정(정작 남겨두고 싶은 부분)은 세션과 함께 증발했습니다. 다음 주에 같은 파일을 열면, 처음부터 다시 해야 합니다.

참고: 네, agents.md나 다른 영구 지식 저장소에 저장하고 공유하고 있을 수 있습니다. 하지만 그게 팀의 일상 업무에 필수적인 컨텍스트를 지속적으로 수집하고, 팀이 쉽게 유지보수할 수 있을 만큼 충분히 업데이트되고 있나요?

팀원 간 격리

코딩 에이전트는 1인용 게임입니다. 한 명의 개발자, 한 개의 세션, 한 대의 머신. 작업 과정이 팀의 다른 누구에게도 보이지 않습니다. 인계가 필요할 때도 받는 사람은 제로에서 시작해야 합니다 — 넘겨줄 것 자체가 없으니까요.

개발을 협업으로 만들기 위해 10년을 투자했습니다: Git, Pull Request, 공유 CI, 누구나 열어볼 수 있는 대시보드. 그런데 AI 개발 도구로 다시 사일로를 만들어버렸습니다!

그 다음에 일어나는 일

에이전트가 코드를 작성하고 PR을 만들어 코드 리뷰를 통과합니다. 다음 스프린트에서 누군가 그 코드의 절반을 다시 작성하고, 한 달 후에는 프로덕션에서 간헐적으로 장애를 일으키는 버그가 발견됩니다. 엔지니어들이 Slack이나 GitHub에서 협업하며 회귀 버그를 수정합니다.

에이전트는 이 모든 결정에서 완전히 배제되어 있습니다.

엔지니어는 코드를 배포하고, 리뷰받고, 깨지고, 고치면서 성장합니다. 각 단계에서 팀과 개인의 집단적 학습이 있죠. 에이전트를 이 루프에서 제외하면, "그럴듯한" 코드를 무한정 생성하지만 어떤 형태의 "그럴듯함"이 실제 프로덕션에서 살아남는지는 절대 배우지 못하는 에이전트만 남게 됩니다.

누군가는 지켜봐야 한다

모든 개발자가 CLI든 IDE든 새로운 형태(ADE?!)든 로컬 AI 코딩 에이전트를 사용하는 흐름을 막을 수는 없습니다. 하지만 엔지니어링 조직 차원에서 에이전트들이 팀 전체에 걸쳐 어떻게 수행되고 있는지에 대한 공유된 관점이 없습니다. 어떤 시스템을 건드리고 있는지, 비용은 얼마나 쓰고 있는지도 모릅니다.

경제적 문제는 곧 피할 수 없게 될 것입니다. Uber CTO는 올해 The Information에서 자신의 팀이 이미 2026년 AI 코딩 예산 전부를 소진했다고 밝혔습니다.

에이전트 기억상실증은 본질적으로 경제학 문제가 되어가고 있습니다. 엔지니어당 토큰 비용이 매일 복리로 불어나는 문제는 엔지니어링 팀이 해결하기 어렵습니다. 여기까지 온 생산성 향상을 포기할 수 없기 때문입니다.

터미널 코딩 에이전트는 잘 되는데?

네. 개인적으로는요. 여러분의 머신에서는요.

터미널 에이전트가 작동하지 않는다는 주장이 아닙니다. 분명히 작동합니다. Claude Code, Codex 같은 도구들은 훌륭합니다. 우리가 이들을 대체하려는 것도 아닙니다.

사실 이 도구들의 Steering Control, 서브에이전트 프레임워크, Hooks, 플러그인 같은 기능들은 개발자에게 매우 유용해서, 이전보다 더 많은 코드를 생산하게 도와줍니다.

분명히 해두자면, 이 도구들에도 메모리 기능이 있습니다. Claude Code는 프로젝트 수준의 CLAUDE.md, 사용자 수준의 파일, 그리고 세션 간 유지되는 로컬 메모리 디렉토리를 읽습니다.

문제는 지속 가능한 팀 지식이 로컬 에이전틱 코딩 세션에서 유실된다는 것입니다. 시니어 엔지니어가 청구 모듈에 대해 어렵게 얻은 이해는 그녀의 마크다운 파일에, 그녀의 노트북에만 있습니다. 다른 지역의 동료가 첫 세션을 열면, 그 지식은 전혀 전달되거나 유지되지 않습니다.

에이전트가 되어야 할 모습

Edsger W. Dijkstra는 유능한 프로그래머는 자기 두개골의 크기가 엄격히 제한되어 있음을 충분히 인식한다고 썼습니다. 에이전트에게는 두개골이 없습니다. 잊을 필요가 없죠. 우리가 에이전트를 일시적인 터미널 세션으로 모델링했기 때문에 기억상실증이 생긴 것입니다. 팀이 실제로 일하는 지속적인 환경 대신에요.

기억상실증을 당연한 것으로 받아들이기를 멈추면, 다음 세대는 이런 모습이어야 합니다:

지식은 복리로 쌓여야 합니다. 한 개발자의 머신에 남아있는 컨텍스트 파일 대신, 모든 코드 리뷰, 해결된 티켓, 아키텍처 논의가 에이전트를 다음 달에 오늘보다 더 유용하게 만드는 레이어에 반영되어야 합니다. 팀, 프로젝트, 도메인 단위로 범위가 지정된 공유 지식 레이어입니다. 새 엔지니어가 합류하면 에이전트가 이미 몇몇 시니어 엔지니어의 머릿속에만 있던 제도적 기억을 갖고 있어야 합니다.

작업은 유지되고 이어질 수 있어야 합니다. Slack 스레드에서 시작한 작업을 중단하고 팀원에게 넘기세요. 이틀 후에 돌아와도 작업이 그대로 남아있어야 합니다. 보이고, 댓글 달 수 있고, 적절한 접근 권한을 가진 누구든 이어받을 수 있어야 합니다. 한 개발자의 노트북 브라우저 탭에 갇혀있지 않고요.

에이전트는 프로덕션 접근 권한을 가진 다른 시스템처럼 관리되어야 합니다. 오늘날 대부분의 코딩 에이전트는 시트당 가격에 사용자 단위로 범위가 지정됩니다. 비용은 개발자들이 우연히 소모하는 양이 전부입니다. 접근 제어는 도구의 기본값(보통 "모든 것")이고, 에이전트가 조직 전체에서 실제로 무엇을 하고 있는지에 대한 가시성은 사실상 제로입니다. 모든 엔지니어에게 프로덕션 root 접근 권한을 주지는 않을 겁니다. AI 에이전트에게 조직 전체 컨텍스트에 대한 무제한 접근 권한을 줄 이유도 없습니다.

컨텍스트는 수동으로 붙여넣는 게 아니라 자동으로 수집되어야 합니다. 에이전트가 코드베이스, 티켓, 문서, 관측 스택, 클라우드 인프라, 그리고 팀이 오랜 시간 쌓아온 지식에서 자동으로 가져와야 합니다. 개발자의 역할은 에이전트를 지시하는 것이지, 에이전트의 리서치 어시스턴트가 되는 것이 아닙니다.

코딩 에이전트에 대한 가장 큰 불만은 일회용 코드를 생성한다는 것입니다. 실제로 merge할 수 있기까지 너무 많은 재작업과 반복이 필요하죠. 하지만 첫 시도에서 더 나은 컨텍스트를 제공하면, 첫 시도에서 더 나은 코드가 나옵니다.

이 모든 것이 향하는 곳

오늘 CodeRabbit Agent for Slack을 소개합니다.

핵심 루프부터 시작합니다: 기획, 코드 생성, 리뷰, 조사, 그리고 지식 기반 개발. 전체 소프트웨어 개발 생명주기를 위한 하나의 에이전트입니다. 모든 것이 Slack 안에서, 실시간으로, 안전장치를 갖추고 진행됩니다.

하지만 비전은 Slack 안의 코딩 에이전트보다 더 큽니다.

우리가 만들어가고 있는 것은 전체 SDLC에 걸친 에이전틱 레이어입니다. 시스템을 이해하고, 도구를 연결하고, 팀의 지식을 유지하며, 엔지니어링 워크플로우를 끝에서 끝까지 실행하는 레이어입니다.

배포 후 회귀 분류(regression triage)에서 Datadog 스파이크를 특정 커밋과 연관 지어 수정안을 작성합니다. 누군가 수동으로 컨텍스트를 조립할 필요 없이요.
브레이킹 체인지 감지가 merge 전에 여러 레포에 걸친 하위 consumer를 추적합니다.
고객 버그 조사가 지원 티켓에서 시작해 에러 로그를 확인하고, 근본 원인을 찾아 팀에 예비 분석을 게시합니다.
스프린트 요약이 Linear, GitHub, Datadog, PostHog에서 정보를 가져옵니다.

우리는 에이전트가 도달할 수 있는 컨텍스트와 실행할 수 있는 액션만큼만 유용하다고 믿습니다.

최종 목표는 스택을 연결하고, 팀이 이미 일하고 있는 곳에서 프로그래밍 가능하게 만드는 레이어입니다.

우리의 베팅

AI를 도입한 모든 팀에서 개인 생산성은 향상되었습니다. 하지만 팀 수준의 생산성은 여전히 정체되어 있으며, 그 이유는 모델 품질과 전혀 관계가 없습니다: 에이전트가 실제로 무엇을 했는지에 대한 설명 가능한 기록이 없고, 비용 배분이 팀 구조와 맞지 않으며, 에이전트가 실제 엔지니어링이 일어나는 곳에 없습니다. 이 세 가지를 해결하면, 팀 생산성이 개인 생산성처럼 복리로 증가하기 시작합니다.

승리할 에이전트는 최고의 모델을 가진 것이 아닙니다. 열었을 때 이미 여러분의 시스템을 알고 있는 에이전트입니다 — 컨벤션, 중단 예정 기능, 문서에 남지 않은 결정들까지 파악하고 있는 에이전트. 이것이 지속 가능한 팀 지식이고, 오늘 출시되는 모든 도구에서 빠져 있는 것입니다.

이 도구가 개발자를 대체한다는 이야기는 하지 않겠습니다. 프로덕션 코드를 배포해본 사람이라면, 엔지니어링의 어려운 부분이 타이핑이 아니라는 걸 압니다. 판단력입니다. 시스템을 이해하는 것입니다. 무엇을 만들고 무엇을 만들지 않을지 아는 것입니다.

CodeRabbit에서 우리가 수년간 걸어온 길이 바로 이것입니다. 주당 200만 건의 코드 리뷰를 처리하는 독자적인 컨텍스트 엔진은 훌륭한 엔지니어링 팀이 실제로 무엇을 하는지를 체계화한 결과입니다. CodeRabbit Agent는 그 엔진을 Slack으로 확장하며, 팀의 결정과 패턴을 위에 얹습니다. 작업이 공개적으로 진행되어 팀원들이 보고, 참여하고, 다른 사람이 멈춘 곳에서 이어받을 수 있습니다. 컨텍스트는 세션이 끝나도 사라지지 않고 복리로 축적됩니다.

에이전트 기억상실증을 해결하는 자가 승리합니다. 기억을 잃는 에이전트로 더 빠르게 만들기만 하는 것은, 잘못된 것을 더 빠르게 만드는 것일 뿐입니다.

출처:

그림 1: Becker, J., Rush, N., Barnes, E., & Rein, D. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, July 10, 2025; Xu, F., Medappa, P. K., Tunc, M. M., Vroegindeweij, M., & Fransoo, J. C. AI-assisted Programming May Decrease the Productivity of Experienced Developers by Increasing Maintenance Burden. arXiv:2510.10165, 2025.