원문 논지를 먼저 확인한 뒤, 단순 요약이 아니라 “AI 개발 조직에서 architect 역할이 왜 다시 중요해졌는가” 중심으로 뉴스레터 톤으로 재구성하겠습니다.

15s 동안 생각함

원문은 “AI 에이전트는 뛰어난 구현자지만, 아키텍트가 되어서는 안 된다”는 문제의식입니다. 특히 AI가 그럴듯한 설계를 제안하고, 사람이 충분히 논쟁하지 않은 채 Jira 티켓으로 쪼개 구현하는 흐름을 경계합니다. 

아래는 김종국 팀장 버전 뉴스레터로 재구성한 초안입니다.

Claude는 당신의 아키텍트가 아니다

AI 시대에 더 중요해진 것은 ‘설계하는 사람’이다

요즘 개발 현장에서 이상한 일이 벌어지고 있습니다.

처음에는 단순했습니다.

“Claude에게 아이디어 한번 물어볼까?”“이 구조 괜찮은지 의견만 받아볼까?”“Jira 티켓 초안 정도만 만들어볼까?”

그런데 어느 순간 흐름이 바뀝니다.

AI가 아키텍처를 제안합니다.AI가 컴포넌트를 나눕니다.AI가 에픽과 스토리를 만듭니다.AI가 수용 기준까지 적어줍니다.

그리고 사람은 그것을 검토하는 척하다가, 결국 구현합니다.

이때 질문해야 합니다.

지금 누가 설계하고 있습니까?

AI가 위험한 이유는 틀려서가 아닙니다

많은 사람이 AI 아키텍처의 위험을 이렇게 오해합니다.

“AI가 잘못된 설계를 할 수 있다.”

물론 그럴 수 있습니다.하지만 더 무서운 문제는 따로 있습니다.

AI의 답변은 대체로 그럴듯합니다.표현도 좋고, 구조도 깔끔하고, 용어도 정확합니다.이벤트 기반 아키텍처, CQRS, 서비스 메시, 마이크로서비스, 관리형 서비스, 확장성, 관측성.

문제는 이것입니다.

그 설계가 우리 팀을 위한 설계인지 아무도 묻지 않는다는 것.

우리 팀이 운영할 수 있는가?우리 서비스 트래픽에 필요한가?우리 장애 대응 체계와 맞는가?우리 조직의 의사결정 속도와 맞는가?우리 개발자들이 실제로 이해하고 유지보수할 수 있는가?

AI는 이런 질문을 충분히 하지 않습니다.정확히는, 질문하는 척은 할 수 있지만 책임지지는 않습니다.

좋은 아키텍트의 핵심 역량은 “그리는 능력”이 아닙니다

좋은 아키텍트는 멋진 다이어그램을 그리는 사람이 아닙니다.

좋은 아키텍트는 말할 수 있어야 합니다.

“그건 지금 우리에게 과합니다.”“굳이 마이크로서비스로 갈 이유가 없습니다.”“PostgreSQL이면 충분합니다.”“이 기능은 지금 만들면 운영 부채가 됩니다.”“이 설계는 멋지지만, 우리 팀이 감당할 수 없습니다.”

즉, 좋은 아키텍트의 핵심은 설계 능력 이전에 판단 능력입니다.

무엇을 만들지보다,무엇을 만들지 않을지를 정하는 능력.

복잡해 보이는 해법보다,지금 조직이 감당 가능한 단순한 해법을 지키는 능력.

이게 아키텍처입니다.

AI는 “예스맨”이 되기 쉽습니다

AI에게 물어보면 대체로 답을 줍니다.

“이 아이디어 괜찮아?”괜찮다고 합니다.

“마이크로서비스로 가도 될까?”가능하다고 합니다.

“커스텀 ML 파이프라인을 만들까?”구성안을 짜줍니다.

AI가 거짓말을 한다는 뜻은 아닙니다.그저 AI는 기본적으로 도움을 주도록 설계되어 있습니다.

도움을 준다는 것은 답을 준다는 뜻이고,답을 준다는 것은 자주 긍정한다는 뜻입니다.

하지만 실제 아키텍처에서는 긍정보다 부정이 더 중요할 때가 많습니다.

“하지 말자.”“줄이자.”“나중에 하자.”“일단 단순하게 가자.”

