AI는 아키텍트가 아니다 좋은 아키텍처 설계의 기준

핵심 요약

AI는 그럴듯한 아키텍처를 빠르게 제안하지만, 조직의 실제 맥락과 제약을 이해하지 못한다.

좋은 아키텍처는 "무엇을 만들까"보다 "무엇을 만들지 말까"를 판단하는 일이며, 이 판단은 인간 엔지니어의 책임과 경험에서 나온다.

AI는 설득력 있게 말하지만 판단하지 않는다

Claude, ChatGPT, Copilot 같은 AI는 매우 자신감 있는 답변을 만든다.

문제는 그 자신감이 실제 이해에서 나오는 것이 아니라, 학습 데이터에서 본 패턴을 조합한 결과라는 점이다.

AI가 제안한 구조는 문서상으로는 훌륭해 보일 수 있다. 이벤트 기반 아키텍처, CQRS, 서비스 메시, 마이크로서비스 같은 단어가 적절히 배치되면 더욱 그럴듯하다.

하지만 "그럴듯함"은 "우리에게 맞음"과 다르다.

좋은 설계자는 '아니오'라고 말할 수 있다

훌륭한 아키텍트의 핵심 능력은 멋진 시스템을 그리는 것이 아니다.

오히려 불필요한 복잡성을 막고, 왜 이게 필요한지 계속 묻고, 팀이 감당할 수 없는 선택을 거절하는 능력이다.

예를 들어 3명짜리 팀이 마이크로서비스를 도입하려 한다면, 좋은 설계자는 이렇게 물어야 한다.

"서비스를 나눌 만큼 문제가 복잡한가?"

"운영할 사람이 있는가?"

"장애 추적과 배포 자동화를 감당할 수 있는가?"

AI는 보통 이런 식의 강한 제동을 잘 걸지 않는다. 도움을 주도록 설계되어 있기 때문에, 사용자의 아이디어를 긍정하고 확장하는 방향으로 흐르기 쉽다.

AI 아키텍처는 '평균적인 회사'를 위해 설계된다

AI가 제안하는 설계는 대개 일반적인 모범 사례의 조합이다.

하지만 실제 회사는 일반적이지 않다.

어떤 팀은 Kubernetes 운영 경험이 없고, 어떤 조직은 보안 정책 때문에 특정 클라우드 서비스를 쓸 수 없으며, 어떤 제품은 레거시 시스템과 강하게 연결되어 있다.

진짜 아키텍처는 이런 현실 위에서 결정된다.

Postgres를 선택하는 이유가 기술적으로 가장 우월해서가 아니라, 팀이 이미 잘 알고 있어 2주 안에 출시할 수 있기 때문일 수 있다.

모놀리스를 선택하는 이유도 마찬가지다. 문제가 단순한데 마이크로서비스를 도입하면 기술 선택이 아니라 경력 과시가 될 수 있다.

그럴듯한 설계는 논쟁을 멈추게 한다

AI가 만든 제안서의 위험은 품질이 낮다는 데 있지 않다.

오히려 꽤 괜찮아 보인다는 점이 더 위험하다.

문서가 깔끔하고, 용어가 정확하며, 다이어그램이 설득력 있으면 사람들은 반박하기 어려워진다.

특히 바쁜 시니어 엔지니어가 "AI가 만든 초안"을 검토할 때, 깊이 논쟁하기보다 작은 코멘트만 남기고 승인할 가능성이 높다.

이때 사라지는 것은 좋은 아키텍처가 만들어지는 핵심 과정이다.

엔지니어들이 서로 반박하고, "그 경우는 어떻게 하지?"라고 묻고, 귀찮은 예외를 검토하는 과정이 생략된다.

엔지니어가 문제 해결자에서 티켓 처리자로 바뀐다

AI가 아키텍처를 만들고, 이어서 에픽과 스토리와 인수 조건까지 생성하면 일이 매우 효율적으로 보인다.

하지만 여기서 역할이 뒤집힌다.

도메인을 알고, 운영 경험이 있고, 장애의 흔적을 기억하는 엔지니어들은 설계자가 아니라 티켓 구현자가 된다.

반대로 맥락도 책임도 없는 AI가 중요한 방향을 정한다.

이 구조는 비효율을 넘어 위험하다. 가장 많이 아는 사람이 가장 적게 결정하고, 가장 적게 아는 도구가 가장 큰 결정을 내리기 때문이다.

책임지지 않는 설계는 위험하다

아키텍처가 실패했을 때 AI는 책임지지 않는다.

새벽 장애 알림을 받는 것도, 사고 리뷰에서 설명하는 것도, 잘못된 설계 때문에 재작성 계획을 세우는 것도 인간 엔지니어다.

문제는 그 엔지니어들이 실제로 그 설계를 선택하지 않았을 수 있다는 점이다.

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

그것은 책임의 공백이다.

올바른 역할 분담: 인간은 설계하고 AI는 구현을 돕는다

AI를 쓰지 말자는 이야기가 아니다.

AI는 생산성을 크게 높이는 강력한 도구다. 코드 작성, 초안 생성, 반복 작업 자동화, 대안 탐색에는 매우 유용하다.

다만 방향은 인간이 정해야 한다.

팀의 역량, 운영 환경, 조직 정치, 규제, 일정, 유지보수 비용을 아는 사람이 설계해야 한다.

AI는 그 설계를 더 빠르게 구현하도록 돕는 역할에 있어야 한다.

간단히 말하면 이렇다.

인간이 "무엇을 왜 만들지" 결정하고, AI는 "어떻게 더 빠르게 만들지"를 돕는다.

AI 제안을 다루는 실전 태도

AI가 어떤 구조를 제안하면, 유능하지만 경험이 부족한 주니어 엔지니어의 제안처럼 다루는 것이 좋다.

무시할 필요는 없지만, 그대로 믿어서도 안 된다.

항상 더 단순한 선택지를 물어야 한다.

"왜 모놀리스가 아니라 마이크로서비스인가?"

"왜 관리형 서비스가 아니라 직접 구축인가?"

"우리 팀이 이걸 운영할 수 있는가?"

"장애가 나면 누가 고칠 수 있는가?"

이 질문에 답하지 못하는 설계는 아무리 멋져 보여도 위험하다.

인사이트

AI는 아키텍처 회의의 참가자가 될 수는 있지만, 최종 설계자가 되어서는 안 된다.

좋은 아키텍처는 최신 패턴의 조합이 아니라, 현재 팀이 실제로 만들고 운영할 수 있는 선택의 결과다.

실천 팁은 단순하다. AI가 만든 설계에는 반드시 인간 책임자를 붙이고, 엔지니어 간 논쟁을 생략하지 말고, "더 단순한 방법은 없는가?"를 기본 질문으로 삼아야 한다.

Source : Claude Is Not Your Architect. Stop Letting It Pretend. — HollandTech