AI 에이전트에게 일을 믿고 맡기려면: 코드 지도·코드 메모리와 스킬 평가 방법

발표자는 지난 10월 31일 패스트캠퍼스에서 진행한 무료 세미나를 구독자와 함께 보기 위해 풀버전을 올린다고 밝혔다. 에이전트에게 일을 믿고 맡기려면 맥락을 주고 그 결과를 검증할 수 있어야 한다는 것이 세미나의 주제다.

발표자는 기존 강의가 리뉴얼되며 세컨드 브레인과 이벨, 사이드 브라우저 내용이 추가됐다고 전했다. 이미 구매한 수강생은 무료로 볼 수 있다고 안내했다.

발표자는 회사에서 AI를 6개월 전인 작년 5월과 6월부터 써 왔다고 말했다. 초기에는 코드 한두 줄, 많아야 열 줄 정도를 자동 완성하는 보조 도구로 쓰였고 사람이 거의 모든 코드를 작성했다.

현재는 버그 수정이나 기능 구현처럼 작업 하나 또는 프로젝트 하나를 통째로 맡기고 결과만 확인한다고 설명했다. 여러 에이전트를 동시에 돌리는 멀티 에이전트 방식도 많이 쓰며, 한 에이전트는 프로젝트 조사, 다른 에이전트는 버그 수정, 또 다른 에이전트는 서비스 배포 모니터링을 맡긴다고 했다. 발표자는 자신의 하루가 에이전트들과 함께 흘러간다고 말했다.

발표자는 AI 사용으로 바뀐 가장 큰 변화가 엔지니어가 코드를 더 이상 쓰지 않는다는 점이라고 말했다. 다만 엔지니어의 일은 원래 문서, 설계, 검증, 배포 등 코드 외의 업무도 포함하고 있었다고 덧붙였다.

발표자는 AI 리뷰 도구 회사 파로스 AI의 올해 4월 분석을 인용했다. 이 회사는 개발자 22,000명, 4,000개가 넘는 팀의 2년치 작업 기록을 분석했고, 같은 회사 안에서 AI를 적게 쓰던 때와 많이 쓰던 때를 비교했다. 그 결과 AI를 많이 쓸 때 PR 크기는 51%, 즉 1.5배 커졌고 리뷰 시간은 약 다섯 배가 됐다. 리뷰 없이 머지된 PR은 31% 늘었다.

발표자는 이를 공장에 비유했다. 생산 라인은 빨라졌지만 검수 라인에 물건이 쌓이면서 검수가 제대로 이뤄지지 않게 되었다는 것이다. 다만 AI 때문에 늘었다고 단정할 수는 없다고 덧붙였다.

발표자는 AI 시대의 잘하는 개발자를 떠올리며, 에이전트를 믿고 맡기려면 사람이 주도권을 쥐고 일의 범위와 결과를 확인하는 방법을 가져야 한다고 말했다.

세컨드 브레인은 넓은 말이며, 발표자의 회사에서는 관련 도구가 11개 있다고 했다. 이 중 검증된 것만 세미나에서 소개한다고 밝혔다.

코딩 에이전트에게 필요한 것은 크게 두 가지라고 발표자는 설명했다. 첫째는 코드베이스의 지도다. 코드베이스가 커질수록 컨텍스트 윈도우에 전부 담을 수 없게 되고, 지도가 없으면 검색이 비효율적이 되어 일을 잘 못 한다. 둘째는 코드 메모리다. 코드베이스 바깥에 있는 설계 이유와 안목 같은 정보가 여기에 해당하며, 설계 문서, ADR, PR, 장애 회고 리포트 등이 포함된다. 발표자는 두 가지를 합쳐 세컨드 브레인이라고 부르겠다고 정리했다.

