최종 PR만 남기는 조직 vs 실패의 경로까지 자산화하는 조직

매일 폐기되는 트레이스..조직 지능의 원자단위

슬랙에는 대화가 남고, 위키와 깃에는 완성된 문서와 코드가 남는다. 덕분에 조직은 ‘무엇을 했는지’ 검색할 수 있다. 하지만 ‘어떤 선택지를 검토했고, 왜 그 방식을 택했는지’는 찾기 어렵다. 업계의 한 엔지니어는 에이전트 트레이스(에이전트가 작업을 수행한 전 과정의 실행 기록)에는 작업 의도와 고려 사항, 결정 사유가 프롬프트와 행동 기록에 함께 담긴다고 말한다.

코딩 에이전트와 몇 시간 동안 협업해도 회사가 보관하는 것은 대개 최종 PR(코드 변경 요청)뿐이다. 에이전트가 살펴본 파일, 호출한 도구, 검토한 뒤 버린 접근법, 엔지니어의 교정, 설계를 제한한 조건은 세션이 끝나면 사라진다. 결정의 결과만큼 그 결정에 이른 대화도 중요하다면, 에이전트 트레이스 역시 보존해야 한다.

일각에서는 트레이스를 ‘조직 지능의 원자 단위’로 표현한다. 기업들이 매일 수십만 개의 트레이스를 만들면서도 대부분 폐기하고 있다는 지적이다. 보안 스타트업 Origin은 이에 따라 엔드포인트 관측 범위를 파일에서 로그로, 로그에서 다시 트레이스로 넓힌다. 최초 프롬프트부터 최종 결과까지 이어지는 행동 기록이 있어야 작업의 중간 과정을 온전히 재구성할 수 있기 때문이다.

트레이스 보존은 지식 관리만의 문제가 아니다. 2026년 7월 AI 모델 공유 플랫폼 Hugging Face 침해 사고에서는 샌드박스 기록과 플랫폼 로그를 대조해 약 1만 7,600건의 공격 행동과 6,280여 개의 클러스터를 복원했다. 프롬프트와 최종 출력만 남았다면 그사이에 실행된 명령과 이동 경로, 실행 주체를 확인하기 어려웠을 것이다. 결과물만 보관하는 방식은 조직의 의사결정을 되짚을 때뿐 아니라 보안 사고를 감사할 때도 뚜렷한 한계를 드러낸다.

세션 커밋과 학습 시스템 설계는 별개다

한 개발자는 코딩 에이전트가 코드베이스를 탐색하며 쌓은 풍부한 맥락이 세션 종료와 함께 사라진다고 지적했다. 그래서 세션 기록을 GitHub에 커밋하자고 제안했다. 이후 공개한 ‘gbird’ 구상은 여기서 한발 더 나아간다. 로컬 세션을 정리하고, 에이전트가 불필요하게 헤맨 구간을 찾아 마크다운 보고서로 만드는 방식이다. 논의가 불과 하루 만에 ‘기록 저장’에서 ‘실패 경로 추출’로 발전한 이유는 간단하다. 기록을 보존하는 일과 기록에서 교훈을 얻는 일은 서로 다른 작업이기 때문이다.

세션의 원본 기록에는 반복된 행동과 실패한 시도뿐 아니라 시크릿(비밀번호, API 키 같은 인증 정보)과 개인 프롬프트도 뒤섞여 있다. 따라서 모든 토큰을 그대로 보관하는 것이 능사는 아니다. 앞선 엔지니어가 보존해야 한다고 본 것은 사건을 재구성하는 데 필요한 증거와, 장기간 참고할 가치가 있는 의사결정의 이력이다. 세션 JSON 파일을 저장소에 넣는 것만으로는 누가 기록을 볼 수 있는지, 기록의 출처는 무엇인지, 얼마나 오래 보관할지 같은 정책이 저절로 마련되지 않는다.

