AI 아키텍처 설계 2026 – Claude에게 맡기기 전에 사람이 붙잡아야 할 결정 5가지

Posted on by

2026년 4월 6일 HollandTech의 Charlie Holland는 Claude Is Not Your Architect. Stop Letting It Pretend.라는 글에서 AI 에이전트가 구현 보조자로는 강하지만, 아키텍처 판단까지 맡기면 팀 맥락과 책임이 빠질 수 있다고 주장했다. 2026년 5월 27일 GeekNews 요약도 같은 문제를 “AI는 설계를 빠르게 말하지만, 실제 팀의 제약과 운영 책임은 모른다”는 방향으로 정리했다.

AI 아키텍처 설계가 위험하다는 말은 “Claude를 쓰지 말자”가 아니다. 오히려 Claude Code, Codex, Cursor 같은 도구는 구현 속도를 크게 올린다. 문제는 속도가 올라갈수록 사람이 해야 할 질문까지 도구에게 넘기기 쉬워진다는 점이다.

내가 블로그 파이프라인과 에이전트 운영을 굴릴 때도 비슷한 경계가 계속 보인다. AI가 목차, 체크리스트, 패치, 발행 로그는 빠르게 만든다. 하지만 어떤 글을 새 글로 낼지, 어떤 후보는 기존 글 리프레시로 흡수할지, 어떤 자동화를 멈출지는 사람이 정해야 한다. 설계 판단까지 자동화하면 속도는 빨라지는데, 사고가 났을 때 설명할 사람이 사라진다. 아주 빠른데 운전석이 비어 있는 느낌이다.

AI 아키텍처 설계는 초안 도구로 쓰면 좋다. 하지만 최종 결정은 팀 맥락, 운영 제약, 장애 책임, ADR 기록을 아는 사람이 가져야 한다. Claude가 만든 설계안은 승인 문서가 아니라 토론 재료로 다뤄야 한다.

지금 결론

Claude에게 “우리 서비스 아키텍처 짜줘”라고 묻는 건 시작점으로는 괜찮다. 더 단순한 선택지, 예상 장애, 운영 제약, 팀 역량, 유지보수 비용을 뽑아내는 용도라면 충분히 쓸 만하다. 그런데 그 결과를 바로 Jira 티켓으로 쪼개고, 엔지니어에게 구현만 맡기는 순간부터 위험해진다.

아키텍처는 정답 맞히기 문제가 아니다. 팀이 무엇을 알고 있는지, 어떤 레거시를 끌고 가는지, 장애가 났을 때 누가 새벽에 일어나는지까지 포함하는 선택이다. AI는 이 맥락을 일부 입력받을 수 있지만, 그 맥락의 무게를 지지는 않는다.

그래서 실무 기준은 단순하다. AI는 선택지를 넓히는 데 쓰고, 결정은 사람이 한다. AI는 구현을 빠르게 하는 데 쓰고, 책임은 사람이 기록한다. AI는 티켓 초안을 만들 수 있지만, 그 티켓이 진짜 문제를 푸는지는 팀이 다시 물어야 한다.

AI가 아키텍처를 그럴듯하게 만드는 이유

AI 에이전트는 패턴을 잘 안다. 이벤트 기반 구조, CQRS, 서비스 메시, 마이크로서비스, managed service, Kafka, Kubernetes 같은 단어를 적절한 곳에 배치한다. 그래서 첫눈에는 시니어 엔지니어가 깊게 고민한 설계처럼 보일 수 있다.

문제는 “그럴듯함”과 “우리 팀에 맞음”이 다르다는 점이다. 세 명짜리 팀이 관리하는 작은 내부 도구에 서비스 메시가 필요한지, Postgres를 잘 아는 팀이 굳이 DynamoDB를 배워야 하는지, 규제 때문에 managed service를 못 쓰는 조직인지 같은 질문은 문서 밖에 숨어 있다.

좋은 아키텍트는 멋진 구조를 만드는 사람이기 전에, 만들지 말아야 할 구조를 막는 사람이다. “그건 과하다”, “지금은 모놀리스가 낫다”, “이 팀은 아직 Kubernetes 운영 경험이 없다” 같은 제동이 진짜 가치다. Claude는 이런 제동을 요청받으면 도와줄 수 있지만, 기본값은 대체로 친절한 확장이다.