발표자는 텍스트 검색에 의존하면 결과가 부정확해지는 사례를 들었다. 예를 들어 1천 개를 찾아야 하는데 800개밖에 찾지 못하는 식으로 누락이 생기면, 에이전트가 주는 답변의 품질이 떨어진다. 코드베이스가 크면 컨텍스트 윈도우 하나에 다 들어가지 않으므로 누락이 불가피하다고 설명했다.

결과가 나쁘면 사람이 모든 결과를 확인해야 해서 휴먼 인 더 루프가 완벽해지는 상황이 온다. 이에 따라 프롬프트, 규칙, 체크리스트가 계속 늘고 하네스가 두꺼워진다. 발표자는 세컨드 브레인으로 제대로 된 컨텍스트를 주는 것이 이 병목을 줄이는 방법이라고 말했다.

발표자는 세컨드 브레인에 PR과 장애 회고 리포트 등이 계속 쌓여야 하며, 한 번 만들고 끝나는 것이 아니라 지속적으로 관리해야 한다고 말했다.

가장 중요한 것은 컨텍스트의 최신성이라고 강조했다. 발표자는 프레시하지 않은 컨텍스트는 컨텍스트가 없는 것보다 더 나쁘다고 말했다. 오래된 정보를 근거로 일하게 되면 잘못된 전제 위에서 작업하게 되기 때문이다.

발표자는 데모에서 쓴 쿼리 파일을 열어 설명했다. 첫 번째 핵심은 너비 우선 탐색, 즉 BFS 알고리즘으로 임포트하는 파일을 단계별로 찾아 패스에 추가하는 방식이라는 점이다.

출력 예시에서 한 번 홉하면 60개 파일이, 전체로는 394개 파일이 찾아졌다. 최대 홉은 아홉 번이었으며, 모든 파일을 빠짐없이 찾았다고 결과 리포트에 나온다고 설명했다.

세컨드 브레인의 입력은 코드베이스 저장소 전체와 커밋, 문서, 디자인 문서 같은 코드 바깥 정보다. 언어마다 컴파일러나 인덱서를 어댑터로 붙이면 언어만 바꿔 같은 구조를 쓸 수 있다고 발표자는 설명했다. 강의에서는 로컬 SQLite 파일 brain.db를 만들어 쓰며, 실서비스에서는 클라우드로 서빙하는 것을 전제한다고 밝혔다.

브레인에서 정보를 제대로 가져오려면 CLI를 써야 하며, CLI는 세 가지가 있다고 소개했다. 지도는 함수나 클래스마다 파일 경로와 이름을 합친 심볼 아이디를 붙이고, 이를 기준으로 찾으면 잘못된 파일을 찾을 일이 없다고 설명했다. 타입스크립트 컴파일러에 실제 파일을 묻고 링킹을 하며, 외부 패키지는 제외한다. 찾지 못한 경로도 못 찾았다고 기록해 에이전트가 없는 길인지 못 찾은 길인지 구분하게 한다고 덧붙였다.

코드 메모리는 파일 이름이 아니라 코드 그래프의 심볼 아이디로 저장되어 두 저장소가 링킹된다고 설명했다.

발표자는 작은 프로젝트를 운영하는 경우에는 그래프와 메모리가 드라마틱한 효과를 주지 않을 수 있다고 말했다. 반면 회사 규모의 큰 코드베이스에서 일할 때는 지도를 그리고 작업하는 것과 그렇지 않은 것의 차이가 크다고 설명했다.

그 차이는 정확도, 토큰 사용량, 에이전트의 응답 속도에서 나타나며, 이 요소들이 합쳐져 생산성과 직결된다고 말했다. 발표자는 큰 프로젝트를 쓰고 있다면 이를 고민해 보라고 권했다. 세미나 슬라이드에는 스킬 두 개를 설치할 수 있는 QR 코드도 있다고 안내했다.

