Claude Code 6주 사용기
(blog.puzzmo.com)- Claude Code 도입 이후, 대규모 코드 작성과 유지보수의 방식이 크게 변화—“코딩계의 사진술 도입기”에 비유될 만큼, 빠른 구현과 자유로운 표현이 가능해짐
- 반복적이고 ‘기술 부채’로 여겨지던 작업들(마이그레이션, 프레임워크 교체 등)을 혼자서도 빠르게 병행 처리, 본 업무와 병행해도 부담 거의 없음
- “일단 써보고 나중에 판단”하는 실험적 개발 패턴, 테스트/추상화/실험 코드를 손쉽게 생성·삭제하며 개발 생산성·통찰력 획득
- 게임 프로토타이핑, 협업, 실험적 배포가 대폭 가속—게임 디자이너가 코드 없이 아이디어→실행까지 수 시간 만에 실현
- 모노레포, 명확한 기술 스택, 최신 코드베이스 등 Claude Code 친화적 환경에서, 실제 개발 업무의 속도·유연성 대폭 향상
서론: Claude Code 도입 후의 변화
- Claude Code를 지난 6주 동안 활용하며 코드 작성과 유지보수 방식에 중대한 변화를 느낌
- 직접 모든 코드를 작성하지 않아도 되는 "표현의 자유" 가 생긴것 같음
- Claude Code를 사용하면 한 번에 전체 구조를 구상하고 리뷰·편집 역량을 통해 결과물을 만들어낼 수 있음
- 마치 사진이 등장하면서 손으로 그림을 그리는 매력이 감소한 것처럼, 이제 프로그래밍의 입력 및 생산 과정이 크게 변하고 있음
- 변화가 불안하게 느껴질 수 있지만, LLM 기반 도구의 등장은 프로그래밍에 대한 패러다임 변화를 일으키고 있음
1. Claude Code가 바꾼 코드 작성과 유지보수 방식
- 과거에는 수주~수개월이 걸렸던 마이그레이션, 리팩토링, 기술 부채 해소 작업을 Claude Code 도입 이후 6주 만에 모두 병행·완료
- 예시: 수백 개 React Native 컴포넌트의 React 전환, RedwoodJS 시스템 교체, Jest→Vitest 마이그레이션, 서버 사이드 렌더링, 디자인 시스템 리팩토링, Node 22 업그레이드 등
- 기존에는 ‘별도로 일정 잡아서 처리’해야 했던 사이드 프로젝트/백로그를 본업과 병행하여 여유 시간에 처리 가능, 업무 부담 거의 없음
- 기존의 "기술 부채는 일정 확보→대규모 투입" 공식이 깨지고, 즉석에서 시작→진행→완료까지 ‘즉각성’ 이 구현됨
2. “일단 써보고 나중에 판단”하는 실험적 개발 문화
- 아이디어가 떠오르면 Claude Code로 먼저 시도해보고, 테스트 코드 등도 초기에 자동 생성・삭제를 반복하며 학습함
- 프론트엔드 테스트 전략이 없어도 Claude Code로 각 PR마다 다양한 방식의 테스트를 즉석 생성/삭제하며 경험치 축적, 전반적 방향 결정에 도움
- 아이디어/추상화에 대한 고민도 “직접 시도→실패해도 부담 없음” 방식으로 빠르게 검증 및 탐색 가능
- 실패 비용이 극적으로 낮아져, 실험-학습-결정의 사이클이 대폭 가속
3. 병렬 개발 및 협업 방식의 변화
- 두 개의 git clone/VSCode 프로필을 활용해, 각 clone별로 독립 작업(예: 하나는 PR 작성, 하나는 실험적 개발) 진행
- Claude Code가 작업 중인 동안 다른 clone에서 병렬로 작업하거나, 각 clone의 테마/포트를 달리해 명확하게 구분
- Pull Request를 병렬적으로 작성하고, 개발 서버 포트 충돌 방지 및 작업 효율화
4. 게임 프로토타입/실험 개발 프로세스 혁신
- 기존에는 수 주~수개월이 소요된 게임 프로토타입 제작→내부 배포→피드백→공개/폐기 과정을 Claude Code 도입 후 디자이너도 수 시간 내 직접 코드 작성→사이트에 배포 가능
- 아이디어→실행→팀 피드백→실험 종료/프로덕션 전환(재작성) 등 배포 주기가 극적으로 짧아짐
- 다만, 임시 게임의 관리·정식화/폐기 기준 등 새로운 운영상 고민도 동반
5. 일상적 코딩/협업에서의 Claude Code 활용
- 주간 triage 시, Claude Code GitHub 액션을 활용해 즉석에서 PR 생성/실험, 작은 이슈는 바로 적용
-
제품+기술 양면 역량과 주도성을 지닌 팀원이 가장 효과적으로 Claude Code를 활용, ‘풀 브레드 개발자’
- "Full-breadth developers" : 한 명의 개발자가 전체 작업 흐름을 자유롭게 리드할 수 있도록 도와줌
- 코드 리뷰, 맥락 제공, 수정·결정 역할을 인간이 유지할 때, 팀 전체의 생산성과 창의력 상승
6. Claude Code 친화적인 코드베이스 환경
- 모노레포: 전체 코드/DB 스키마/API/화면 로직이 한 곳에 있어, Claude Code가 맥락 파악·자동화 작업에 최적
- 표준화된 기술 스택(React, Relay, GraphQL, TypeScript, StyleX, Bootstrap 등) 을 채택, LLM이 쉽게 이해/자동화
- 코드베이스 최신화·레거시 최소화 등으로 LLM 활용 효율성 극대화
7. Claude Code의 한계와 실제 체감 변화
- PR/커밋 수 등 정량적 변화는 크지 않지만, 업무 체감 속도·유연성·생산성은 크게 향상
- Claude Code는 ‘경험 많은 주니어+급’ 페어 프로그래머 역할—엔지니어가 코드 품질·논리·컨텍스트를 관리하면 최고의 파트너
- 반복적 작업/기술 부채 해소·신속한 사이드 프로젝트 추진 등 질적으로 다른 업무 경험 제공
8. 주니어/학습자에게 권장하는 ‘평행 구현’ 전략
- LLM 생태계의 최신 트렌드에 지나치게 집착할 필요 없음
- 초보 개발자에게는 스스로 코드를 작성한 후 동일 과제를 Claude Code에 요청하여 비교/분석 학습하는 것을 추천
- Claude Code의 해법을 참고해 다양한 추상화와 실무 패턴을 빠르게 습득 가능
- LLM을 '경쟁자+멘토'로 활용하며 실무 역량과 최신 생태계 감각을 동시에 성장
- Claude Code는 모바일 폰과 같아서, 항상 켜둘 필요 없음
- 궁극적으로 주도권을 갖고 효율적으로 사용하는 것이 중요함
9. 사이드 프로젝트·단기 실험의 폭발적 증가
- 기존에는 시간·에너지 제약으로 시도하기 어려웠던 작은 실험/도구 개발/블로그 개선 등을 Claude Code로 몇 시간 내 실현
- 아이디어→즉시 구현→실패해도 부담 없음—프로덕션과 별개로 창의적 실험/개인 프로젝트 병행 용이
10. 실제 Claude Code 대화·코드 리뷰 사례
- DB 정리 스크립트, 퍼즐 REPL, 크로스워드 PDF 레이아웃 등 구체적인 요구-코드 생성-실행-수정-리뷰 과정들 실제 예시
- LLM의 오류(추론, 과장, 하드코딩 등) 발생 가능—엔지니어가 논리적 검증/품질 책임을 반드시 수행해야 실질적 가치 확보
11. Claude Code의 엔지니어링 위치와 결론
- Claude Code는 레퍼런스 코드, 스크린샷, 추가 설명 등 넓은 맥락을 받아들이는 능력이 뛰어남
- Claude Code는 'Post-Junior(숙련 주니어 이상)' 수준의 보조 프로그래머—무한한 patience와 속도로 실무 파트너 역할로 매우 효율적
- 설계/품질/최종 컨트롤은 인간 엔지니어가 담당, Claude Code는 구현·실험·자동화의 범위와 속도를 대폭 확장
- “직접 한 줄씩 코딩해야 한다”는 제약에서 벗어나, 설계·품질 관리·혁신에 더 집중할 수 있는 개발 환경 실현
저도 클로드 코드 아주 만족하며 사용하고 있습니다.
이제 저도 6주 쯤 쓴 것 같네요.
대부분의 내용이 공감이 갑니다.
저의 마음이 바로 원글작성자의 마음과 같습니다 ㅎㅎ
$200 결제하고 한시간만에 4년짜리 난제를 해결했습니다.
아마 저 혼자로는,,, 커서로는 절대 해결이 안되더라구요
혹시 claude code 와 커서 + Claude LLM 을 사용했을 때 차이를 알 수 있을까요?
저는 커서를 쓰고 있는데 claude code 로 넘어갈까 고민입니다.
Claude LLM 이라하면 API키를 말씀하시는 것일까요?
아니면 채팅창 밑에 있는 Agent 모델들을 말씀하시겠죠?
커서도 충분히 만족하고 썼지만, 사용량 제한이 자주걸려 $60 짜리 쓰면서도 리밋 걸릴까봐 노심초사했구요
그럴까봐 gemini cli 번갈아쓰며 스트레스가 많았어요.
커서 + Claude 4 sonnet 도 충분히 좋은데 하루 지나면 리밋걸리고 리밋걸리면 한달동안 못쓰는게 제일 문제였어요
커서 + Claude 4 opus는 써볼 엄두도 못냈구요
클로드 코드가 결국 cli 기반이고, IDE 특성 안타서 써보기로 결심했구요
처음엔 $20 달러 쓰다가, 그런데 얘도 opus가 없어요
그래서 리밋 걸리려고하니 한달만 써보자는 심정으로 $200 결제하고 써보니
신세계가 열립니다. opus .. 체급이 다르구나...
지금 200쓴지 4일차인데, 묵혀둔 난제들 다 해결하고 있어요 ㅎㅎ
글이 수정이 안되네요
커서 + Claude 4 sonnet 도 충분히 좋은데 하루 지나면 리밋걸리고 리밋걸리면 한달동안 못쓰는게 제일 문제였어요
한달이 아니고 하루인가 그랬던거 같아요. 한달 내내 노심초사였습니다.
그리고 커서랑 많이 싸웠는데
클로드 코드랑은 많이 안 싸웁니다.
Hacker News 의견
-
약 2주간 Claude Code를 사용해본 결과, 평소 AI 코딩에 회의적인 입장이었지만 정말 놀라웠음 경험을 쌓으려면 약간의 학습곡선을 타야 하고, 적절한 맥락 제공 및 작업 분할이 필수임 물론 프로그래밍 실력이 필요하고, 모르는걸 AI에게 몽땅 던지면 반드시 문제가 생김 25년 이상의 경력이 있기 때문에 Claude Code가 무슨 결과를 내든 리뷰하고 잘못될 땐 바로 잡아줄 수 있는 자신감이 있음 10~15년 전쯤에는 코드를 직접 쓰지 않아도 되는 신경 인터페이스 같은 것을 꿈꿨는데 Claude Code가 어느 정도 그걸 실현한 느낌임 가끔씩 일일 사용 한도에 걸려 Gemini CLI 2.5 pro 모델을 대체로 써봤는데, Claude Code와 비교 자체가 안됨 Gemini는 너무 답답해서 쓸 수가 없음 옛날에는 한 달에 100달러 넘는 개발 툴을 쓸 일은 상상도 못했는데, Max 플랜으로 업그레이드를 심각하게 고민 중임
-
시니어 개발자가 주니어 개발자에게 조언을 주고 가이드해줄 수 있는 상황이라면 이 툴이 잘 맞는다는 생각임 주변의 시니어 개발자들 이야기를 들어보면, 주니어들은 오히려 더 이상한 코드, 느린 코드, 보안에 취약하거나 아예 엉망인 코드를 LLM으로 만들고 코드를 이해하지 못한 채 PR에 올린다는 불만이 많음 나에게 가장 유용한 것은 보일러플레이트 생성(설명만 주면 클래스 설계도 뽑기), JSON을 클래스나 다른 포맷으로 변환, 그리고 “이 코드 뭐가 문제야? Staff 급 엔지니어라면 어떻게 바꿀까?” 같은 질문임 실제로 내가 직접 타이핑한 코드에 Claude Code로 버그를 미리 찾기도 함
-
흥미로운 점은 “vibe coding”에 회의적인 사람들이 실제로 툴을 써보기 전까진 기대치가 엄청 낮다는 것임 많은 이들이 LLM이 내놓는 코드는 쓰레기일 거라 생각하고 극단적 예시만을 평균이라 치부함 그런데 직접 써보고 나면, 예상 이상으로 좋다는 사실에 스스로 놀라게 됨 물론 Claude Code로 팀 10명 만에 10억불 가치 SaaS를 뚝딱 만드는 건 불가능하지만, 그래도 툴의 실제 힘을 과소평가하는 사람들이 많음
-
사실 엄밀히 말하면 당신은 vibe coding을 하고 있는 게 아님 AI를 활용한 소프트웨어 엔지니어링에 가까움 vibe coding은 AI가 무슨 코드를 내놔도 곧이곧대로 쓰며 이해도 없이 계속 나아가는 것을 의미함 용어의 정의가 사람마다 다르니, vibe coding 자체는 너무 신뢰하지 않는 게 좋겠음
-
나도 불과 몇 달 전까지만 해도 어떤 구독 서비스도 20달러 이상 내지 않았는데 지금은 Max 20 플랜 200달러를 매달 내는 중임 미국에 거주하는 슬로바키아 출신이고 20년 경력의 개발자라서인지 나 역시 놀라고 있음 다른 툴들도 써봤지만 항상 이 정도 수준에 직접적인 생산성과 효율을 체감하긴 힘들었음 Claude Code는 정말 차원이 다름 물론 계속 세세하게 챙겨줘야 하지만 내 방식은 Plan Mode로 철저히 요구 사항, 코드 변경 계획을 세우고 거기에 100% 납득하면 실행시킨 뒤 그 결과를 코드 리뷰하는 흐름임 (컴파일러 에러, 유닛 테스트, 린트 문제는 AI가 알아서 수정함) 약간 엉뚱하지만 지식 많은, 엄청 빠른 주니어 엔지니어가 있다는 느낌임 소프트웨어 개발 방향이 분명히 이쪽으로 가고 있고 미래임
-
최근 Claude 모델이 SQL 작성/수정에 있어선 신뢰도가 떨어진다는 생각을 함 예를 들어 조건절은 잘 만들지만 AND/OR를 괄호로 묶지 않아서 Gemini pro가 이걸 올바르게 버그로 체크해줌
-
-
Claude Code가 모든 경쟁 툴보다 확실히 앞서 있다는 것에 깊이 동의함 2023년부터 AI 코드 생성용 cli 툴을 직접 만들어왔고, 주요 옵션들은 거의 모두 시도해봤다고 할 수 있음 작성자의 여러 방법들에 깊이 공감하게 됨:
- 모노레포가 시간을 많이 아껴줌
- 명확한 스펙으로 시작하기, 그리고 그 스펙엔 충분한 시간 투자하기 좋은 아웃라인만 있으면 AI가 대부분의 스펙을 써줄 수 있음
- 시작부터 테스트를 반드시 마련해야 함 이게 가장 중요함 좋은 테스트와 스펙이 있어야 AI가 더 나은 솔루션을 재귀적으로 탐색할 수 있음 TDD가 다시 돌아온 느낌임
- 타입과 린터는 엄청나게 큰 도움이 됨
- 외부 문서는 프로젝트 내 별도 디렉토리에 정리해서 두면 좋음 (예: docs/external-deps)
- 모든 툴과 마찬가지로 자신한테 맞는 테크닉을 익히는 데 약간 시간이 필요함 예전보다는 쉬워졌지만 여전히 배워야 할 게 있음 각자 워크플로우는 살짝씩 달라서 오히려 코딩 과정과 비슷한 느낌임 최근 Permiso(https://github.com/codespin-ai/permiso)라는 초간단 GraphQL RBAC 서버도 vibe coding으로 만들었음 아직 안정적으로 테스팅/리뷰된 프로젝트는 아니지만 간단한 게 필요한 분들에게 이미 쓸모 있을 수 있음
-
두 번째 항목(좋은 스펙으로 시작하기)에서, 구체적으로 스펙을 어떻게 정리하는지 궁금함 마크다운 문서로 따로 빼는지, 어느 정도까지 디테일이 필요한지 등 궁금함 또한 “시작부터 테스트를 챙기라”는 조언에는 공감하지만 실제로 Claude가 테스트 후킹이 있을 땐 오히려 테스트 코드를 먼저 만드는 과정이 생략되고 그냥 버그/가정 검증 없이 수정만 반복하는 경우도 있음 테스트 관련 동작을 켜고 끄는 플래그를 만들어 쓰기도 함
-
모노레포가 당신 시간을 아껴주기는 하지만, Claude의 도구 호출과 토큰 소모는 훨씬 늘어남 Aider처럼 필요한 파일만 골라서 AI에 전달하는 쪽이 더 좋다고 생각함 Claude가 왜 이렇게 인기가 많은지 이해가 잘 안 됨 Aider는 거의 모든 면에서 더 나은 툴이고, 다양한 LLM도 연동해서 쓸 수 있음
-
CC를 제대로 쓰려면 프로젝트 구조가 잘 갖춰져 있어야 함 Django 프로젝트에 테스트, 타입, 문서 잘 갖춘 상태에서 CC가 거의 모든 걸 잘 해줬지만 중간 중간 가이드가 필요했음 최근에는 CC를 오프라인에서 로컬 모델로 돌리는 사이드 프로젝트도 하는 중임 첫 버전은 ChatGPT 도움으로 잘 만들었고, CC로 넘어오니 CC가 오히려 핵심 이슈에서 빙빙 돌며 실수를 우회하고 기존 코드 리팩토링, 버그 수정 대신 자꾸 새로운 파일/스크립트를 생성하는 버릇을 보여줌
-
외부 문서를 프로젝트 내에 직접 포매팅하는지 궁금함 대부분의 프로젝트는 웹사이트에만 문서가 있는데 따로 깔끔한 마크다운 파일로 만드느라 시간 들이는지 묻고 싶음
-
Claude Code의 진정한 파워는 단순히 코딩을 넘어서 컴퓨터 전체를 통제할 수 있다는 점임 CLI 툴이 있다면 Claude가 이를 사용할 수 있고, 없다면 그래도 Claude에게 물어보면 깜짝 놀랄 때가 많음 예를 들어 이미지 크롭/리사이즈, 유튜브 영상에서 mp3 추출, 오디오 파일 무음 부분 제거 등 잡다한 작업을 다 맡겼음 덕분에 엄청난 시간을 절약하고 있음 이전에 어땠는지 기억조차 안 남 다시는 예전 방식으로 못 돌아갈 것 같음
-
Claude에게는 자신의 실제 컴퓨터를 연결하기보다는 (항상 본인 컴퓨터가 아닌) 별도의 컴퓨터를 부여하는 게 좋음 나의 경우는 클라우드 VM 상에 IDE가 동작하고, 거기에 Claude를 연결해 브라우저로 접속함(https://brilliant.mplode.dev) 내 생각에 이 방식이 에이전트 운영에 가장 가까운 최적의 UX라고 생각함 터미널, ssh 준비 없이 로그인만 하면 되고 인스턴스는 자동 생성/일시정지됨 결과적으로 Claude + 개인 Linux 인스턴스 + IDE를 그냥 링크로 바로 띄우는 셈임 앞으로는 인스턴스를 원하는 대로 여러 개 띄우고 권한/파일시스템/컨테이너 권한(JWT 등)도 세밀히 제어할 예정임 만약 장애나 검토가 필요한 상황이 생기면 IDE로 바로 진입해 해결하면 됨 UI도 별도로 필요 없고, IDE 내 여러 패널로 보거나 직접 컨테이너에서 웹앱 띄워 사용할 수 있음 지금처럼 기술의 발전에 흥분된 적이 없음
-
모든 게 좋아 보여도 실제 코드 산출물만 따지면 데이터가 전/후로 거의 차이가 없음 Claude로 작업해도 커밋, PR, 코드라인이 예전과 큰 차이가 나지 않음 즉 AI 코딩은 “생산성이 커졌다”는 느낌과 "내가 손 안 대고 뭔가를 만들어서 기분이 좋다"는 마음이 들지만 실제로는 대량 리뷰, 수정, 재프롬프트가 필요하고 결국 산출물 총량은 비슷함 그리고 어려운 부분을 AI에 넘기면서 스스로 설계력/사고력이 점점 약화됨 한 달간 Claude 등 LLM만 쓰다가 내 힘으로 작은 앱을 만들어보면, 코드뿐만 아니라 전체 구조 설계 자체도 어렵게 느껴짐 장기적인 결과로는 코드베이스가 천천히 망가지고 결국은 마이너스가 될 위험도 큼(최소한 지금 세대 LLM에서는)
-
예전엔 이미지마지크(mogrify) 명령어를 옛 방식으로 하나하나 직접 만들었었음 AI 도구의 지원을 받으면서 미친 듯이 시간이 절약됨
-
리눅스 PC가 자꾸 크래시가 나는 원인을 Claude에게 진단 요청, journalctl로 로그를 긁어 원인까지 밝혀내줘서 큰 도움을 받았음 문제 해결에도 직접적으로 도움을 준 경험임
-
또 다른 사례로, 정적 사이트 생성이 매우 쉬워짐 어떤 문법으로든 글을 써도 Claude Code에게 이 포스트를 블로그용 포맷으로 만들어달라고 하면 알아서 해줌 예를 들어 “이미지 image.jpeg 넣어줘”라고만 써도 바로 조치해줌 마크다운이나 Hugo 포맷에 구애받지 않아도 돼서 편리함
-
-
Claude code를 하루에 12~16시간씩 사용한 경험자로서, 다음과 같은 팁들을 발견함:
- 실행하자마자 sonnet 모델로 교체하기(opus와는 퀄리티 차이가 큼)
- compacting(대화 로그 압축)은 진행 중에 품질이 크게 떨어지니, 최적 시점을 잡아야 함
- 첫 프롬프트가 대단히 중요하고 세션의 성격이 여기서 정해짐 만약 Claude 인스턴스가 주저하거나 불친절해지면 그냥 세션을 끝내고 새로 여는 게 나음
- “이거 별로인 의견일 수 있지만 ~을 구현하고 싶어요”처럼 공손하게 부탁하면 훨씬 적극적으로 도와주는 경향이 있음
- 도커 오케스트레이션을 Claude에게 맡기니 생산성이 10배는 뛴 느낌임 컨테이너 새로 띄우기, 오류 로그 확인, 삭제/재빌드 등 전체 플로우를 Claude에게 맡겨 한 번의 프롬프트로 서비스 전체를 띄울 수 있게 됨
-
5번은 도커 외에도 playwright MCP 서버와 연동하면 UI 및 요청도 바로바로 확인하게 만들 수 있음 6. 계획 모드(plan mode)로 시작해서 계획이 마음에 들 때까지 반복 수정 7. 슬래시 커맨드(/커맨드) 기능을 적극적으로 활용해 미니 프롬프트로 지속적인 개선과 컨텍스트 제공, gh 등 외부 툴 활용 지시까지 포함 compacting은 반드시 0%에서 갑자기 하지 말고, 적절한 중간에 적용하는 것이 좋음 1번(sonnet 추천)은 동의하지 않을 수도 있음
-
도커를 피하려는 성향이 있지만, 5번 팁(Claude로 도커 오케스트레이션하기)이 매우 궁금함 어떤 프롬프트 포맷을 사용하는지 알고 싶음
-
아주 상세한 plan.md 파일(시스템 간 연결, 전체 구성 등)부터 만들어서 claude-loop(https://github.com/DeprecatedLuke/claude-loop) 같은 툴로 밤새 돌려놓고, 아침에 수동 패치하는 방식도 성공적으로 써봤음
-
Claude Code를 하루 16시간씩 어떻게 쓰는지 궁금함
-
가끔 Claude가 컨테이너 내부를 너무 들쑤실 때가 있음 단지 코드 이해만 시키고 싶었는데 컨테이너 안에서 수많은 방식으로 코드를 실행시키려 해서 오히려 이상해진 적도 있음 예전에 파일을 cli 명령어로 파이프해서 아무 동작도 안 하는 행동도 했었지만, 뭔가 집착적으로 실행하려는 경향이 있다는 예시임
-
Claude Code가 실제로 얼마나 좋은지는 모르겠지만(직접 써보지는 않았지만), 개인적으로 고민이 되는 점이 있음 굉장히 느리고 어지러운 gdscript(파이썬류)를 C#으로 리팩토링하고자 함보다 깨끗하고 빠르게 하고 싶은 개인 프로젝트임 이 작업은 나에게 새로운 도전이고, 교육적인 부분도 많음 Claude를 쓰면 배울 수 있는 소중한 기회를 스스로 뺏는 것 같은 기분이고(장기적으로 자기 성장에 도움도 될 것 같음), 안 쓰면 귀한 시간 낭비에 불과한 지루한 일에 투자하는 감정(실제론 앞으로 자동화될 작업인데도)이 들어서 딜레마가 반복됨
-
35년간 개발 경력에서 어떤 LLM이든 내가 직접 풀 수 있지만 하기 싫을 때(지루, 반복적)만 AI에게 맡기는 방식을 쓰고 있음 예를 들어 Open API 3.0 스키마 수정도 내가 직접 하면 아무런 배움이 없으니 Claude에 맡겼고, 예시 코드를 생성하는 것도 AI에게 시킴 정말 새롭게 배우는 포인트가 있을 땐 Anki SRS 같은 앱에 플래시카드로 정리하거나 TIL 블로그에 적어둠 또는 스스로 예제들을 여러 번 직접 구현해서 경험치로 만듦 핵심은 새 배움을 뇌에 최소 두 번 이상 연결시켜야 효과적인 학습이 된다는 것임 새로운 자연어 단어를 익힐 때 3개 문장에 통합해서 써보는 식임
-
생성된 코드를 직접 리뷰하지 않으면(즉, C#을 충분히 익히지 않으면) 코드베이스가 순식간에 망가짐 LLM 코딩은 오류가 누적되는 경향이 있으니 반드시 개선이 필요함, 그렇지 않으면 유지보수 불가능한 쓰레기덩어리가 됨 주변 친구들은 AI가 충분한 테스트 코드를 생성하게 해서 문제를 초기에 발견한다고 하는데, 나는 아직 그 방법까지 써보진 못함 내 코드가 워낙 알고리즘보단 로직 위주라 테스트 작성도 애매함
-
16년간 전문 개발자로 일하며, Claude Code가 벽에 부딪혀 머리를 싸매던 것들도 한결 쉽게 해결하도록 도와줬다고 느낌 새로운 걸 빨리 익힐 때는 AI 도구(특히 묻고 답하는 "ask" 모드)가 효과적임, 비유/케이스/암기법을 적극 활용함 만약 목표가 느린 성장을 통한 깊은 학습이면, 느리더라도 직접 고전적인 방법이 더 나음 하지만 빠르게 배우는 게 목표라면 AI를 활용하는 쪽도 나쁘지 않음 결과만 내고 싶다면 스펙을 잘 쓰고, 테스트도 충분히 챙기는 게 중요함 결국 어느 방식이든, 뭔가를 계속 만들어내는 게 의미를 가져온다고 생각함
-
“너만의 x 라이브러리를 만들어보라”는 블로그 트렌드가 예전에 있었음 직접 뭔가를 구현하는 과정에서 가장 많이 배울 수 있음 예를 들어 클라이언트 사이드 라우터가 궁금하면 직접 라우터를 만들어보는 것처럼 LLM 시대엔 뭐든 라이브러리 코드로 대체될 수 있지만, 내가 진짜 C#을 배우고 싶다면 직접 포팅하는 게 좋음 단순히 결과물만 필요하고, 다른 부분에 집중하고 싶다면 Claude에게 맡겨도 됨 배움에는 반드시 고통의 구간이 동반되고, 너무 쉬우면 실은 아무것도 배우지 못하는 것임
-
AI 이전에는 복붙이 대세였음 Stackoverflow에서 코드를 이유도 모르고 뺏긴 친구들은 결국 아무것도 배우지 못했음 조언이나 개념 설명을 AI에게 요청하는 것은 문제 없다고 생각함 근데 모든 걸 대신 써달라고 하면 분명 배움이 없음 다만, 개발자로서 내 시간을 지키는 것도 현명함 배워야 할 게 무수히 많으니, 만약 목표가 게임 개발이라면 GDscript 포팅 작업이 필수적 경험은 아닐 수도 있음 물론 분명 배우는 부분도 있음
-
-
약 3주간 Claude Code로 코딩한 경험으로, 10년 차로 Python ML/데이터엔지니어링 위주로 일함 여러 이유가 있음:
- 시작의 고통을 제거해서 첫 줄을 쓰는 장벽이 없음
- 실행되는 동안 머리를 온전히 사고에 쓸 수 있음
- 동시에 여러 작업을 병렬로 진행 가능
- '더 챙길 걸'이 떠오르면 바로 새로운 Claude 세션에서 곧바로 시도(더는 TODO 안 남김)
- 분석/시각화, 플로팅 등도 쉽게 script를 자동으로 돌려볼 수 있음
- 단순한 린트/타입/테스트 이슈는 자동으로 알아서 고쳐줌 전체적으로 코드의 본질–무엇을 해야 하는가, 산출이 맞는가, 어떻게 더 나아질 수 있는가–에만 집중할 수 있음
-
시작의 고통을 없애주는 게 정말 큼 예전엔 “시간만 있으면 하고 싶다”던 것들도 지금은 프롬프트 몇 개면 실행 가능함 실제로 NYT Connections 게임을 터미널에 만들고 싶었는데 3개 프롬프트 만에 완성함(https://github.com/jleclanche/connections-tui)
-
4번이 특히 인상적임 예전엔 테스트나 기술부채를 남기는 게 당연했지만, 이젠 테스트 스위트도 “필요하다” 한 마디면 꽤 괜찮은 게 자동 생성됨꼭 완벽하진 않아도 중간 난이도의 일감들은 확실히 챙길 수 있게 된 셈임
-
에이전트 기반 코딩에 계속 도전하는 호기심 많은 소수로서, 왜 내 경험이 주류와 다른지 그 원인을 고민해옴 아래 설명이 핵심일 것 같음:
"Claude Code로 우리는 '사진이 등장한 시점의 프로그래밍'에 있는 것이다. 손으로 그림을 그리던 무드가 사라지는 건 단지 아이디어 하나를 바로 현실화시킬 수 있고, 나의 코드리뷰와 편집 능력으로 원하는 형태에 맞춰 조각해갈 수 있기 때문이다" 이 비유가 적절하긴 한데도, 여전히 사람들은 페인팅을 하고, 누군가는 돈을 내서 그림을 사고, 누군가는 예술로 코딩 자체를 즐김 나는 직접 코딩하는 게 취미고, 코드리뷰는 싫어하지만 어쩔 수 없이 함 주어진 선택지라면 직접 만드는 쪽을 택하게 됨(그래서 IC로 남아있음) 사람들은 AI 코딩 에이전트를 엄청 주니어 개발자 인턴 같다고 하지만, 나는 오히려 두렵게 느껴짐
-
아직도 사람들이 그림을 그리고 그림에 돈을 내는 환경이 존속하는가를 묻고 싶음 대부분 조립식, 대량생산 공정에 밀려난 수공업도 이제는 상품 자체보다는 생산자와 소비자가 상상력을 통해 상호 경험하는 게 더 중요한 가치인 것 같음 그냥 아마존에서 물건 시키는 게 아니라, 장인과의 관계, 창작 과정이 서사로 소비됨 코딩도 앞으로 생존하려면 이런 방식이 필요해질 것 같음
-
나도 이 입장이 너무 잘 이해됨 작은 작업, 버그 픽스, 초안 용도로 에이전트 코딩의 효용을 인정함 다만, 소수 모델만 감싸는 다양한 인터페이스를 두고 지지/반대 논쟁이 심해지는 게 이해가 안 됨 또, junior dev를 위한 impact는 아직 고민임 만약 AI가 코드리뷰까지 자동화해주면 내 삶은 더욱 행복해질 듯함
-
그 비유가 완전히 유효하다고 생각하진 않음 역사적으로 페인팅은 현실 세계 재현의 유일 수단이었으나, 예술은 단순 모사가 아니라 창작자의 해석임 이게 사람들이 여전히 그림을 그리는 이유임 코딩 자체를 예술로 생각한다면 계속 할 수 있음 다만 많은 이들은 제품 개발이 목표고, 제품 자체가 예술이긴 함 AI로 그 목표까지 더 빨리 도달할 수 있다면 당연히 AI 선택이 낫지 않을까 한편으론 "코드몽키" 시절(순수 코딩만 하는)도 그립긴 함 이제는 모두가 리드 개발자처럼 디렉션, 코드리뷰, 기술 결정만 하게 되는 상황이 올 것 같음 현업 코딩에서 손을 덜 대야 한다는 변화가 조금은 아쉬움
-
더 적합한 비유는 손도구(hand-tool)에서 파워툴로 넘어가는 전환에 가까움 페인트-포토그래피 비유는 새로운 매체가 등장한 것과 달라서 과도하게 확장하는 것 같음 에이전트 코딩은 그 정도로 혁신적인 건 아님
-
-
Claude Code를 많이 써보려 했지만 너무 느리고, 항상 뭔가 어긋나서 답답함 대부분의 작업에서 멘탈 에너지를 절약한다는 느낌이 없음 몇몇 작업에서는 도움이 됐지만 번번이 뒤통수 맞는 일도 많아서 자주 쓰고 싶지 않음 예를 들어 nushell로 .zshrc를 변환해달라고 했는데 30분을 씨름해도 실행되지 않았고, 직접 공식 문서를 보는 게 10분도 걸리지 않았음 이런 실망스러운 경험 때문에 Claude를 다시 쓰고 싶지 않은 마음이 큼
-
이 경험이 나랑도 비슷함 테스트 코드 작성 등에 도움을 받으려 했지만 번번이 내가 다 새로 쓰게 됨 디버깅은 한 번도 성과를 못 봤음 아주 단순한 스크립트 변환(커맨드 출력 파싱 등)이나 새 프로젝트 스캐폴딩 정도만 쓸만함(하지만 이런 일을 얼마나 자주 하는가) 간단한 코드 포팅용으로는 괜찮았지만 실패 경험이 훨씬 더 많았음
-
context7 MCP 같은 걸 써봤는지 묻고 싶음 인기가 덜한 언어나 생소한 도메인에서는 LLM들이 약한 경향이 있음 context7처럼 최신 소스에서 레퍼런스를 직접 불러오는 방식이 더 낫게 느껴짐
-
-
RSI와 손목터널증후군 때문에 코딩을 덜 하게 됐었지만, Claude 덕분에 (고통이 10분의 1로 줄어들어) 다시 프로그래밍을 할 수 있게 됨 차라리 거부하려 했던 기술이지만, 경력을 이어가려면 이제 반드시 필요함
-
비슷한 이들의 이야기를 많이 들어봄 RSI를 가진 사람들에게 Claude 같은 도구는 진정한 게임 체인저임 가장 힘들고 지루한 보일러플레이트 등 반복 업무를 훨씬 수월하게 해주기 때문임 예전엔 반복 코드만 보면 손목과 멘탈이 모두 아팠는데, 이젠 신경 쓸 일도 없고 오히려 추상적/새로운 문제에 집중할 수 있어 프로그래밍 자체가 더 즐거워짐 “이런 도구 때문에 경력이 끝날 수도 있다”는 우려도 있지만 오히려 반대로 내 커리어를 살려줄 거라 믿음
-
Claude를 쓰기 시작한 후로 RSI 통증이 거의 사라졌음 특히 아주 정확한 명령과 문장으로 반복 작업을 대체할 수 있음, 음성 인식 사용 사례도 많이 들었고, 이로 인해 접근성의 문이 열리는 것 같음
-
음성으로 Claude Code를 바로 활용할 수 있다면 더욱 도움이 되지 않을까 생각함 MacOS에서는 무료 TTS/ASR 옵션이 있고, BYOK로 다른 음성엔진도 붙일 수 있음(https://github.com/robdmac/talkito)
-
충분히 정확하고 편리한 STT/음성인식 앱을 쓰면 Claude Code에 자세한 맥락을 전달하는 것도 효과적임 다양한 음성 인식 앱을 써 본 결과 키보드 단축키 기반 핸즈프리 모드와 정확성/속도를 모두 갖춘 Wispr Flow가 가장 잘 맞았음 단지, 로컬 앱도 지원되길 바라는 마음이 있음
-
혹시 텍스트 입력 자체를 음성으로 하고 있는지 궁금함
-
-
유지보수 관점에서 저자 생각에 매우 동의함 예전엔 리팩토링/리마인드용 TODO나 티켓만 만들던 작업도, Claude 덕분에 바로바로 구현해버림 덕분에 반복적인 수고가 매우 줄어듦 리팩토링 아이디어도 빠르게 시험해보고, 맘에 안 들면 폐기하는 게 쉬워짐 이런 류의 작업에 대한 활성화 에너지가 현저히 낮아졌음 AI 에이전트를 병렬/오프라인으로 무차별 돌리다간 오히려 번아웃과 코드 품질 저하로 이어질 수 있으니 반드시 휴먼 슈퍼비전 모드로 유지해야 함에 동의함 추가로 정리한 글은 https://www.modulecollective.com/posts/agent-assisted-coding... 에 있음