에이전트, 잘못 쓰고 계셨습니다.

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

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

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

이렇게 대놓고 말하는 에이전트는 없습니다. 그런데 일하는 순서는 정확히 이렇습니다. 사용자가 뭘 만들고 싶은지 말하기도 전에, 테스트를 언제 쓸지, 일을 몇 단계로 나눌지, 에이전트를 몇 개 띄울지가 이미 다 정해져 있습니다.

사용자의 요구는 그 순서에 맞춰서만 받아들여집니다. 순서에 맞는 요구는 반영되고, 안 맞는 요구는 슬그머니 빠집니다. 빠졌다는 걸 아는 사람은 없습니다. 에이전트도, 사용자도.

에이전트는 이미 일할 줄 압니다

요즘 에이전트는 코드를 읽고, 구조를 파악하고, 테스트를 돌리고, 실패하면 고칩니다. 1년 전만 해도 사람이 옆에 붙어 하나하나 알려 줘야 했던 일입니다.

그런데 틀리는 방식은 그대로입니다. 시키지 않은 걸 하고, 묻지 않은 걸 정하고, 끝나지 않은 걸 끝났다고 합니다. 설명만 해 달라고 했는데 코드가 바뀌어 있습니다. 게시판 목록을 만들어 달라고 했더니 페이지 번호 대신 무한 스크롤을 붙여 놓습니다. 어느 쪽이 좋은지는 묻지도 않습니다. 다 됐다고 해서 열어 보면 절반이 비어 있습니다.

에이전트가 멍청해서 이러는 게 아닙니다. 더 좋은 모델로 바꿔도 이런 실수는 그대로입니다. 에이전트가 모르는 건 일하는 법이 아니라 사용자의 의도이기 때문입니다. 의도는 모델이 커진다고 생기지 않습니다. 사용자 머릿속에 있습니다.

묻는 대신 절차를 만들었습니다

의도를 모르면 물어보면 됩니다. 그런데 업계는 묻는 대신 절차를 만들었습니다. 절차는 만드는 쪽에서 보면 편합니다. 한 번 만들어 두면 누구 일이든 똑같이 돌릴 수 있고, 일하는 티도 잘 납니다.

물어야 할 건 안 묻고, 안 물어도 될 건 묻습니다

질문도 절차 안에 들어갔습니다. 무슨 일이든 미리 정해 둔 질문 목록을 순서대로 묻습니다.

결제 기능을 붙여 달라고 해 봅시다. 에이전트는 어떤 프레임워크를 쓰는지, 데이터베이스는 뭔지 묻습니다. package.json만 열어 봐도 나오는 것들입니다. 정작 환불은 어떻게 처리할지, 결제가 중간에 끊기면 어떻게 할지는 묻지 않습니다. 절차에 그 항목이 없으니까요.

그 결정은 에이전트가 조용히 내리고, 사용자는 한참 뒤에 고객 문의로 알게 됩니다. 가장 위험한 질문은 끝내 나오지 않은 질문입니다.

테스트부터 써도 틀린 건 틀립니다

테스트부터 쓰라는 규칙은 설정 파일 한 줄에도, 결제 로직에도 똑같이 적용됩니다.

테스트는 원하는 동작을 코드로 적어 둔 것입니다. 원하는 게 잘못 전달됐다면, 테스트부터 써 봐야 잘못된 걸 한 번 더 적는 셈입니다. 같은 에이전트가 테스트와 코드를 둘 다 쓰면, 테스트는 코드가 한 일을 그대로 확인해 줄 뿐입니다. 테스트가 통과했다는 건 에이전트가 자기 답을 자기가 채점했다는 뜻입니다. 통과하지 못하면 아예 테스트를 고쳐 버리는 에이전트도 흔합니다.

테스트가 쓸모없다는 얘기는 아닙니다. 결제 로직에는 엄밀한 테스트가 필요하고, 설정 파일 한 줄에는 필요 없습니다. 어디에 얼마나 테스트를 쓸지는 규칙이 아니라 그 일이 얼마나 위험한지에 달렸습니다.

에이전트를 다섯 띄워도 모르는 건 똑같습니다

PM 에이전트가 요구 사항을 쓰고, 아키텍트 에이전트가 설계하고, 개발 에이전트가 짜고, QA 에이전트가 검사합니다. 그럴듯해 보이지만, 사실은 같은 모델이 PM인 척, 개발자인 척하는 것뿐입니다.

이 팀에서 사용자의 의도를 아는 에이전트는 하나도 없습니다. 모르는 걸 다섯이서 짐작하고, 그 짐작을 서로 검토해 줍니다. 토큰은 다섯 배로 나가는데, 사람들은 그걸 일이 잘 돌아가는 거라고 여깁니다. 토큰을 얼마나 태웠는지가 자랑이 되는 시대입니다.