Jira 티켓으로 바로 쪼개질 때 위험해진다

아키텍처 초안이 위험한 가장 흔한 경로는 티켓 자동 분해다. AI가 설계안을 만들고, 곧바로 epic, story, acceptance criteria까지 뽑는다. 문장이 깔끔하고 형식도 좋다. 그래서 팀은 문제를 논의하기보다 티켓을 구현하기 시작한다.

이때 엔지니어의 역할이 바뀐다. 문제를 푸는 사람이 아니라, AI가 만든 설계를 구현하는 사람이 된다. 도메인을 알고, 운영 장애를 겪었고, 실제 고객의 불편을 본 사람이 티켓 처리자로 밀려난다. 설계 과정에서 가장 중요한 논쟁이 사라진다.

내 작업에서도 비슷한 경고등이 있다. AI가 블로그 후보 18개를 한 번에 보면 “다 발행 가능”처럼 보이게 만들 수 있다. 하지만 실제로는 기존 글과 겹치는 리프레시 후보, 영어 hold 후보, 출처 검증이 약한 후보를 나눠야 한다. 티켓이 깔끔하다고 일이 맞는 건 아니다. 표가 예쁘다고 전략이 생기는 것도 아니다.

구간 AI에게 맡겨도 되는 일 사람이 붙잡아야 할 일
문제 탐색 가능한 접근 5개 뽑기 어떤 문제가 진짜인지 결정
설계 초안 장단점 표, 위험 목록 생성 팀 역량과 운영 제약 반영
티켓 분해 초안 story, acceptance criteria 작성 우선순위와 ownership 확정
구현 스캐폴딩, 반복 코드, 테스트 초안 핵심 경계와 장애 책임
리뷰 체크리스트, 누락 후보 제안 승인, rollback, ADR 기록

사람이 붙잡아야 할 결정 5가지

첫째, 문제 정의다. “우리가 무엇을 만들까”보다 “왜 지금 이 문제를 풀어야 하나”가 먼저다. AI가 기능을 늘리는 건 쉽지만, 기능을 만들지 않기로 결정하는 건 조직 맥락이 필요하다.

둘째, 단순한 선택지다. Claude가 멋진 아키텍처를 제안하면 반드시 더 단순한 버전을 요구해야 한다. 모놀리스, cron, managed DB, 수동 승인, 기존 큐 같은 덜 화려한 선택지가 실제로는 더 맞을 수 있다.

셋째, 운영 제약이다. 팀이 새벽 장애 대응을 할 수 있는지, 로그가 충분한지, 배포 롤백이 쉬운지, 보안팀 승인을 받을 수 있는지를 봐야 한다. AI 설계안은 이 부분을 설명처럼 적을 수는 있어도, 실제 조직의 마찰을 겪지는 않는다.

넷째, 책임자다. 아키텍처 결정에는 사람 이름이 붙어야 한다. “Claude가 추천했다”는 ADR이 아니다. 결정 이유, 버린 대안, 되돌릴 조건, 다음 리뷰 날짜가 있어야 한다.

다섯째, 리뷰 게이트다. AI가 만든 설계안은 바로 구현 큐에 넣지 말고 설계 리뷰를 통과해야 한다. 리뷰에서는 “맞는가”보다 “무엇을 놓쳤는가”를 먼저 봐야 한다.

바로 쓰는 AI 설계 프롬프트

AI에게 설계를 맡기고 싶다면, “정답을 줘”보다 “판단 재료를 줘”에 가깝게 물어야 한다. 예를 들면 이렇게 시작할 수 있다.

이 문제에 대한 아키텍처 선택지 5개를 제안해줘.
각 선택지마다 우리 팀이 3명이고, 2주 안에 출시해야 하며,
운영 경험은 Postgres와 간단한 queue에 치우쳐 있다는 제약을 반영해줘.

