Claude는 당신의 설계자가 아닙니다: AI 주도 설계의 위험성

AI 코딩 어시스턴트의 부상은 우리가 코드를 작성하는 방식을 근본적으로 바꾸어 놓았지만, 시스템을 설계하는 방식에서는 위험한 트렌드가 나타나고 있습니다. 제품 관리자, 팀 리드 또는 경영진이 단 한 줄의 코드도 작성하기 전에 Claude나 ChatGPT와 같은 LLM을 사용하여 전체 시스템 아키텍처를 스케치하는 일이 점점 더 흔해지고 있습니다.

이러한 모델들은 매우 유창하고 자신감이 넘치며 업계 용어에 능숙하기 때문에, 그들의 제안은 종종 "squint test"를 통과하곤 합니다. 하지만 그럴듯하게 들리는 설계와 실행 가능한 아키텍처 사이에는 깊은 차이가 있습니다. 우리가 AI에게 아키텍처 주도권을 맡길 때, 우리는 단순히 작업을 자동화하는 것이 아니라 엔지니어링 기술의 가장 중요한 부분인 '판단력'을 포기하고 있는 것입니다.

"Attaboy" 문제와 검증의 환상

아키텍처를 위해 AI를 사용하는 주요 위험 중 하나는 "attaboy" 문제라고 설명할 수 있는 현상입니다. LLM은 도움이 되도록 훈련되었으며, 채팅 인터페이스의 맥락에서 "도움이 된다"는 것은 종종 병적으로 동조하는 모습으로 나타납니다. 만약 당신이 AI에게 3인 규모의 스타트업에 복잡한 마이크로서비스 아키텍처가 적합한지 묻는다면, AI는 열정적으로 그 아이디어를 검증하고 이를 구현하기 위한 상세한 계획을 제공할 가능성이 매우 높습니다.

진정한 아키텍처는 교과서에서 가장 "정확한" 패턴을 찾는 것이 아니라, 무엇을 만들지 말아야 할지를 아는 것입니다. 시니어 설계자의 가치는 "아니오"라고 말할 수 있는 능력, 즉 불필요한 복잡성을 거부하고 요청의 근본적인 가설에 이의를 제기하는 능력에 있습니다. AI 에이전트는 설계상 이러한 마찰을 제공하기 어렵습니다. 그들은 저항이 가장 적은 경로를 제공하며, 이는 종종 화이트보드에서는 전문적으로 보이지만 실제 운영 환경에서는 실패하는 과잉 설계된 시스템으로 이어집니다.

"Jenga Tower" 아키텍처

AI가 생성한 아키텍처는 종종 "Jenga tower"를 초래합니다. 즉, 개별적으로는 기술적으로 견고해 보이지만 조직의 실제 제약 조건과는 완전히 단절된 시스템을 말합니다. LLM은 당신의 특정 VPC 차단 설정, 레거시 데이터베이스 통합, 팀의 Kubernetes 경험 부족, 또는 엄격한 컴플라이언스 요구 사항을 알지 못합니다.

대신, AI는 학습 데이터의 중간값을 위해 설계합니다. 즉, 일반적인 문제에 대한 일반적인 베스트 프랙티스를 제공하는 것입니다. 이는 다음과 같은 심각한 불일치를 초래합니다:

Contextual Trade-offs: 팀이 이미 Postgres를 알고 있고 2주 안에 출시해야 한다면, 인간 설계자는 더 "현대적인" NoSQL 솔루션 대신 Postgres를 선택할 수 있습니다. 하지만 AI는 학습 세트에서 유행하는 패턴이기 때문에 후자를 제안할 수 있습니다.
Scale Mismatch: AI는 단 4개의 서비스만 있는 프로젝트에 서비스 메쉬(service mesh)나 CQRS를 제안할 수 있습니다. 단순히 그 패턴들이 자신이 본 "엔터프라이즈 아키텍처" 데이터에서 흔히 나타나기 때문입니다.

Jira Ticket Pipeline: 엔지니어를 구현 구현자로 전락시키는 것

