🤖
1259 in / 3973 out / 5232 total tokens
🔥 핫 토픽
Claude is not your architect. Stop letting it pretend
원문: https://www.hollandtech.net/claude-is-not-your-architect/
이 글이 왜 중요한가. 요즘 개발자들 사이에서 Claude나 ChatGPT에게 "마이크로서비스 아키텍처 설계해줘", "이 시스템 어떻게 구성하지?" 같은 질문을 던지는 게 거의 기본처럼 자리잡았다. Hacker News에서 215점을 받은 이 글은 그 흐름에 제동을 건다. 핵심 주장은 단순하다. LLM은 아키텍트가 될 수 없다. 아키텍처는 트레이드오프를 결정하는 일인데, LLM은 트레이드오프를 이해하지 못한다. 과거 코드 패턴을 통계적으로 재구성할 뿐, 현재 프로젝트의 비즈니스 맥락이나 팀 규모, 기술 부채의 누적을 고려하지 못한다.
게임 개발 관점에서 생각해보면 더 명확하다. UE5로 멀티플레이어 프로젝트를 시작할 때 Claude에게 "서버 아키텍처 설계해줘"라고 물어봤자, 아마 표준적인 디디케이트 서버 + 클라이언트 구조, 리전 서버 분산, 매치메이킹 서버 분리 같은 교과서적 대답이 나온다. 맞는 말이긴 하다. 하지만 그건 이미 아는 내용이다. 진짜 문제는 "우리 팀이 3명인데 이 구조를 감당할 수 있는가", "첫 달에 100명 동시접속도 안 나올 건데 언리얼 전용 서버 비용을 어떻게 할 것인가" 같은 질문이다. Claude는 이런 맥락을 모른다. 질문에 적힌 정보만으로 추론할 뿐이다.
실무적으로 더 위험한 건, LLM이 아주 그럴싸한 아키텍처 다이어그램과 기술 스택을 뱉어낸다는 점이다. 초보 개발자는 이걸 "전문가의 조언"으로 받아들인다. 그리고 프로젝트 중반에 가서야 그 아키텍처가 현재 요구사항에 맞지 않는다는 걸 깨닫는다. 필자가 말하는 "Stop letting it pretend"는 정확히 이 지점을 겨냥한다. LLM이 아는 것과 이해하는 것은 다르다. 패턴 매칭과 진정한 설계 사고는 완전히 다른 차원의 문제다.
그렇다고 Claude가 쓸모없다는 뜻은 아니다. 코드 생성, 리팩토링 제안, 특정 알고리즘 구현, 버그 분석 같은 잘 정의된 작업에서는 훌륭하다. 문제는 경계를 허물 때 생긴다. "설계"라는 모호한 영역에 AI를 끌어들이는 순간, 우리는 패턴의 노예가 될 위험이 있다.
출처: Holland Tech - Claude is not your architect
📰 뉴스
Mad House — Usborne Creepy Computer Games (Simon Willison)
원문: https://simonwillison.net/2026/May/24/usborne-mad-house/#atom-everything
Simon Willison이 또 재밌는 걸 했다. 1980년대 Usborne에서 출판한 "Creepy Computer Games" 책에 수록된 게임들을 Claude로 재구현한 것이다. 이 책은 필자 같은 80년대생(혹은 그 이전)에게는 향수의 대상이다. BASIC 코드가 책에 인쇄되어 있고, 아이들이 직접 타자 쳐서 입력하는 방식이었다. Willison은 이 오래된 BASIC 게임들을 Claude에게 주고 현대 코드로 변환하게 했다.
이게 왜 중요한가. 앞서 언급한 "아키텍트 논쟁"과 정확히 대비되는 사례이기 때문이다. Claude는 아키텍처 설계에는 부적합하지만, 이런 명확하게 정의된 변환 작업에는 엄청난 힘을 발휘한다. 입력이 명확하다 (오래된 BASIC 코드). 출력도 명확하다 (작동하는 현대 코드). 검증 방법도 명확하다 (게임이 제대로 돌아가는지 확인하면 된다). 이런 조건에서 LLM 코딩은 거의 마법처럼 작동한다.
게임 개발자 관점에서 보면 더 흥미롭다. 레트로 게임 코드는 규칙이 단순하고 로직이 투명하다. 변수 이름이 의미 없는 알파벳 한두 글자여도, Claude는 전체 코드 맥락에서 의미를 파악한다. GOTO 문이 난무하는 스파게티 코드를 현대적 제어 흐름으로 변환하는 능력은 인상적이다. 물론 100% 완벽하진 않다. Willison도 몇 번의 수정이 필요했다고 했을 것이다. 하지만 출발점으로서의 가치는 엄청나다.
이 실험이 보여주는 핵심은 LLM 코딩의 "적절한 사용처"를 명확히 한다는 점이다. 아키텍처 설계 같은 추상적 작업이 아니라, 입력과 출력이 명확한 변환/구현 작업에 LLM을 투입하라. 게임 개발에서도 마찬가지다. "이 시스템 어떻게 설계해?"는 위험하지만, "이 쉐이더 코드 HLSL에서 GLSL로 변환해줘", "이 알고리즘 C++로 구현해줘" 같은 요청은 생산성을 크게 높여준다.
출처: Simon Willison - Mad House
💡 분석: 두 기사를 관통하는 핵심 통찰
두 기사를 나란히 놓고 보면 한 가지 결론이 도출된다. Claude의 강점과 한계는 "작업의 모호성 정도"에 의해 결정된다.
아키텍처 설계는 본질적으로 모호하다. "좋은 아키텍처"가 무엇인지는 팀, 예산, 일정, 기술 스택, 비즈니스 목표에 따라 완전히 달라진다. 같은 게임이라도 인디 3인팀과 200인 AAA 스튜디오의 서버 아키텍처는 전혀 다르다. Claude는 이 맥락을 품지 못한다. 질문에 적힌 정보만으로 추론할 뿐이다.
반면 레트로 게임 변환은 모호성이 거의 없다. 입력 코드가 있고, 그 게임이 어떻게 작동해야 하는지 명확하다. Claude는 이런 작업에서 압도적인 효율을 보여준다.
필자의 경험을 덧붙이자면, UE5 C++ 작업에서도 동일한 패턴이 관찰된다. "이 기능 어떻게 구현하지?" 같은 넓은 질문보다는, "이 UPROPERTY 리플렉션 매크로 왜 컴파일 에러 나는지 확인해줘", "이 TArray 순회를 범위 기반 for문으로 바꿔줘" 같은 구체적 요청이 훨씬 유용하다. AI 사이드프로젝트를 진행할 때도 마찬가지다. "RAG 파이프라인 설계해줘"가 아니라, "이 LangChain 체인에서 컨텍스트 윈도우 초과 에러 어떻게 해결하지?"가 더 나은 질문이다.
결국 똑똑한 AI 활용법은 똑똑한 질문에서 시작된다. AI가 대신 설계해주길 바라는 순간, 우리는 주도권을 잃는다.
Claude에게 아키텍트 자리를 넘기지 마라. 하지만 타이핑과 디버깅의 동료로는 환영하라. 경계를 아는 것이 현명한 개발자의 핵심 역량이다.