What Context Does a Coding Agent Actually Need to Act?
이 논문은 코드를 편집하는 코딩 에이전트의 경우, 자연어 요약과 주변 파일 내용이 소스 코드 자체에 비해 문제 해결에 기여하는 바가 미미하기 때문에 필수적인 컨텍스트가 수정되는 특정 파일들로 엄격히 제한된다는 점을 입증하며, 또한 비결정론적인 API 추론으로 인해 벤치마크 결과에서 발생하는 상당한 노이즈 플로어를 밝혀낸다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
거대한 100층짜리 마천루에서 새는 수도꼭지를 고치려 한다고 상상해 보세요. 당신은 렌치를 찾기 위해 건물 전체의 설계도나 구내식당 메뉴, 혹은 보안 로그를 읽을 필요가 없습니다. 그저 어느 파이프가 새고 있는지 정확히 알고, 그 주변의 즉각적인 상황만 알면 됩니다.
이것은 코딩 에이전트(소프트웨어를 작성하고 수정하는 AI 봇)에 관한 새로운 연구가 주는 놀라운 교훈입니다. 오랫동안 기술 업계는 이 봇들이 자신의 직무를 수행하기 위해 프로젝트의 전체 코드베이스(때로는 수백만 줄에 달하는)를 "두뇌" 속으로 집어삼켜야 한다고 가정해 왔습니다. "컨텍스트(문맥)는 많을수록 좋다"는 생각이 지배적이었습니다.
하지만 이 논문은 이렇게 말합니다: 두뇌에 너무 많이 채워 넣지 마세요. 실제로 코드를 수정하는 행위에 있어서, AI에게는 자신이 수정하려는 바로 그 몇 줄의 코드 외에는 거의 아무것도 필요하지 않다는 것이 밝혀졌습니다.
"찾기"와 "수행하기"
연구진은 문제를 두 부분으로 나누었습니다:
- 찾기: 고장 난 코드를 찾아내는 것.
- 수행하기: 코드를 찾은 후 실제로 수정하는 것.
이를 테스트하기 위해, 그들은 "마법의 지도"(오라클)를 사용하여 AI에게 고장 난 코드가 정확히 어디에 있는지 알려주었습니다. 이는 AI가 어디를 찾아야 할지 추측할 필요 없이, 어떻게 고칠지에만 집중할 수 있게 함을 의미합니다. 그런 다음 연구진은 AI에게 다양한 형태의 코드 "뷰(view)"를 제공하여 어떤 방식이 가장 효과적인지 확인했습니다.
큰 실망: 요약본은 효과가 없다
한 가지 인기 있는 아이디어는 이것이었습니다: "AI에게 코드에 대한 자연어 요약, 즉 책의 홍보 문구 같은 것을 제공하자."
- 테스트: 연구진은 AI에게 코드의 동작 방식에 대한 까رض린 질문에 답하도록 요청했습니다. 이때 전체 소스 코드를 사용하거나, 혹은 매우 똑똑한 AI(프런티어 모델)가 작성한 요약본을 사용했습니다.
- 결과: 전체 소스 코드는 45문제 중 27문제를 맞혔습니다. 그렇다면 요약본은 어땠을까요? 단 45문제 중 4문제만을 맞혔습니다.
- 반전: 요약본을 작성한 모델이 세상에서 가장 똑똑한 AI인지 아니면 아주 작고 기본적인 모델인지는 중요하지 않았습니다. 둘 다 똑같이 실패했습니다. 문제는 작성자가 아니라 형식이었습니다. 요약본은 버그를 고치는 데 필요한 구체적인 "동작"의 세부 사항을 담아낼 수 없습니다. 이는 자동차 엔진을 고치기 위해 자동차에 대한 여행 안내 책자를 읽는 것과 같습니다. 안내 책자는 멋지지만, 어떤 볼트가 느슨해졌는지는 알려주지 않습니다.
"골격" vs "전신"
다음으로, 연구진은 AI에게 전체적인 살점이 붙은 코드 전체가 필요한지, 아니면 단지 "골격"(함수 이름과 시그니처 같은 구조)만 있으면 되는지를 테스트했습니다.
- 설정: 70개의 실제 세계 코딩 문제를 사용했습니다. 일부 문제에는 AI에게 전체 파일을 주었고, 다른 문제에는 "골격"(UML 다이어그램 및 시그니처)만 주거나, "유지/삭제(keep/drop)" 버전(필수적인 부분만 남기고 나머지는 삭제한 형태)을 주었습니다.
- 결과: "골격" 버전과 "유지/삭제" 버전은 전체 파일을 주었을 때와 거의 동일한 수의 문제를 해결했습니다. 사실, "유지/삭제" 방식이 전체 파일(70개 중 19개)보다 약간 더 많은 문제(70개 중 25개)를 해결했지만, 그 차이는 운에 의한 것일 수도 있을 만큼 미미했습니다.
- 비용: 여기서 핵심이 나옵니다. 전체 파일을 사용하여 문제를 해결하는 데는 AI가 94,000 토큰(텍스트 단위)을 소모했습니다. 반면, 압축된 "유지/삭제" 방식을 사용했을 때는 단 19,000 토큰이 들었습니다. 이는 엄청난 절약이며, 성능 저하 없이 약 3배에서 3.7배 더 저렴하게 해결할 수 있음을 의미합니다.
"노이즈" 경고
연구진은 또한 이상하면서도 중요한 점을 발견했습니다. 완전히 동일한 설정으로 동일한 테스트를 실행했음에도 불구하고, AI가 가끔 서로 다른 답을 내놓는다는 것입니다. 약 **9%**의 경우, 실행할 때마다 결과가 뒤집혔습니다. 이는 만약 두 방법 사이의 차이가 아주 작게(예: 2% 개선) 나타난다면, 그것은 실제 혁신이 아니라 단순한 무작위 노이즈일 수 있음을 의미합니다.
결론
이 논문은 코드를 수정하는 특정 작업에 있어서는 **적은 것이 더 많은 것(less is more)**이라고 결론짓습니다.
- 효과적인 것: AI에게 편집해야 할 정확한 코드 줄을 제공하되, 필수적인 부분만 남기고 불필요한 것을 걷어내는 것입니다.
- 효과적이지 않은 것: AI에게 코드의 요약, 전체 파일 기록, 또는 복잡한 구조적 다이어그램을 쏟아붓는 것입니다.
- 판결: "신호(signal)"는 우리가 코드에 대해 이야기하는 이야기가 아니라, 코드 자체에 존재합니다. 불필요한 부분을 잘라냄으로써, 우리는 한 번의 실수로 전체 스카이스크래퍼를 다 읽을 필요 없이 훨씬 적은 비용으로 버그를 잡을 수 있습니다.
저자들은 이 결과가 "싱글 샷(single-shot)" 수정(AI가 한 번 시도하고 다시 읽거나 도움을 요청할 수 없는 경우)에 적용된다는 점을 매우 신중하게 명시하고 있습니다. 하지만 그 특정한, 높은 수준의 정밀도가 요구되는 편집의 순간에 있어서는 데이터가 명확합니다: 당신에게 필요한 것은 도서관 전체가 아니라, 바로 그 페이지입니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.