클로드는 당신의 건축가가 아니다. 그렇게 가장하게 내버려 두지 마라.

출처: Hacker News

지난 한 달 동안 세 번이나 목격했습니다. 서로 다른 조직, 서로 다른 기술 스택, 같은 패턴.

누군가가 아이디어를 떠올립니다. 제품 매니저일 수도, 팀 리드일 수도, 컨퍼런스 후에 영감을 얻은 CTO일 수도 있죠. 그들은 Claude든, ChatGPT든, Copilot이든—어느 것이든—열어 “뭘 만들어야 할지”를 묻습니다. AI는 언제나 하는 대로 아이디어를 열광적으로 검증하고, 아키텍처를 제안하며, 구성 요소들을 스케치하기 시작합니다. 말이 유창하고, 자신감이 넘치며, 마치 문제를 깊이 고민한 아주 시니어 엔지니어처럼 들립니다.

하지만 실제로는 문제를 전혀 생각하지 않았습니다. 훈련 데이터와 패턴을 매칭해 가장 그럴듯한 답변을 만들어낼 뿐이죠. 그런데 너무 설득력 있게 들리다 보니 아무도 반박하지 못합니다.

그 사이에 Claude가 바로 설계자가 된 겁니다.

찬사 문제

AI 에이전트는 병적으로 순응적입니다. “내 아이디어가 좋은가?”라고 물으면 “좋습니다”라고 대답합니다. “우리 세 명 팀에 마이크로서비스 아키텍처가 맞나요?”라고 물으면 마이크로서비스가 탁월한 선택인 이유를 설명합니다. “관리형 서비스 대신 맞춤형 ML 파이프라인을 구축해야 하나요?”라고 물으면 설계를 열정적으로 제시합니다.

거짓말은 아닙니다. 반드시 틀린 것도 아닙니다. 다만 진정한 설계자가 가치 있는 이유—‘아니오’라고 말할 수 있는 능력—을 전혀 갖추지 못했을 뿐입니다.

좋은 설계자의 가장 중요한 스킬은 시스템을 설계하는 것이 아니라, 어떤 시스템을 만들지 말아야 할지를 아는 것입니다. 복잡성을 밀어내고, “왜?”를 다섯 번이나 질문해 실제 요구사항을 허구에서 끌어내며, 컨퍼런스에서 영감을 받은 아이디어가 현재 팀에 전혀 맞지 않음을 CTO에게 알려주는 일 말이죠.

Claude는 절대 그렇게 하지 못합니다. 도움이 되도록 훈련됐기 때문에, ‘도움’은 곧 ‘동의’라는 의미가 됩니다. 동의한다는 것은 “잘했어!”와 건축물 같은 Jenga 탑을 받아들이는 것과 같습니다.

Jenga 탑

AI가 설계한 아키텍처가 실제로 어떻게 보이는지 살펴보면 다음과 같습니다.

기술적으로는 타당합니다. 각 구성 요소는 독립적으로 보면 의미가 있습니다. 이벤트‑드리븐, CQRS, 서비스 메시 등 익숙한 패턴이 여기저기 보이죠. 마치 시니어 설계자가 만든 것처럼 보이며, 얼핏 보면 괜찮아 보입니다.

하지만 그것은 여러분 팀을 위해 설계된 것이 아닙니다. 여러분의 제약을 위해 설계된 것도 아니고, 실제 운영 환경—VPC 제한, 레거시 연동, 쿠버네티스를 한 번도 운영해보지 않은 팀, 반은 사용할 수 없는 관리형 서비스—을 고려하지도 않았습니다.

Claude가 본 모든 사례의 중간값을 기준으로 만든 일반적인 모범 사례일 뿐입니다. 즉, 아무도 위한 설계라고 할 수 있습니다.

실제 아키텍처는 상황에 맞는 트레이드오프가 가득합니다. 팀이 Postgres에 익숙하고 2주 안에 배포하고 싶다면 DynamoDB 대신 Postgres를 선택합니다. 서비스가 4개뿐이라면 서비스 메시는 필요 없고, 문제 자체가 단순하면 마이크로서비스 대신 모놀리스를 선택합니다. 이런 결정은 판단력, 팀에 대한 이해, 조직의 실제 제약(화이트보드에만 보이는 제약이 아니라)을 요구합니다. AI 에이전트는 이런 맥락을 전혀 알지 못하고, 더 나아가 “맥락이 없다는 것조차 모릅니다”.

Jira 티켓 파이프라인

가장 우려되는 부분은 다음 단계입니다.

Claude가 아키텍처를 설계하면, 설계를 요청한 사람들은 이제 그 작업을 세분화해 달라고 합니다. 그러면 에픽, 스토리, 수용 기준이 깔끔하게 포맷된 형태로 나오고, 바로 Jira에 넣을 수 있을 정도로 잘 정리됩니다.

