Claude를 사용해 Peewee, cysqlite, 문서, 테스트 스위트를 다듬어 본 경험을 바탕으로, AI가 코드 분석에는 강하지만 생성과 대규모 리팩터링에는 한계를 보인다는 점을 돌아본 글.
2026년 3월 23일 21:33 /aipython/댓글 0개
오 모든 나무 가운데 으뜸이며, 고결하고, 귀한 나무여
낙원에서! 작용에 있어 축복받아
지금껏 가려지고 오명 씌워졌던 지혜로 이끄는구나.
몇 주 전 Anthropic은 오픈소스 개발자에게 Claude 최고 요금제를 6개월 동안 무료로 제공하는 프로모션을 발표했다. 나는 신청서를 제출했고, 며칠 뒤 받은편지함에 초대장이 도착했으며 최신 Opus 4.6 모델을 바로 사용할 수 있게 되었다. 이전에는 무료 계정에 주어지는 보잘것없는 토큰 한도 내에서 Sonnet만 쓸 수 있었으니, 이는 AI 도구를 사용할 때 내가 익숙했던 모든 것에서 꽤 큰 변화였다.
손에 나무의 열매를 딴 채 나는 곧장 뛰어들었다. 먼저 Claude에게 내가 Peewee에 asyncio를 구현하려고 하며 해오던 작업을 검토하게 했고, cysqlite에서 성능을 최적화할 방법을 찾게 했으며, Peewee 문서를 재구성하기 위한 계획도 세우게 했다. 이 작업들은 모두 상당히 독립적이었지만, 점점 더 많은 데이터와 문맥을 다루고 있었다.
Claude의 성능은 이 작업들 전반에서 들쭉날쭉했다. asyncio 구현에서는 여러 버그를 찾아 수정했는데, 대부분 리소스 정리와 관련된 것이었고, 이는 asyncio에서 꽤 까다로운 문제일 수 있다. 특히 소멸자가 동기식이라는 점이 그렇다. 결국 이 작업은 task-local storage 구현을 더 깔끔하게 만드는 방향으로 이어졌고, 이것은 Peewee를 async로 만드는 데 필요한 마법의 약 절반을 차지한다. 이 구현은 diff를 아주 면밀히 검토해야 했고, 제안된 해결책이 정말 괜찮은지 판단하기 위한 많은 분별력이 필요했다. 조각조각 떼어 보면 Claude가 만들어낸 코드는 너무나도 그럴듯해서, 나조차도 거의 반사적으로 그냥 훑어넘기게 된다. 그래서 꼼꼼한 리뷰가 믿을 수 없을 만큼 중요하다. 처음 몇 번의 결과물은 형편없었지만, 방심한 개발자라면 그것을 필연적인 해법으로 착각할 법한 그럴싸함은 갖추고 있었다.
cysqlite의 성능 최적화를 맡겼을 때 Claude는 꽤 형편없었다. 예를 들어 Python 코드가 이미 최적화된 호출로 적절히 번역되어 있는데도 C 수준의 구성을 사용하라고 제안했다. Claude가 “hot”하다고 지목한 구간들에 대한 다른 제안들도 코드베이스에 적용해 보니 코드 품질과 가독성만 떨어졌고, 측정했을 때 성능 향상은 잡음과 구분되지 않는 수준이어서 결국 커밋하지 않았다. 반면 구현상의 버그를 찾는 데에는 훨씬 더 잘했다. 심지어 실패하는 테스트 케이스까지 만들어냈는데, 그건 정말 훌륭하다. 누군가 우연히 그 버그들을 밟기 전에 수정할 수 있었던 점에 대해 매우 고맙게 생각한다. 또한 테스트 커버리지의 빈틈을 식별하는 데에도 도움이 되었고, 덕분에 온갖 지루한 경계 사례들이 결국 테스트로 덮이게 되었다. 그런 측면에서는 분명 시간을 절약해 주었고 라이브러리도 더 좋아졌다.
Peewee documentation 재구성 작업에서 Claude는 분석 과 계획 수립 으로 제한했을 때는 아주 훌륭했다. 예를 들어 최상위 주요 섹션은 무엇이어야 하는지, 현재 문서의 특정 섹션이 새로운 계층 구조에서는 어디에 가장 적절하게 들어가야 하는지 같은 일들이다. 하지만 그 계획을 실제 문서에 적용 하라고 시키자 온갖 문제가 발생했다. 기존 문서의 전체 섹션이 통째로 바닥에 떨어진 듯 결과물에서 사라졌고, 다른 섹션은 일부가 중복되었다. Claude는 존재하지도 않는 API를 만들어 호출하는 식으로 잘못된 사용 예제를 환각해 내기도 했다. 결국 나는 구체적으로 살펴볼 무언가를 얻기 위해서만 Claude에게 재구성을 수행하게 했다. 그리고 Claude의 결과물은 한쪽으로 치워 둔 뒤, 문서 하나하나 섹션 하나하나를 현재 문서와 Claude 버전과 비교하면서 일종의 수동 병합을 했다. 이 작업에는 여러 시간이 걸렸다. 돌이켜 보면, 좋은 개요만 받아서 내가 직접 그 개요를 바탕으로 작업하고, Claude에게는 빠진 부분이나 더 나은 예제가 필요한 곳을 찾게 했더라면 시간 절약 측면에서 비슷했거나 오히려 더 나았을지도 모르겠다.
Claude: 탑에 달 큰 시계가 필요해.
Claude: 4개의 시계면과 종을 수년간 연속 운용하면서 안정적으로 구동할 수 있는 중력 구동식 시계가 필요해. 약 100kg인 길이 5m의 분침과 약 300kg인 길이 3m의 시침을 회전시키기에 충분한 연속 토크를 제공해야 해. 바늘이 회전하면서 지레팔 길이가 바뀌어 생기는 토크 변화와 큰 다이얼 면에 작용하는 풍력도 고려해야 해. 10도에서 100도 사이에서 안정적으로 작동해야 하고, 열팽창, 습기, 먼지, 윤활 성능 저하도 감안해야 해. 부분적인 기계 고장에도 견고해야 해.
Claude: ... 내 시계 평가해 줘
나는 Claude의 읽고 분석하는 능력과, 무언가를 생성하거나 제자리에서 수정하는 능력 사이에 거대한 간극이 있다는 사실을 깨달았다. 그리고 이 간극은 작업 범위가 커질수록 더 극적으로 드러난다. 이 능력 차이는 asyncio extension 같은 더 작은 작업에서도 이미 분명했다. Claude는 리소스 정리가 취약한 부분을 능숙하게 식별하고 테스트 커버리지의 빈틈을 찾아낼 수 있었다. 그중 많은 일은 생명주기, API 계약, async 대 sync 동작, 경쟁 상태, 데드락 등등에 대한 깊은 사고를 필요로 했다. 하지만 새롭거나 낯선 구현을 만들어내라 는 과제를 주면 Claude는 비틀거리며 같은 똥을 포장지만 다른 색으로 계속 선물해 주었다. 코드를 읽을 때 보여 주었던 그 통찰과 독창성은 다 어디로 간 걸까?
이것이 next-token generation의 본질 때문인지, 아니면 multi-agent 피드백 루프(에이전트 1이 코드를 쓰고 에이전트 2가 비판하는 식)가 필요하다는 뜻인지는 모르겠다. 하지만 Claude의 성능에는 두 종류의 작업 사이에 분명한 차이가 있고, 문맥 크기가 커질수록 그 차이는 더 또렷해진다. 그러다 보니 확장 사고 모델이 코드 생성 중에 왜 더 견고한 내부 피드백 루프를 갖고 있지 않은지 의문이 들었고, 결국 내 프롬프팅 전략을 다시 생각하게 만들었다.
나는 지금 Peewee test suite를 재구성하고 정리하는 데 Claude의 도움을 받고 있으며, 앞선 작업들에서 겪은 실패와 좌절에서 배운 것을 적용하고 있다. Peewee에는 1MB가 넘는 테스트가 있으니, “이 테스트들 리팩터링하고 정리해 줘”라고 입력하는 꿈 같은 일은 절대 일어나지 않을 것이다. 많은 테스트는 암묵적으로 여러 미묘한 동작을 동시에 검증하고 있다. 더 골치 아픈 것은, 많은 테스트가 model class를 공유하지만 어떤 경우에는 이름만 같은 지역 변형을 따로 사용한다는 점이다. 게다가 Peewee가 생성하는 SQL은 model class와 field 인스턴스의 이름에 의존한다. 물론 명시적인 이름을 주지 않는 한 그렇다. 따라서 이름을 바꾸려면 대응되는 SQL 생성 assertion도 찾아서 함께 고쳐야 한다.
이 프로젝트에서 잘 작동한 방식은 내가 예상했던 것과는 아주 달랐다. 초반에는 훨씬 더 많은 명세 작업이 필요했다.
그 다음에는 테스트를 작고 독립적인 단계로 재구성하는 계획을 제안하라고 Claude에게 요청했다. 계획이 타당해 보이는 것을 확인한 뒤에 진행하게 했다. 각 단계마다 현재 테스트 스위트와 비교해 테스트 러너 출력과 diff를 검토하여 작업이 제대로 진행되는지 확인했다. Claude는 결국 테스트 모듈 안에서 주석을 “anchor”로 사용하는 체계를 고안했고, 큰 문제 없이 기계적인 재구성을 완료할 수 있었다.
이 작업은 아직 진행 중이고, Claude 자신의 분석에 따르면 더 깊은 논리적 리팩터링을 시도하는 것은 이득보다 위험이 더 클 수도 있어서 일부는 끝내 하지 않을 수도 있다.
전반적으로 나는 Claude가 많은 시간을 절약해 주었다고 믿고 있으며, 많은 단점도 프롬프팅 전략을 조정하고 작업을 더 작은 조각으로 나누면서 해결할 수 있었다. 이것은 Anthropic의 Nicholas Carlini가 Rust C Compiler를 작업하며 설명한 내용과도 일치하는 듯하다.
따라서 작업 검증기는 거의 완벽에 가까워야 한다. 그렇지 않으면 Claude는 잘못된 문제를 풀게 된다. 테스트 하네스를 개선하려면 고품질 컴파일러 테스트 스위트를 찾고, 오픈소스 소프트웨어 패키지를 위한 검증기와 빌드 스크립트를 작성하고, Claude가 어떤 실수를 하는지 지켜본 뒤, 그런 실패 양식을 식별할 때마다 새로운 테스트를 설계해야 했다.
나는 Claude가 테스트 스위트를 리팩터링하려고 시도하는 과정을 여러 차례 지켜보았고, 각 실행 결과의 부족한 점을 바탕으로 위의 프롬프팅 전략을 조정하여 새롭게 피해야 할 문제 유형을 특별히 강조했다. 이것은 꽤 효과적이었다.
일반적으로 Claude는 다음과 같은 일에 확실히 도움이 된다.
Claude가 잘하지 못한 것은 다음과 같다.
AI 소프트웨어 개발은 창업자들 사이에서 거의 종교적 경외심으로 다뤄진다. 그들은 아이디어를 수익성으로 바꾸는 silver bullet을 찾았다고 믿는다. 여기에 더해, 도태될지 모른다는 두려움, 시장 선점에서 밀릴지 모른다는 두려움, 혹은 AI Native 혁명을 놓칠지 모른다는 두려움도 함께 도취를 부추긴다. 나는 이 두 가지 가정이 모두 잘못되었다고 생각한다. 내 경험상 AI는 코드 작성과 기존 코드의 정확성 검증 모두에서 내 효율을 압도적으로 높여 줄 수 있다. 하지만 더 크고 더 복잡한 문제를 다루기 시작하면, 프롬프트와 워크플로는 믿을 수 없을 만큼 중요해지고, 코딩 그 자체가 요구하는 것과 매우 비슷한 형태와 성격을 띠기 시작한다. 극단으로 밀고 가면, 프롬프팅은 코딩과 수렴한다.
비슷한 방식으로, 나는 이러한 두려움도 빗나갔다고 생각한다. 만약 AI가 정말 거기까지 와 있었다면, 순수 소프트웨어 혹은 심지어 대부분이 소프트웨어인 B2B형 엔터프라이즈 소프트웨어는 80%의 기능을 더 싼 가격에 제공하는 수백 개의 vibe-coded 대안으로부터 실존적 위협을 받았을 것이다. Slack, SalesForce, PhotoShop, Office365, DocuSign 같은 것들 말이다. 나는 vibe-coding AI-Native 스타트업들이 이런 비즈니스를 조만간 대체하리라고 믿지 않는다. 그리고 그 주된 이유가 관성이나 기존 입지라고도 생각하지 않는다. AI는 아직 거기까지 오지 못했다.
나는 아내에게, 간호전문가인 그녀에게, 이 모든 것에 대해 어떻게 생각하는지 물어봤다. AI는 그녀의 사무실과 학회에서 화제가 되고 있기 때문이다. 의료 분야에서의 AI-Native 비전은 모든 EMR의 제거일 것이다. 환자가 증상을 호소하며 오면, AI가 듣는 가운데 진찰이 이루어지고, AI가 관련 검사를 주문하면 그 결과가 다시 입력되어 분석되고 환자의 전반적인 건강 상태, 병력, 복용 약물과 연관 지어진다. AI는 진단을 종합하고 치료 계획을 세우거나, 입원을 처리하고 수술 일정을 잡는다. 보험 청구와 그에 따른 업무도 AI가 처리한다. 이게 가능할까?
그녀는 심부전을 앓고 있는 환자 한 명의 이야기를 들려주었다. 그는 약을 잘 복용하지 않지만, 자신이 복약 비순응적이라는 말을 듣는 것은 싫어한다. 그는 아주 나이가 많은 것도 아니고 건강 상태가 극도로 나쁜 것도 아니지만, 몸은 쇠약해지고 있다. 그녀는 그 같은 사람들, 어느 정도 복약 비순응적인 사람들, 특정 약을 견디지 못하지만 급할 때는 복용할 수 있는 사람들, 그리고 다른 모든 “경계 사례”들이 AI가 운영하는 시스템에 들어맞지 않을까 봐 걱정한다고 했다. 또한 진료 중 휴대폰을 사용해 메모 개요를 잡는 동료의 이야기도 해주었는데, AI가 생성한 메모는 대체로 좋지만 가끔은 논의된 적도 없는 황당한 진단을 끼워 넣는다고 한다. 그럼에도 그녀가 더 우려하는 것은, 진찰과 환자와의 대화 과정에서 일어나는 인간적인 재량과 분별이 사라질 수 있다는 점이었다. 환각된 진단도, 엉뚱한 다리를 자를 가능성도 잠시 잊어 보자. 훨씬 더 위험한 일은 환자와 의료 제공자 사이의 상호작용을 잃는 것이라고 했다.
AI를 정말 오래 써 본 우리에게는 이것들이 딱히 새로운 이야기가 아닐 것이라 짐작하지만, 생각이 아직 생생할 때 여기에 정리해 두고 싶었다. 아니면 3월 말에 시작하는 소형 엔진 수리 수업이 정말 절묘한 타이밍에 찾아온 것인지도 모르겠다.
홈페이지에도 적혀 있지만, 여기서 다시 한 번 강조할 가치가 있다. 이 글을 쓰거나 편집하는 데 어떤 방식으로도 AI는 사용되지 않았다. 이미 세상에는 slop이 충분히 많다.
이름
이메일
Url
댓글
링크
댓글 등록
Contact | About this site © charles leifer, 2026
