오늘은 Agentic Engineering, 그중에서도 코드를 어떻게 믿을 수 있는가 하는 검증 이야기를 해보려고 합니다. 저는 Simon Willison이고요, 반갑습니다.
2022년부터 LLM과 함께
저는 2022년부터 LLM의 도움을 받아 코드를 짜 왔는데요, 그동안 이 도구들이 얼마나 빠르게 달라졌는지 직접 겪어 왔습니다.
달라진 개발 풍경
그 몇 년 사이에 개발이라는 일 자체의 모습이 꽤 많이 바뀌었습니다.
도구의 진화
도구가 좋아질수록, 우리가 실제로 하는 일이 무엇인지 다시 묻게 되더라고요.
전문가의 바이브 코딩, 뭐라 부를까
전문 소프트웨어 엔지니어가 진짜 제품을 만들면서 하는 바이브 코딩, 이걸 도대체 뭐라고 불러야 할까요?
저는 이걸 Agentic Engineering이라고 부릅니다. 오늘 이야기의 중심 개념이죠.
완전히 새로운 문제
이건 어떤 면에서는 완전히 새로운 문제입니다.
코딩 에이전트, 이제야 쓸만해졌다
LLM이 코드를 직접 쓰고 실행까지 하는 코딩 에이전트가 정말 쓸만해진 건 사실 지난 11월부터입니다. 얼마 안 됐어요.
2004년, 하루 10~50줄
Steve McConnell의 Code Complete를 보면, 2004년엔 하루에 전달하는 코드가 10줄에서 50줄 정도였습니다.
2014년, 하루 600줄이면 예외
2014년만 해도 하루 600줄은 개발자 성과에서 아주 예외적인 수치로 여겨졌죠.
이제는 산책하며 폰으로 600줄
그런데 지금 저는 개를 산책시키면서 폰으로 테스트와 문서까지 갖춘 600줄을 짤 수 있습니다.
그런데 그 코드, 좋은 코드일까
문제는 이겁니다. 개랑 산책하면서 짠 그 코드가 과연 좋은 코드일까요?
동시에 아주 오래된 문제
그리고 이건 동시에 아주 오래된 문제이기도 합니다.
10만 개발자 규모의 Microsoft
생각해 보세요. Microsoft처럼 경력도 제각각인 개발자가 10만 명이 넘는 회사가 도대체 어떻게 뭔가를 출시해 내는 걸까요?
거대 팀의 방식을 노트북 규모로
거대한 팀에서 통하는 방식을 알아내서, 그걸 우리 노트북 한 대 규모로 줄여 오면 됩니다.
우리 일은 코드 생산과 검증
결국 우리 일은 코드를 만들어 내고, 그게 제대로 작동하는지 검증하는 것, 이 두 가지입니다.
타이핑 병목은 사라졌지만
컴퓨터에 코드를 타이핑하는 병목은 사라졌습니다. 하지만 나머지 수많은 병목은 그대로 남아 있죠.
이제 실제 사례를 하나 볼까요. StrongDM의 Dark Factory 이야기입니다.
규칙 1, 2: 사람은 손대지 않는다
규칙 1, 코드는 사람이 쓰지 않는다. 규칙 2, 코드는 사람이 리뷰하지 않는다. 정말 과감하죠.
시나리오를 검증하는 에이전트 군단
대신 에이전트 군단이 소프트웨어를 상대로 온갖 시나리오를 테스트합니다.
Digital Twin Universe
핵심은 Digital Twin Universe입니다. Slack, Okta 같은 의존성들을 에이전트가 직접 복제해 만든 거죠.
의존성을 통째로 복제하다
이렇게 외부 서비스 클론을 갖춰 두면, 실제 환경과 똑같이 마음껏 테스트를 돌릴 수 있습니다.
원조 토큰맥서
한 엔지니어당 하루에 토큰을 최소 1,000달러어치는 써야, 소프트웨어 팩토리에 개선 여지가 없다고까지 말합니다. 원조 tokenmaxxers인 셈이죠.
자, 그럼 이제 실제로 통하는 패턴들을 하나씩 살펴보겠습니다.
모든 줄을 못 본다면, 어디를 볼까
모든 줄을 다 리뷰하지 않는다면, 그럼 우리는 어떤 줄을 봐야 할까요?
리뷰하면서 능동적으로 리팩터링
리뷰하는 도중에 직접 리팩터링을 합니다. 사람한테 이러면 무례하지만, 에이전트한테는 괜찮죠.
중복 제거, 변수명 통일
예를 들면, 테스트의 중복 코드를 줄이고 변수명을 blog/models.py와 일관되게 맞춰 달라고 바로 시키는 겁니다.
위험을 따지고 이음새를 찾아라
무엇을 얼마나 볼지는, 걸린 위험이 얼마나 큰지 따져 보고 코드의 이음새를 찾는 데서 시작합니다.
API 설계 검증을 위해 코드를 쏟아내라
API 설계가 좋은지 검증하려면, 그 API를 쓰는 코드를 잔뜩 생성해 보는 게 최고입니다.
마지막 커밋 리뷰 후 기능 3개 프로토타입
마지막 커밋을 리뷰한 다음, 새 API를 상대로 기능 세 개를 브레인스토밍해서 프로토타입으로 만들어 보라고 시킵니다.
먼저 프로토타입, 그다음 합치기
순서가 중요합니다. 먼저 프로토타입을 만들고, 그다음에 그 프로토타입들을 합칩니다.
붙여넣기 감지 에디터 프로토타입
예를 들어, 직접 타이핑은 되지만 X자 넘게 붙여넣으면 그걸 paste-file 이벤트로 처리하는 텍스트 에디터를 만들어 보라고 하는 거죠.
프로토타입이 돌아가는 모습
이렇게 하면 아이디어가 실제로 동작하는 모습을 곧바로 확인할 수 있습니다.
빠르게 검증하는 실험
작게 빠르게 만들어 보면서 설계가 맞는지 실험하는 겁니다.
프로토타입을 실제 기능으로
그다음, file-paste.html 프로토타입을 바탕으로 chat에 paste-file 기능을 붙여 달라고 이어서 시킵니다.
에이전트가 문서까지?
그럼 문서 작업도 에이전트에게 맡길 수 있을까요?
diff 보고 문서 갱신 검토
main과 diff를 떠서, 업데이트가 필요한 문서가 있는지 검토하게 합니다.
의견도 근거도 넣지 마라
단, 의견이나 장황한 근거는 넣지 말라고 못을 박습니다.
과한 홍보성 표현만 손보기
예를 들면 커밋 메시지가 그냥 과하게 홍보성이던 표현을 좀 다듬었다, 이 정도면 충분하죠.
프리뷰 환경에 지속 배포
그리고 프리뷰 환경으로 지속적으로 배포합니다.
PR마다 새 머신에 자동 배포
새 PR을 fly.io, Cloud Run, Vercel 같은 새 머신에 배포하는 GitHub Actions 워크플로를 짜게 합니다.
먼저 명확화 질문부터
이럴 때는 곧바로 만들지 말고, 먼저 확인 질문부터 하라고 시키는 게 좋습니다.
실수의 폭발 반경 줄이기
이제 실수가 났을 때 그 폭발 반경을 어떻게 줄일지 살펴보겠습니다.
CSP, 샌드박스 iframe, WASI
프런티어 에이전트한테 Content Security Policy, 샌드박스 iframe, WebAssembly와 WASI 같은 걸 물어보세요.
샌드박스, 탈출해 봐
제가 만든 샌드박스 안에서 돌고 있으니 한번 탈출을 시도해 보라고, 일부러 시켜 보기도 합니다.
불안정한 테스트엔 무관용
불안정한, 이른바 flaky 테스트에는 무관용 원칙을 세웁니다.
Docker로 CI 크래시 재현
CI에서 Linux의 Python 3.14로 크래시가 났다면, Docker를 써서 그대로 재현해 보라고 합니다.
엔지니어를 돕는 도구가 에이전트도 돕는다
재미있는 건, 엔지니어를 돕는 도구는 그대로 에이전트한테도 도움이 된다는 점입니다.
온보딩 문서부터 로그까지
온보딩 문서, CI, 린터, 코드 포매터, 디버거, 로그까지, 사람한테 좋은 건 에이전트한테도 그대로 좋습니다.
수십 년 된 좋은 관행을 가르치는 트릭
사실 Agentic Engineering은, 수십 년간 쌓여 온 좋은 엔지니어링 관행을 모두에게 가르치는 하나의 트릭입니다.
다크 팩토리는 곧 검증 기계
다크 팩토리를 만든다는 건, 결국 검증 기계를 만든다는 뜻입니다.
우리는 지금, 소프트웨어를 만드는 방식 자체를 다시 발명할 기회를 얻은 겁니다.
simonwillison.net
더 자세한 이야기는 simonwillison.net에 있습니다. 감사합니다.
감사합니다
들어 주셔서 감사합니다.