Kuna는 이번 주 제가 본 코딩 에이전트(coding-agent) 출시물 중 가장 흥미로운데, 그 이유는 에이전트가 똑똑한 부분인 척하지 않기 때문입니다.

Zion Basque는 7월 29일, Rust로 작성되었으며 다른 에이전트들에 의해 정교화되도록 설계된 실험적인 디컴파일러(decompiler)인 Kuna를 출시했습니다. 헤드라인은 사람들이 스크롤을 멈추게 하기에 충분할 만큼 훌륭합니다. Basque는 LLM이 거의 모든 줄을 작성했다고 말하며, C 프로그램의 제어 흐름 구조화(control-flow structuring)에 대한 DecBench 테스트에서 Kuna는 IDA Pro 9.2의 45.7%에 맞먹는 44.4%의 완벽한 구조화 성능을 기록했습니다.

이는 놀라울 정도로 근접한 수치입니다. 하지만 "에이전트가 역공학(reverse engineering)을 해결했다"라고 말할 만큼 근접한 것은 아닙니다. 두 번째 문장이 첫 번째 문장보다 더 중요합니다.

디컴파일러의 품질은 단일 점수로 결정되지 않습니다. 제어 흐름 구조화(Control-flow structuring)는 저수준 점프(low-level jumps)를 다시 읽기 가능한 루프(loops), 조건문(conditionals), 스위치(switches)로 변환하는 부분입니다. 이는 중요하지만, 전체 작업은 아닙니다. 타입(Types), 변수 복구(variable recovery), 최적화(optimization), 재컴파일 가능성(recompilability), 기이한 아키텍처(weird architectures), 병리적인 컴파일러 출력(pathological compiler output), 그리고 리버서(reversers)들이 실제로 마주치는 모든 지저분한 사례들이 여전히 중요합니다. Basque는 출시 포스트에서 이를 명확하게 밝히고 있습니다. Kuna는 구조화 작업은 잘 수행하고 있지만, 여전히 극복해야 할 영역이 많이 남아 있습니다.

그러한 절제력이 바로 이 프로젝트를 진지하게 받아들일 가치가 있게 만드는 이유입니다.

일반적인 에이전트-소프트웨어 이야기는 지나치게 깔끔합니다. 모델에게 작업을 부여하고, 실행하게 한 뒤, 코드베이스가 나타나는 것을 지켜봅니다. 데모는 누군가가 결과물이 정말 좋은지 묻기 전 단계에서 끝나버립니다.

Kuna는 그보다 덜 화려한 버전의 이야기를 중심으로 구축되었습니다. 힘든 작업은 에이전트가 코드를 쓰기 전에 이미 일어났습니다. 누군가는 무엇이 "더 나은지"를 결정해야 했습니다. 누군가는 DecBench를 구축해야 했습니다. 누군가는 왜 angr, Ghidra, 그리고 IDA Pro가 다르게 동작하는지 알아야 했습니다. 누군가는 실패를 에이전트가 실행할 수 있는 예시로 바꾸어야 했습니다. 에이전트는 그러한 판단력을 대체하는 것이 아닙니다. 그것을 소모하고 있는 것입니다.

이것은 마케팅 버전보다 규모가 작게 들릴 수 있습니다. 하지만 훨씬 더 유용합니다.

코딩 에이전트 (Coding agent)가 문제의 피드백 루프 (feedback loop)가 긴밀하다면 구현 작업을 밀어붙일 수 있습니다. 디컴파일러 (Decompilers)는 그러한 작업에 유난히 뛰어납니다. 코퍼스 (corpus)에 도구를 실행하고, 출력을 비교하며, 회귀 (regression)를 찾아내어 에이전트에게 구체적인 실패 지점을 지목할 수 있습니다. Kuna의 리포지토리 (repository)는 이 점을 활용합니다. 단계들이 분리되어 있고, 기능 스위치 (feature switches)가 노출되어 있으며, 중요한 동작은 자연어 명세 (natural-language specs)로 기술되어 있어 에이전트가 모호한 Rust 워크스페이스 (workspace)를 둘러보는 것보다 더 나은 정보를 가질 수 있게 합니다.

