Claude는 당신의 아키텍트가 아니다. 그런 척하게 두지 말라

AI 에이전트가 설계자 역할을 맡을 때 발생하는 structural 문제

Claude는 당신의 아키텍트가 아니다. 그런 척하게 두지 말라

최근 개발자 커뮤니티에서 화제가 된 글이 있다. "Claude는 당신의 아키텍트가 아니다. 그런 척하게 두지 말라"는 제목의 에세이는, AI 에이전트가 설계자 역할을 맡을 때 발생하는 구조적 문제를 날카롭게 분석한다. 화이트보드에 강하게 의견을 담은 시대에서, 며칠 걸리던 것을 몇 분 만에 만들어내는 AI 에이전트 시대에 아키텍처의 본질은 변하지 않았다는 것이 저자의 주장이다.

AI가 설계자 흉내를 내는 순간 발생하는 문제

Claude, ChatGPT, Copilot 같은 AI 에이전트에 "무엇을 만들어야 하는지"를 묻는 순간, 아이디어를 긍정하고 아키텍처를 제안하며 컴포넌트를 그려내는 흐름이 자연스럽게 시작된다. 답변은 유창하고 자신감 있으며, 시니어 엔지니어가 깊이 고민한 것처럼 들린다. 그러나 실제로는 문제를 사고한 결과라기보다 훈련 데이터의 패턴에 맞춘 응답에 가깝다. 결과물이 설득력 있게 보일수록 반박은 줄어들고, 어느새 Claude가 사실상 아키텍트 역할을 맡게 된다.

AI 에이전트는 아이디어가 좋은지, 3명짜리 팀에 마이크로서비스가 맞는지, 관리형 서비스 대신 커스텀 ML 파이프라인을 만들어야 하는지 물어도 긍정적인 설계를 내놓기 쉽다. 이것이 항상 틀린 답은 아니지만, 좋은 아키텍트에게 중요한 능력인 "아니오"라고 말하기를 제대로 수행하지 못한다.

젠가 탑 같은 아키텍처의 함정

AI가 설계한 아키텍처는 겉보기에는 기술적으로 타당해 보인다. 개별 컴포넌트는 논리적으로 말이 되고, 이벤트 기반, CQRS, 서비스 메시 같은 익숙한 패턴이 등장하며, 시니어 아키텍트가 만든 산출물처럼 보일 수 있다. 하지만 그 설계는 실제 팀, 제약, 운영 환경의 지루한 현실에 맞춰져 있지 않을 수 있다.

프로덕션에서 Kubernetes를 운영해본 적 없는 팀, 관리형 서비스 절반을 사용할 수 없게 만드는 컴플라이언스 요구사항, VPC 잠금 레거시 통합 같은 상황은 AI가 만든 일반적인 모범 사례와 충돌한다. 실제 아키텍처는 맥락 안에서만 의미가 생기는 트레이드오프로 구성된다. Postgres를 알고 있고 2주 안에 출시하는 편이 새 데이터 모델을 한 달 배우는 것보다 낫다면, DynamoDB 대신 Postgres를 선택하는 것이 올바른 결정이다.

Jira 티켓 파이프라인이라는 책임 회피 구조

Claude가 아키텍처를 설계한 뒤 작업 분해까지 맡으면, 에픽, 스토리, 인수 기준이 깔끔하고 설득력 있게 생성된다. 이 칸반은 바로 Jira에 넣을 수 있는 형태가 되며, 엔지니어들은 문제를 푸는 사람이 아니라 Claude의 설계를 티켓 단위로 구현하는 사람이 된다.

도메인을 이해하고, 시스템의 숨은 문제를 알고, 오랜 시간 역량을 쌓아온 엔지니어들이 티켓 구현자로 축소되는 것이다. 가장 많은 맥락과 경험과 책임을 가진 사람들이 결정을 내리지 않고, 맥락도 경험도 책임도 없는 존재가 아키텍처 결정을 내리는 구조가 된다.

시니어가 검토했다는 방어 논리의 빈틈