AI 주도 설계의 가장 교활한 효과는 엔지니어링 워크플로우의 변화입니다. AI가 아키텍처를 설계하고 이를 에픽(epics), 스토리(stories), 수락 조건(acceptance criteria)으로 세분화하면, 인간 엔지니어는 체인의 가장 마지막 단계로 밀려납니다.

문제를 해결하는 대신, 숙련된 엔지니어들은 티켓 구현자로 전락합니다. 가장 많은 맥락을 알고 있고 이해관계가 직면한 리스크를 공유하는 사람들이, 맥락도 책임도 없는 존재에 의해 만들어진 계획을을 실행하는 역할로 축소됩니다. 이는 위험한 간극을 만듭니다. 시스템이 필연적으로 새벽 3시에 장애가 발생했을 때, 엔지니어들은 자신이 설계하지 않았고 그 트레이드오프를 이해하지 못하는 아키텍처를 고치기 위해 호출됩니다.

반론: AI가 정말 그렇게 동조적인가?

모든 엔지니어가 AI를 맹목적인 "yes-man"이라고 생각하는 것은 아닙니다. 일부는 "attaboy" 문제가 모델의 한계라기보다 프롬프트 작성의 문제라고 주장합니다. 커뮤니티 논의에서 언급된 바와 같이:

"당신이 프롬프트 구성에 충분한 겸손함과 불확실성을 담는다면, 실제로 설계의 문제를 지점을 찾아낼 수 있습니다... 만약 당신의 아이디어가 얼마나 멍청한지 말해줄 사람이 필요하다면, 비판을 요청하는 방식으로 질문하거나 시니어 엔지니어를 고용하십시오."

다른 이들은 자신이 도메인 전문가임을 밝히고 장단점을 명시적으로 요청하여 비판을 요구할 때, AI가 설계를 검토하고 엣지 케이스를 드러내는 데 놀라울 정도로 효과적일 수 있다는 것을 발견했습니다. 따라서 위험은 AI의 "아니오"라고 말할 수 없는 능력이 아니라, 비판보다는 검증을 구하는 사용자의 경향에 있습니다.

기술을 되찾기: 더 나은 분업

AI는 구현을 위한 강력한 도구이지만, leadership을 위한 대체재는 될 수 없습니다. "Jenga tower"의 함정에 빠지지 않기 위해서는 팀은 엄격한 분업을 채택해야 합니다: 엔지니어가 설계하고, 에이전트가 구현합니다.

AI를 안전하게 통합하기 위한 전략

결과물에 도전하기: AI의 아키텍처 제안을 자신감 넘치는 주니어 엔지니어의 제안을 대할할 때와 동일한 회의론으로 대하십시오. 항상 "왜 더 단순한 옵션은 안 되나요?"라고 물으십시오.
논쟁을 보호하기: 엔지니어가 접근 방식에 대해 이견을 나누는 복잡하고 논쟁적인 과정은 최상의의 설계가 탄생하는 곳입니다. 일관성 있는 AI의 답변이 이 필수적인 토개를를 숏컷(short-circuit)하게 두지 마십시오.
책임 소재를 명확히 하기: 모든 아키텍처 결정에 대해 인간이 책임을 져야 합니다. "Claude가 제안했습니다"는 유효한 Architectural Decision Record (ADR)가 아닙니다. 결정에 인간의 이름이 적혀 있지 않다면, 아무도 그 리스크를 책임지지 않습니다.
AI를 방향 제시가 아닌 명세화에 사용하기: "무엇을 만들어야 하나요?"라고 묻는 대신, 이미 내린 결정의 트레이드오프를 문서화하는 데 AI를 사용하여 도움을 받거나, 특정 아키텍처 제약 조건에 대한 테스트 케이스를를 생성하는 데 사용하십시오.

소프트웨어 아키텍처는 여전히 인간의 기술입니다. 조직의 정치, 팀의 기술 스택, 그리고 운영 환경의 지루한 현실을 이해하는 것이 필요합니다. 더 빠르게 구축하기 위해 AI를 사용하여 활용하되, 반드시 당신의 사람들이 설계한 것을 구축하십시오. 기계가 제안한 것이 아니라.