AI를 활용한 프로그래밍 역량을 높이는 방법

• AI 코딩 도구를 써서 사람이 1~2시간 걸리던 변환 작업을 15~20분 리뷰 수준으로 줄이고 싶음
• 하지만, 현재는 AI가 만들어주는 코드 품질이 직접 짠 코드의 90%에도 못 미쳐서 실질적인 도움이 되지 않는것 같음
• 그래서 AI를 어떻게 써야 생산성과 코드 품질을 동시에 끌어올릴 수 있는지 방법이 궁금함

AI로 프로그래밍 효율과 품질을 높이기 위한 실전 팁 모음

1. 반복 가능한 작업에만 AI를 집중 투입하기

• AI는 비슷한 형태의 작업을 여러 번 반복할 때 가장 큰 효과를 냄
• 한 번은 사람이 직접 최고 품질로 구현하고, 이를 기준 예제로 사용
• 이후 동일 패턴 작업을 AI에 맡겨 대량 처리
• 사고와 판단이 필요한 작업에는 기대 효율이 급격히 낮아짐

2. 코딩 전에 반드시 계획부터 만들기

• 바로 코드를 생성하지 말고 해결 계획을 먼저 작성
• 계획 단계에서 모호한 부분과 질문을 모두 드러내게 함
• 계획이 만족스럽지 않으면 실행 단계로 넘어가지 않음
• 결과 품질은 프롬프트보다 계획 문서의 명확도에 좌우됨

3. 작업 단위를 극도로 작게 쪼개기

• 파일 하나, 컴포넌트 하나, 함수 몇 개 단위로 요청
• “전체 리팩터링”, “idiomatic하게 개선” 같은 요청은 실패 확률이 높음
• 구조 설계는 사람이 하고, 반복 구현만 AI에 맡김

4. 컨텍스트는 쌓지 말고 자주 초기화하기

• 대화가 길어질수록 규칙 준수와 품질이 급격히 떨어짐
• 한 세션은 하나의 작업만 처리
• 방향이 바뀌면 새 세션에서 다시 시작
• 장기 작업은 문서(plan.md 등)로 상태를 보존하고 재주입

5. 규칙 문서는 짧고 기계적으로 만들기

• CLAUDE.md / AGENTS.md는 500~1000 토큰 내로 유지
• 선언적 지침보다 구체적이고 검증 가능한 규칙 위주로 작성
• 자주 틀리는 것만 최소한으로 기록
• 나머지는 코드와 자동 검사로 강제

6. 테스트·린터·빌드를 피드백 루프로 사용하기

• “잘 만들어줘” 대신 통과 조건을 명확히 제시
• 테스트 통과, 빌드 성공, 린터 에러 0개를 목표로 설정
• 피드백 루프가 있어야 AI가 스스로 수렴함
• 기존 동작을 검증하는 테스트는 리팩터링 난이도를 크게 낮춤

7. 실행 중 수정하지 말고 계획을 고쳐서 다시 실행하기

• 결과가 마음에 들지 않으면 코드 수정 요청을 반복하지 않음
• 계획 문서를 수정한 뒤 새 세션에서 다시 실행
• 실행 단계에서 방향을 틀면 품질이 빠르게 무너짐

8. 예제 기반으로 스타일을 학습시키기

• 추상적인 “좋은 코드” 지시는 거의 효과 없음
• Before / After 예제를 함께 제공
• 좋은 예와 나쁜 예를 명확히 구분해 제시
• 예제를 중심으로 규칙을 확장

9. 이해를 포기하지 말고 책임 경계를 명확히 하기

• AI가 생성한 코드는 반드시 사람이 이해하고 검토
• 프로토타입과 저위험 코드 외에는 무검토 사용 금지
• 보안·운영·장기 유지 코드에서는 이해가 품질의 전제

10. 이 작업이 AI에 적합한지부터 점검하기

• 정답이 없고 미적·구조적 판단이 큰 작업은 AI에 불리함
• 시각적 결과를 자동 검증하기 어려운 UI 리팩터링은 특히 까다로움
• 필요한 경우:
  • 1단계: 동작 유지 목적의 기계적 변환
  • 2단계: 사람이 품질 리팩터링 수행

11. 기대치는 “10% 개선”에서 시작하기

• 처음부터 10x를 기대하지 않음
• 작은 개선을 누적하는 전략이 장기적으로 더 효과적
• 설계와 품질 기준을 포기하지 않는 것이 핵심

