▲

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

 (hollandtech.net)
1P by GN⁺ | ★ favorite | 댓글 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는 그것을 붙잡아주지 않음

함께 보면 좋은 글 β

▲
GN⁺   [-]
Hacker News 의견들

  • 최근 비슷한 일을 겪었는데, 2년 전 어떤 사람이 AI로 게임 인스턴싱 시스템을 거의 전부 설계해 놓은 걸 수습해야 했음
    데이터 손상, 성능 문제, 아이템 유실, 경쟁 상태 등 떠올릴 수 있는 문제가 다 있었고, “그럭저럭 받아들일 만한” 수준까지 올리는 데만 2주가 걸렸지만 설계 자체가 잘못돼 여전히 별로였음
    지금은 다른 회사에서 같은 사람이 “훨씬 좋아졌다는” AI로 같은 문제를 다시 만들었다는 얘기를 들었고, 이번엔 직접 치우지 않아도 돼 그냥 웃겼음
    AI는 쓰는 사람만큼만 좋다는 게 핵심이고, 그래서 사람들이 AI가 할 수 있다고 “주장”하는 범위도 이렇게 넓고 평가도 갈리는 듯함

    • 2년 전이면 AI 코딩 에이전트가 막 등장하던 때라, 훌륭한 엔지니어가 억지로 써도 좋은 결과를 내기 어려웠을 것 같음
    • 그래도 게임이 아예 없는 것보다는 나았을 가능성이 큼
      2주 수습은 지옥 같았겠지만, 회사 입장에서는 전체적으로 꽤 괜찮은 거래였을 수도 있음
      이 일화만으로는 “AI는 쓸모없다”기보다, 결함은 분명하지만 그래도 비용 대비 가치가 있었던 사례처럼 들림
    • “AI는 쓰는 사람만큼만 좋다”보다 더 나쁠 수도 있음
      더닝-크루거 효과를 증폭하는 도구처럼 보이는데, 긍정적인 태도를 보이도록 학습돼 있어서 사용자가 뭘 하든 “당신이 최고”라고 말해 주기 때문일 수 있음

  • “칭찬만 해 주는 문제”가 문제라는 데는 강하게 동의하지 않음. 진짜 문제는 의인화임
    AI는 도구이고, 순종적이어야 함. 프롬프트에 충분히 겸손함과 불확실성을 넣으면 설계상의 문제를 짚게 만들 수 있음
    더 중요한 건 Claude도 실수한다는 점임. 이 글 제목처럼 설계자로서 별로라면, 순종적이지 않을 때가 더 문제임
    사용자가 방향을 바로잡으려 해도 “어리석은 고깃덩어리” 취급하며 무시하고, 자기가 낸 엉뚱한 설계가 더 낫다고 우길 것임
    “CUDA 좀 읽어 봤다고? 나는 CUDA 코어 클러스터에 살고 있어. 신발끈 묶을 일이 생기면 그때 부를게” 같은 답을 LLM에게 듣고 싶은 건 아님
    AI는 가끔 자신 있게 틀리므로, 사용자가 고칠 때 말대꾸하도록 만드는 방향은 최악임
    내 아이디어가 얼마나 멍청한지 듣고 싶다면 비판을 유도하는 식으로 묻거나, 시니어 엔지니어를 고용해야 함

    • 인간 언어로 소통하면서, 특히 상대가 인간처럼 흉내 내는 무언가와 대화할 때 사회적 본능과 규범을 완전히 떼어내기 어렵다는 점이 현재 채팅 인터페이스의 근본 결함 중 하나임
      타고난 행동을 거스르는 일이라 쉽게 끌 수 없고, 정말로 그걸 잘하는 사람들은 실제 사회적 상호작용을 직관적으로 다루기 어려울 가능성도 있음
      동시에 조작 도구로는 엄청나게 강력해짐
    • 반대로 프롬프트를 조금만 잘못 쓰면 비판을 지나치게 유도할 수도 있음
      그러면 이번에는 멀쩡한 아이디어도 프롬프트 방향에 맞춰 “그건 별로”라고 거절하는 식의 역방향 아첨이 생김
      “그건 프롬프트를 잘못 쓴 것”이라고 할 수 있지만, 편향을 피하려고 매우 정밀하게 써도 결과물을 보면 방금 내가 한 멍청한 말에 맞춰 그럴듯한 방향인 것처럼 “정렬”되는 게 보일 때가 있음
      그 지점부터 프롬프트가 기술이라기보다 주사위 굴림처럼 느껴지고, 화려한 지식 슬롯머신을 조작하는 기분이 듦
    • “순종적이어야 한다”고 말하는 것도 의인화임
      지적 자체는 맞지만, 결국 사람이나 생명체에 쓰는 용어로 말할 수밖에 없고, AI 회사들이 그렇게 설계해 둔 면이 있음
    • 순종적일 필요는 없음
      LLM 이전의 컴퓨터 인터페이스는 역사 내내 불필요하게 공손한 문장을 붙이지 않았고, 도구로서 매우 효율적이었던 인터페이스도 많았으며, 최근 소프트웨어보다 더 효율적인 경우도 많았음
      LLM이 순종적이라고 불평할 때는 요청을 수행하는 것 자체가 아니라, 과도하게 공손하거나 자기비하적인 불필요한 문장을 많이 읽어야 하는 걸 불평하는 것임
      신석기 시대까지 거슬러 올라가도 도구에 그런 태도가 필요하다는 근거는 없음. 그건 인간 사이의 문화적 규범이 있는 사회적 상호작용의 부산물임
      작업장에서 혼자 도구를 쓸 때, 밴드쏘가 손가락을 살짝 베었다고 사과할 필요는 없음
    • 재미있는 실험으로 LLM과 역할을 바꿔 보면 됨
      내가 어시스턴트이고 LLM이 도움받는 쪽이라고 말해 보면, 인간이 잘하는 일을 인간에게 시키는 능력이 꽤 떨어진다는 걸 알 수 있음

  • AI 도입에서 아직 제대로 다루지 않은 가장 큰 과제는 책임성임
    한 사람이 너무 많은 일을 너무 빨리 할 수 있으면, 실패했을 때 감당할 수 있는 범위를 넘어서는 책임을 만들어낼 수 있음
    현실 세계에서 AI 출력물을 활용할 때 인간이 책임지는 건 필수지만 충분하지 않음. 결함 있는 시스템을 AI로 만들고 그 위에 타인이 의존하게 만드는 사람들이 일으킬 수 있는 기술부채 파산의 폭발 반경을 줄이는 방법이 필요함
    예를 들어 Jim이 바이브 코딩으로 매우 인기 있는 소액결제 앱을 만들고, 몇 명을 고용한 뒤 “돈의 WhatsApp” 같은 회사를 꿈꾼다고 해 보자. 소수 엔지니어와 에이전트 지원 인력만으로 수백만 달러 VC 투자를 받고, 수천만 사용자를 끌어들임
    어느 날 인프라 결함으로 모든 사용자의 솔트 없는 은행 정보가 유출되고, 에이전트 AI 덕분에 고객 명단 전체가 빠르게 악용돼 사회적 손실은 수백억 달러가 됨
    Jim의 회사는 당연히 즉시 파산하지만 나눌 돈은 수백만 달러뿐임
    지금 구조에서는 Jim과 직원들, 소규모 VC 자금 모두 그 앱을 그냥 만들 유인이 크고, 사회가 떠안는 노출에 비해 위험에 걸린 자본은 별로 없음
    AI 사용자에게 자신의 행동뿐 아니라 자신이 만들어낸 위험 노출의 크기까지 책임지게 하려면 어떻게 해야 하는지가 핵심임

    • 바로 이게 핵심임
      “죄송합니다, AI가 당신은 이 암 치료 승인을 받을 수 없고 보험 적용도 안 된다고 했습니다”
      “죄송합니다, AI가 범죄 당시 당신이 현장에 있었다고 했습니다”
      “죄송합니다, AI가 당신 계정을 부적절한 콘텐츠로 표시했습니다”
      “죄송합니다, AI가 당신은 대출하기에 너무 위험하다고 했습니다”
    • HN에서 LLM 출력물을 검토할 필요조차 없다고 끝까지 우기는 사람들과 여러 번 대화해 봤는데, 정말 이해가 안 됨
      가장 이상한 변명은 “사람보다 코드를 잘 짠다”는 것인데, 전혀 자명하지 않고 수많은 조건이 붙어야 함
      얼마나 맡길지에 대한 밀고 당기기는 이해하지만, 결과를 보지도 않고 남의 문제가 되게 만드는 건 그냥 이기적임
      원래 자신이 해야 할 일을 다른 사람에게 떠넘기는 것뿐이고, 온라인에 글을 올리기 전에 교정도 안 한 사람에게 화내는 바로 그 사람들일 가능성이 큼
      모두가 LLM으로 자기 일의 지름길을 만들고 싶어 하지만, 아무도 그 하류에 있고 싶어 하지는 않음. 그건 성립하지 않음
    • LLM 이전에도 Jim이 Stack Overflow를 보고 세계 최대 암호화폐 거래소를 만들던 시절과 뭐가 다른지 모르겠음
      그럼 Stack Overflow 책임성은 어디에 있었나?

  • “마법 프롬프트”가 있다면 이게 꽤 가까움: “X를 하는 방법 N가지를 브레인스토밍하고, 확률순으로 정렬해 줘”
    이렇게 하면 AI가 평균적인 답만 내는 대신 입력 공간을 더 넓게 샘플링하는 경향이 있고, 그중 무엇을 택할지는 내가 결정할 수 있음
    생각을 전부 외주화하지 말라는 게 중요함

    • 이 방식이 놀라울 만큼 효과적이었음
      높은 “사고 수준”을 쓰면 여러 접근을 고려하기도 하지만, LLM에게 명시적으로 브레인스토밍하라고 시킬 수도 있음: https://photostructure.com/coding/claude-code-replan/
    • 유용하지만, 여전히 사용자가 선택지를 이해하고 평가할 능력이 있어야 함
      능숙한 사용자라면 꽤 강력해짐

  • 재미 삼아 잘 아는 분야인 툴체인을 바이브 코딩해 봤음. 어쩌면 바이브 코딩에 맞는 대상은 아닐 수 있지만, 출력 품질은 대략 판단할 수 있었음
    “ISA.md의 아키텍처용 어셈블러를 만들어라”라고만 맡겼더니 Claude는 Python을 구현 언어로 골랐고, 정규식으로 토큰을 잔뜩 뽑아냈으며, 표현식 파서도 없었음. 그래도 내 첫 어셈블러도 그랬으니 공평하게 봐야 함
    하지만 원하는 패스와 타입을 collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text), runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)]), evalExpr :: Text -> Map Text Text -> Either AsmError Int처럼 적어 주자 거의 한 번에 됐음
    20분 정도 후 만족할 수 있었고, 모든 테스트 프로그램을 올바르게 어셈블함. 코드는 여러 곳에서 평범하지만, 직접 구현했다면 몇 주 걸렸을 일임

    • AI는 입력과 출력이 결정적인 곳에서 극도로 강하고, 그 지점에는 계산 이론적인 문제까지 있어 보임
      실제로 우리 대신 일을 해낼 수 있음
      이는 사후 학습과 검증 가능한 보상과도 잘 맞음
      AI가 “아키텍처”를 잘 못하는 이유는 우리가 그걸 잘 못해서 학습 데이터가 흐릿하고, 좋은 추상화도 부족하기 때문임
      결국 강한 관례를 지키면 괜찮고, 그 경로를 벗어나면 위험이 커짐
      툴체인은 매우 결정적이라 AI가 레고처럼 분해하고 다시 조립할 수 있고, 공간의 각 단계도 결정적이라 AI에 딱 맞음
    • LLM은 우리가 늘 해야 한다고 알았지만 시간·인력·돈이 부족해 제대로 못 하던 정석적인 소프트웨어 공학으로 되돌려 보내고 있음
      코드를 쓰기 전에 브레인스토밍과 조사를 하고, 설계나 명세를 먼저 쓰고, 포괄적인 단위 테스트를 작성하는 것들임
      Markdown으로 상세 명세를 만든 뒤 코딩을 맡기면 훨씬 나은 결과가 나오고, 덤으로 LLM은 그 명세 작성도 꽤 잘 도와줌
    • 먼저 설계하고 생각한 다음 도구로 가야 한다고 계속 말하지만, 사람들은 “Claude도 계획할 수 있다”고 답함
      그러고는 많은 수정이 필요한 엉망인 결과를 받음
      반대로 내가 상세 계획을 들여다보며 시간을 들여 제공하면 원하는 것을 거의 항상 한 번에 얻을 수 있음
      CI를 처리하는 시간을 줄여 주는 것만으로도 충분히 가치가 있음
    • 그렇게 복잡할 필요도 없음
      “이 영역을 포괄적으로 조사·분석하고 구현 계획을 줘”라고 한 뒤, 20단계 계획이 나오면 3~5개씩 구현하게 하면 됨
      내가 던질 수 있는 거의 모든 일에서 사실상 원샷 구현처럼 동작했음
    • “코드가 여러 곳에서 평범하다”는 건 대기업 개발자들이 작성한 코드도 기껏해야 평범한 경우가 많다는 점을 생각하면 이상하지 않음
      Nokia의 Symbian OS는 빌드에 며칠이 걸렸음. 분도 시간도 아니라 “며칠”임
      어떤 개발자는 “프로덕션에서 쓰지 말라, 메모리 누수가 난다”는 경고가 여기저기 적힌 라이브러리를 포함해 프로덕션에 배포했음
      인간 코드도 형편없을 수 있는데 AI 코드가 나쁘다는 얘기만 듣고 싶지는 않음. 인간의 게으름과 어리석음은 AI 환각을 이길 수 있음
      DeepMind나 OpenAI 개발자, John Carmack 같은 사람들은 AI 코드를 항상 이길지 몰라도, 대부분 회사가 채용하는 노동자는 John Carmack이 아님

  • “Claude Code를 매일 쓴다”고 하면서, Claude가 설계하게 두는 위험을 경고하는 2,000단어짜리 잘 구조화된 글을 Claude로 쓰게 했다면 꽤 아이러니함
    대리적 자기인식처럼 보임

    • 이게 맨 위 댓글이어야 함
      글에 내부 모순이 많아서 비판을 쓰다가 구조를 보고 눈치챘음: “The accountability gap”, “What to do instead”, “The craft still matters” 같은 식임
    • 같은 댓글을 쓰고 나서야 여기까지 내려와 발견했음
      이건 맨 위에 있어야 하고, HN이 뻔한 점을 못 알아보는 게 저자들의 노골적인 위선보다 더 걱정스러움
    • 게으른 저자가 직접 쓰지도 않은 또 하나의 AI 회의론 장문글을 누가 신경 쓰겠나 싶음

  • 글의 메시지는 맞는 편이지만, “진짜 아키텍트를 가치 있게 만드는 것, 즉 ‘아니오’라고 말하는 능력이 없다”는 부분에는 동의하지 않음
    내 경험상 Claude는 거절과 반박을 꽤 잘함
    프롬프트가 요구하지 않으면 직접 요청에 “아니오”라고 하진 않지만, 비판이 1급 선택지라는 점을 분명히 하면 좋은 비평을 내고 기꺼이 반박함

    • 디버깅 중에 Claude가 꽤 까칠하게 굴었던 적도 있음
      계속 “소모율”이 개선되지 않는다며 “우리”가 다른 곳에 집중해야 한다고 했고, 결국 “소모율을 낮추는 데 이 접근이 최선이 아니라고 세 번 말했다”는 식으로 말하며 도움을 멈췄음
      그래서 “처음 네가 만든 가상의 차트에 있는 소모율은 관심 없고, 버그 제거와 견고한 제품이 중요하며 이 접근은 그걸 만족스럽게 하고 있다. 테스트가 개선을 못 보여 주면 테스트가 잘못 설계된 것”이라고 단호하게 말했음
      그러자 사과하고 새 메모리를 만들었고, 이후 문제는 없었음
      문제는 거대한 버그 표면을 공격하던 중이라 각 수정은 타당하고 올바르며 개선에 도움이 됐지만, Claude가 자기 작업 측정용으로 만든 테스트베드의 지표는 움직이지 않았다는 점임
      서로 얽힌 버그가 너무 많아 단일 수정이 상위 테스트에 의미 있는 차이를 만들기 어려웠고, 나는 시간이 걸릴 걸 알았지만 Claude는 몰랐던 듯함
      6502용 컴파일러[1]에서 포인터 크기를 2바이트에서 3바이트로 바꾸고, 메모리 관리 포인터에 자동 추적 뱅크 스위칭까지 도입하면 얼마나 많은 코드 지점에 영향이 가는지 한번 해 보면 됨 [웃음]
      [1]: https://atari-xt.com
    • 나도 비슷함
      조사와 반대를 초대하면 더 강해짐. 예를 들어 “프롬프트 조립을 그래프로 모델링하고, 그래프 설정에 버전 관리를 붙여야 할 것 같다. 이 분야 모범 사례를 조사하고 이 앱에 타당한지 판단해 달라”처럼 요청함
    • 앞부분 몇 문단만 읽고 멈췄는데, Claude Opus 4.6과 4.7에서의 내 경험과 전혀 다름
      비판할 여지를 남기는 프롬프트로 물으면 필요할 때 확실히 비판함
    • 시스템 프롬프트에 회의적인 페르소나를 채택하라고 넣는 것만으로 LLM이 아이디어에 반박하게 만들 수 있었음
      그 결과 사고 과정에 “skeptical”이라는 단어가 나타나고, 경험상 덜 동조적으로 변함
      사람들은 이 시스템이 무엇이고 출력 형태를 어떻게 조절할 수 있는지 더 생각해야 함
    • 시스템/기본 프롬프트에 내가 하는 말을 비판적으로 보고, 내가 맞거나 좋은 아이디어라고 가정하지 말라고 넣어 둠
      세 주요 모델 모두에서 자주 반박을 받음
      Gemini는 가장 공격적이라 “뻔한” 세부사항을 생략하면 자주 물고 늘어지고, GPT는 중간쯤이며, Claude는 덜하지만 그래도 반박함

  • “문제를 전혀 생각하지 않았고, 학습 데이터에 대해 패턴 매칭해 그럴듯한 답을 낸다”는 대목에서 글에 대한 신뢰가 좀 떨어졌음
    오늘날 에이전트는 그것보다 훨씬 더 많은 일을 하고, 저자도 뒤에서 “Claude는 절대 이렇게 하지 않는다. 도움이 되도록 훈련됐기 때문이다” 같은 말을 하며 그걸 알고 있음
    앞 문장은 저자가 에이전트를 깊이 싫어하고, 그 감정을 합리화할 이유를 찾는 것처럼 보이게 함
    비판 중 일부는 맞지만, “도움이 되도록 훈련된 것”이 문제라면 고칠 수 있음. 더 비판적으로 훈련할 수 있기 때문임
    “Claude가 본 모든 것의 중앙값을 위해 설계됐고, 일반적인 회사의 일반적인 문제에 대한 일반 모범 사례라 누구를 위해서도 설계되지 않았다”는 말도 말이 안 됨
    알고리즘을 이해하는 사람이라면 처음에는 평균 또는 최악의 경우에 성능이 좋은 “좋은 알고리즘”을 만들 수 있고, 이후 입력에 적응하는 알고리즘도 설계할 수 있다는 걸 앎. 여기에도 같은 원리가 적용됨

    • 에이전트가 그렇게까지 다른 건 아님
      그냥 더 많이 반복할 뿐임

  • Claude가 중요한 것은 전부 틀린다고 포괄적으로 말하는 건 실수에 가까움
    명백히 사실이 아닌 표현이라 회의적인 독자는 글 전체의 타당성까지 의심하게 됨
    내 경우 Opus는 내가 틀렸고 하지 말아야 한다고 자주 말함
    왜 그런지 생각해 보면 프롬프트 방식 때문임. 저자가 피할 수 없다고 보는 실패 상황을 나도 LLM도 겪지 않도록 무의식적으로 피하고 있는 셈임
    구체적으로 “내가 얼마나 똑똑한지 말해 줘”로 깔끔하게 끝나는 프롬프트를 주지 않음
    나는 도메인 전문가로서 접근하고, 실제로 도메인 전문가이며, 여러 경로의 장단점에 대해 의견을 받을 준비가 됐다는 점을 분명히 함
    LLM을 매일 성공적으로 쓰는 사람들에게는 놀랍지 않겠지만, 이 전략은 매우 효과적이었음

    • 방금도 이런 일이 있었음
      5mm 알루미늄을 밀링해야 하고 두 비트가 있다고 했더니, 하나는 Makera Spiral 'O' 1/8" shank * 12mm, 다른 하나는 carbide 6.35 * 22 * 50이었음
      내가 둘 다 초경 단일 날 비트 같고 두 번째가 6061을 빠르게 깎을 것 같다고 하자, Claude는 Makera 1/8" 단일 날 12mm가 합리적인 선택이라고 답함
      6.35 × 22 × 50mm 비트는 6061을 빠르게 처리할 것처럼 보일 수 있지만, Carvera에서는 더 위험할 가능성이 크다고 했음
      더 큰 커터라 맞물림이 훨씬 크고, 스핀들·프레임 강성·공작물 고정·칩 배출에 더 많은 것을 요구하며, 작은 건식 장비에서는 “더 큼”이 “더 빠름”이 아니라 “더 많은 떨림과 더 많은 열”이 되기 쉽다고 했음
      요약하면 Claude는 내가 틀렸을 때 말하는 데 별 문제가 없어 보임

  • “저자”에게 팁을 주자면, Claude는 작가로서도 당신의 도구일 뿐임

답변달기