당신의 AI 코딩 에이전트에게는 흉터 조직(Scar Tissue)이 필요합니다
요약
AI 코딩 에이전트가 과거의 실수를 반복하지 않도록 '흉터 조직(Scar Tissue)'과 같은 내구성 있는 기억 체계가 필요함을 강조합니다. 단순히 컨텍스트 윈도우를 늘리는 것이 아니라, 실패의 원인과 방지책을 구조화된 지식으로 저장하는 것이 핵심입니다.
핵심 포인트
- 에이전트의 반복되는 실수는 단순한 오류가 아닌 비용 문제임
- 흉터 조직은 단순 문서화가 아닌 '기억된 실패'를 의미함
- 컨텍스트 확장만으로는 에이전트의 판단력을 높일 수 없음
- 실패 사례를 내구성 있는 지식으로 변환하여 저장해야 함
가장 비용이 많이 드는 AI의 실수는 코딩 에이전트가 무언가를 틀렸을 때가 아닙니다.
그것은 에이전트가 내일 똑같은 실수를 다시 반복할 때입니다. 바로 그 지점이 당신을 지치게 만들기 시작합니다. 모델이 한 번 실패했기 때문이 아닙니다.
그런 일은 일어날 수 있습니다.
정말 좌절스러운 부분은 당신이 이미 그것을 수정해 주었을 때입니다.
당신은 레포지토리 패턴 (repo pattern)을 설명했습니다.
당신은 왜 그 마이그레이션 (migration)이 실패했는지 알려주었습니다.
당신은 이상한 CI 이슈를 지적했습니다.
당신은 이미 실패했던 의존성 (dependency)을 보여주었습니다.
에이전트는 작업을 수정했습니다.
세션이 종료되었습니다.
그러고 나서 이틀 뒤, 새로운 세션은 마치 아무 일도 없었던 것처럼 똑같은 나쁜 아이디어를 제안합니다.
이것이 제가 최근에 고민해 온 문제입니다. AI 코딩 에이전트에게는 단순히 더 큰 컨텍스트 윈도우 (context windows)만 필요한 것이 아닙니다.
그들에게는 흉터 조직 (scar tissue)이 필요합니다.
[
흉터 조직 (scar tissue)이란 의미하는 것
흉터 조직은 기억된 실패입니다.
그것은 일반적인 문서화 (documentation)가 아닙니다.
그것은 방대한 채팅 트랜스크립트 (chat transcript)도 아닙니다.
관련이 있든 없든 모든 프롬프트 (prompt)에 억지로 집어넣는 또 다른 비대한 AGENTS.md 파일도 아닙니다.
흉터 조직은 무엇이 잘못되었는지, 왜 잘못되었는지, 그리고 무엇을 반복해서는 안 되는지에 대한 내구성이 있는 기억입니다.
[
예시:
이 레포지토리에서는 이 마이그레이션 (migration) 패턴을 사용하지 마세요.
로컬에서는 통과하지만 X 때문에 스테이징 (staging) 환경에서 깨집니다.
...
그러한 종류의 지식은 믿을 수 없을 정도로 가치 있습니다.
하지만 대부분의 경우, 그것은 사라져 버립니다.
누군가의 머릿속에 머물러 있습니다.
혹은 Slack에 묻혀 있습니다.
혹은 어제의 AI 세션에 갇혀 있습니다.
혹은 아무도 다시 읽지 않을 풀 리퀘스트 (pull request) 코멘트 어딘가에 숨겨져 있습니다.
컨텍스트 (Context)는 학습 (learning)과 같지 않습니다
많은 AI 코딩 워크플로우 (workflows)가 여전히 컨텍스트 (context)를 모든 문제의 해결책처럼 취급합니다.
더 많은 파일을 추가하세요.
더 많은 지침 (instructions)을 추가하세요.
더 많은 문서 (docs)를 추가하세요.
더 많은 예시 (examples)를 추가하세요.
더 많은 프로젝트 히스토리 (project history)를 추가하세요.
결국 프롬프트 (prompt)는 잡동사니 서랍이 되어버립니다. 에이전트 (agent)는 더 많은 텍스트를 갖게 되지만, 반드시 더 나은 판단력을 갖게 되는 것은 아닙니다. 제가 주목하는 차이점이 바로 이것입니다. 컨텍스트 (context)는 에이전트에게 무엇이 근처에 있는지를 알려줍니다. 흉터 조직 (scar tissue)은 에이전트에게 무엇을 고통스럽게 배웠는지를 알려줍니다.
이 둘은 같은 것이 아닙니다.
기존 패턴 (The old pattern)
많은 AI 코딩 세션 (sessions)은 다음과 같은 모습입니다:
세션 1:
에이전트 (Agent)가 잘못된 접근 방식을 제안합니다.
개발자가 이를 수정합니다.
...
모델 (model)이 기술적으로 "잊어버린" 것은 아닙니다.
애초에 지속 가능한 메모리 (durable memory)가 없었을 뿐입니다. 단지 일시적인 작업 공간 (temporary working space)만 있었을 뿐입니다. 세션이 종료되면 그 교훈은 사라집니다.
더 나은 패턴 (The better pattern)
대신 제가 원하는 패턴은 다음과 같습니다:
세션 1:
에이전트 (Agent)가 잘못된 접근 방식을 제안합니다.
개발자가 이를 수정합니다.
...
이것은 다른 종류의 AI 코딩 워크플로우 (workflow)입니다.
단순히 더 빠른 것이 아닙니다.
단순히 더 저렴한 것이 아닙니다.
단순히 토큰 (tokens)이 적게 드는 것도 아닙니다.
더 숙련된 것입니다.
에이전트가 발전할수록 이것이 더 중요한 이유
코딩 에이전트 (coding agents)가 더 똑똑해질수록, 이 문제는 더욱 중요해집니다. 에이전트가 아주 작은 코드 조각 (snippets)만 작성할 때는 잊어버리는 것이 짜증 나는 정도였습니다. 하지만 이제 에이전트는 실제 아키텍처 (architecture)를 다룰 수 있습니다.
파일 리팩터링 (refactor)을 할 수 있습니다.
마이그레이션 (migrations)을 생성할 수 있습니다.
테스트 (tests)를 작성할 수 있습니다.
프로덕션 인접 코드 (production-adjacent code)를 수정할 수 있습니다.
이로 인해 반복되는 실수의 비용이 더 커집니다.
AI 에이전트 (AI agent)가 실제 코드베이스 (codebase) 내부에서 작동하려면, 지침 (instructions) 이상의 것이 필요합니다.
결과에 대한 기억이 필요합니다. 고통스러웠던 것들을 기억해야 합니다.
Empirical이 적합한 위치
이것이 제가 Empirical을 통해 탐구하고 있는 유스케이스 (use cases) 중 하나입니다.
Empirical은 AI 도구들을 위한 메모리 레이어 (memory layer)입니다.
모든 교훈, 결정, 선호도, 경고를 거대한 프롬프트 (prompt)에 쑤셔 넣는 대신, Empirical은 에이전트가 필요할 때 필요한 특정 메모리 (memory)를 검색할 수 있게 해줍니다.
코딩 에이전트 (coding agents)의 경우, 이는 메모리 레이어 (memory layer)가 다음과 같은 것들을 보유할 수 있음을 의미합니다:
프로젝트 결정 사항 (Project decisions)
저장소 컨벤션 (Repo conventions)
실패한 접근 방식 (Failed approaches)
...
이것들은 보통 세션 (sessions) 사이에서 유실되는 것들입니다.
또한, 이는 시간이 지남에 따라 개발자를 더욱 유능하게 만드는 요소이기도 합니다.
AI 코딩 에이전트라고 해서 무엇이 달라야 할까요?
미래는 단순히 더 똑똑한 에이전트만을 의미하지 않습니다
저는 코딩 에이전트의 다음 도약이 오직 더 똑똑한 모델 (models)로부터만 오지는 않을 것이라고 생각합니다.
그 중 일부는 더 나은 메모리 (memory)로부터 올 것입니다.
기록을 덤프(dump)한 형태의 메모리가 아닙니다.
"저장소 전체를 컨텍스트 (context)에 로드하라"는 식의 메모리도 아닙니다.
축적된 판단 (accumulated judgment)으로서의 메모리.
운영 이력 (operational history)으로서의 메모리.
흉터 조직 (scar tissue)으로서의 메모리.
진정한 승리는 단순히 코드를 작성할 수 있는 에이전트가 아닙니다. 진정한 승리는 지난번 수정이 왜 실패했는지를 기억하는 에이전트입니다.
이 아이디어에 대해 이곳에 더 자세히 작성했습니다:
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기