Staff Engineer의 Claude Code 여정 (First attempt will be 95% garbage)
Staff Engineer의 Claude Code 여정
한 줄 요약
Sanity의 Staff Engineer가 Claude Code를 6주간 사용한 경험. 첫 시도는 95% 쓰레기이며, 본문의 가치는 높지 않지만 HN 댓글의 통찰(주니어 교육 문제, 엔지니어링 관행의 중요성)과 자녀 미래 시사점이 유용함.
1. 원문 요약 (간략)
- 3번 시도 프레임워크: 첫 시도(95% 쓰레기, 컨텍스트 구축), 두 번째 시도(50% 쓰레기, 뉘앙스 이해), 세 번째 시도(사용 가능, 정제 시작점)
- 컨텍스트 관리: Claude.md 파일(아키텍처, 패턴, 주의사항), MCP 도구 통합(Linear, Notion, GitHub)으로 컨텍스트 없이 시도 1부터 시작하는 문제 해결
- 다중 AI 개발자 관리: 여러 Claude 인스턴스 병렬 실행, 같은 문제 공간 병렬화 금지, 인간 편집 코드 명시
- 3단계 리뷰: Claude 리뷰 → 나(아키텍처/비즈니스 로직) → 팀(품질 기준 동일)
- 비용/효과: 월 $1000-1500 비용, 2-3배 빠른 출시, 보일러플레이트 0. 하지만 "전투를 고르는 것"이 핵심
2. HN 댓글 분석 (핵심 가치)
주니어 개발자 vs LLM의 근본적 차이
- rafaelmn: 주니어가 LLM 쓰면 신뢰 깨짐. LLM이 올바른 솔루션 줬다고 해도 다음에도 그럴 보장 없음. 검색/문서/통합에 들인 노력이 기술이 됨 — LLM 쓰면 배우지 못함
- LtWorf: 주니어는 배우지만 LLM은 배우지 않고, 영원히 같은 것 반복 설명해야 함
- adastra22: 두 번 이상 설명한다면 잘못하고 있는 것. 컨텍스트(포함 학습된 교훈) 지능적 매칭으로 LLM '학습' 가능
엔지니어링 관행의 '객관적 평가자'
- BoiledCabbage: TDD, 모듈화, 단일 책임, 캡슐화 — 조직을 위해 좋다고 주장하던 것들이 LLM과도 작동함. LLM은 처음으로 엔지니어링 관행이 실제로 효과적인지 '객관적'으로 검증하는 도구가 됨
- shortstuffsushi: 이 관행들이 좋은 게 아니라, 추론 못하는 것에 대한 보호책일 뿐. LLM이 실제로 추론하고 기억하고 개선하기를 바램
코드 소유권의 해방
- "내 코드"에 대한 감정적 애착 사라짐 → 더 빠른 삭제, 더 객관적인 리뷰, 리팩토링에 제로 에고. 예상치 못한 부수적 이익
실용적 통찰
- 전투 고르기: "프롬프트에 너무 많은 노력 들이면 직접 쓰는 게 더 빠름" — 언제 AI 쓰고 언제 직접 쓰는 판단이 새로운 기술
- conception: todo.md 생성, 각 todo 20 LOC 이하. 변경 크면 phase(5-25개) 생성
- jaggederest: 프롬프트를 소스 코드처럼 대우. 파일에서 편집, @ 기호로 콘솔 가져오기
3. 자녀/미래 영향
AI 코딩 도구의 현실적 이해
- "AI가 코드를 써준다"는 마케팅과 실제 경험 간극 큼. 첫 시도 95% 쓰레기, 세 번째 시도에서야 사용 가능
- 자녀들이 AI 코딩 도구 사용할 때 기대치 현실적으로 설정하도록 교육
주니어 개발자 교육의 변화
- LLM 학습하지 않으므로, 주니어가 LLM 의존하면 학습 느려짐. Stack Overflow로 검색하고 통합하는 과정이 기술 됨
- 자녀들이 기초 단단히 쌓은 후 AI 도구 사용하도록 유도
코드 소유권 개념의 변화
- 미래 개발자는 "코드를 작성하는 사람"이 아니라 "문제를 정의하고 AI 출력 검증하는 사람"
- 코드보다 문제 정의, 아키텍처, 리뷰 능력에 더 집중
엔지니어링 관행의 중요성 강화
- TDD, 모듈화, 테스트 — LLM 시대에 오히려 더 중요해짐. LLM 잘 작동하려면 코드베이스 잘 구조화되어 있어야 함
- 자녀들이 좋은 엔지니어링 관행 배울 때 LLM도 더 잘 작동한다는 점 이해
실용적 조언
- AI 코딩 도구는 rubber duck의 turbocharged 버전. 생각 정리에는 탁월하지만, 훌륭한 엔지니어 아님
- "전투를 고르는 것"이 핵심 — 언제 AI 쓰고 언제 직접 쓰는 판단이 새로운 기술