Opus 4.5는 인상적이지만, 잘 설계된 추상화를 ‘조립’하는 데는 강해도 새로운 추상화를 ‘창조’하는 데는 여전히 취약하다. Sentry 디버깅 루프, AWS ECS 마이그레이션, React 리팩터 사례로 그 한계를 짚는다.
Jan 12, 2026 6 min read
Opus 4.5가 나왔고 사람들은 칭찬을 멈추지 못하고 있다. AGI가 코앞이다! 능력이 단계적으로 도약했다!
오해는 말자. 정말 인상적이다. 하지만 실제 코드베이스에서 몇 주 동안 써 본 뒤로는, 그런 관점이 지나치게 단순하다고 생각하게 됐다. 이제 Claude는 잘 설계된 블록을 조립하는 데는 невероят하게 능하지만, 그 블록을 만들어야 할 때는 여전히 와르르 무너진다.
이를 보여주기 위해, 실제 사례 세 가지를 살펴보겠다. Claude가 90분 동안 혼자 돌며 문제를 해결한 Sentry 디버깅 루프, 3시간 만에 한 번에 끝낸 AWS 마이그레이션, 그리고 코드베이스를 더 나쁘게 만들 뻔한 꼼수를 제안했던 React 리팩터 사례다.
이 셋은 모두 같은 패턴으로 설명된다. 그리고 그 과정에서 시니어 엔지니어가 실제로 무엇을 하는지, 또 우리가 한동안은 AGI로부터 안전할 이유가 무엇인지도 드러난다.
🎯
— Ryan Nystrom (@ryannystrom) January 10, 2026
요약(tl;dr)
Claude Code가 내게 해 준 일 중 가장 인상적인 건, 혼자서 디버깅을 해낸 일이었다.
나는 우리 시스템에 Sentry를 붙이려고 했다. Sentry는 코드의 각 부분이 언제 실행되는지 보기 좋은 트레이스를 만들어 주는 훌륭한 서비스다. 덕분에 왜 기대보다 느린지 파악하기가 쉽다.
데이터베이스 조회를 최적화해야 한다는 것을 보여주는 Sentry 트레이스 예시...
보통 설정은 매우 쉽지만, 그날은 작동하지 않았다. 그리고 괜찮은 디버그 로그도 없어서, 무슨 일이 벌어지는지 알아내는 유일한 방법은 추측하고 확인하는(guess-and-check) 것뿐이었다. 프런트엔드에서 테스트 메시지를 보내고, Sentry 로그를 확인해서 제대로 연결됐는지 보고, 문서를 읽다가 또 무작위로 다른 접근을 시도해야 했다. 답답하고 지루했다.
그래서 Claude에게 Playwright로 작은 테스트 스크립트를 쓰게 했다. 우리 웹사이트에 로그인해서 채팅을 보내는 스크립트였다. 그리고 MCP로 Sentry에 연결하게 한 뒤, 내가 디버깅하려는 정확한 코드 경로를 찾게 했다. 마지막으로 Sentry 문서를 주고, 해결할 때까지 계속 시도하라고 했다.
약 한 시간 반이 걸렸지만, Claude가 결국 해냈다. 꽤 멋졌다! 성능 엔지니어링의 핵심 루프는 단순하다. 코드 변경 → 테스트 → 트레이싱 로그 확인 → 반복. 이런 툴링이 있으면 Claude가 그 작업을 대신할 수 있다.
(궁금하다면 문제는 이랬다. Sentry는 FastAPI 엔드포인트에 대해 트랜잭션을 자동으로 설정해 주지만, _StreamingResponses_를 반환하는 엔드포인트에는 설정하지 않는다. 해결책은 그 부분을 수동으로 작성하는 것이었다.)
나는 1년 동안 Modal을 만족스럽게 써 왔다. 필요할 때 클라우드에서 컨테이너를 띄우는 UI는 정말 _최고_다. 하지만 지난주에 한계를 맞았고, 결국 AWS로 옮겨야 했다.
나는 Amazon Elastic Container Service(ECS)에서 오토스케일링이 되는 컨테이너 워크플로를 구축하고 싶었다. 이게 ‘정답’이라고 알고 있었기 때문이다. 리눅스 서버는 손으로 많이 설정해 봤으니 뭘 해야 하는지는 알았다. 하지만 Kubernetes나 ECS는 한 번도 만져 본 적이 없었다. AWS의 용어를 배우는 고통이 늘 나를 주저하게 만들었다.
이번에는 Claude에게 맡겼다. Terraform과 aws 커맨드라인 툴 접근 권한을 주었다. Claude는 우리 코드용 Dockerfile을 한 번에 만들어냈다. 그리고 AWS의 컨테이너 레지스트리에 푸시하고, CLI로 올바른 권한을 설정하고, Terraform으로 필요한 AWS ECS 설정을 구성했다.
그리고 첫 시도에 전부 동작했다! 놀랍다!
Terraform 설정들이다. 신나는(?) 내용. 이걸 손으로 쓴다고 상상해 보라!
이 작업은 단순하긴 하지만, 내가 했다면 하루나 이틀은 걸렸을 것이다. 열두 번쯤 실수하고, AWS 문서를 수십 페이지 읽어야 했을 테다. Claude는 압도적으로 잘 해냈고, 늦은 밤 3시간 만에 전부 굴러가게 만들었다.
이 두 가지 유스케이스는 정말 인상적이다! 디테일과 주의가 많이 필요했다. 각각 하루 반 정도의 저부가가치의 지루한 일을 절약해 줬을 것이다. 그리고 Claude가 자기 상태를 추적하면서 계속 밀어붙이는 능력도 좋았다! 사람들이 왜 Opus 4.5 얘기를 그렇게 하는지 알 것 같다.
나는 한때 sweeks라는 저명 엔지니어를 알았다. Sweeks는 좋은 코드로 전설적이었다. 사람들은 그가 혼자서 우리 회사의 OCaml 프로그래밍 패러다임 여러 개를 발명했다고 수군거렸다.
Sweeks가 신이었던 건 아니다. 그도 당신과 나처럼 평범하고 버그 많은 코드를 썼다. 그가 코딩을 잘한 이유는 그가 정원사였기 때문이다. 코드베이스에 들어올 때마다 가위를 들고 삐져나온 코드를 조금씩 다듬었다. 시간이 지나면서 모든 라인을 반복해서 다시 쓰며, 완벽하게 추상화된 핵심만 남을 때까지 점점 조여 나갔다.
Sweeks는 영감이 된다. 그래서 나는 코드베이스를 변경할 때마다 그것이 가장 우아한 해법인지 스스로 묻는다. 아니라면, 우아해질 때까지 다시 쓴다. 대충 땜빵(hacky)으로 고치면 5분이면 끝날지도 모르지만, 변경 주변의 코드를 고쳐서 수선하는 데는 30분이 걸릴 수도 있다. 하지만 급하지 않다면, 나는 항상 후자를 한다.
이 얘기를 꺼낸 이유는, 이것이 시니어 엔지니어가 하는 일을 축소판으로 보여주기 때문이다. 시니어 엔지니어는 명확하지 않은 개선점을 보고 빠르게 실행한다. 시니어 엔지니어는 비용이 크지만 나중에 몇 배로 돌아오는 **큰 단계 변화(step change)**를 알아채고, 그것을 관철시키기 위해 싸운다.
Opus는 시니어 엔지니어가 아니다.
최근에 나는 꽤 지저분한 React 코드를 다루고 있었다. (사실, 크리스마스에 바이브 코딩으로 대충 만들고 제대로 정리하지 않은 채 푸시해서 지저분해진 것이었다.)
우리는 같은 데이터에 접근해야 하는 컴포넌트 두 개가 있었다. 컴포넌트 A는 key를 가지고 있었고, 컴포넌트 B는 id를 가지고 있었다. 그리고 데이터 구조는 이랬다:
keyIdPairs: [(key, id)] // 튜플 리스트idToData: Map<id, data>
우리의 핵심 문제는, 컴포넌트 A도 필요할 때 data를 조회해야 한다는 것이었다. 어떻게 해야 할까?
천재적인 바보 같은 Claude는 선형 조회를 제안했다:
// 리스트를 스캔해서 일치하는 id를 찾는다id = keyIdPairs.find(pair => pair.key == key).iddata = idToData.get(id)
하지만 맥락 안에서는 이게 명백히 말이 안 됐다. 나는 key와 id가 같은 업스트림 소스에서 온다는 걸 알고 있었다. 그래서 올바른 해결책은, 업스트림 소스가 key를 가진 코드에도 id를 함께 넘겨주게 해서 빠르게 조회할 수 있도록 하는 것이었다.*
Claude에게 순수한 데이터 문제만 주면 올바른 해결책을 내놓는다. 하지만 실제 코드베이스에서는 길을 잃었다. 형편없이 작성된 React 코드 속에서 진짜 데이터 문제를 보지 못했다. 내가 Claude를 풀어 놨다면, 프런트엔드 코드베이스를 더 나쁘게 만들었을 것이다.
요즘 나는 Claude를 매우 똑똑한 아이, 그러니까 레고를 조립하는 걸 사랑하는 아이로 생각한다. 좋은 인프라와 추상화는 Claude에게 쥐여 주는 레고 블록이다. 블록이 크고 좋을수록 더 많은 일을 할 수 있다.
Sentry를 줬을 때는 루프에 넣어 두고 움직이는 걸 볼 수 있었다. Terraform을 주고 AWS CLI에서 마음껏 하게 했을 때 성공한 이유는, Terraform이 클라우드 컴퓨팅 자원 위에 씌운 훌륭한 추상화이기 때문이다.
하지만 좋은 추상화가 없으면—우리의 지저분한 React 코드처럼—Claude는 길을 잃고, 스스로를 구해내지 못한다.
Grant Slatton이 이를 아주 잘 표현했다:
obviously this is a very rough analogy, it's just a handwave sketch at a concept
but the general idea is LLMs are bad at making clean cuts in the concept graph
— Grant Slatton (@GrantSlatton) December 27, 2025
Claude는 좋은 추상화를 _창조_할 수 없기 때문이다. Claude의 힘은 당신이 제공하는 블록이 얼마나 좋은지에 의해 제한된다. 착각하지 말자. Claude는 Sentry나 Terraform이나 Playwright를 재현해 낼 수 없다. 이것들은 믿을 수 없을 만큼 복잡하고 잘 설계된 코드 조각들이다. 그리고 Claude는 스스로 좋은 추상화를 만들 수 없으니, Claude만으로 할 수 있는 일에는 한계가 있다. X(트위터)에서는 모두가 바이브 코딩으로 모든 소프트웨어를 만들 수 있을 것처럼 말하지만, 나는 정반대라고 생각한다. 좋은 추상화와 잘 설계된 인프라의 가치는 지금이야말로 가장 높다.
내가 Claude에 대한 비판을 한 문장으로 요약해야 한다면 이렇다. Claude에게는 영혼이 없다. Claude는 어떤 것도 원하지 않는다. 아름다운 것을 만들고자 갈망하지도 않는다. 그래서 좋은 해법을 만들어내지 못한다. 아무것도 없던 곳에 우아한 추상화를 써내리지 못하고, 코드 정원을 손질하지도 못한다.
그리고 이건 괜찮다! 그래도 환상적인 도구다. 하지만 영혼을 갖기 전까지는, 모두가 조금은 진정해야 한다. Claude는 모든 엔지니어를 대체하기엔 한참 멀었다. 오히려, 우리를 훨씬 더 중요하게 만든다.
1월 12일 수정: React 섹션을 더 명확히 설명하기 위해 다시 썼다. 이를 지적해 준 Konsti 에게 감사한다!
Approach with Alacrity © 2026