플랫폼 차원에서도 코드 커밋과 에이전트 세션을 연결하려는 움직임이 시작됐다. GitHub은 2026년 3월 Copilot coding agent가 작성한 커밋 메시지에 Agent-Logs-Url을 추가했다. 덕분에 코드에서 해당 세션 로그로 곧바로 이동할 수 있는 영구 링크가 생겼다. 동기화된 세션에서는 자연어로 과거 작업을 찾거나 반복적으로 발생한 수정 과정을 검색할 수도 있다.

이러한 연결은 코드 리뷰와 감사, 문제 재현을 위한 유용한 출발점이다. 하지만 링크만으로 모든 문제가 해결되지는 않는다. 기록 속 진술과 추론을 구분하고, 기록의 수신자와 사용 목적, 보존 기간을 정하며, 실패 유형을 분류하는 일은 별도의 설계가 필요하다. 나아가 기록을 평가와 프롬프트 개선에 활용하는 체계도 따로 마련해야 한다. 기록에 접근할 수 있게 만드는 것과, 조직이 그 기록에서 학습하게 만드는 것은 결국 서로 다른 문제다.

실패한 트레이스를 회귀 테스트 데이터로 고정하라

스타트업 액셀러레이터 Y Combinator가 2026년 여름에 제안한 ‘Company Brain’은 회사 곳곳에 흩어진 노하우를 에이전트가 활용할 수 있는 형태로 바꾸는 구상이다. 문서, 이메일, 슬랙, 티켓에 담긴 지식을 ‘스킬 파일’과 ‘업무 지도’로 정리해 에이전트가 실제 업무에 활용하도록 만드는 것이다.

이는 단순한 문서 검색이나 사내 챗봇과는 다르다. 위키, Jira, 슬랙을 연결하고 검색증강생성(RAG)을 적용하는 것만으로는 충분하지 않다. 그렇게 하면 여러 팀에서 빠르게 쌓이는 에이전트의 실행 기록, 즉 무엇을 시도했고 어디서 실패했으며 사람이 어떻게 바로잡았는지가 지식에서 빠지기 때문이다.

티켓과 런북(장애 대응 표준 절차서)은 회사의 공식 정책과 표준 절차를 알려 준다. 반면 실행 기록인 트레이스는 실제 문제 해결 과정을 보여 준다. 지난 장애에서 어떤 가설을 버렸는지, 도구를 어떤 순서로 사용했는지, 사람이 어느 지점에서 개입해 방향을 수정했는지가 여기에 담긴다. 신규 직원이나 신규 에이전트가 완성된 문서만 읽는다면, 이미 겪었던 실패를 그대로 반복할 수 있다.

따라서 원본 로그를 보관하는 데서 그쳐서는 안 된다. 실패를 재발하지 않게 만드는 평가 자료로 전환해야 한다. AI 평가 플랫폼 Braintrust가 제시하는 방식은 다음과 같다. 운영 중 실패한 트레이스에서 원인이 발생한 구간을 표시하고, 이를 회귀 테스트용 데이터셋과 평가 기준으로 고정한다. 이후 새로운 버전을 배포하기 전, CI(지속적 통합) 단계에서 같은 실패가 다시 발생하는지 검사한다. 트레이스가 고장 난 지점을 알려 주는 기록이라면, 그 기록의 진짜 운영 가치는 한 번의 실패를 영구적인 평가 사례로 바꾸는 데 있다.

AI 모니터링 기업 Arthur가 제시한 개발 순환도 같은 방향을 따른다. 생산 환경에서 발생한 실패를 수집하고, 전체 실행 과정을 기록한 뒤, 실패 유형을 분류한다. 그다음 개인정보와 비밀 정보를 제거하고, 올바른 행동을 판별할 검증 기준을 작성한다. 이렇게 정제한 사례는 골든 데이터셋(정답이 확정된 기준 평가 데이터)과 배포 전 품질 게이트로 활용된다.