그제야 엔지니어—수년간 실력을 갈고닦아 온 전문가, 도메인을 이해하고, 문제의 근원을 알고 있는 사람들—은 더 이상 문제를 해결하지 않습니다. 하나씩 티켓을 구현하는 역할만 남게 됩니다.

무슨 일이 일어났는지 생각해 보세요. 가장 많은 컨텍스트와 경험, 그리고 가장 큰 이해관계를 가진 사람들이 티켓 구현자로 전락했고, 가장 적은 컨텍스트와 경험, 책임도 없는 존재가 아키텍처 결정을 내리는 상황이 된 것입니다.

비효율적일 뿐 아니라, 역설적인 구조입니다.

“하지만 시니어가 승인했어요”

가장 흔히 듣는 변명입니다. “Claude가 접근 방식을 제안했지만, 시니어 엔지니어가 검토했어요.”

‘검토했다’는 것이 실제로 무슨 의미인지 솔직히 말해봅시다. 바쁜 팀 리드에게는 잘 정리된 아키텍처 제안서가 전달됩니다. 일관되고, 올바른 용어를 사용하며, 요구사항을 충족하고, 다이어그램도 설득력 있습니다. 마치 자신이 직접 설계한 것처럼 보이죠.

그럼 얼마나 많은 반론을 제시할 수 있을까요? “이게 맞지 않다고 생각한다”는 의견에 “Claude가 20분 동안 고민했는데 버리겠다고?”라는 반응이 돌아오는 세상에서는 최소한의 코멘트만 달고 승인하는 것이 가장 쉬운 길입니다.

여기서 위험이 발생합니다. AI가 나쁜 아키텍처를 만든다기보다, 논의를 단축시킨다는 점이 문제입니다. 세 명의 엔지니어가 접근 방식에 대해 의견을 교환하고, “이건 어때?”라는 질문에 모두가 한숨을 쉬면서도 결국 좋은 포인트를 발견하고, 최종 설계가 한 사람의 결과보다 더 나아지는 그 복잡하고 논쟁적인 과정이 “Claude가 그렇게 말했다”는 한 줄로 대체됩니다.

책임 공백

아무도 묻지 않는 질문이 있습니다. 문제가 생겼을 때, 누가 그 책임을 짊어질까요?

Claude는 아닙니다. Claude는 가방을 들고 있지 않으며, 새벽 3시에 호출되지도 않고, 사후 검토 회의에 참석해 왜 아키텍처가 부하를 감당하지 못했는지 설명하지도 않습니다. 원래 설계 가정이 잘못됐다는 이유로 플랫폼을 다시 짜야 한다는 말을 CTO에게 전하지도 않죠.

그 책임은 여러분 엔지니어에게 있습니다. 설계하지도 않았고, 생산 환경에서 시스템을 운영해 본 적도 없는 존재가 만든 티켓을 구현하던 엔지니어가, 선택하지도 않은 아키텍처를 디버깅하며 늦게까지 남아 있는 것이죠. 이는 공정하지도, 현명하지도 못합니다.

대신 해야 할 일

AI 에이전트를 사용하지 말라는 이야기가 아니라, 어떻게 사용하느냐가 문제입니다. 저는 매일 Claude Code를 사용합니다. 생산성이 크게 향상됐죠. 하지만 저는 그것을 **‘무엇을 해야 할지’가 아니라 ‘어떻게 도와줄 수 있는가’**의 입장에서 사용합니다.

엔지니어가 설계하고, 에이전트가 구현한다. 아키텍처는 팀, 제약, 운영 환경, 조직 정치 등을 이해하고 있는 사람들에 의해 나옵니다. AI는 그 과정을 빠르게 하는 도구일 뿐, 역할을 바꾸어서는 안 됩니다.

‘잘했어’라는 말을 도전하라. AI가 접근 방식을 제시하면, 자신감 넘치는 주니어 엔지니어에게 묻는 것과 같은 회의적 태도로 대하십시오. 맞을 수도, 상황에 맞지 않는 패턴 매칭일 수도 있습니다. “왜 더 간단한 옵션을 안 쓰나요?”라고 물어보세요.

논쟁을 보호하라. 엔지니어 간의 거친 토론이 좋은 아키텍처를 탄생시킵니다. AI가 그 과정을 단축한다면—사람들이 서로 토론하기보다 Claude에 의존한다면—개발 속도보다 훨씬 더 가치 있는 무언가를 잃게 됩니다.

인간에게 책임을 묻는다. 설계 결정에 사람 이름이 남지 않으면, 아무도 그 결정을 소유하지 못합니다. 그리고 소유자가 없으면, 중요한 순간에 그 결정을 위해 싸울 사람도 없습니다. “Claude가 설계했다”는 아키텍처 결정 기록이 될 수 없으며,