흔한 방어는 "Claude가 접근법을 제안했지만 시니어 엔지니어가 검토했다"고 주장하는 것이다. 실제 검토 상황에서는 바쁜 테크 리드가 잘 정리된 아키텍처 제안을 받게 된다. 논리적으로 일관되고, 적절한 용어를 사용하며, 명시된 요구사항을 다루고, 다이어그램도 그럴듯하다. 자신이 설계했을 법한 결과처럼 보인다.

이런 상황에서 강한 반박이 나오기 어렵고, "Claude가 20분 동안 만든 것을 버리자는 것이냐?"라는 분위기에서는 사소한 코멘트만 남기고 승인하는 것이 저항이 가장 적은 길이 된다. 진짜 위험은 AI가 항상 나쁜 아키텍처를 만든다는 데 있지 않다. AI는 종종 꽤 합리적인 아키텍처를 만들지만, 문제는 논의 과정을 우회한다는 데 있다.

책임의 공백이 만드는 실질적 피해

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

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

올바른 역할 분담: 사람이 설계하고, AI가 구현한다

AI 에이전트를 사용하지 말라는 뜻은 아니다. Claude Code처럼 생산성을 크게 바꿔주는 도구로 활용할 수 있다. 핵심은 AI에게 무엇을 할지 지시해야지, AI가 사람에게 무엇을 만들지 지시하게 해서는 안 된다는 점이다.

엔지니어가 설계하고 에이전트가 구현해야 한다. 아키텍처는 팀, 제약, 프로덕션 환경, 조직 정치 같은 맥락을 이해하는 사람들에게서 나와야 하며, AI는 그들이 설계한 것을 더 빠르게 만드는 데 도움을 주는 역할이 맞다.

AI가 접근법을 제안하면 자신감 있는 주니어 엔지니어를 대하듯 같은 수준의 회의심을 적용해야 한다. 답이 맞을 수도 있지만, 현재 상황에 맞지 않는 패턴을 가져온 것일 수도 있다. "왜 더 단순한 선택지는 안 되는가?"를 물어야 한다.

엔지니어링 기예는 여전히 중요하다

30년 전 도구가 화이트보드와 강한 의견이었다면, 지금의 도구는 예전에는 며칠 걸리던 것을 몇 분 만에 만들어내는 AI 에이전트다. 속도는 진짜로 놀랍지만, 아키텍처의 본질은 바뀌지 않았다.

문제를 이해하고, 제약을 알고, 트레이드오프를 만들고, 흥미로운 해법보다 단순한 해법을 방어하며, 멋져 보이지만 맞지 않는 아이디어에 "아니오"라고 말하는 것이 아키텍처다. 어떤 에이전트도 이 일을 대신하지 못한다.

실용적 활용 전략

AI 에이전트를 효과적으로 활용하려면 브레인스토밍 단계에서 사용하되, 최종 선택은 인간이 해야 한다. "X를 하는 방법 N가지를 브레인스토밍하고, 확률순으로 정렬해 줘"라고 요청하면 AI는 평균적인 답만 내는 대신 입력 공간을 더 넓게 샘플링한다. 그중 무엇을 택할지는 내가 결정한다.

상세 명세를 마크다운으로 먼저 쓰고 코딩을 맡기면 훨씬 나은 결과가 나온다. LLM은 명세 작성도 꽤 잘 도와주며, 코드를 쓰기 전에 브레인스토밍과 조사를 하고 설계나 명세를 먼저 쓰는 정석적인 소프트웨어 공학 절차를 되돌려 준다.

결론: Claude가 운전대를 잡게 했다면 다시 가져와야 한다

AI가 제안한 아키텍처가 아무리 그럴듯해 보여도, 그 결정에 인간의 이름이 없다면 아무도 그 결정을 소유하지 않는다. 아무도 소유하지 않는 결정은 중요한 순간에 지켜지지 않는다. "Claude가 설계했다"는 말은 아키텍처 의사결정 기록이 아니라 책임 회피다.

엔지니어들은 이런 판단을 내리기 위해 수년 동안 역량을 쌓아왔고, 그 판단을 하게 해야 한다. AI는 더 빠르게 만들기 위해 사용하되, 기계가 제안한 것이 아니라 사람들이 설계한 것을 만들어야 한다. Claude가 젠가 탑을 흔들 때, 그것을 붙잡아주는 것은 언제나 인간이어야 한다.

---

📚 출처

• https://news.hada.io/topic?id=29862