AI 코딩 에이전트를 위한 신뢰성 검사는 어디서 이루어져야 할까?

첫 번째 체크는 애초에 그 작업이 위임 가능한 상태인지 확인하는 것부터 시작해야 한다고 봐. 명확한 인수 조건(AC), 실패 조건, 비목표, 엣지 케이스, 그리고 성공을 증명할 증거 같은 것들 말이야. 워크플로우에서 AC가 엉망일 때 보통 뭐가 빠져 있어? 엣지 케이스, 예시, 비목표, 테스트 기대치, 아니면 담당자 승인?

내 경험상 가장 큰 문제는 티켓의 세부 사항이나 테스트, AC 같은 게 아니야. 가장 큰 문제는 양쪽 다 상대방이 실제로 뭘 원하는지 완전히 이해하지 못했다는 거지. 그 부분이 이해되면 테스트나 AC 같은 건 자연스럽게 정렬될 거야. 목표를 제대로 이해할수록 불일치는 자연스럽게 줄어들겠지. 물론 인센티브가 일치한다는 전제하에 말이야.

맞아, 정말 공감됨. 에이전트는 새로운 실수를 만들어낼 뿐만 아니라, 잘못된 핸드오프를 아주 빠르게 증폭시킬 수 있음. 그렇다면 첫 번째로 유용한 검사는 에이전트가 잘 행동했는지가 아니라, 이 작업을 위임해도 안전한 상태인가일지도 모르겠음. 아키텍처 경계, 가정, 수락 기준, 보안 민감 영역은 코딩 시작 전에 명확히 해야 할 것 같음. 코딩 전에 가장 강력한 검사를 원한다고 했는데, 구체적으로 무엇을 검사하고 싶음? 아키텍처 경계, 수락 기준, 보안 위험 등?

궁금한 게 있는데, 제품/아키텍처 승인을 위해 코딩 에이전트가 초기 계획을 초안으로 작성하게 둘 거야, 아니면 제품/아키텍처 쪽에서 먼저 경계를 정의하고 에이전트는 그 안에서만 계획하게 할 거야?

누가 먼저 초안을 작성하든 상관없다고 봐. 적절한 오너들이 스펙을 검증하기만 한다면 말이지. 제품 오너나 엔지니어들이 검증을 위해 스펙을 가져오게끔 강제하는 편이야. 에이전트에게 모든 맥락을 미리 줬는지, 아니면 에이전트가 초안을 만들게 했는지는 중요하지 않아. 내가 보는 건 그들이 수동으로 작업하느라 시간을 낭비하지 않는지뿐이야. 한 명은 하루 만에 스펙 초안을 가져오는데 다른 한 명은 비슷한 작업에 2주가 걸린다면, 누가 AI를 제대로 못 쓰고 있는지 뻔하잖아.

솔직히 이에 대한 유일한 해결책은 걱정되는 문제들을 '불가능'하게 만드는 명확하게 정의된 테스트를 통과시키는 것임. 모든 걸 테스트할 수는 없고 그래서도 안 되지만, 계속 발생하는 문제를 일관되게 막을 수 있는 유일한 방법임. 이에 대한 책임은 구현하는 사람에게 있어야 하고, PR 리뷰는 실제로 무엇이 테스트되었는지 논의하는 자리가 되어야 한다고 생각함. 다른 방법은 안 보임.

시스템을 완전히 이해할 수 없다면, 신뢰할 수 있을 만큼 일관된 프록시가 필요해. 그래서 AI 코드의 경우, 유용한 리뷰는 코드 한 줄 한 줄을 읽는 것보다 이 변경 이후에 불가능해져야 할 것이 무엇인지, 그리고 그걸 증명할 테스트가 무엇인지 묻는 쪽으로 가야 할 것 같아. 내가 파악하려는 건 그런 테스트들이 어디서 정의되어야 하느냐는 거야. 예상되는 테스트나 인수 체크가 에이전트가 시작하기 전에 작성되어야 한다고 봐, 아니면 구현자나 에이전트가 PR에서 제안해도 괜찮다고 생각해?

성공 기준은 모호할 수 있지만, 실패 조건은 인간이 무엇이 허용 불가능한 결과인지 명확히 말하게끔 강제해. 양쪽 모두에게 유용한 것 같아. 인간은 자신이 실제로 신경 쓰는 게 뭔지 명확히 해야 하고, 에이전트는 테스트할 구체적인 기준을 얻으니까. 까다로운 건 빌드 중의 반복 작업이야. AI가 새로운 엣지 케이스를 발견하고 테스트를 업데이트하는 건 좋지만, 이미 만들어놓은 결과물에 맞춰 목표를 조용히 바꿔버리는 건 나쁜 거거든. 그건 어떻게 처리할 거야?