Claude로 지난 몇 주간 코딩하며 얻은 몇 가지 단상
(twitter.com/karpathy)- Claude를 활용해 최근 몇 주간 집중적으로 코딩한 경험에서 나온 간단한 메모 모음
- 트위터 쓰레드 형식으로 개발 과정에서 느낀 점과 관찰을 공유
- 구체적인 코드 예시나 기술적 세부 내용은 본문에 포함되지 않음
- 게시물은 개인적 경험 기반의 짧은 노트 형태로 구성
- 현재 제공된 자료에는 추가 설명이나 세부 내용이 없음
내용 불분명
- 제공된 트위터 링크 외에 본문 내용이 포함되지 않아 세부 요약 불가
- 제목과 게시 형식으로 보아 Claude를 이용한 코딩 경험 요약 트윗 시리즈로 추정되나, 구체적 내용은 언급 없음
- 추가 정보가 없으므로 세부 항목 요약 불가능
Hacker News 의견들
-
어떤 에이전트가 지치지 않고 계속 시도하는 모습을 보는 게 흥미로움
사람이라면 포기했을 상황에서도 30분 뒤엔 결국 성공함
하지만 그 과정에서 GPU와 NPU가 뜨겁게 돌아가고, 우리는 엄청난 데이터를 제공하며 실제 비용은 거의 지불하지 않음
이런 의존이 장기적으로 사회적·정치적 문제로 이어질 수 있음- 나도 그 인용문이 인상 깊었음
지난 20년간 기술 업계에서 성공을 가른 핵심은 끈기(tenacity) 였다고 생각함
새로운 프로토콜이나 프레임워크를 만든 사람보다, 복잡한 시스템을 끝까지 붙잡고 완성한 사람이 훨씬 많았음
Claude 같은 AI가 바로 그 끈기를 갖고 있음 - 하지만 이런 경우 절반은 지름길을 택한 결과임
테스트가 없는 부분에 새 버그를 만들거나, 인간이라면 당연히 지켰을 암묵적 규칙을 깨버림
그리고 잡아내면 “코인 몇 개만 더 넣으면 이번엔 진짜 고치겠다”고 말하는 느낌임 - “비용이 싸지 않을 수도 있다”는 말에 동의하지 않음
인류 역사상 값이 안 내려간 기술은 없었음, 이미 작년 대비 절반 수준임 - 인간도 결국 뜨겁게 돌아감
우리가 먹고, 운전하고, 살아가는 데 드는 공급망 에너지를 생각하면 GPU 전력보다 훨씬 큼 - “실제 비용을 지불하지 않는다”는 비판은 약함
이미 Kimi K2.5, GLM 4.7 같은 오픈 모델이 있고, 상업적으로도 충분히 수익이 남음
진짜 돈이 드는 건 학습 과정이지 추론이 아님
OpenAI나 Anthropic은 실제 비용보다 훨씬 높은 가격으로 API를 팔고 있음
- 나도 그 인용문이 인상 깊었음
-
AI를 쓰면서 두뇌 위축(brain atrophy) 을 느끼고 있음
처음엔 빠른 생산성에 도취되지만, 반복될수록 AI가 내 의도와 다른 방향으로 프로젝트를 끌고 감
결국 내가 원하는 디자인보다 AI의 방식에 순응하게 됨
새로운 접근을 시도할수록 AI의 훈련 데이터 편향이 벽처럼 느껴짐- 단순한 두뇌 위축이 아니라, 모델 사용법을 배우는 데 뇌를 쓰는 구조적 전환임
하지만 이 메타 스킬도 금방 낡음
모델이 바뀔 때마다 새로 배워야 하고, 결국 영원한 러닝 트레드밀 위에 서게 됨
나는 이런 의존을 원치 않음 - 나도 비슷한 경험을 함
최근 Claude Code로 Rust 기반 멀티플레이어 게임을 만들고 있는데, 코드가 잘 돌아가도 내가 진짜 이해하고 있지 않음
과거엔 도구를 완전히 이해해야 여기까지 왔을 텐데, 지금은 반쯤 기능하는 게임만 있음
유지보수나 버그 대응을 생각하면 이건 위험한 상태임 - LLM 사용이 틱톡·릴스 중독과 비슷하다고 느낌
가끔 “와, 이런 결과가?” 하는 순간이 도파민을 자극하고, 그 짧은 쾌감을 다시 얻기 위해 계속 프롬프트를 돌림 - “AI가 하자는 대로 두는 게 더 편하다”는 말에 공감함
하지만 이건 곧 기술 부채를 미덕처럼 여기는 산업 문화로 이어질 수 있음
AI 발전 속도가 그 부채 누적 속도를 따라잡지 못하면 큰 대가를 치를 것임 - 오늘은 새로운 문제를 겪음 — ‘읽기 위축(reading atrophy)’
LLM이 모르면 개발자들이 문서를 읽지 않음
내가 직접 스크린샷과 하이라이트로 문서를 보여줘도 “이게 될지 모르겠다”는 반응을 들음
- 단순한 두뇌 위축이 아니라, 모델 사용법을 배우는 데 뇌를 쓰는 구조적 전환임
-
LLM 코딩은 ‘코드를 좋아하는 사람’과 ‘무언가를 만드는 걸 좋아하는 사람’ 을 갈라놓음
나는 결과를 만드는 빌더(builder) 쪽이라 이 변화가 반가움- 나도 그 구분에 공감함
예전엔 문제를 데이터 구조와 명령으로 정의하고, 그게 실행될 때의 쾌감이 좋았음
그런데 지금은 “이걸 대신 해주는 존재에게 지시하는 일”이 되어버림
그게 즐겁다면 차라리 매니저가 되었을 것임 - 사실 이런 논쟁은 새롭지 않음
과거에도 컴파일 vs 인터프리트, 타입 vs 무타입, 빠른 배포 vs 유지보수성 같은 논쟁이 있었음
결국 성공한 소프트웨어는 모두 혼란스러운 초기 단계에서 안정적 확장 단계로의 전환을 거침
AI가 이 과정을 도와줄지, 오히려 복잡하게 만들지는 아직 확신이 없음 - 하지만 빌더라면 LLM을 신뢰할 수 있어야 함
인간 팀원은 책임과 신뢰가 있지만, AI는 책임이 없는 존재라 완전히 동일선상에 둘 수 없음 - 두 관점 모두 필요하다고 생각함
대규모 서비스에는 엄격함이 필요하지만, 내부 도구나 실험적 프로젝트에서는 AI가 프로세스를 75% 단축시켜줌
실제로 사내에서 이런 식으로 에디터들의 업무 효율을 크게 높였음 - 아마 중간 지점도 있을 것임
코딩보다 시스템 설계 자체를 즐기는 사람들처럼
- 나도 그 구분에 공감함
-
“10X 엔지니어” 개념이 AI 시대에 더 벌어질 수 있음
DevOps가 팀 단위의 10배 성과를 만든 것처럼, AI 활용 능력도 새로운 생산성 격차를 만들 것임
하지만 이를 위해선 문화적 변화와 교육이 필요함
DevOps가 그랬듯, 배우기 싫어하는 조직은 이 변화를 놓칠 것임 -
큰 코드베이스에서는 LLM이 쓸모없다고 느꼈음
ChatGPT로는 제대로 작동하지 않음-
Codex를 쓰고 있는지 묻고 싶음
나는 수천 개 파일이 있는 리포지토리에서도 꽤 효율적으로 작업함
다만 리팩터링 주기와 정적 분석·테스트·문서화가 필수임
모델별로도 차이가 커서, Opus는 일상용으로, Codex는 테스트 작성에 강함
Gemini는 빠른 프로토타입용으로 좋음 - 나는 3개월 동안 Bluesky용 앱 Skyscraper를 만들었는데, 코드의 98%가 Claude가 작성한 것임
App Store 링크 - 우리 팀은 대형 CRUD 대시보드에 LLM을 쓰고 있음
프런트엔드는 엉망이라 AI도 고생하지만, 백엔드(Typescript + Node)는 거의 원샷 구현 가능함
Cursor를 통해 Opus 4.5와 GPT-5.2-Codex를 병행 사용 중이며, 유료 모델이 확실히 품질이 좋음 - 나도 Swift를 처음 배웠을 때 AI 덕분에 한 달 만에 꽤 복잡한 앱을 완성했음
Salam Prayer 앱 링크
AI가 막히면 직접 Swift와 Xcode 프로파일러를 공부하며 성능을 개선했음 - “ChatGPT” 웹 인터페이스로 대형 코드베이스를 다루는 건 논점이 아님
Claude나 Codex CLI를 써야 제대로 된 맥락을 제공할 수 있음
-
Codex를 쓰고 있는지 묻고 싶음
-
최근 몇 달간 AI 성능이 오히려 퇴보한 느낌임
규칙을 잊고, 과도한 계획을 세우며, 불필요하게 복잡한 코드를 생성함
그래도 프런트엔드(HTML + Tailwind) 에서는 여전히 유용함- 프런트엔드를 그렇게 가볍게 보는 건 아쉬움
이미 접근성 문제로 가득한 영역이라 LLM이 그 문제를 더 확대할 위험이 있음 - 그 말투는 마치 FrontPage나 Dreamweaver 시절로 돌아간 것 같음
- 혹시 Opus 4.5 대신 Sonnet을 쓰는 건 아닌지 묻고 싶음
- 프런트엔드를 그렇게 가볍게 보는 건 아쉬움
-
끈기(grit) 가 지능보다 성공과 더 상관 있다는 연구가 많음
AI는 예산이 허락하는 한 무한한 끈기를 가짐
결국 인간의 생산성 병목이었던 지속력(stamina) 이 LLM으로 크게 확장된 셈임 -
AI가 끝없이 시도하는 모습은 인상적이지만, 잘못된 방향으로 파고드는 경우도 많음
특히 Sonnet은 타입 에러 하나 해결하려고 코드베이스 전체를 수정하기도 함
“지금 엉뚱한 길로 가는 거 아니야?”라고 물으면 바로 수정하지만, Opus가 훨씬 안정적임
그래도 최근엔 전반적으로 많이 개선됨 -
지금의 AI 코딩은 세세한 작업 지시와 주니어 개발자 코드 리뷰의 결합처럼 느껴짐
이런 일이 내 주된 업무가 되지 않기를 바람 -
Copilot + VS Code 조합에 만족 중임
Claude에게 변경 요청을 하고, diff 뷰에서 수락·거절하며 직접 수정도 가능함
Karpathy가 말한 “IDE는 여전히 필요하다”는 주장과 일맥상통함- 나도 Copilot Chat만으로 충분히 작업함
Claude 플러그인은 불편했고, Copilot의 변경 이력 되돌리기 기능이 훨씬 직관적임
내 사고방식과 잘 맞음 - Copilot이 직접 테스트를 실행하거나 코드 스니펫을 돌려보게 하면 훨씬 흥미로워짐
단순한 diff 제안보다 훨씬 강력한 방식임 - 나는 GitHub 이슈를 Copilot에 할당해 풀리퀘스트를 자동 생성하게 함
모든 맥락이 PR에 담겨 리뷰하기 편하고, 병렬 세션도 가능함 - 하지만 Copilot은 아직 cc나 Cursor 수준에는 미치지 못함
- 나도 Copilot Chat만으로 충분히 작업함