00:00:00앤스로픽이 방금 엄청난 일을 해냈습니다. 16개의 클로드 에이전트를 풀어놓고
00:00:05C 컴파일러를 만들게 한 건데요. 2주 동안 쉬지 않고 가동한 결과, 실제로 작동하는 컴파일러를 완성했습니다.
00:00:11리눅스 커널을 컴파일하고 '둠' 게임까지 실행할 수 있는 수준이죠. 이전 버전인 오퍼스 4에서는
00:00:16절대 불가능했던 정말 인상적인 성과입니다. 하지만 일각에서는 앤스로픽이 이 결과를 얻기 위해 사용한
00:00:22의심스러운 기법들 때문에, 이번 성과가 '낚시'이자 절반의 진실일 뿐이라고 비판합니다.
00:00:28과연 앤스로픽은 속임수를 쓴 걸까요? 구독 누르시고 지금 바로 확인해 보시죠.
00:00:31이번 영상은 세 부분으로 나누어 살펴보겠습니다. 먼저 실험 세팅 과정을 알아보고,
00:00:37개발자라면 누구나 배울 점이 많은 핵심 발견 사항들을 짚어본 뒤,
00:00:42마지막으로 이 결과가 정말 타당한지 분석하겠습니다. 앤스로픽의 제작 방식에 대해 제 개인적인 의견이 좀 있거든요.
00:00:47자, 이 실험은 제가 보기에 아주 똑똑한 인물인 니콜라스 칼리니가 주도했습니다.
00:00:52그가 시스템을 어떻게 구축했는지 살펴볼까요? 우선 실제 프로젝트는 'Upstream'이라는 디렉토리에 저장되었고,
00:00:58이 디렉토리는 16개의 서로 다른 도커 컨테이너에 마운트되었습니다.
00:01:03화면에는 4개만 보이지만 16개라고 가정해 봅시다.
00:01:08각 도커 컨테이너에는 오퍼스 4.6 기반의 클로드 코드가 실행 중이었으며,
00:01:15Upstream 저장소를 작업 공간으로 복제해 수정한 뒤 다시 Upstream으로 푸시하는 방식이었습니다.
00:01:21이 방식이 영리했던 이유는 각 에이전트가 다른 에이전트의 작업에 영향을 주지 않고 독립적으로 일할 수 있었기 때문입니다.
00:01:27만약 병합 충돌(merge conflict)이 발생하면 클로드가 스스로 판단해 해결하고 다시 푸시했습니다.
00:01:32각 에이전트는 부여된 작업 목록에서 하나씩 골라 수행했는데요.
00:01:38이 작업들이 사람이 만든 건지, 에이전트가 테스트 결과를 바탕으로 생성한 건지는 확실치 않지만,
00:01:44이름이 지정된 작업들이 존재했고 각 에이전트는 새로운 작업을 맡을 때마다
00:01:50새 세션을 시작했습니다. 에이전트를 장시간 계속 가동하기 위해 Ralph 루프를 사용했는데요.
00:01:56에이전트가 작업을 마치고 푸시하면, 즉시 새 세션으로 다른 작업을 선택하는 과정을 무한 반복하는 구조입니다.
00:02:02이전 영상에서 설명했듯, 장기 가동 에이전트의 핵심은 명확하게 정의된 작업입니다.
00:02:08그런데 16개의 에이전트가 동시에 돌아가는데 어떻게 서로 같은 작업을 고르지 않게 했을까요?
00:02:13바로 '작업 잠금(Task lock-in)' 방식입니다.
00:02:19저자가 언급하지 않은 어딘가에 작업 목록이 있고, 에이전트가 작업을 선택하면
00:02:24해당 작업 이름과 일치하는 텍스트 파일을 만들어 커밋을 생성함으로써 독점권을 확보하고,
00:02:30이를 Upstream 디렉토리에 푸시합니다.
00:02:36만약 다른 에이전트가 같은 작업을 골라 동일한 파일을 만들고 푸시하려 하면,
00:02:42깃(Git)에서 파일이 이미 존재한다는 이유로 거부하므로 에이전트는 다른 작업을 찾아야 합니다.
00:02:48이것이 칼리니가 오퍼스 4.6 기반 에이전트의 장기 가동 능력을 테스트한 기본 원리이며,
00:02:53결과는 정말 놀라웠습니다. 하지만 이 실험을 통해 그는 개발자들에게 유용한 몇 가지 사실을 발견했습니다.
00:03:00첫 번째는 다양한 테스트를 수행하는 '테스트 하네스'나 스크립트를 구축하는 것입니다.
00:03:07닉(이제 친해졌으니 닉이라 부르죠)이 실험을 진행할 때,
00:03:12클로드가 새 기능을 만들면서 기존 기능을 망가뜨리는 일이 빈번했기 때문입니다.
00:03:17그래서 그는 SQLite, libjpg, Redis 같은 유명 오픈 소스의 고품질 테스트들로 테스트 하네스를 구성했습니다.
00:03:23또한 컨텍스트 오염을 방지하기 위해 테스트 하네스가 에이전트에게 필요한 로그, 즉 에러 로그만 출력하게 했고,
00:03:29나머지 로그는 별도 파일에 저장해 필요할 때만 클로드가 확인하도록 했습니다.
00:03:35하지만 수천 개의 테스트를 매번 돌리면 에이전트가 다른 일을 할 시간에 몇 시간씩 테스트만 하게 됩니다.
00:03:41여기서 닉의 영리함이 돋보이는데, 그는 테스트 하네스에 'fast 플래그'를 추가했습니다.
00:03:47에이전트가 설정된 값에 따라 전체 테스트의 1% 또는 10%만 무작위로 실행하게 만든 거죠.
00:03:52각 에이전트가 10%씩만 맡아도 합치면 160%니까 충분하고도 남습니다.
00:03:58이때 각 에이전트가 실행하는 테스트는 무작위로 선택되지만, 시드 번호를 동일하게 부여해 결정론적으로 작동하게 했습니다.
00:04:05결과적으로 각 에이전트는 서로 다른 무작위 테스트를 수행하며 혼자 할 때보다 훨씬 빠르게 전체 테스트를 마칠 수 있었습니다.
00:04:13다음 포인트 역시 기발하지만, 기존 기술을 활용했다는 점에서 다소 논란의 여지가 있습니다.
00:04:19지금까지는 여러 오픈 소스 프로젝트의 단위 테스트를 쪼개서 실행하는 방식이 잘 통했습니다.
00:04:25하지만 리눅스 커널 컴파일 단계에 이르자 상황이 복잡해졌습니다. 소스 파일이 개별 단위 테스트가 아니기 때문이죠.
00:04:31에이전트들이 전체를 컴파일하려다 보니 똑같은 에러에 직면하고, 서로의 수정을 덮어씌우는 문제가 발생했습니다.
00:04:36닉은 이번에도 각 에이전트가 컴파일의 일정 비율만 담당하게 하고,
00:04:41나머지는 기존의 GNU 컴파일러인 GCC가 처리하도록 했습니다.
00:04:46닉은 리눅스 커널을 완벽하게 컴파일할 수 있는 GCC를 '오라클(신탁)'이라 불렀습니다.
00:04:53에이전트가 특정 섹션은 자신의 컴파일러로, 나머지는 GCC로 컴파일했을 때 문제가 생겼다면
00:04:58그건 확실히 에이전트 컴파일러의 잘못이지 GCC 때문이 아니라는 게 증명됩니다.
00:05:04덕분에 에이전트는 다른 에이전트의 버그를 고치는 대신 자신의 문제에만 집중할 수 있었습니다.
00:05:09클로드가 바닥부터 직접 만들기로 한 작업에 기존 컴파일러를 썼다는 게 논란이 될 수 있는데,
00:05:15이 부분은 영상 후반부에서 더 자세히 다루겠습니다.
00:05:22다음 포인트는 에이전트에게 '기억력'을 부여하는 것입니다.
00:05:27새 작업은 이전 작업 내용을 모르는 완전히 새로운 클로드 세션에서 시작되므로,
00:05:34닉은 Readme 파일을 업데이트하고 작업 진행 상황과 지침이 담긴 별도 파일을 관리하는 것이 유용하다는 걸 발견했습니다.
00:05:40덕분에 새 세션은 원활하게 작업을 이어받고 이미 해결된 버그를 다시 만드는 실수를 방지할 수 있었습니다.
00:05:46마지막으로 좀 더 당연한 조언은 에이전트에게 각기 다른 역할을 부여하는 것입니다.
00:05:51여러 에이전트가 병렬로 일할 때의 장점은 동일한 코드에 대해 여러 작업을 동시에 진행할 수 있다는 점입니다.
00:05:57닉은 새 코드를 작성하지 않을 때 에이전트들에게 중복 코드 확인,
00:06:03성능 최적화 방안 찾기 같은 고유한 역할을 주었습니다.
00:06:09심지어 Rust 개발자의 관점에서 디자인을 비판하라는 역할도 주었는데, 부디 다른 에이전트들에게 자기가 Rust 개발자라고 떠벌리고 다니진 않았길 바랍니다.
00:06:13자, 프로젝트는 성공적이었지만 진짜 질문은 이겁니다. 앤스로픽이 속임수를 쓴 걸까요?
00:06:18어느 정도는 그렇다고 볼 수 있습니다. 원래 목표는 바닥부터 C 컴파일러를 만드는 것이었고
00:06:23에이전트는 인터넷 연결 없이 모든 코드를 직접 작성했습니다. 그런데 정말 그랬을까요?
00:06:29에이전트는 오픈 소스 프로젝트의 테스트 수트와 이미 컴파일된 GCC에 접근할 수 있었습니다.
00:06:35즉, GCC 컴파일러에 이런저런 값을 넣어보고 결과를 확인하면서
00:06:40Rust로 작성 중인 자기 컴파일러의 설계 방향을 정하는 데 참고했을 가능성이 큽니다.
00:06:45하지만 공평하게 말해서 저라도 C 컴파일러를 밑바닥부터 만든다면 똑같이 행동했을 겁니다.
00:06:51기존 컴파일러를 보고 어떻게 구현됐는지 파악해 제 작업의 방향을 잡았겠죠.
00:06:57만약 완전히 새로운 언어의 컴파일러를 만드는 작업이었다면 훨씬 어려웠을 것이고,
00:07:03클로드가 진짜 무에서 유를 창조할 수 있는지 확인하는 더 좋은 시험대가 되었을 겁니다.
00:07:10닉이 다음에 시도해 볼 만한 아이디어네요. 이제 실험의 자율성에 대해 이야기해 봅시다.
00:07:16솔직히 클로드가 모든 코드를 작성한 건 맞지만, 인간의 강력한 개입이 있었습니다.
00:07:24어떤 테스트 수트를 돌릴지, 루프를 시작하고 Ralph를 쓸지 결정한 건 인간이었습니다.
00:07:31테스트 하네스를 만들고 에이전트에게 구체적인 역할을 준 것도 인간이었죠.
00:07:36그러니 단순히 클로드에게 컴파일러를 만들라고 시켜두고 무한정 방치한 것과는 거리가 멉니다.
00:07:41인간의 도움이 전혀 없었다면 과연 이 정도 수준의 컴파일러가 탄생했을까요? 100% 자율적인 결과라고 보긴 힘듭니다.
00:07:47게다가 인간이 설계한 시스템을 모두 갖췄음에도 클로드 C 컴파일러에는 치명적인 한계가 있었습니다.
00:07:53예를 들어, 직접 만든 어셈블러와 링커에 버그가 너무 많아 결국 GCC의 것을 가져다 써야 했습니다.
00:07:57리눅스 부팅을 위해 GCC의 16비트 x86 컴파일러도 필요했죠. 무엇보다 코드 자체가 효율적이지 않았습니다.
00:08:04클로드 컴파일러의 최고 최적화 버전이 GCC의 최저 최적화 버전보다 성능이 떨어졌으니까요.
00:08:11결론적으로 개발자들은 당분간, 아니 적어도 지금 당장은 실직 걱정을 하지 않아도 될 것 같습니다.
00:08:16specific roles. So while this is far from someone telling Claude to build a compiler and leaving it
00:08:22to run forever and ever, I wouldn't say the code was written by an agent that was a hundred percent
00:08:28autonomous because how good would the compiler have been if a human wasn't involved in the first place?
00:08:33And even with all the systems in place designed by a human, the Claude C compiler did have some
00:08:39key limitations. For example, it used the assembler and linker from GCC because the one it created was
00:08:46too buggy. It also needed GCC's 16-bit x86 compiler in order to boot up Linux. And to top that all off,
00:08:54the code wasn't very efficient. The most optimized version of the Claude's compiler was less
00:09:00performant than the least optimized version of the GCC compiler. So it looks like developers
00:09:05aren't going anywhere anytime soon, or at least for now.