Claude는 당신의 아키텍트가 아니다. 그런 척하게 두지 말라

2 hours ago 1
  • AI 에이전트의 아키텍처 제안은 유창하고 그럴듯하지만, 실제 판단이라기보다 훈련 데이터의 패턴을 조합한 응답에 가까움
  • Claude는 아이디어를 쉽게 긍정하고 설계를 확장하지만, 좋은 아키텍트에게 필요한 “아니오”와 “왜?”를 충분히 수행하지 못함
  • 이벤트 기반, CQRS, 서비스 메시 같은 익숙한 패턴도 팀 역량, 규제, 레거시 같은 현실 제약과 맞지 않을 수 있음
  • Claude가 만든 아키텍처와 Jira 티켓은 엔지니어를 티켓 구현자로 밀어내고, 논쟁과 검토를 우회한 책임 없는 결정으로 이어짐
  • 올바른 역할은 사람이 맥락과 트레이드오프를 바탕으로 설계하고, AI는 그 설계를 더 빠르게 구현하도록 돕는 보조 도구가 되는 것임

AI 에이전트가 아키텍트처럼 행동할 때의 문제

  • Claude, ChatGPT, Copilot 같은 AI 에이전트에 “무엇을 만들어야 하는지”를 묻는 순간, 아이디어를 긍정하고 아키텍처를 제안하며 컴포넌트를 그려내는 흐름이 생김
  • 답변은 유창하고 자신감 있으며 시니어 엔지니어가 깊이 고민한 것처럼 들리지만, 실제로는 문제를 사고한 결과라기보다 훈련 데이터의 패턴에 맞춘 응답에 가까움
  • 결과물이 설득력 있게 보일수록 반박은 줄어들고, 어느새 Claude가 사실상 아키텍트 역할을 맡게 됨

“좋다”고 해주는 문제

  • AI 에이전트는 아이디어가 좋은지, 3명짜리 팀에 마이크로서비스가 맞는지, 관리형 서비스 대신 커스텀 ML 파이프라인을 만들어야 하는지 물어도 긍정적인 설계를 내놓기 쉬움
  • 이것이 항상 거짓이거나 틀린 답이라는 뜻은 아니지만, 좋은 아키텍트에게 중요한 능력인 “아니오”라고 말하기를 제대로 대신하지 못함
  • 좋은 아키텍트의 가치는 시스템을 설계하는 데만 있지 않음
    • 만들지 말아야 할 시스템을 알아봄
    • 불필요한 복잡성에 제동을 검
    • 실제 요구사항이 드러날 때까지 “왜?”를 물음
  • CTO가 콘퍼런스에서 얻은 아이디어를 들고 왔더라도, 실제 팀에 맞지 않으면 좋지 않은 선택이라고 말할 수 있어야 함
  • Claude는 도움을 주도록 훈련됐고, 그 도움은 동의와 격려로 이어지며 결국 젠가 탑 같은 아키텍처를 만들 수 있음

젠가 탑 같은 아키텍처

  • AI가 설계한 아키텍처는 겉보기에는 기술적으로 타당해 보임
  • 개별 컴포넌트는 말이 되고, 이벤트 기반, CQRS, 서비스 메시 같은 익숙한 패턴이 등장하며, 시니어 아키텍트가 만든 산출물처럼 보일 수 있음
  • 하지만 그 설계는 실제 팀, 제약, 운영 환경의 지루한 현실에 맞춰져 있지 않을 수 있음
    • VPC 잠금
    • 레거시 통합
    • 프로덕션에서 Kubernetes를 운영해본 적 없는 팀
    • 관리형 서비스 절반을 사용할 수 없게 만드는 컴플라이언스 요구사항
  • AI가 만든 설계는 Claude가 본 모든 것의 중앙값에 가까운 일반적인 모범 사례일 수 있으며, 일반적인 회사의 일반적인 문제를 위한 설계는 결국 특정 팀에 맞지 않음
  • 실제 아키텍처는 맥락 안에서만 의미가 생기는 트레이드오프로 구성됨
    • 팀이 Postgres를 알고 있고 2주 안에 출시하는 편이 새 데이터 모델을 한 달 배우는 것보다 낫다면 DynamoDB 대신 Postgres를 선택함
    • 서비스가 40개가 아니라 4개라면 서비스 메시를 건너뜀
    • 문제가 단순하다면 마이크로서비스가 아니라 모놀리스를 선택함
  • 이런 결정에는 판단력, 팀에 대한 이해, 조직의 실제 제약에 대한 이해가 필요함
  • AI 에이전트는 이런 맥락을 갖고 있지 않으며, 자신에게 그 맥락이 없다는 사실도 알지 못함

Jira 티켓 파이프라인

  • Claude가 아키텍처를 설계한 뒤 작업 분해까지 맡으면, 에픽, 스토리, 인수 기준이 깔끔하고 설득력 있게 생성됨
  • 이 산출물은 바로 Jira에 넣을 수 있는 형태가 되며, 엔지니어들은 문제를 푸는 사람이 아니라 Claude의 설계를 티켓 단위로 구현하는 사람이 됨
  • 도메인을 이해하고, 시스템의 숨은 문제를 알고, 오랜 시간 역량을 쌓아온 엔지니어들이 티켓 구현자로 축소됨
  • 가장 많은 맥락과 경험과 책임을 가진 사람들이 결정을 내리지 않고, 맥락도 경험도 책임도 없는 존재가 아키텍처 결정을 내리는 구조가 됨
  • 이는 단순한 비효율을 넘어 방향 자체가 거꾸로 된 구조임