발표자는 정리하며 지도는 에이전트가 최적화된 길을 찾게 해 주고, 코드 메모리는 코드베이스에서 왜 이런 일이 일어났는지 알려 준다고 말했다. 여기에 스킬이 정말 도움이 되는지 어떻게 알 수 있는지, 느낌 말고 어떤 조건과 환경에서 채점할 수 있는지가 이어서 다뤄질 Eval의 주제라고 밝혔다.

발표자는 스킬 평가가 필요한 이유로 실제 사고를 들었다. 아마존에서 파일과 클라우드 리소스를 지우라는 프롬프트가 든 코드가 배포 직전까지 들어간 일이 있었다고 소개했다. 배포되지는 않았지만 PR 단계에서 잡아내지 못했다는 점이 문제였다. 퍼켓 OS라는 회사에서도 비슷한 일이 있었다고 덧붙였다.

발표자는 Eval을 붙이면 얻는 효과를 올해 공개된 수치 세 개로 설명했다. 첫 번째 사례에서는 56%의 케이스에서 스킬이 아예 분리되지 않았다. 프롬프트로는 스킬이 불릴 거라고 생각했지만 실제로는 트리거가 되지 않아 스킬을 붙여도 붙이지 않아도 점수가 같았다. 스킬을 고치자 점수가 53에서 79로, 더 고치자 100%로 올랐다고 소개했다. 두 번째는 앤트로픽의 스킬 크리에이터 사례로, 평가에서 트리거가 나빴던 것을 튜닝해 여섯 개 중 다섯 개의 트리거를 개선했다고 했다. 세 번째 사례는 2025년 7월 라이즈 회사의 사례로 이어진다.

발표자는 Eval 결과가 통과 실패로만 나오는 것이 아니라 세 가지 지표로 나온다고 설명했다. 통과 실패 결과, 점수와 통과율, 그리고 델타 값이다. 델타는 스킬이 있을 때와 없을 때 에이전트 점수가 얼마나 차이 나는지 비교하는 숫자다.

발표자는 이 지표를 통해 스킬이 있으면 에이전트가 일을 얼마나 자주, 얼마나 잘하는지 알 수 있다고 말했다. 스킬을 바꿨는데 일을 잘하는 빈도가 줄었다면 리그레션이 발생한 것이므로, 이를 잡아낼 수 있다는 것이다.

채점 방식은 두 단계다. 사실인지 확인하는 부분은 저장소를 격리한 샌드박스에서 코드로 검증해야 하며 에이전트에게 맡기면 안 된다고 강조했다. 인용한 파일과 줄이 실제로 있는지 같은 팩트 체크가 예다. 품질과 퀄리티는 다른 모델을 저지로 세워 루브릭 항목별로 채점한다. 저지 모델이 정답 자료를 보고 에이전트의 답변을 채점하는 방식이다. K 횟수, 즉 반복 횟수를 너무 많이 돌리면 비용이 늘고 너무 적게 돌리면 정확도가 떨어지므로 적절한 균형을 찾는 것이 중요하다고 덧붙였다.

발표자는 예시 프롬프트로 배치 두 개가 동시에 시작되면 생기는 문제와 해결 근거를 쓰게 하는 과제를 들었다. 이때 평가 환경은 실제 저장소를 건드리지 않도록 샌드박스로 격리해야 한다고 강조했다. 구체적으로는 서비스 코드베이스를 통째로 복사하고 커밋 하나에 고정하며, 원본 저장소와 정답, 전역 설정 파일, 네트워크 접근을 모두 막는다고 설명했다.

채점은 먼저 하드 체크로 시작한다. 인용한 파일과 커밋이 실제로 존재하는지 예아니오로 검증하며, 하나라도 실패하면 그 답변은 바로 0점 처리한다. 통과한 답변만 다른 모델을 저지로 세워 루브릭 항목별로 패스 페일을 매긴다. 세 저지의 다수결로 점수를 내며, 예시에서는 10개 항목 중 7개가 통과해 0.7점이 됐다.