병렬 작업 자체는 좋은 도구입니다. 서로 상관없는 조사를 동시에 돌릴 때는 확실히 빠릅니다. 문제는 필요해서가 아니라 바빠 보이려고 띄우는 에이전트입니다.

다 묻는 건 안 묻는 것만 못합니다

에이전트가 묻는 방식은 둘 중 하나입니다. 아예 안 묻거나, 전부 묻거나.

안 묻는 쪽이 왜 위험한지는 앞에서 봤습니다. 그래서 나온 게 전부 묻는 방식입니다. 파일 하나 고칠 때도, 명령 하나 돌릴 때도, 계획을 세울 때도, 계획을 바꿀 때도 확인 창이 뜹니다.

처음 몇 번은 읽습니다. 스무 번째쯤 되면 읽지도 않고 '예'부터 누릅니다. 300줄짜리 계획서를 끝까지 읽고 승인하는 사람은 거의 없습니다. 이렇게 되면 질문은 사용자를 지키지 못합니다. 나중에 문제가 터졌을 때 "승인하셨잖아요"라는 말만 남습니다. 차라리 안 물었으면 에이전트 탓이라도 할 수 있었을 겁니다.

질문은 드물어야 제대로 읽힙니다. 사용자만 정할 수 있는 것만 물어야, 사용자가 멈추고 생각합니다.

절차는 모델보다 빨리 낡습니다

이런 절차에는 공통점이 하나 더 있습니다. 일을 보기도 전에, 그 시점의 모델에 맞춰 만들어졌다는 점입니다.

약한 모델은 단계를 쪼개 주면 더 잘했습니다. 그래서 단계를 쪼갰습니다. 자주 틀리니까 규칙을 더했습니다. 틀릴 때마다 규칙 파일이 한 줄씩 늘었습니다. 그렇게 쌓인 규칙 파일은 결국 지난 실패들의 목록입니다.

새 모델이 나오면 절차가 어긋나기 시작합니다. 더 똑똑한 모델이 옛 모델에 맞춰 짠 순서에 묶여서 오히려 이상하게 움직입니다. 그러면 사람들은 모델이 멍청해졌다고 말합니다. 욕은 모델이 먹고, 절차는 또 뜯어고칩니다. 다음 모델이 나오면 또 뜯어고칩니다.

지금 쓰는 워크플로는 다음 모델이 나오는 날 레거시가 됩니다.

방법이 아니라 순서가 틀렸습니다

여기까지 읽고 절차를 전부 버리라는 말로 들렸다면 반만 맞습니다. 테스트도, 병렬 작업도, 사람 확인도, 문서도 필요합니다. 틀린 건 그걸 언제 정하느냐입니다.

의도가 방법을 정해야 하는데, 지금은 방법이 의도를 정합니다.

의도가 분명하면 방법은 따라 나옵니다. 결제 로직이면 테스트가 따라오고, 조사할 게 많으면 병렬 작업이 따라오고, 되돌리기 어려운 결정이면 사람 확인이 따라옵니다. 방법부터 정하는 건 꼼꼼한 게 아닙니다. 아무도 먼저 듣지 않았다는 뜻일 뿐입니다.

그렇다고 에이전트를 그냥 풀어 주면 반대로 실패합니다. 아무도 정하지 않은 부분을 그럴듯한 추측으로 채우고, 사용자가 뭘 뜻했는지까지 제멋대로 정합니다. 석 달 뒤에는 왜 이렇게 만들었는지 아무도 모르는 코드가 남습니다. 꽉 조이면 절차에 갇히고, 풀어 주면 짐작으로 채웁니다. 어느 쪽이든 사용자가 원한 것과는 멀어집니다.

답은 그 사이에 있습니다. 에이전트가 알아낼 수 있는 건 묻지 말고 알아내야 합니다. 사용자가 정할 건 절대 짐작하면 안 됩니다. 짐작할 바에는 멈추고 물어야 합니다. 그 질문은 절차에 있어서가 아니라, 그 결정이 사용자 몫이라서 나와야 합니다.

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

에이전트는 앞으로도 계속 좋아질 겁니다. 더 빨리, 더 많이 만들 겁니다. 그래도 뭘 만들어야 하는지는 모델이 아무리 좋아져도 알 수 없습니다. 그건 사용자만 압니다. 에이전트가 빨라질수록 엉뚱한 걸 만드는 속도도 같이 빨라집니다.

필요한 건 절차를 더 쌓는 게 아닙니다. 사용자가 정해야 할 것만 사용자에게 묻고, 나머지는 에이전트가 끝까지 해내게 하는 겁니다. 그러면 결과물을 받고 "이게 내가 원한 게 맞나" 하고 따져 볼 일이 없습니다. 중요한 건 전부 사용자가 직접 정했으니까요.

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