에이전트를 제대로 쓴다는 것

지난 2년 동안 에이전트를 잘 쓰는 법이라며 나온 것들은 셀 수 없이 많습니다. 워크플로, 테스트부터 쓰라는 규칙, 역할을 나눈 에이전트 팀, 밤새 도는 루프, 단계마다 뜨는 승인 창, 수백 줄짜리 계획서, 매주 길어지는 규칙 파일.

전부 한 가지를 피하려고 만든 겁니다. 뭘 원하는지 묻는 일입니다.

"테스트부터 짤게요. 그런데 뭘 만드시려고요?"

요즘 에이전트는 코드를 읽고, 구조를 파악하고, 테스트를 돌리고, 실패하면 고칩니다. 1년 전만 해도 사람이 옆에 붙어 하나하나 가르쳐야 했던 일입니다. 일하는 방법만 놓고 보면, 이제 사람이 일일이 짜 주는 것보다 에이전트가 알아서 고르는 게 낫습니다.

그런데 우리는 아직도 1년 전 방식으로 가르치고 있습니다. 이 순서로 읽어라, 이 단계에서 테스트를 써라, 이만큼 쪼개라. 그저 쓸모없는 정도가 아닙니다. 안 해도 될 일을 하고 있고, 그 일 때문에 에이전트가 오히려 일을 더 못합니다.

그 방식은 모델이 약할 때의 이야기입니다. 모델이 틀릴 때마다 규칙을 한 줄씩 붙였고, 그렇게 쌓인 규칙 파일은 지난 실패들의 목록입니다. 새 모델은 그렇게 덕지덕지 붙은 제약에 묶여 제 실력을 못 냅니다. 지금 쓰는 워크플로는 다음 모델이 나오는 날 레거시가 됩니다.

정작 에이전트가 틀리는 방식은 그대로입니다. 버그 하나 고쳐 달라고 했더니 잘 돌던 결제 로직까지 뜯어고쳐 놓고, 코드 좀 정리하랬더니 쓰던 데이터를 날려 버립니다. 그래도 되는지는 묻지 않습니다. 모델을 바꿔도 똑같습니다. 에이전트가 모르는 건 일하는 법이 아닙니다. 사용자의 의도입니다.

요즘은 사람이 병목이라는데

에이전트는 빨라졌습니다. 에이전트 여러 개를 동시에 돌리고, 밤새 혼자 돌게 걸어 두고, 아침에 결과를 받습니다. 그러자 새로운 말이 돌기 시작했습니다. 이제 느린 건 사람이라는 말입니다. 쏟아지는 결과를 검토하고 승인하는 사람이 병목이라는 겁니다.

그래서 다들 작업에 사람이 덜 끼어들게 만드는 데 매달립니다. 에이전트를 혼자 더 오래 돌리고, 작업을 잘게 쪼개고, 리뷰도 에이전트에게 맡기고, 확인은 모아서 한 번에 합니다. 사람이 빠진 자리는 절차로 메웁니다. TDD가 뭔지도 모르면서 냅다 TDD부터 강제하고, 서브에이전트 여럿이 서로 일을 주고받는 그래프가 화면에 그려지면 일이 잘 돌아가는 줄 압니다.

병목은 뒤에 있지 않습니다

왜 검토할 게 그렇게 많을까요. 왜 에이전트는 만들다 말고 자꾸 "결정해 주세요" 하며 돌아올까요.

처음에 사용자가 무엇을 원하는지 끌어내지 않고 일을 시작했기 때문입니다. 그러니 결과물이 맞는지는 사람이 나중에 전부 뜯어봐야 하고, 에이전트는 가다가 막힐 때마다 돌아와 물어야 합니다. 처음에 끌어내지 않은 의도가 나중에 병목으로 보이는 겁니다.

요즘 도구들도 묻긴 합니다. 그런데 대부분 엉뚱한 데 꽂혀 있습니다. 질문을 많이 할수록 꼼꼼하다고 여기거나, 에이전트에게 "너는 PM이야", "너는 QA야" 하고 역할을 씌웁니다. 역할을 바꿔 입는다고 모르던 의도를 알게 되지는 않습니다. 그렇게 받은 질문 스무 개를 다시 읽어 보면, 대부분 어떤 프레임워크를 쓰는지, 데이터베이스는 뭔지처럼 package.json만 열어 봐도 나오는 것들입니다. 에이전트가 모르는 건 의도 하나뿐인데, 딱 그것만 안 묻습니다.

