Claude는 당신의 아키텍트가 아니다 - AI에게 시스템 설계를 맡기면 안 되는 이유

"Claude, 우리 시스템 아키텍처 좀 짜줘"의 함정

요즘 개발자 사이에서 Claude나 GPT를 코딩 파트너로 쓰는 게 자연스러워졌어요. 코드를 짜달라고도 하고, 리팩터링도 시키고, 심지어 "이 시스템 어떻게 설계하면 좋을까?"라고 아키텍처 조언까지 구하잖아요. 그런데 한 시니어 엔지니어가 강하게 경고하고 나섰어요. "Claude는 당신의 아키텍트가 아니다. 그런 척하게 두지 마라"는 거예요.

글쓴이의 핵심 주장은 이거예요. LLM은 코드 "생성"에는 점점 능숙해지고 있지만, 시스템 "설계"는 본질적으로 다른 영역이라는 거죠. 설계는 기술적 트레이드오프뿐 아니라 조직의 역량, 운영 비용, 미래의 변화 가능성, 팀의 학습 곡선까지 종합적으로 고려해야 하는 작업이거든요. 그런데 LLM은 이런 "맥락 밖 정보"를 알 수 없어요.

그럴듯한 답변의 위험성

예시를 보면 이해가 빨라요. "마이크로서비스 vs 모놀리스, 뭐가 좋을까?"라고 물으면 Claude는 양쪽의 장단점을 술술 정리해줘요. 표까지 만들어주고요. 그런데 그게 "우리 팀이 5명이고, 운영 경험이 부족하고, 트래픽은 일 1만 건이고, 6개월 안에 출시해야 한다"는 우리 팀 맥락을 반영한 답일까요? 아니에요. 일반적인 교과서 답변에 가깝죠.

글쓴이가 지적하는 더 심각한 문제는 LLM이 "자신감 있게" 답한다는 점이에요. "잘 모르겠어요"라고 답하는 경우가 거의 없거든요. Kubernetes를 도입할지 말지 물어보면 "네, 좋은 선택입니다. 다음과 같은 이유로..." 식으로 친절하게 정당화해줘요. 주니어 개발자가 이런 답변을 받으면 "전문가가 추천했으니까 맞겠지"라고 받아들이기 쉬워요. 그런데 그 추천은 우리 회사 상황을 1%도 모르는 상태에서 나온 거죠.

진짜 아키텍처는 뭘 고민하는가

시니어 아키텍트가 시스템을 설계할 때 실제로 고민하는 건 기술 스택 선택만이 아니에요. "이 팀이 1년 뒤에 운영할 수 있을까?", "이 결정을 6개월 뒤에 되돌리려면 얼마나 비용이 들까?", "조직 구조가 이 아키텍처를 지원할 수 있나?" 같은 질문들이거든요. 콘웨이의 법칙(Conway's Law)이 말하듯, 시스템 아키텍처는 결국 조직 구조를 따라가요. 그런데 LLM은 우리 조직을 모르잖아요.

또 하나, 좋은 아키텍처는 "무엇을 하지 않을 것인가"를 정의하는 작업이기도 해요. "이 기능은 일부러 안 만든다", "이 추상화는 일부러 안 한다" 같은 결정들이죠. 그런데 LLM은 사용자가 요청한 걸 거절하기보다 "네 해드릴게요" 하고 다 만들어주는 경향이 강해요. 결국 필요 이상으로 복잡한 시스템이 만들어지기 쉬워요.

그럼 AI를 어떻게 활용해야 하나

글쓴이가 부정하는 건 "AI 활용 자체"가 아니에요. 적절한 역할 분담이 필요하다는 거예요. AI는 다음 같은 일에 잘 써요. 이미 결정된 아키텍처 안에서 코드를 빠르게 구현하기, 여러 옵션의 장단점을 빠르게 리서치하기, 본인이 생각한 설계를 비판적으로 검토받기, 문서 초안 작성하기 같은 거요.

반대로 위험한 활용법은 이래요. "이 시스템 처음부터 설계해줘"라고 백지에서 시작하기, AI 답변을 그대로 의사결정 근거로 쓰기, AI가 "가능하다"고 한 걸 "좋은 선택"이라고 오해하기. 특히 마지막 게 핵심이에요. LLM은 "기술적으로 가능한 모든 옵션"을 알려주는 데는 강하지만, "우리 상황에서 최선의 옵션"을 골라주는 건 우리 몫이거든요.

업계 맥락에서 보면

비슷한 논의가 최근 1년 사이 부쩍 늘었어요. ThoughtWorks의 Technology Radar에서도 "AI 어시스턴트를 시니어 의사결정에 사용할 때는 주의가 필요하다"는 항목이 등장했고, Martin Fowler도 "AI는 페어 프로그래밍 파트너로는 훌륭하지만 아키텍트는 아니다"라는 글을 썼어요. 한편으로는 Devin, Replit Agent 같은 "자율 에이전트"들이 등장하면서 "AI가 풀스택 의사결정까지 한다"는 마케팅도 동시에 늘고 있어요. 이 둘 사이의 긴장이 지금 업계의 핵심 논쟁 중 하나예요.

한국 개발자에게 주는 시사점

특히 주니어, 미들 레벨 개발자분들께 강조하고 싶은 게 있어요. AI에게 설계 질문을 할 때는 "이게 정답이다"가 아니라 "이런 옵션이 있구나" 정도로 받아들이세요. 그리고 "우리 팀 인원, 운영 경험, 트래픽, 일정" 같은 맥락 정보를 프롬프트에 충분히 넣어주세요. 그러면 답변의 질이 확연히 달라져요.

또 사내에서 AI 활용 가이드를 만들 때, "코드 구현은 AI, 아키텍처 결정은 사람"이라는 기본 원칙을 명시해두면 좋아요. AI가 만든 코드를 PR로 올릴 때 "왜 이 구조를 선택했는가"를 사람이 직접 설명하게 하는 프로세스도 효과적이에요. 그래야 AI에 의존하다가 시스템 전체에 대한 이해가 사라지는 사고를 막을 수 있거든요.

마무리

AI는 강력한 도구지만, 도구일 뿐이에요. 망치가 좋다고 모든 문제가 못은 아니듯, AI가 답을 잘 한다고 모든 결정을 맡기면 안 돼요.

여러분은 AI에게 어디까지 맡기시나요? "여기까지는 AI, 여기서부터는 내가" 하는 본인만의 선이 있다면 어디인가요?