에이전트에게 목표만 대충 던져주고 알아서 하게 두는 쪽이 효율적이라는 이야기가 요즘 자주 들립니다. 그런데 이건 효율이 아닙니다. 비용을 뒤로 미루는 것에 가깝습니다.

O’Reilly Radar에 실린 에세이가 에이전틱 개발에서 스펙을 얼마나 줘야 하는지를 다룹니다. 짧은 프롬프트 하나로 시작하면 당장은 빠릅니다. 하지만 그 뒤로 결과를 검토하고, 의도를 다시 설명하고, 수정을 요청하는 교정 루프가 이어집니다. 결국 결과가 원래 목표와 맞는지 판단하는 사람이 필요해지고, 그 사람이 실질적인 검증 기준(오라클) 역할을 떠맡게 됩니다.

출처: The Right Amount of Spec for Agentic Development – O’Reilly Radar

병목은 사라진 게 아니라 옮겨갔다

소프트웨어 개발의 본질은 원래 타이핑이나 코드 생산이 아니었습니다. 무엇이 존재해야 하는지, 무엇이 절대 일어나면 안 되는지를 결정하는 일이었습니다. 어떤 트레이드오프가 중요한지, “완료”가 무엇을 뜻하는지도 그 결정에 포함됩니다.

그동안은 이런 결정이 빠진 부분을 사람이 부딪히며 찾아냈습니다. 리뷰어가 예외 상황을 짚어내고, QA가 아무도 설명 안 한 경로를 발견했습니다. 시니어 엔지니어는 진짜 요구사항 절반을 머릿속에 담아두고 회의 때마다 그때그때 풀어냈습니다. 우아하진 않아도, 이 과정이 모호함을 밖으로 끌어내는 역할을 했습니다.

에이전트는 이 구조를 근본적으로 바꿔놓습니다. 구현이 훨씬 저렴하고 빨라졌기 때문입니다. 제대로 정의되지 않은 아이디어도 누구 하나 제대로 합의하기 전에 그럴듯한 시스템으로 완성될 수 있습니다.

예전에는 애매한 요구사항이 사람의 느린 속도에 부딪혀 걸러졌습니다. 지금은 그 애매함이 기계의 속도 그대로 시스템에 반영되죠. 스펙이 갑자기 다시 중요해진 것처럼 보이는 이유입니다. 사실 스펙은 원래부터 중요했습니다. 그저 구현 비용이 비쌌기 때문에, 그 비용 자체가 거칠게나마 스펙을 강제하는 역할을 대신 해줬을 뿐입니다.

스펙을 쓰는 것과 스펙이 맞는지 확인하는 것은 다른 일이다

사람들이 가장 자주 건너뛰는 단계가 있습니다. “스펙을 쓰고, 에이전트가 그대로 구현한다”는 순서가 전부인 것처럼 이야기합니다. 정작 빠진 건 그 사이에 있는, 비용이 드는 단계입니다. 스펙 자체도 검증받아야 한다는 것.

아무리 꼼꼼하게 쓴 스펙도 익숙한 방식으로 실패합니다. 스스로 모순되는 경우도 있고, 정상 경로만 다루고 재시도나 부분 실패 같은 상황은 아무 말도 하지 않는 경우도 있습니다. 정확해 보이지만 실제로는 검증할 방법이 없는 서술도 있죠. 때로는 정확하긴 한데 엉뚱한 방향으로 정확합니다. 의도한 바가 아니라 글자 그대로 쓰인 것만 정확한 경우입니다.

에이전트가 이런 결함 있는 스펙을 충실하게 그대로 실행하면, 실패 원인을 찾기가 더 어려워집니다. 결과물은 그럴듯해 보입니다. 심지어 미리 정해둔 검사도 통과할 수 있습니다. 하지만 진짜 문제는 스펙 그 자체에 있어서, 코드와 논리를 함께 다시 풀어야 합니다.

