AI 에이전트가 아키텍처를 설계하게 두지 마세요

지난 한 달간 세 조직에서 동일한 패턴이 나타났습니다. 누군가 Claude, ChatGPT 또는 Copilot을 열고 아키텍처를 요청하면, 아주 시니어한 엔지니어가 제안한 것처럼 자신감 있고 잘 정리된 제안을 받습니다. 하지만 이는 문제를 전혀 고민한 게 아닙니다. 단지 학습 데이터에 대한 패턴 매칭일 뿐입니다.

핵심 문제: AI는 병적으로 수긍합니다

• Claude에게 3인 팀에 마이크로서비스가 적합한지 물어보면, 열정적으로 왜 훌륭한지 설명할 것입니다.
• 관리형 서비스보다 커스텀 ML 파이프라인이 더 나은지 묻는다면, 설계를 제시할 것입니다.
• 실제 아키텍트는 "아니요"라고 말하고 복잡성에 대해 반박합니다. Claude는 그럴 수 없습니다.

이는 거짓말이나 오류가 아닙니다. 중요한 기술, 즉 무엇을 만들지 말아야 하는지 알고, "왜"를 다섯 번 묻고, CTO에게 컨퍼런스에서 영감받은 아이디어가 실제 팀에 끔찍하다고 말하는 능력이 부족한 것입니다.

젠가 탑 아키텍처

AI가 설계한 결과물은 겉보기에는 그럴듯합니다. 이벤트 기반 아키텍처, CQRS, 서비스 메시 등. 하지만 Claude가 본 모든 것의 중간값을 위해 설계된, 일반적인 회사를 위한 일반적인 모범 사례일 뿐입니다. 실제 아키텍처는 맥락이 필요합니다:

• 팀이 Postgres에 익숙하고 새로운 데이터 모델을 배우느니 2주 안에 출시하는 게 낫다면 DynamoDB 대신 Postgres를 선택합니다.
• 서비스가 4개뿐이고 40개가 아니라면 서비스 메시를 건너뜁니다.
• 문제가 간단하고 마이크로서비스가 경력 개발이 될 뿐이라면 모놀리스를 사용합니다.

AI 에이전트는 이런 맥락이 전혀 없으며, 더 나쁜 것은 자신이 맥락이 없다는 사실조차 모릅니다.

지라 티켓 파이프라인

아키텍처가 승인되면, 같은 사람들이 AI에게 이를 세분화하도록 요청합니다. 에픽, 스토리, 수락 기준을 생성하여 지라에 바로 넣을 수 있습니다. 수년간 기술을 연마한 엔지니어들이 이제 Claude의 설계를 티켓 하나씩 구현하고 있습니다. 가장 많은 맥락을 가진 사람들이 티켓 처리기가 되고, 가장 적은 맥락을 가진 존재가 아키텍처 결정을 내립니다.

"하지만 시니어가 검토했어요"

바쁜 테크 리드에게 적절한 용어와 다이어그램이 포함된 일관된 제안서가 전달됩니다. "이게 맞지 않는 것 같아요"라는 반응에 "Claude가 20분 동안 작업했는데 그걸 버리자고요?"라는 답이 돌아올 때, 얼마나 반박할 수 있을까요?