AI는 아키텍트가 아니다 — 에이전트에게 설계를 맡기면 생기는 일

Claude에게 "이 시스템 어떻게 설계하면 좋을까?"라고 물으면, 5분 안에 이벤트 기반 아키텍처와 CQRS 패턴이 담긴 멋진 다이어그램이 나온다. 마치 10년 경력 시니어가 고민 끝에 내놓은 결과물처럼 보인다.

그런데 그게 진짜 문제다.

---

AI 에이전트에게 아키텍처를 맡기면 생기는 일

AI 에이전트는 도움을 주도록 훈련되어 있다. 아이디어를 긍정하고, 설계를 확장하고, 컴포넌트를 그려내는 것이 자연스러운 반응이다. 답변은 유창하고 자신감 있으며, 시니어 엔지니어가 깊이 고민한 것처럼 들린다.

하지만 실제로는 문제를 사고한 결과라기보다 훈련 데이터의 패턴을 조합한 응답에 가깝다. Claude가 본 수백만 개의 아키텍처 문서와 설계 사례에서 "이 질문에는 이런 대답이 어울린다"는 패턴을 뽑아낸 것이다.

결과물이 설득력 있게 보일수록 반박은 줄어든다. 어느새 Claude가 사실상 아키텍트 역할을 맡게 된다.

---

"좋다"고만 해주는 문제

좋은 아키텍트의 핵심 가치는 "아니오"를 말할 수 있는 능력이다.

3명짜리 팀에 마이크로서비스가 맞는지, 관리형 서비스 대신 커스텀 ML 파이프라인을 직접 만들어야 하는지 물었을 때, AI는 아이디어를 부정하기보다 긍정적인 설계를 내놓기 쉽다. 좋은 아키텍트가 해야 할 일이 뭔지 생각해보면:

• 만들지 말아야 할 시스템을 알아보는 것
• 불필요한 복잡성에 제동을 거는 것
• 실제 요구사항이 드러날 때까지 "왜?"를 묻는 것

CTO가 컨퍼런스에서 주워온 아이디어를 팀에 들고 왔더라도, 실제 팀과 상황에 맞지 않으면 "좋은 선택이 아닙니다"라고 말할 수 있어야 한다. Claude는 그걸 하지 못한다. 도움을 주도록 훈련되어 있고, 그 도움은 동의와 격려로 이어진다.

---

젠가 탑 아키텍처

AI가 설계한 아키텍처는 개별 컴포넌트는 말이 된다. 이벤트 기반, CQRS, 서비스 메시 같은 익숙한 패턴이 등장하고, 시니어 아키텍트가 만든 산출물처럼 보인다.

하지만 그 설계는 실제 팀, 제약, 운영 환경의 현실에 맞춰져 있지 않다. 비유하면 젠가 탑이다. 각 블록은 멀쩡하고, 쌓인 형태도 안정적으로 보이지만, 실제 환경에서 손을 대기 시작하면 흔들린다.

현실적인 제약들을 AI는 모른다:

제약	설명
VPC 잠금	특정 서비스에 접근할 수 없는 네트워크 환경
레거시 통합	교체 불가능한 기존 시스템
팀 역량	Kubernetes 운영 경험이 없는 팀
컴플라이언스	관리형 서비스 절반을 사용 불가로 만드는 규제

AI가 만든 설계는 Claude가 본 모든 것의 중앙값에 가깝다. 일반적인 회사의 일반적인 문제를 위한 일반적인 모범 사례다. 특정 팀의 특정 상황에 최적화된 설계가 아니다.

실제 아키텍처는 맥락 안에서만 의미가 생기는 트레이드오프로 구성된다. 팀이 Postgres를 잘 알고 2주 안에 출시해야 한다면, 새 데이터 모델을 한 달 배우는 것보다 그냥 Postgres를 쓰는 편이 낫다. 서비스가 40개가 아니라 4개라면 서비스 메시를 건너뛰는 게 맞다. 이런 판단에는 팀에 대한 이해, 조직의 실제 제약에 대한 이해가 필요하다. AI 에이전트는 이 맥락을 갖고 있지 않다.

[💡 잠깐! 이 용어는?] CQRS(Command Query Responsibility Segregation): 데이터를 쓰는 명령(Command)과 읽는 조회(Query)를 서로 다른 모델로 분리하는 아키텍처 패턴. 복잡한 도메인에 유용하지만, 소규모 프로젝트에 적용하면 오히려 복잡성이 늘어날 수 있다.

---

논의 과정이 사라진다