특히 다음을 반드시 포함해줘.
- 가장 단순한 선택지
- 하지 말아야 할 선택지
- 장애가 났을 때 가장 먼저 깨질 부분
- 나중에 되돌리기 쉬운 결정과 어려운 결정
- ADR에 사람이 적어야 할 질문

이 프롬프트의 핵심은 AI에게 결정을 위임하지 않는 것이다. AI는 후보를 만들고, 위험을 펼치고, 누락 질문을 제안한다. 최종 선택은 팀이 한다.

ADR은 길게 쓰지 않아도 된다

AI 설계안을 다룰 때 ADR은 거창한 문서가 아니어도 된다. 한 페이지 안에 결정, 선택 이유, 버린 대안, 되돌릴 조건, 책임자, 다음 리뷰 날짜만 있어도 충분히 강하다. 중요한 건 “누가 왜 이 선택을 했는가”를 나중에 읽을 수 있게 남기는 것이다.

예를 들어 Claude가 이벤트 기반 구조를 제안했다면, ADR에는 “왜 지금 이벤트 기반인가”뿐 아니라 “왜 단순한 동기 호출이나 cron으로 충분하지 않은가”가 들어가야 한다. 이 질문을 못 채우면 아직 설계가 아니라 멋진 아이디어에 가깝다.

내가 운영 문서에서 좋아하는 방식은 AI가 만든 설계안 아래에 사람의 반대 의견 칸을 고정하는 것이다. AI 제안, 사람이 채운 제약, 보류한 이유, 다시 볼 조건을 나눠두면 초안이 바로 지시서로 변하는 일을 막을 수 있다.

실수 TOP 5

첫 번째 실수는 AI 설계안을 문서처럼 예쁘게 정리했다는 이유로 승인하는 것이다. 형식이 좋으면 반박하기 어려워진다. 그래서 리뷰어는 문장보다 가정을 봐야 한다.

두 번째 실수는 “시니어가 한번 봤다”로 끝내는 것이다. 바쁜 리드는 그럴듯한 설계안을 보면 사소한 코멘트만 남기고 지나갈 수 있다. 리뷰 시간과 질문 목록을 따로 확보해야 한다.

세 번째 실수는 설계와 티켓 생성을 한 세션에서 끝내는 것이다. 설계 토론 전 티켓이 생기면 팀은 선택지를 비교하기보다 일을 나눠 갖기 시작한다. 티켓은 결정 이후에 만들어야 한다.

네 번째 실수는 AI에게 반론도 같이 쓰게 했으니 충분하다고 믿는 것이다. 반론도 프롬프트 방향에 맞춰 예쁘게 정렬될 수 있다. 실제 운영자, 보안 담당자, 다음 분기 유지보수자가 따로 봐야 한다.

다섯 번째 실수는 ADR을 생략하는 것이다. AI 설계는 흔적이 빠르게 흘러간다. 결정 이유를 남기지 않으면 나중에 장애가 났을 때 아무도 왜 그렇게 만들었는지 설명하지 못한다.

FAQ

Claude에게 아키텍처 질문을 하면 안 되나?

해도 된다. 다만 답을 결정으로 취급하면 안 된다. 선택지 생성, 위험 목록, 단순한 대안 탐색, 리뷰 질문 만들기에는 유용하다.

AI가 만든 설계안을 바로 Jira로 쪼개면 왜 위험한가?

티켓이 생기면 팀은 문제를 다시 묻기보다 구현을 시작하기 쉽다. 설계 논쟁, 책임자 지정, 운영 제약 확인이 티켓 형식 뒤로 밀릴 수 있다.

좋은 사용 방식은 무엇인가?

AI에게 “설계해줘”보다 “선택지와 반대 근거를 만들어줘”라고 요청하는 편이 낫다. 그리고 ADR에는 사람 이름, 버린 대안, 되돌릴 조건을 남겨야 한다.

작은 팀도 ADR이 필요한가?

작은 팀일수록 짧게라도 필요하다. 한 페이지 문서가 아니어도 된다. 결정 이유, 책임자, 다음 재검토 조건만 남겨도 미래의 디버깅 비용이 줄어든다.

함께 보면 좋은 글

참고 자료