사람을 덜 부르면 나아질까요. 반대입니다. 의도를 모른 채 오래 돌릴수록 에이전트는 엉뚱한 데로 가고, 아침에 받는 건 더 많고 더 엉뚱한 결과물입니다. 검토는 더 밀립니다.

병목은 사람이 아니라 묻지 않은 의도입니다.

Dryforge는 여기서 출발했습니다

사람이 덜 끼어들게 하는 쪽이 아니라, 처음에 의도를 제대로 끌어내는 쪽을 택했습니다. 그래서 Dryforge는 에이전트에게 코드를 어떻게 짜라고 일일이 정해 주지 않습니다. PM이니 QA니 하는 역할극도 시키지 않습니다. 코드를 어떻게 읽고 어떻게 만들지는 에이전트가 판단합니다. 그건 모델이 가장 잘하는 일이고, 모델이 좋아지면 그 판단도 저절로 더 좋아집니다.

대신 딱 하나를 고정했습니다. 작업에 들어 있는 결정마다 누구 몫인지 가리는 일입니다. 고정한 건 이 원칙과, 그걸 지키는 데 꼭 필요한 최소한의 장치뿐입니다. 나머지는 에이전트에게 맡겼습니다. 이 원칙은 다음 모델이 나와도 낡지 않습니다. 모델이 바뀌어도 누가 무엇을 정하는지는 그대로니까요. 아래에 이어지는 것들은 모두 이 원칙에서 나옵니다.

사람이 할 일은 따로 있습니다

코드를 어떻게 읽을지, 어떤 순서로 만들지, 테스트를 어디에 얼마나 쓸지, 일을 나눌지 말지는 에이전트가 정할 일입니다. 사람보다 잘 정하고, 모델이 좋아질수록 더 잘 정합니다.

사용자가 무엇을 원하는지는 에이전트가 절대 정할 수 없습니다. 환불을 해 줄지, 지운 글을 살려 둘지, 느려도 정확한 게 나은지 빨라도 덜 정확한 게 나은지는 모델이 아무리 좋아져도 사용자만 압니다.

지금은 이게 거꾸로 돼 있습니다. 사람은 방법을 정하고 결과를 검토하느라 바쁘고, 에이전트는 비어 있는 의도를 짐작으로 채웁니다. 의도가 분명하면 방법은 에이전트가 알아서 고릅니다.

Dryforge에서 사용자가 내릴 결정은 어떤 형태로 숨어 있든 사용자에게 돌아가고, 에이전트는 자기 몫의 결정을 가진 정보를 다 써서 내립니다.

의도가 방법을 정합니다. 그 반대가 아닙니다.

의도는 암묵지입니다

문제는 사람이 할 일이 생각보다 어렵다는 겁니다. 원하는 걸 본인도 다 모릅니다. 알고는 있는데 한 번도 말로 꺼내 본 적이 없습니다. 말할 수 있는 것보다 더 많이 아는 상태, 암묵지입니다.

게시판을 만들고 싶은 사람의 머릿속에는 화면 한 장이 있습니다. 글이 쌓이면 페이지 번호로 넘길지 스크롤로 이어 붙일지, 지운 글은 정말 지울지 숨겨 둘지는 그 화면에 없습니다. 떠올리지 않았을 뿐 원하는 답은 있습니다. 다 만들어진 걸 보고 나서야 "이게 아닌데" 합니다.

의도는 한 줄 프롬프트로도, 수백 줄 스펙 문서로도 다 전달되지 않습니다. 사용자가 게을러서가 아닙니다. 본인도 한 번도 말로 해 본 적이 없는 것들이라서입니다. 그런데 결과를 가르는 건 대개 그런 것들입니다.

그래서 Dryforge는 의도를 받아 적지 않고 끌어냅니다. 본인도 모르는 의도는 받아 적을 수가 없으니까요.

가장 무서운 건 조용히 정해진 기본값입니다