이 과정에서 최종 답변만 평가해서는 부족하다. 에이전트의 실패는 최종 출력보다 도구의 입력과 출력, 검색 결과, 중간 판단에서 더 자주 발생하기 때문이다. gbird는 이러한 기록, 정제, 평가 과정을 개인의 코딩 세션에서도 적용할 수 있도록 축소한 사례다.

전사 지식 체계를 위한 2대 분기 설계하기

전사 지식 체계를 설계할 때는 먼저 에이전트의 실행 트레이스를 수집해야 한다. 그다음 트레이스에서 얻은 정보를 두 갈래로 보낸다. 하나는 회사의 기억을 축적하는 경로이고, 다른 하나는 에이전트를 개선하는 경로다.

위키, 티켓, 슬랙 검색은 온보딩에 필요한 정책과 업무 요약을 제공한다. 하지만 실제 판단 과정까지 보여주지는 못한다. 반면 트레이스에는 에이전트가 어떤 판단을 내렸는지, 어떤 대안을 검토하고 기각했는지가 남는다. 장애를 재현할 때도 단순히 비슷한 문서를 찾는 데 그치지 않고, 실패가 발생한 구간을 평가 사례로 만들어 다시 실행할 수 있다.

이에 따라 거버넌스의 범위도 넓어져야 한다. 기존의 문서 중심 전략은 원본 시스템의 접근 권한을 그대로 적용하는 데 초점을 맞췄다. 트레이스 중심 전략에서는 여기에 중간 행동에 대한 감사 기능이 추가되어야 한다. Hugging Face 사례처럼 누가 어떤 에이전트로 무엇을 실행했는지 확인할 수 있어야 한다. Agent-Logs-Url은 실행 결과와 관련 로그를 연결하는 최소한의 장치다.

처음부터 세션 전체를 RAG용 조각으로 나눌 필요는 없다. 우선 트레이스를 온전히 수집하고, 그 안에서 실패, 제약, 교정이 발생한 구간을 표시한다. 이후 필요한 내용만 다음 두 영역으로 분리하면 된다.

회사의 기억: 권한과 출처 정보가 포함된 검증된 지식
개선 자산: 평가 사례, 프롬프트, 도구 스키마로 구성된 회귀 테스트 세트

기억 계층을 제공하는 Hyperspell 같은 서비스는 검증을 거쳐 승격된 지식을 공유하고 그 출처를 관리한다. Origin이 다루는 발견 사항과 보안, 투자 관련 판단은 운영 담당자가 별도로 관리한다.

플랫폼 조직은 이 과정을 뒷받침하는 공통 기반을 제공해야 한다. 여기에는 트레이스 스키마, 커밋, 티켓과 연결되는 상관관계 ID, 시크릿 제거 기능, 보고서 및 평가 후보 추출 기능, 권한 메타데이터 API가 포함된다. 에이전트 책임자와 플랫폼, 리스크 조직은 함께 다음 기준을 정해야 한다.

실패 유형의 분류 체계
골든셋의 버전 관리 방식
배포 승인 기준
개인 대화를 회사 지식으로 승격하는 규칙
감사 로그의 보존 기간

세션과 커밋을 연결하는 것은 그동안 버려졌던 지식의 원자를 보존하는 유효한 출발점이다. 그러나 그것만으로는 충분하지 않다. ‘회사 두뇌(company brain)‘를 만들려면 실행 기록을 체계적으로 수집하는 동시에, 그 안의 실패와 판단을 재사용 가능한 지식으로 정제해야 한다.

결국 트레이스는 기억과 개선이라는 두 경로에 모두 투입되어야 한다. 그렇지 않으면 검색할 수 있는 자료만 늘어날 뿐, 같은 실패의 반복을 막는 조직적 학습은 일어나지 않는다.

출처

#에이전트 #지식 인프라 #AI 안전