그래서 스펙 검증에는 별도의 단계가 필요합니다. 구현을 시작하기 전에 몇 가지를 물어야 합니다. 이 스펙이 내적으로 일관된지, 이 작업에 충분할 만큼 완결됐는지. 어느 부분이 실제로 테스트 가능한지, 어디를 여전히 사람의 판단에 맡기고 있는지. 모두가 암묵적으로 가정해서 빠뜨린 실패 상황은 없는지도 확인해야 합니다.

이 검증 단계에 에이전트를 활용하는 방법도 있습니다. 한 에이전트에게 최소한의 스펙 초안을 쓰게 합니다. 다른 에이전트가 실제로 구현할 수 있을 만큼만요. 그 초안을 또 다른 에이전트에게 넘겨 공격하게 합니다. 모순되는 지점, 애매한 표현, 검증 불가능한 주장, 빠진 실패 상황을 찾아내라고 시키는 겁니다. 이 정도의 간단한 절차만으로도, 사람의 판단을 들일 만한 수준의 스펙에 도달하는 비용이 낮아집니다.

스펙에도 유효기간이 있다

여기서 팀들이 흔히 저지르는 또 다른 실수가 있습니다. 스펙 곡선을 계속 밀어붙이면서, 텍스트를 더 많이 쓸수록 더 안전해진다고 여기는 것. 적어도 지금의 모델들에는 해당하지 않는 이야기입니다.

입력이 길어질수록 모델의 성능은 단순한 작업에서조차 덜 안정적으로 변합니다. 코딩 프로젝트에는 여기에 겹치는 문제가 하나 더 있습니다. 설계 문서, 예시, 계획, 코멘트, 티켓, 오래된 승인 기준을 컨텍스트에 계속 쌓아 넣을수록, 어느 부분이 지시사항이고 어느 부분이 그냥 남은 기록물인지 구분하기가 점점 어려워집니다.

이건 보안 의미의 프롬프트 인젝션과는 다릅니다. 누가 모델을 공격하려는 게 아닙니다. 스스로 만들어낸 지시사항 혼선에 가깝습니다. 컨텍스트 안에는 오래된 설계 의도가 있습니다. 지금의 실제 구현도 있습니다. 절반쯤만 유효한 예시, 몇 세션 전에 만든 계획, 이미 존재하지 않는 클래스를 여전히 설명하는 낡은 설계 문서까지 뒤섞여 있습니다. 이쯤 되면 모델은 스펙 하나를 읽는 게 아닙니다. 서로 경쟁하는 여러 정보 출처를 평균 내고 있는 셈입니다.

설계 문서는 코드가 아직 존재하지 않는 초반에는 유용합니다. 하지만 인터페이스와 테스트, 불변 조건이 실제로 갖춰진 뒤에는 그 상세한 계획서가 줄어들어야 하죠. 그렇지 않으면 결국 스펙이 두 개가 됩니다. 하나는 사람이 참고하는 것, 다른 하나는 에이전트가 참고하는 것. 사람은 리뷰 과정에서 이 불일치에 불만을 갖습니다. 에이전트는 종종 둘 다 지키려 애쓰다가 오히려 더 헷갈려합니다.

결국 정답은 두 극단 어느 쪽도 아닙니다. 스펙을 아예 안 쓰는 것도, 한번 쓴 스펙을 끝없이 쌓아두는 것도 둘 다 대가를 치릅니다. 필요한 만큼의 구조로 작업 범위를 잡아주고, 의도를 구체화할 예시를 곁들이고, 검토가 추측 게임으로 변하지 않을 실행 가능한 확인 장치를 두는 것. 코드와 테스트, 인터페이스가 실제로 자리 잡으면, 한때 필요했던 상세한 설계 문서는 제때 정리하는 것. 그 사이 어딘가가 대부분의 에이전틱 작업에 맞는 지점입니다.