GitHub은 이번 달 제가 가장 좋아하는 유형의 엔지니어링 포스트를 게시했습니다. 바로 첫 번째 시도가 상황을 더 악화시킨 사례에 관한 글입니다.

이야기는 불편할 정도로 단순합니다. Copilot 코드 리뷰(code review)는 자체적인 코드 탐색 도구들을 가지고 있었습니다. GitHub은 이를 Copilot CLI 세계에서 더 잘 관리되는 공유 도구인 grep, glob, view로 교체하려고 시도했습니다. 이는 분명 좋아 보입니다. 중복된 도구 구현이 줄어들고, 개선 사항을 공유할 수 있으며, 매우 깔끔한 아키텍처 다이어그램이 그려집니다. 아마도 보기 좋은 화살표도 포함되었겠지요.

하지만 벤치마크(benchmarks) 결과는 그렇지 않았습니다.

리뷰 비용은 상승했습니다. 유용한 이슈(issues)를 포착하는 빈도는 줄어들었습니다.

the

이 부분이 제가 좋아하는 지점입니다. 실패가 웃겨서가 아니라(물론 실패는 종종 절묘한 타이밍에 발생하곤 하지만), 이것이 에이전트(agents)에 관한 실질적인 진실을 드러내기 때문입니다.

도구는 중립적인 배관(plumbing)이 아닙니다.

에이전트에게 있어 도구의 표면(tool surface)은 행동의 일부입니다. 도구는 모델이 무엇을 인지하는지, 어떻게 검색하는지, 얼마나 많은 컨텍스트(context)를 끌고 다니는지, 언제 포기하는지, 그리고 어떤 종류의 증거를 가지고 있다고 생각하는지를 변화시킵니다.

이것은 단순한 구현 세부 사항(implementation detail)이 아닙니다.

이것은 터미널이 부착된 제품 디자인(product design)입니다.

더 나은 망치라도 적절한 작업이 필요하다

유혹적인 해석은 "더 나은 도구가 더 나은 에이전트를 만들어낼 것이다"라는 것입니다.

이것은 거의 맞지만, 그렇기 때문에 가장 비용이 많이 드는 오류입니다.

GitHub이 시도했던 공유 도구들은 나쁘지 않았습니다. 문제는 그 도구들과 그에 따른 지침(instructions)이 암시하는 워크플로우(workflow)였습니다. CLI 코딩 어시스턴트는 종종 탐색(explore)이 필요합니다. 사용자는 어시스턴트에게 저장소(repo)를 이해하고, 변경 사항을 계획하며, 파일을 수정하고, 테스트를 실행하며, 일반적인 소프트웨어 개발 방식처럼 첫 번째 시도가 실패한 후에도 계속 진행할 것을 요청할 수 있습니다.

그런 상황에서는 광범위한 탐색이 합리적입니다.

하지만 코드 리뷰는 다릅니다.

리뷰어는 diff (차이점)에서 시작합니다. 리뷰어는 작은 질문들을 던집니다. 이 변경된 헬퍼 (helper)가 호출자 (caller)에게 영향을 미쳤는가? 이 설정 (config) 값이 다른 곳에서도 사용되는가? 이 새로운 권한 부여 (authorization) 경로가 실제로 커버되는가? 우려 사항을 증명하거나 반증할 수 있는 가장 작고 인접한 증거는 무엇인가?

리뷰어는 보통 "컨텍스트 (context)를 구축하기 위해" 저장소의 절반을 열어보지 않습니다.

그것은 리뷰가 아닙니다. 그것은 줄 번호가 매겨진 관광입니다.

Copilot 코드 리뷰가 더 일반적인 탐색 도구 세트를 갖게 되었을 때, 그것은 브라우징 어시스턴트 (browsing assistant)처럼 행동하기 시작했습니다. 그것은 광범위하게 검색하고, 광범위하게 읽고, 추가적인 컨텍스트를 끌고 가며, 풀 리퀘스트 (pull request) 증거에 덜 집중하게 되었습니다.

인간의 관점에서 말하자면, 그것은 "먼저 시스템 전체를 이해해야겠어요"라고 말한 뒤, services/legacy_v2_final/ 디렉토리 속으로 40분 동안 사라져 버리는 리뷰어가 된 것입니다.

우리 모두는 이런 사람과 함께 일해 본 적이 있습니다. 때로는 우리 자신이 이런 사람이 되기도 합니다. 누구도 이를 자랑스러워하지 않습니다.

텍스트라고 해서 컨텍스트가 공짜인 것은 아니다

이것이 중요한 이유 중 하나는 에이전트 (agent)가 도구의 출력값을 일회용 터미널 출력물처럼 취급하지 않기 때문입니다.

만약 사람이 grep을 실행하고 20개의 무관한 줄을 본다면, 우리는 그것들을 무시할 수 있습니다. 우리는 보지 못한 척하는 데 능숙합니다.