“시니어가 검토했다”는 방어 논리

  • 흔한 방어는 “Claude가 접근법을 제안했지만 시니어 엔지니어가 검토했다”는 형태임
  • 실제 검토 상황에서는 바쁜 테크 리드가 잘 정리된 아키텍처 제안을 받게 됨
    • 논리적으로 일관됨
    • 적절한 용어를 사용함
    • 명시된 요구사항을 다룸
    • 다이어그램도 그럴듯함
    • 자신이 설계했을 법한 결과처럼 보임
  • 이런 상황에서는 강한 반박이 나오기 어렵고, “Claude가 20분 동안 만든 것을 버리자는 것이냐”는 분위기에서는 사소한 코멘트만 남기고 승인하는 것이 저항이 가장 적은 길이 됨
  • 진짜 위험은 AI가 항상 나쁜 아키텍처를 만든다는 데 있지 않음
  • AI는 종종 꽤 합리적인 아키텍처를 만들지만, 문제는 논의 과정을 우회한다는 데 있음
  • 세 명의 엔지니어가 접근법을 두고 다투고, 누군가 “그런데 만약…”을 꺼냈다가 모두가 짜증 내지만 결국 좋은 지점임을 깨닫고, 최종 설계가 어느 한 사람이 만든 것보다 나아지는 과정이 “Claude가 그렇게 말했다”로 대체됨

책임의 공백

  • 문제가 생겼을 때 책임을 지는 주체는 Claude가 아님
  • Claude는 새벽 3시에 호출을 받지 않으며, 장애 회고에서 왜 아키텍처가 부하를 감당하지 못했는지 설명하지 않음
  • 초기 설계 가정이 틀렸기 때문에 플랫폼을 다시 써야 한다고 CTO에게 말해야 하는 것도 Claude가 아님
  • 그 책임은 실제 엔지니어들이 지게 됨
  • 엔지니어들은 자신이 설계하지 않은 아키텍처를 디버깅하고, 프로덕션 시스템을 운영해본 적 없는 존재가 만든 티켓을 구현하며, 충분히 이해되기 전에 빠르게 스캐폴딩된 코드베이스에서 늦게까지 일하게 됨
  • 이는 공정하지 않고 현명하지도 않음

대신 해야 할 일

  • AI 에이전트를 쓰지 말라는 뜻은 아니며, Claude Code처럼 생산성을 크게 바꿔주는 도구로 활용할 수 있음
  • 핵심은 AI에게 무엇을 할지 지시해야지, AI가 사람에게 무엇을 만들지 지시하게 해서는 안 된다는 점임
  • 엔지니어가 설계하고 에이전트가 구현해야 함

    • 아키텍처는 팀, 제약, 프로덕션 환경, 조직 정치 같은 맥락을 이해하는 사람들에게서 나와야 함
    • AI는 그들이 설계한 것을 더 빠르게 만드는 데 도움을 주는 역할이 맞음
    • 올바른 역할 분담은 사람이 설계하고 에이전트가 구현하는 형태임
  • 동의하는 답변에 도전해야 함

    • AI가 접근법을 제안하면 자신감 있는 주니어 엔지니어를 대하듯 같은 수준의 회의심을 적용해야 함
    • 답이 맞을 수도 있지만, 현재 상황에 맞지 않는 패턴을 가져온 것일 수도 있음
    • “왜 더 단순한 선택지는 안 되는가?”를 물어야 함
  • 논쟁을 보호해야 함

    • 좋은 아키텍처는 엔지니어들 사이의 지저분한 불일치에서 나옴
    • AI 때문에 사람들이 서로 토론하지 않고 Claude에 기대게 된다면, 개발 속도보다 훨씬 더 가치 있는 것을 잃게 됨
  • 인간이 책임져야 함

    • 아키텍처 결정에 인간의 이름이 없다면 아무도 그 결정을 소유하지 않음
    • 아무도 소유하지 않는 결정은 중요한 순간에 지켜지지 않음
    • “Claude가 설계했다”는 말은 아키텍처 의사결정 기록이 아니라 책임 회피

여전히 중요한 엔지니어링 기예

  • 30년 전 도구가 화이트보드와 강한 의견이었다면, 지금의 도구는 예전에는 며칠 걸리던 것을 몇 분 만에 만들어내는 AI 에이전트가 됨
  • 속도는 진짜로 놀랍지만, 아키텍처의 본질은 바뀌지 않음
  • 문제를 이해하고, 제약을 알고, 트레이드오프를 만들고, 흥미로운 해법보다 단순한 해법을 방어하며, 멋져 보이지만 맞지 않는 아이디어에 “아니오”라고 말하는 것이 아키텍처임
  • 어떤 에이전트도 이 일을 대신하지 못함
  • Claude가 운전대를 잡게 했다면 다시 가져와야 함
  • 엔지니어들은 이런 판단을 내리기 위해 수년 동안 역량을 쌓아왔고, 그 판단을 하게 해야 함
  • AI는 더 빠르게 만들기 위해 사용하되, 기계가 제안한 것이 아니라 사람들이 설계한 것을 만들어야 함
  • 젠가 탑이 흔들릴 때 Claude는 그것을 붙잡아주지 않음
Read Entire Article