가장 무서운 건 묻지 않고 넘어간 결정입니다. 아무도 말하지 않았는데 조용히 정해진 기본값 말입니다. 환불은 해 주는지, 지운 글은 어디로 가는지, 두 요구가 부딪히면 어느 쪽이 이기는지 같은 것들입니다. 에이전트는 이걸 그럴듯한 기본값으로 채우고 넘어가고, 사용자는 한참 뒤에 고객 문의로 알게 됩니다.

이런 기본값은 나중에 아무리 검토해도 드러나지 않습니다. 코드는 멀쩡하게 돌아가고 테스트도 통과합니다. 틀린 건 코드가 아니라 결정이라서, 결정이 있었다는 것조차 아무도 모릅니다. 검토를 늘려서는 못 잡습니다. 결정이 내려지기 전에, 사람에게 물어서 잡아야 합니다.

그래서 Dryforge는 질문하는 방식부터 다르게 잡았습니다. 좋은 질문은 이 기본값을 사용자 앞으로 끌어내는 질문입니다. 먼저 프로젝트부터 읽고, 찾아보면 나오는 건 묻지 않습니다. 사람의 주의는 에이전트가 혼자 알아낼 수 있는 데 쓰라고 있는 게 아닙니다. 그리고 말한 것만 보지 않고, 말하지 않았지만 누군가는 정해야 하는 걸 짚습니다. "아, 그건 생각 못 했네요"가 나오는 질문입니다. 기술적인 결정이라도 사용자가 겪을 결과가 달라지면 묻되, 개발을 몰라도 고를 수 있게 추천안까지 함께 가져옵니다.

그러면 쓸데없는 질문은 사라지고, 남은 질문 하나하나가 결과를 바꿉니다. 절차에 질문 단계가 있어서 묻는 게 아닙니다. 그 결정이 사람 몫이라서 묻습니다.

사람은 필요한 것만 정하면 됩니다

의도를 끌어내고 나면 사람이 정할 건 많지 않습니다. 정한 걸 한데 모아 승인하면, 그다음은 에이전트가 방법을 정하고 전력으로 일합니다. 방법까지 정해 주면 오히려 방해입니다.

요즘 에이전트는 이미 알아서 진행합니다. 문제는 멋대로 한다는 겁니다. 아무도 안 정한 부분을 그럴듯한 추측으로 채우고, 사용자가 뭘 뜻했는지까지 제 마음대로 정합니다. 석 달 뒤엔 왜 이렇게 만들었는지 아무도 모르는 코드가 남습니다.

Dryforge에서 에이전트는 사용자가 승인한 의도 안에서만 알아서 움직입니다. 에이전트가 정할 수 있는 건 에이전트가 정하고, 사람만 정할 수 있는 건 짐작하지 않습니다. 만들다가 승인한 걸 바꿔야 하는 상황이 오면 의도를 임의로 바꾸지 않고 멈춰서 사용자에게 묻습니다. 처음에 의도를 끌어냈으니 이런 일은 드뭅니다. 진짜 막힌 일이 아니라면, 사람 몫이 아닌 일로는 사람을 부르지 않습니다.

작업이 끝났는지는 에이전트의 말이 아니라 실제로 돌려 본 결과가 정합니다.

그러니 끝에 가서 결과물을 하나하나 뜯어볼 필요가 없습니다. 정한 대로 됐는지만 보면 됩니다. 검토에 쓰던 시간이 결정에 쓰입니다.

---

이렇게 쓰면 사람 혼자서는 못 하던 일을 하게 됩니다. 에이전트를 쓰는 이유가 원래 그거였습니다. 에이전트는 앞으로도 계속 좋아지고, 의도를 모른 채 빨라지면 엉뚱한 걸 만드는 속도도 같이 빨라집니다.

에이전트를 잘 쓰는 법은 결국 하나입니다. 제대로 묻게 하는 것.

Dryforge는 에이전트에 붙여 쓰는 플러그인입니다. 하고 싶은 걸 ready에 던지고, 정리된 의도를 승인한 뒤 go를 부르면 됩니다.

한 번 써 보세요. 생각 못 한 질문부터 받게 될 겁니다.