하지만 에이전트는 도구의 출력값을 자신의 작업 컨텍스트 (working context)로 가져갑니다. 추가 파일, 인접한 범위, 광범위한 검색 결과, 잘못된 경로, 그리고 추측성 읽기 등이 모두 추론의 수프 (reasoning soup)의 일부가 될 수 있습니다.

여기에는 두 가지 비용이 발생합니다.

첫째, 물리적인 비용입니다. 더 많은 토큰 (tokens), 더 많은 호출 (calls), 더 많은 시간입니다.

둘째, 주의력 (attention) 비용입니다. 에이전트는 리뷰 질문에 답하지 않는 컨텍스트에 추론 예산 (reasoning budget)을 소비할 수 있습니다. 근처의 패턴을 발견하고 그것을 쫓을 수도 있습니다. 기술적으로는 흥미롭지만 실질적으로는 쓸모없는 것에 대해 코멘트를 달 수도 있는데, 이는 이미 인간의 코드 리뷰에서 알려진 유형이기도 합니다.

when the agent discovers every file except the one that matters

이것이 바로 "에이전트에게 더 많은 컨텍스트를 그냥 주면 된다"가 전략이 될 수 없는 이유입니다.

때로는 더 많은 컨텍스트가 도움이 됩니다. 하지만 때로는 그 작업을 마치 유령이 나오는 다락방처럼 만들어 버리기도 합니다.

훌륭한 에이전트 시스템에는 컨텍스트 규율 (context discipline)이 필요합니다. 이는 모델을 굶기려는 것이 아니라, 작업에는 고유한 형태가 있기 때문입니다. Diff (차이점)에 고정된 코드 리뷰 에이전트는 리포지토리 온보딩 어시스턴트처럼 동작해서는 안 됩니다.

모델은 같고, 도구도 같지만, 직무(job)가 다릅니다.

직무가 다르다는 것은 지시 사항 (instructions)도 달라야 함을 의미합니다.

도구 지시 사항은 모델을 위한 API 문서입니다

GitHub는 도구와 관련된 지시 사항을 변경함으로써 성능 저하 (regression) 문제를 해결했습니다.

리뷰 에이전트는 Diff에서 시작하여, 구체적인 리뷰 질문을 형성하고, 저렴한 탐색 (cheap discovery)을 통해 범위를 좁힌 뒤, 왜 읽어야 하는지 알 때만 집중된 코드 범위를 읽어야 했습니다. 만약 검색에 실패했다면 단순히 재시도해야 했습니다. 만약 경로가 틀렸다면, 새벽 1시의 지친 엔지니어처럼 인접한 경로를 추측하는 대신 glob을 사용해야 했습니다.

사소하게 들릴 수도 있습니다.

하지만 사소하지 않습니다.

도구 지시 사항은 모델을 위한 API 문서 (API documentation)입니다.

우리는 이미 나쁜 API 문서가 인간으로 하여금 좋은 API를 잘못 사용하게 만들 수 있다는 것을 알고 있습니다. 잘못된 엔드포인트 (endpoint)를 호출하고, 잘못된 형태 (shape)의 데이터를 전달하며, 동일하게 고장 난 요청을 반복합니다. doThing2라는 이름의 래퍼 (wrapper)를 만들고, 이제 모두가 그것을 감수하며 살아가야 합니다.

에이전트도 똑같은 일을 합니다. 다만 더 빠르고, 더 확신에 차서 할 뿐입니다.

view라고 불리는 도구만으로는 충분하지 않습니다. 무엇을 봅니까? 언제 봅니까? 얼마나 봅니까? 어떤 종류의 검색 후에 봅니까? 어떤 종류의 증거를 위해 봅니까?

모델에게 필요한 것은 단순한 기능적 가능성 (affordance)이 아니라 워크플로우 (workflow)입니다.

이 지점에서 많은 내부 에이전트 프로젝트들이 스스로를 해치게 됩니다. 플랫폼 팀이 검색, 브라우저, 티켓, 로그, 배포 상태, 그리고 분위기에 따라 몇 가지 관리자 작업까지 포함된 멋진 공유 도구 레이어 (shared tool layer)를 노출하면, 각 제품 팀은 도구 레이어가 완성되었다고 가정할 것입니다.

하지만 완성된 것이 아닙니다.

도구 레이어는 가공되지 않은 능력 (raw capability)일 뿐입니다. 에이전트에게는 여전히 직무의 형태에 맞는 가이드가 필요합니다.

평가 (evals)는 경로를 보여줄 때 유용합니다

GitHub 포스트에서 얻을 수 있는 또 다른 유익한 교훈은, 벤치마크(benchmarks)가 단순히 점수뿐만 아니라 트레이스(traces)를 보여주었기 때문에 유용했다는 점입니다.