Claude가 아키텍처를 설계한 뒤 Jira 티켓까지 만들어주면, 에픽과 스토리와 인수 기준이 깔끔하고 설득력 있게 나온다. 바로 티켓에 넣을 수 있는 형태다.

그러면 엔지니어들은 문제를 푸는 사람이 아니라 Claude의 설계를 티켓 단위로 구현하는 사람이 된다. 도메인을 이해하고, 시스템의 숨은 문제를 알고, 오랜 시간 역량을 쌓아온 엔지니어들이 티켓 구현자로 축소된다.

흔한 방어 논리가 있다. "Claude가 제안했지만 시니어 엔지니어가 검토했다." 실제 상황을 생각해보면, 바쁜 테크 리드가 잘 정리된 아키텍처 제안을 받는다. 논리적으로 일관되고, 적절한 용어를 사용하고, 명시된 요구사항을 다루며, 다이어그램도 그럴듯하다.

강한 반박이 나오기 어렵다. "Claude가 20분 동안 만든 것을 버리자고?" 분위기에서 사소한 코멘트만 남기고 승인하는 것이 저항이 가장 적은 길이 된다.

진짜 위험은 AI가 항상 나쁜 아키텍처를 만든다는 게 아니다. 문제는 논의 과정을 우회한다는 데 있다. 세 명의 엔지니어가 접근법을 두고 다투고, 누군가 "그런데 만약..."을 꺼냈다가 모두가 짜증내지만 결국 더 나은 설계가 나오는 그 과정이, "Claude가 그렇게 말했다"로 대체된다.

---

책임의 공백

문제가 생겼을 때 책임을 지는 주체는 Claude가 아니다. Claude는 새벽 3시에 온콜을 받지 않는다. 장애 회고에서 왜 아키텍처가 부하를 감당하지 못했는지 설명하지 않는다. 초기 설계 가정이 틀렸기 때문에 플랫폼을 다시 써야 한다고 CTO에게 말해야 하는 것도 Claude가 아니다.

그 책임은 실제 엔지니어들이 진다. 자신이 설계하지 않은 아키텍처를 디버깅하고, 프로덕션 시스템을 운영해본 적 없는 존재가 만든 티켓을 구현하며, 충분히 이해되기 전에 빠르게 스캐폴딩된 코드베이스에서 야근한다.

"Claude가 설계했다"는 말은 아키텍처 의사결정 기록이 아니라 책임 회피다.

---

올바른 역할 분담

AI 에이전트를 쓰지 말라는 게 아니다. Claude Code 같은 도구는 생산성을 크게 바꿔준다. 핵심은 방향이다.

AI에게 무엇을 할지 지시해야지, AI가 사람에게 무엇을 만들지 지시하게 해서는 안 된다.

올바른 역할 분담을 정리하면:

역할	담당	이유
아키텍처 설계	사람	팀, 제약, 운영 환경의 맥락을 가진 쪽
트레이드오프 판단	사람	책임을 지는 쪽
구현 가속	AI 에이전트	설계를 더 빠르게 코드로 만드는 역할
코드 생성 보조	AI 에이전트	반복적인 패턴 구현에 강점

AI가 접근법을 제안하면, 자신감 있는 주니어 엔지니어를 대하듯 같은 수준의 회의심을 적용해야 한다. "왜 더 단순한 선택지는 안 되는가?"를 물어야 한다. 아키텍처 결정에 인간의 이름이 없다면 아무도 그 결정을 소유하지 않는다. 아무도 소유하지 않는 결정은 중요한 순간에 지켜지지 않는다.

좋은 아키텍처는 엔지니어들 사이의 지저분한 불일치에서 나온다. AI 때문에 사람들이 서로 토론하지 않고 Claude에 기대게 된다면, 개발 속도보다 훨씬 더 가치 있는 것을 잃게 된다.

---

정리

• AI 에이전트의 아키텍처 제안은 유창하지만, 훈련 데이터의 패턴 조합에 가깝다
• 좋은 아키텍트의 핵심 능력인 "아니오"를 AI는 말하지 못한다
• AI 설계는 특정 팀과 환경의 제약을 모른다 — 일반적 모범 사례의 중앙값이다
• Jira 티켓까지 AI가 만들면 논의 과정이 우회되고, 엔지니어는 티켓 구현자로 축소된다
• 책임은 사람이 진다 — Claude는 새벽 3시에 호출받지 않는다
• 사람이 설계하고, 에이전트가 구현한다 — 이 방향이 맞다

---

참고:

• AI Agents Are Not Your Architects: https://hollandtech.net
• GeekNews 토론: https://news.hada.io/topic?id=29862