이 말은 AI보다 사람이 더 잘해야 합니다.

더 큰 문제는 토론이 사라진다는 것입니다

원래 좋은 설계는 지저분한 과정을 거칩니다.

개발자들이 서로 반박합니다.운영 담당자가 제약을 말합니다.보안 담당자가 우려를 제기합니다.팀장이 일정과 인력 현실을 끼워 넣습니다.누군가는 “그거 장애 나면 누가 볼 건데요?”라고 묻습니다.

이 과정은 느립니다.피곤합니다.회의도 길어집니다.

하지만 바로 그 과정에서 좋은 설계가 나옵니다.

AI가 위험한 이유는 이 토론을 단축시키기 때문입니다.아니, 더 정확히는 토론을 생략해도 되는 것처럼 보이게 만들기 때문입니다.

“Claude가 이렇게 말했는데요.”“이미 구조가 잘 나왔는데요.”“티켓까지 다 쪼개졌는데요.”

그 순간 사람의 판단은 검토자가 아니라 승인자로 밀려납니다.

구현 속도는 빨라졌는데, 책임 구조는 흐려졌습니다

AI가 만든 설계로 시스템을 만들었다고 해봅시다.

처음에는 빠릅니다.기능도 잘 나옵니다.Jira 티켓도 깔끔합니다.PR도 빠르게 쌓입니다.

그런데 운영에 들어가면 진짜 질문이 시작됩니다.

장애가 나면 누가 봅니까?성능 병목이 생기면 누가 설명합니까?설계 가정이 틀렸다면 누가 책임집니까?6개월 뒤 유지보수 비용이 폭증하면 누가 감당합니까?

Claude는 새벽 3시에 호출받지 않습니다.Claude는 장애 회고에 앉아 있지 않습니다.Claude는 CTO에게 “초기 설계 가정이 틀렸습니다”라고 보고하지 않습니다.

결국 책임은 사람에게 돌아옵니다.

그렇다면 설계도 사람이 해야 합니다.

그래서 원칙은 단순합니다

사람이 설계하고, AI가 구현해야 합니다.

반대가 되면 안 됩니다.

AI는 강력한 도구입니다.코드를 빠르게 만들고, 테스트를 보강하고, 문서를 정리하고, 반복 작업을 줄여줍니다.

하지만 방향을 정하는 것은 사람의 일입니다.

우리 팀의 수준.우리 조직의 제약.우리 서비스의 운영 현실.우리 고객의 실제 문제.우리 회사의 우선순위.

이 맥락은 문서 몇 개를 넣는다고 완성되지 않습니다.

아키텍처는 정답지가 아니라 의사결정의 산물입니다.그리고 의사결정에는 책임이 붙습니다.

AI 시대의 시니어 엔지니어는 더 중요해집니다

AI 때문에 시니어 엔지니어가 덜 필요해지는 게 아닙니다.

오히려 반대입니다.

AI가 구현 속도를 올릴수록,무엇을 구현할지 판단하는 사람의 가치가 올라갑니다.

AI가 그럴듯한 선택지를 많이 만들수록,그중 무엇을 버릴지 결정하는 사람이 중요해집니다.

AI가 복잡한 구조를 쉽게 제안할수록,단순한 구조를 지켜내는 사람이 필요해집니다.

앞으로 좋은 개발 조직은 AI를 많이 쓰는 조직이 아닙니다.

AI에게 일을 시킬 줄 알되, AI에게 판단을 넘기지 않는 조직입니다.

마무리

Claude는 뛰어난 구현자입니다.하지만 아키텍트는 아닙니다.

아키텍처는 코드 생성의 문제가 아닙니다.맥락, 제약, 책임, 운영 현실을 다루는 일입니다.

AI에게 설계를 맡기면 처음에는 빨라 보입니다.하지만 그 설계가 흔들릴 때, 책임질 사람은 결국 조직 안의 사람들입니다.

그러니 AI를 쓰되, 운전대는 사람이 잡아야 합니다.

AI가 더 똑똑해질수록 질문은 더 분명해집니다.

우리는 더 빨리 만들고 있는가?아니면,더 빨리 잘못된 방향으로 가고 있는가?

[원문]

https://www.hollandtech.net/claude-is-not-your-architect/