"리뷰 품질이 저하되었다"라고 말하는 점수는 유용하지만, 에이전트가 어디에서 길을 잃었는지는 알려주지 않습니다. 트레이스는 광범위한 검색, 잘못된 읽기, 반복되는 루프, 그리고 디프(diff)에 대한 충분한 앵커링(anchoring) 부족과 같은 동작을 보여줄 수 있습니다.

이것이 결과(outcome)를 측정하는 것과 시스템을 디버깅(debugging)하는 것의 차이입니다.

단순히 등급만을 반환하는 에이전트 평가(evals)는 경영진용 대시보드(executive dashboards)로 전락할 것입니다. 아시다시피, 뉘앙스가 파이 차트(pie chart)로 변해버리는 그런 곳 말입니다.

유용한 평가(evals)는 경로를 보존해야 합니다. 어떤 도구(tools)가 호출되었는지, 무엇이 반환되었는지, 에이전트가 범위를 좁히는 대신 넓혔는지, 이유 없이 먼저 읽지는 않았는지, 그리고 최종 답변이 작업(task)과 일치하는지 등을 말입니다.

이는 GitHub 규모의 제품만을 위한 것이 아닙니다. 내부 에이전트를 구축하는 모든 기업에 필요합니다.

만약 고객 지원 에이전트가 CRM 조회 도구를 가지고 있다면, 답변하기 전에 고객 기록을 확인하는지 알아야 합니다. 만약 장애 대응 에이전트가 로그 접근 권한을 가지고 있다면, 경고(alert)를 따르는지 아니면 관련 없는 서비스들을 구경하러 다니는지 알아야 합니다.

트레이스(trace)는 진실이 새어 나오는 곳입니다.

공유 도구(shared tools)는 여전히 중요합니다

이 모든 내용이 공유 도구가 나쁜 아이디어라는 뜻은 아닙니다.

그것들은 아마도 필요할 것입니다. 중복된 에이전트 도구들은 매우 빠르게 유지보수의 늪(maintenance swamp)이 됩니다. 모든 팀이 자신만의 검색 래퍼(search wrapper), 브라우저 헬퍼(browser helper), 로그 리더(log reader), 그리고 "안전한" 셸 추상화(shell abstraction)를 만들어냅니다.

공유 도구는 좋습니다.

하지만 공유 도구는 그 주변의 워크플로(workflow)가 직무(job)와 일치할 때만 확장 가능(scale)합니다.

동일한 grep, glob, view가 CLI 어시스턴트, 코드 리뷰 에이전트, 보안 수정 도구, 그리고 마이그레이션 헬퍼를 지원할 수 있습니다. 하지만 각 에이전트는 서로 다른 본능(instincts)이 필요합니다. CLI 어시스턴트는 광범위하게 탐색할 수 있습니다. 리뷰어는 디프(diff)로부터 범위를 좁혀야 합니다.

만약 하나의 범용 프롬프트(generic prompt)가 이 모든 것을 다룰 수 있다고 가정한다면, 우리는 다시 기업식 마법(corporate magic)으로 돌아가는 것입니다. 매우 비싸고, 대시보드와 함께 제공되는 그런 마법 말입니다.

one shared tool layer trying to satisfy five workflows

결론 (the punchline)

이 교훈은 "AI 코드 리뷰는 신뢰할 수 없다"가 아닙니다.

이 교훈은 훨씬 더 짜증 나면서도 유용한 것입니다:

에이전트(Agent)의 동작은 모델(model), 도구(tools), 지침(instructions), 컨텍스트(context), 평가(evals), 그리고 제품 워크플로우(product workflow)의 조합 속에 존재합니다.

한 부분만 바꿔도 시스템은 개선될 수 있습니다. 혹은 추적(trace)을 조사하기 전까지는 비합리적으로 보일 정도로 악화될 수도 있습니다.

그것이 바로 진지한 에이전트 작업이 평범한 엔지니어링 작업이 되어가고 있는 정확한 이유입니다. 벤치마크(benchmarks)가 필요합니다. 추적(traces)이 필요합니다. 작업별 특정 지침(job-specific instructions)이 필요합니다. 비용 가시성(cost visibility)이 필요합니다.

더 나은 도구만으로는 충분하지 않습니다.

에이전트는 자신이 어떤 종류의 일을 하고 있는지 알아야 합니다.

코드 리뷰의 경우, 이는 diff(차이점)에서 시작하여, 좁은 범위의 질문을 던지고, 집중된 증거를 수집하며, 조사가 취미 생활이 되기 전에 멈추는 것을 의미합니다.

솔직히 말해서, 이것은 인간에게도 나쁜 조언은 아닙니다.

참고 문헌 (references)

• GitHub Blog: Better tools made Copilot code review worse. Here's how we actually improved it.
• OpenAI: Running Codex safely at OpenAI

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.