[GN⁺]

Hacker News 의견들

• Claude Code 팀의 Boris임. 몇 가지 팁을 공유함

  1. Claude가 자주 틀리거나 이해하지 못하는 부분은 CLAUDE.md에 적어두면 좋음. Claude는 이 파일을 자동으로 읽음
  2. Plan 모드(Shift+Tab 두 번) 를 적극 활용해 계획을 먼저 세운 뒤 실행시키면 어려운 작업에서 2~3배 더 나은 결과를 얻을 수 있음
  3. 작업 검증 방법을 제공하면 좋음. 예를 들어 Svelte에서는 Puppeteer MCP 서버를 써서 브라우저에서 결과를 확인하게 할 수 있음
  4. 모델은 Opus 4.5를 추천함. Sonnet 4.5보다 확실히 한 단계 업그레이드된 느낌임
     도움이 되길 바람
  • 나도 Plan 모드 덕분에 큰 생산성 향상을 경험했음. 하지만 최근 버전에서 Plan 모드가 세션 첫 계획만 계속 참조하는 버그가 생겨서 워크플로우가 망가졌음. 내가 비정상적으로 쓰는 건지 궁금함
  • 작업 중 Claude를 교정한 뒤에는 self-reflection 프롬프트를 실행하면 좋음. 이 과정이 수동으로 정리한 내용들을 CLAUDE.md로 자동 반영해줌
  • 위 조언들에 공감함. 특히 (3)번의 피드백 루프가 핵심임. 모델이 직접 수정하고 결과를 확인할 수 있게 해야 함. 로그 파일을 남기게 하거나, pseudocode 계획을 세우게 하면 복잡한 문제도 빠르게 해결됨
  • Opus 4.5는 진짜 게임 체인저임. 오래된 React 프로젝트를 리팩터링할 때 큰 도움이 되었음. 프롬프트를 정밀하게 작성하고 CLAUDE.md를 잘 세팅하면 효과가 큼
  • CLAUDE.md가 4~5번 정도까지만 잘 작동하고 이후엔 지시를 잊어버림. 예를 들어 이름을 “Mr. bcherny”로 부르라고 해도 금방 잊음
  • Google Jules와 비교했을 때 Claude Code가 훨씬 전문 개발자처럼 느껴졌음. 다만 Claude Code Web에는 프로젝트 기능이 없어 .clinerules 파일을 쓰라는 답변을 받았는데, CLAUDE.md와의 차이를 알고 싶음
  • CLAUDE.md에서 유용한 기능 하나는 @import임. 파일 이름 앞에 @를 붙이면 강제로 컨텍스트에 포함시킬 수 있음. 다만 너무 많이 쓰면 비효율적임

• 음성 입력을 활용하면 모델이 의도를 더 정확히 이해함. 500단어 정도의 프롬프트를 말로 전달함. 타이핑보다 말할 때 생각이 더 자연스럽게 이어짐.
  “계획을 세우고 질문이 있으면 물어봐”라고 하면 Claude가 실제로 질문을 해옴. 이전 코드 스타일을 모방하도록 지시하는 것도 효과적임

  • 나도 음성으로 laboratory.love를 거의 전부 만들었음. 단축키로 “코드 작성 전 문제와 요구사항을 분석하고 모호한 점을 물어봐”라는 문장을 자주 씀
  • 말이 빠르다고 해서 생각 없이 말하는 건 아님. 오히려 생각을 덜 하고 말하는 게 문제일 수 있음
  • 누군가 듣고 있을 때 AI에게 말하는 건 좀 어색하지만, 긴 문장은 나도 음성으로 입력함
  • 어떤 음성 인식 서비스를 쓰는지 궁금함

• 프롬프트에 루프 조건(loop condition) 을 포함해야 함. 예: “yarn test가 통과할 때까지 반복”.
  LLM은 결국 도구를 반복 실행하는 에이전트이므로 그렇게 다뤄야 함
  참고: Prompting the Agent Loop

• 내가 만든 nori-profiles 설정을 추천함.
  4개월간 실험한 결과 Claude Code의 성능이 눈에 띄게 향상됨.
  관련 글: Averaging 10 PRs a Day with Claude

  • Claude Code의 skills와 비교하면 어떤 차이가 있는지 궁금함

