# AI를 활용한 프로그래밍 역량을 높이는 방법 > Clean Markdown view of GeekNews topic #25060. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25060](https://news.hada.io/topic?id=25060) - GeekNews Markdown: [https://news.hada.io/topic/25060.md](https://news.hada.io/topic/25060.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-14T13:32:38+09:00 - Updated: 2025-12-14T13:32:38+09:00 - Original source: [news.ycombinator.com](https://news.ycombinator.com/item?id=46255285) - Points: 48 - Comments: 1 ## Summary AI 코딩 도구는 반복적이고 패턴이 뚜렷한 작업에서 가장 큰 효율을 냅니다. 핵심은 **‘계획–실행–검증’의 루프를 짧게 유지하는 것**으로, 명확한 계획 문서와 테스트 기반 피드백이 품질을 결정합니다. 구조 설계와 판단은 사람이 맡고, AI는 반복 구현과 기계적 변환에 집중할 때 생산성과 코드 품질을 함께 끌어올릴 수 있습니다. ## Topic Body - 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를 기대하지 않음 - 작은 개선을 누적하는 전략이 장기적으로 더 효과적 - 설계와 품질 기준을 포기하지 않는 것이 핵심 ## Comments ### Comment 47709 - Author: neo - Created: 2025-12-14T13:32:39+09:00 - Points: 2 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46255285) - 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](https://www.skeptrune.com/posts/prompting-the-agent-loop/) - 내가 만든 [nori-profiles 설정](https://github.com/tilework-tech/nori-profiles)을 추천함. 4개월간 실험한 결과 Claude Code의 성능이 **눈에 띄게 향상**됨. 관련 글: [Averaging 10 PRs a Day with Claude](https://12gramsofcarbon.com/p/averaging-10-prs-a-day-with-claude) - Claude Code의 [skills](https://github.com/anthropics/skills/tree/main/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](https://github.com/obra/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 모드에 넣어 계획을 세운 뒤 실행함. 한 번에 완벽하지 않으면 계획 문서를 수정하고 다시 시도함. **주니어 개발자처럼 세세히 지도하려 들면 오히려 비효율적**임 - 다른 사람은 “요즘 모델은 꼭 세션을 새로 시작하지 않아도 된다”며, **인라인 리팩터링**으로도 충분히 안정적이라고 경험을 공유함