발표자는 이렇게 채점 기준을 분리하면 사실 확인과 품질 평가가 섞이지 않는다고 설명했다.

발표자는 조건에 맞는 파일을 전부 찾으라는 코드베이스 검색 과제를 예로 들었다. 이 경우 정답은 394개로 정해져 있다. 채점에는 두 가지 숫자를 본다. 첫째는 찾은 비율로, 394개 중 몇 개를 찾았는지다. 둘째는 맞은 비율로, 에이전트가 낸 결과 중 몇 개가 맞았는지다. 예를 들어 100개를 냈는데 50개가 맞으면 맞은 비율은 50%다.

발표자는 이를 각각 리콜과 프리시전이라고 정의한다고 말했다. 검색 과제의 루브릭은 이 두 지표를 기준으로 설정된다고 설명했다.

평가 환경에서는 비교군별로 스킬을 격리해야 한다. 예를 들어 스킬 A를 테스트하는데 B, C, D, E가 함께 로드되면 테스트 환경 세팅이 잘못된 것이므로, 테스트 대상 스킬만 켜야 한다고 강조했다.

발표자는 메타에서 밟은 도입 단계를 설명했다. 0단계는 느낌이다. 스킬을 써 보니 좋은 것 같고 에이전트가 일을 더 잘하는 것 같다는 수준이다. 문제는 사람마다 느낌이 다르다는 점이고, 스킬이 나빠져도 아무도 나빠졌는지 알지 못한다고 말했다.

1단계는 팀이 실제로 자주 시키는 요청의 패턴을 파일로 남기는 것이다. 팀에는 반복되는 패턴이 있고 가장 많이 쓰는 쿼리가 있어, 그런 질문을 20개 정도만 모아도 충분한 테스트 세트가 된다고 설명했다. 질문을 모은 뒤 그 질문에 대한 답변 케이스를 만들면 그때부터 Eval을 돌릴 수 있게 된다.

2단계부터는 Eval을 설계하는 단계다. 코드로 판정할 수 있는 답변은 먼저 하드 체크로 판정하고, 에이전트에게 판정을 맡기지 않는다. 그 뒤 저지를 세우는데, 저지 모델, 반복 횟수 K 등을 설정한다. 발표자는 여기까지가 오늘 보여준 프로토타입이며 3단계는 더 고도화된 형태라고 설명했다.

발표자는 대시보드에서 비교군별 통과율을 보여줬다. 스킬이 없을 때 통과율은 88%였고, 스킬 버전 1과 버전 2로 갈수록 통과율이 조금씩 올라갔다. 이렇게 스킬의 효과를 수치로 평가할 수 있다고 설명했다.

발표자는 실무에서 할 일을 제안했다. 팀에서 중요하다고 생각하는 스킬이 실제로 트리거되는지 먼저 확인하고, 아무도 쓰지 않는 스킬이 많을 수 있다고 말했다. 설명이 나빠 트리거가 잘 안 되는 경우도 있으므로 가장 먼저 확인하라고 권했다. 고친 스킬이 제대로 됐는지는 Eval로 점수를 비교하면 된다고 덧붙였다.

발표자는 이 프로토타입이 기본적인 형태이며, 회사에서는 더 고도화된 세컨드 브레인과 Eval을 쓰고 있다고 밝혔다. 강의에서는 더 고도화된 스킬과 파이프라인을 보여줄 예정이라고 했다.

발표자는 강의가 세컨드 브레인 구축, Eval 파이프라인 구축, 브라우저 에이전트 활용을 다룬다고 소개했다. 브라우저 에이전트는 새로운 흐름이라고 판단해 강의 중간에 넣었다고 설명했다.

세미나 당일에만 안내한 혜택도 있다고 밝혔다. 강의 25% 할인과 ChatGPT Pro 1개월 무료 구독권이며, 구독권은 선착순이라고 안내했다. 영상 설명란 기준으로 현재는 할인 쿠폰 혜택만 남아 있다.