• 회사에서 Golang 대규모 코드베이스를 다룸. Cursor, Claude Code, Gemini CLI 등 여러 툴을 써봤지만 대부분 코드량에 압도됨.
  그러나 aider는 훨씬 제어가 쉬웠고 정확도가 높았음. 파일 추가는 수동이지만 거의 100% 정확함.
  최신 Claude Sonnet이나 Gemini 2.5 Pro와 함께 쓰면 가장 정확함

  • aider는 완전한 에이전트형이 아니라는 점이 장점임. 수동으로 컨텍스트를 관리해 잘못된 파일 수정이 없음. 토큰 절약과 속도 면에서도 유리함

• Cursor로 작업할 때는 먼저 한 라우트를 리팩터링하면서 규칙 파일을 생성하게 함. 이후 다른 라우트에서는 “refactor”만 하면 됨

  • 긴 프롬프트를 두려워하지 말 것. 이것이 바로 context engineering임. 대화 기록 자체가 컨텍스트를 풍부하게 만들어줌.
    남은 컨텍스트 용량을 항상 의식하고, 필요 시 일찍 context clear를 하는 게 좋음

• 에이전트를 팀원처럼 대하는 관점이 중요함. 서로의 강점과 약점을 관찰하며 협업 방식을 조정해야 함.
  나는 검증 가능한 문제나 실험용 코드에 에이전트의 힘을 집중함.
  Svelte는 잘 모르지만, TDD 스타일의 disposable 테스트로 리라이트를 유도하는 게 좋을 듯함.
  때로는 이전의 잘못된 맥락을 버리고 새로운 워크스페이스에서 다시 시작하는 게 최선임

  • 그 “인지 스타일과 팀워크” 관련 텍스트의 요약을 공유해주면 좋겠음

• 나는 LLM을 탐색기(searcher) 로 봄. 질문을 작고 구체적으로 하면 탐색이 쉬워지고, 훈련 데이터에서 멀어질수록 오류 확률이 높아짐.

  1. 프로젝트를 Zed에서 열고
  2. Gemini CLI, Qwen code, Claude 중 하나를 연결
  3. 파일을 수정 요청하고 테스트
  4. 안 되면 Grok이나 Gemini 3 Chat에 시도
  5. 그래도 안 되면 수동으로 해결
     새 프로젝트는 one-shot 프롬프트로도 충분히 가능함
  • 하지만 너무 작은 프롬프트는 정보 부족(underspecification) 문제를 일으킴. 계산 비용만 줄 뿐, 품질 면에서는 불리함

• 내가 즐겨 쓰는 Claude Code 툴셋은 superpowers임

  1. 먼저 브레인스토밍 세션으로 기능을 설명
  2. Claude가 디자인 문서와 구현 계획을 작성해 디스크에 저장
  3. 새 Claude 창에서 Execute Plan 명령으로 단계별 실행 및 커밋
  4. 세 단계마다 자체 리뷰를 시켜 코드 품질을 높임
     2주째 쓰고 있는데 거의 실패한 적이 없음

• 나의 AI 프로그래밍 원칙은 단순함

  1. 한 번에 완성(one-shot) 은 실패함
  2. 작업을 검증 가능한 단위로 쪼갬
  3. 전체 계획을 Markdown 파일에 정리
  4. 각 단계마다 새 세션으로 실행하고 검토 후 커밋
     핵심은 “Less is more” 임. 컨텍스트 창은 새로울수록 좋고, 500~750단어 정도가 이상적임. 모든 단계는 검증 가능해야 함

• Java 관련 작업에서는 Claude가 지속적으로 방향을 바꾸거나 모순된 제안을 함. ChatGPT가 훨씬 낫다고 느낌

  • 프롬프트에 더 구체적인 지시를 주면 나아질 수 있음
  • 혹시 Claude Code 버전을 써봤는지 궁금함

• “Idiomatic code”를 원한다면 먼저 자신이 생각하는 스타일을 세세히 정의해야 함. 좋은/나쁜 예시를 작게 나누고, 이를 Opus 4.5의 Plan 모드에 넣어 계획을 세운 뒤 실행함. 한 번에 완벽하지 않으면 계획 문서를 수정하고 다시 시도함. 주니어 개발자처럼 세세히 지도하려 들면 오히려 비효율적임

  • 다른 사람은 “요즘 모델은 꼭 세션을 새로 시작하지 않아도 된다”며, 인라인 리팩터링으로도 충분히 안정적이라고 경험을 공유함