이것이 제가 더 많은 팀이 모방하기를 바라는 패턴입니다. "에이전트가 그것을 만들게 두라"가 아닙니다. 테스트 하네스 (harness)를 먼저 구축하십시오. 에이전트에게 변경할 수 있는 좁은 표면을 제공하십시오. 에이전트에게 실패 사례, 지표 (metric), 그리고 말로 때울 수 없는 테스트를 제공하십시오.

DecBench의 결과는 또한 함정을 보여줍니다. 지표 (metrics)는 에이전트의 작업을 가능하게 하지만, 에이전트가 무엇을 쫓을지도 정의합니다. 만약 지표가 제어 흐름 구조화 (control-flow structuring)라면, 시스템은 제어 흐름 구조화에 더 능숙해질 것입니다. 이것은 비판이 아닙니다. 그것이 핵심입니다. 하지만 이는 인간이 여전히 분모 (denominator)를 소유하고 있음을 의미합니다. 만약 벤치마크 (benchmark)가 특정 클래스의 바이너리 (binaries)를 충분히 대표하지 못한다면, 에이전트가 마법처럼 이를 신경 써주지는 않을 것입니다. 만약 지표가 깔끔해 보이지만 의미론적 세부 사항 (semantic detail)을 놓치는 출력에 보상을 준다면, 에이전트 역시 그것을 학습할 것입니다.

이 지점에서 많은 "자율 연구 (autonomous research)" 주장들이 모호해집니다. 시스템이 논문, 벤치마크, 차트 또는 리포지토리를 생성하면, 그 결과물이 충분히 완성된 것처럼 보여 사람들이 지루한 감사 (audit) 과정을 건너뛰게 만듭니다. Kuna가 다른 이유는 감사가 곧 제품이기 때문입니다. 그것은 작업 루프 (working loop)를 노출합니다. 외부인이 코드, 테스트, 명세, 그리고 명시된 한계점들을 검사할 수 있게 합니다.

그렇다고 해서 결과가 Basque의 환경 밖에서 자동으로 재현 가능하다는 뜻은 아닙니다. DecBench는 여전히 실험적이고 살아있는 벤치마크입니다. 독립적인 실행 결과가 중요할 것입니다. 이 프로젝트는 단순히 강력한 피드백 신호가 있는 부분뿐만 아니라, 디컴파일 (decompilation)의 덜 성숙한 부분들도 개선할 수 있음을 여전히 증명해야 합니다. 이것들은 단순한 각주가 아니라 실제적인 주의 사항 (caveats)입니다.

하지만 이러한 주의 사항 (caveats)들이 이번 출시의 흥미를 반감시키지는 않습니다. 오히려 에이전트가 구축한 소프트웨어 (agent-built software)를 위한 더 나은 모델을 제시합니다.

제가 Kuna를 통해 얻은 교훈은 에이전트가 디컴파일러 (decompiler)를 작성할 수 있다는 것이 아닙니다. 도메인 전문가 (domain expert)가 자신의 안목 (taste)을 테스트 (tests)로 전환할 때, 에이전트가 상당한 진전을 이룰 수 있다는 점입니다. 전문가의 작업은 한 단계 위로 이동합니다. 상용구 코드 (boilerplate)를 타이핑하는 시간은 줄어듭니다. 대신 지표 (metrics)를 선택하고, 실패 사례를 큐레이션 (curating)하며, 어떤 "개선"이 실제로는 더 나은 느낌 (better vibes)을 주는 버그인지 결정하는 데 더 많은 시간을 할애하게 됩니다.

이것이 에이전트 엔지니어링 (agent engineering)의 지루한 절반이며, 여전히 가장 중요한 부분으로 남아 있습니다.

출처: Zion Basque의 Kuna 출시 포스트, Noelo-Lab/kuna 리포지토리, 그리고 RuntimeWire의 7월 29일 보도 내용.