AI 코딩 도구로 생산성 10% → 200% 높이는 11가지 실전 팁

AI 코딩 도구를 쓰는데 오히려 시간이 더 걸린다고요? Hacker News 개발자 커뮤니티에서 3개월간 논의된 결과, **”AI를 잘못 쓰고 있다”**는 결론이 나왔습니다.

실제로 Claude Code를 제대로 활용한 개발자는 하루 10개 PR을 처리하고, aider로 대규모 코드베이스를 100% 정확도로 리팩터링했습니다. 반면 “AI가 내 코드의 90%도 못 만든다”고 불평하는 개발자도 있죠.

차이는 뭘까요? 전략입니다.

오늘은 Hacker News에서 검증된 AI 프로그래밍 실전 전략 11가지를 공유합니다. Claude Code 팀의 공식 조언, 4개월 실험 사례, 음성 프롬프트 활용법까지 모두 담았습니다. 이 글을 읽고 나면 “10배 생산성”은 못 얻어도 “10% → 50% → 200%” 점진적 개선 경로는 확실히 보일 거예요.

---

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

AI는 “생각하는 작업”이 아니라 “반복하는 작업”에 강합니다.

Claude Code 팀 Boris는 “AI는 비슷한 형태의 작업을 여러 번 반복할 때 가장 큰 효과를 낸다”고 강조합니다. 사고와 판단이 필요한 작업에서는 기대 효율이 급격히 낮아지거든요.

왜 반복 작업인가?

AI 모델은 “패턴 학습”에 최적화되어 있습니다. 한 번 잘 만들어진 예제를 주면, 그 패턴을 100번 반복해도 일정 수준 이상 품질을 유지합니다. 하지만 추상적 설계나 트레이드오프 판단은 여전히 사람이 훨씬 낫습니다.

실전 워크플로우

1. 첫 번째 케이스: 사람이 직접 최고 품질로 구현
2. 패턴 추출: 이 코드를 “기준 예제”로 AI에 제공
3. 나머지 케이스: AI가 동일 패턴으로 대량 처리
4. 사람은 검토만: 품질 체크와 예외 케이스만 처리
   

실제 사례

Hacker News 사용자 중 한 명은 “Cursor로 한 라우트를 리팩터링하면서 규칙 파일을 생성하게 했다. 이후 다른 라우트에서는 ‘refactor’만 하면 됐다”고 경험을 공유했습니다.

작업 유형	AI 효율	추천 도구
유사한 컴포넌트 10개 생성	⭐⭐⭐⭐⭐	Claude Code, Cursor
전체 아키텍처 설계	⭐⭐	직접 설계 후 AI 보조
반복적인 테스트 코드 작성	⭐⭐⭐⭐⭐	GitHub Copilot
복잡한 알고리즘 최적화	⭐⭐⭐	AI 아이디어 + 사람 검증

핵심: AI는 “도구”가 아니라 “어시스턴트”입니다. 반복 업무는 맡기되, 중요한 의사결정은 사람이 하세요.

---

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

“바로 코드 생성”은 실패율 80%입니다.

Claude Code 팀 Boris가 가장 강조하는 전략이 바로 Plan 모드 활용입니다. “Plan 모드(Shift+Tab 두 번)로 계획을 먼저 세운 뒤 실행하면 어려운 작업에서 2~3배 더 나은 결과를 얻을 수 있다”고 공식적으로 권장합니다.

왜 계획이 중요한가?

AI에게 바로 “코드 만들어줘”라고 하면 모호한 부분을 AI가 임의로 추측해서 채웁니다. 그 추측이 틀리면 전체를 다시 만들어야 하죠. 계획 단계에서 모호함을 미리 드러내면 그런 낭비를 막을 수 있습니다.

Hacker News 사용자는 “결과 품질은 프롬프트보다 계획 문서의 명확도에 좌우된다”고 정리했습니다.

계획 문서 작성 팁

# Plan: 사용자 인증 기능 추가

## 목표
- JWT 기반 로그인/로그아웃
- 토큰 갱신 자동화

## 모호한 부분 (AI에게 질문할 것)
- [ ] 토큰 저장 위치: localStorage vs httpOnly Cookie?
- [ ] 리프레시 토큰 갱신 주기는?
- [ ] 로그인 실패 시 재시도 정책은?

## 구현 순서
1. 백엔드 API 엔드포인트 작성
2. 프론트엔드 로그인 폼
3. 토큰 관리 로직
4. 테스트 코드

## 검증 조건
- [ ] 로그인/로그아웃 성공
- [ ] 토큰 만료 시 자동 갱신
- [ ] 테스트 커버리지 80% 이상

Plan 모드 실전 활용법

1. Shift+Tab 두 번 눌러 Plan 모드 실행
2. AI가 계획 초안 작성
3. 모호한 부분 질문 받기
4. 계획 수정 후 실행 단계로

주의: 최근 Claude Code에서 “Plan 모드가 세션 첫 계획만 계속 참조하는 버그”가 보고되었습니다. 방향이 바뀌면 새 세션에서 다시 시작하세요.

접근 방식	성공률	걸리는 시간	코드 품질
바로 코딩 시작	20%	2시간	60점
간단한 계획 → 실행	60%	1.5시간	75점
Plan 모드 → 검토 → 실행	85%	1시간	90점

---

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

“전체 리팩터링” 요청은 실패 확률 90%입니다.

AI는 한 번에 많은 것을 처리하려 하면 중간에 방향을 잃습니다. Hacker News 커뮤니티에서 가장 많이 나온 조언이 “작업을 파일 하나, 컴포넌트 하나, 함수 몇 개 단위로 쪼개라”는 것이었습니다.

실패하는 요청 vs 성공하는 요청

실패하는 요청 ❌	성공하는 요청 ✅
“전체 코드를 idiomatic하게 바꿔줘”	“UserCard.tsx를 함수형 컴포넌트로 변환해줘”
“프로젝트 구조를 개선해줘”	“utils/api.ts에서 fetchData 함수만 async/await로 바꿔줘”
“성능 최적화해줘”	“ProductList.tsx에 React.memo 적용해줘”

쪼개기 전략

1. 구조 설계: 사람이 전체 그림 그리기
2. 단위 작업 리스트: 체크리스트로 정리
3. 하나씩 실행: AI에게 한 번에 하나씩만
4. 검증 후 다음: 테스트 통과 확인 후 다음 항목

실전 예시: React 리팩터링

# React 리팩터링 체크리스트

## Phase 1: 컴포넌트 함수형 변환
- [ ] UserCard.tsx
- [ ] ProductList.tsx
- [ ] Sidebar.tsx

## Phase 2: 상태 관리 개선
- [ ] useContext → Zustand 마이그레이션 (store.ts)
- [ ] UserCard에서 Zustand 사용
- [ ] ProductList에서 Zustand 사용

## Phase 3: 성능 최적화
- [ ] ProductList에 React.memo 적용
- [ ] 무거운 계산에 useMemo 적용

aider 사용자는 “작업 단위를 작게 쪼개고 파일을 수동으로 추가하니 거의 100% 정확도를 얻었다”고 경험을 공유했습니다.

핵심: “전체”를 한 번에 주지 말고, “하나”씩 던지세요.

---

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

대화가 길어질수록 AI는 멍청해집니다.

이건 체감적으로 모두 느낄 겁니다. 처음엔 잘 하던 Claude가 20번째 메시지에서는 엉뚱한 답을 하죠. Hacker News 커뮤니티에서는 “대화가 길어질수록 규칙 준수와 품질이 급격히 떨어진다”고 정리했습니다.

왜 컨텍스트를 초기화해야 하나?

AI는 대화 기록 전체를 계속 참조합니다. 초반에 했던 잘못된 가정, 중간에 바뀐 방향, 임시로 한 테스트까지 모두 “컨텍스트”로 쌓입니다. 그러다 보면 “지금 뭘 하고 있는지” 초점을 잃어버립니다.

세션 관리 전략

상황	행동	이유
작업 하나 완료	새 세션 시작	컨텍스트 깨끗하게
방향 변경	새 세션 시작	기존 가정 버리기
10번 이상 왔다갔다	새 세션 시작	품질 저하 방지
장기 프로젝트	plan.md로 상태 저장	세션 독립적으로 관리

plan.md로 상태 관리하기

대화 기록에 의존하지 말고, 문서로 상태를 보존하세요.

# Project: 사용자 인증 구현

## 완료된 작업
- [x] JWT 토큰 발급 API (2025-12-10)
- [x] 로그인 폼 컴포넌트 (2025-12-12)

## 다음 작업
- [ ] 토큰 자동 갱신 로직
- [ ] 로그아웃 기능

## 중요 결정 사항
- 토큰 저장: httpOnly Cookie (XSS 방지)
- 갱신 주기: 15분

새 세션을 시작할 때 이 문서를 AI에게 주입하면, 긴 대화 없이도 컨텍스트를 이어갈 수 있습니다.

Hacker News 사용자는 “컨텍스트 창은 새로울수록 좋고, 500~750단어 정도가 이상적이다”라고 정리했습니다.

핵심: “대화 누적”보다 “문서 기반 상태 관리”가 훨씬 안정적입니다.

---

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

CLAUDE.md는 500~1000 토큰 내로 유지하세요.

Claude Code는 프로젝트 루트의 CLAUDE.md 파일을 자동으로 읽습니다. 여기에 “자주 틀리는 부분”만 적어두면 AI가 계속 참조합니다. 하지만 너무 길면 오히려 효과가 떨어집니다.

규칙 문서 작성 원칙

❌ 나쁜 규칙	✅ 좋은 규칙
“코드는 깔끔하게 작성하세요”	“함수는 50줄 이내로 제한”
“좋은 변수명을 사용하세요”	“boolean 변수는 is/has 접두사 필수”
“테스트를 작성하세요”	“각 함수마다 최소 2개 테스트 케이스”

CLAUDE.md 예시

# Project Rules

## Code Style
- 함수 길이: 50줄 이내
- boolean 변수: is/has 접두사 (예: isLoading, hasError)
- 파일명: kebab-case (예: user-card.tsx)

## Testing
- 각 함수마다 최소 2개 테스트
- 테스트 파일명: *.test.ts

## Common Mistakes (자주 틀리는 것만)
- ❌ useState 초기값 빈 객체 {} 금지 → null 사용
- ❌ useEffect dependency 빼먹지 말기
- ❌ API 에러 핸들링 항상 포함

Claude Code 팀 Boris는 “Claude가 자주 틀리거나 이해하지 못하는 부분만 CLAUDE.md에 적어두라”고 조언합니다.

주의사항

Hacker News 사용자는 “CLAUDE.md가 4~5번 정도까지만 잘 작동하고 이후엔 지시를 잊어버린다”고 보고했습니다. 너무 많은 걸 기대하지 마세요. 자주 틀리는 것만 최소한으로 기록하고, 나머지는 테스트와 린터로 강제하세요.

---

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

“잘 만들어줘”는 모호합니다. “테스트 통과할 때까지 반복”은 명확합니다.

AI에게 추상적인 목표를 주면 AI도 추측합니다. 하지만 검증 가능한 목표를 주면 AI가 스스로 수렴합니다. Hacker News에서 추천된 전략이 바로 “루프 조건을 프롬프트에 포함하기”입니다.

루프 조건 프롬프트 예시

"이 함수를 리팩터링해줘. 
조건: yarn test가 통과할 때까지 반복"

"ProductList 컴포넌트를 최적화해줘.
조건: 
1. 빌드 에러 0개
2. ESLint 경고 0개
3. 기존 테스트 모두 통과"

피드백 루프의 힘

피드백 루프 없음	피드백 루프 있음
AI가 “잘 만들었다”고 주장	AI가 직접 테스트 실행 후 확인
사람이 일일이 검증	AI가 스스로 수정 반복
5번 왔다갔다	자동 수렴

실전 활용법

1. 테스트 먼저 작성: TDD 스타일로 “통과해야 할 테스트” 미리 작성
2. AI에게 목표 제시: “이 테스트를 통과하는 코드를 만들어줘”
3. AI가 반복 실행: 테스트 실패하면 수정하고 다시 실행
4. 통과하면 완료: 사람은 검토만

Hacker News 사용자는 “피드백 루프가 있어야 AI가 스스로 수렴한다. 기존 동작을 검증하는 테스트는 리팩터링 난이도를 크게 낮춘다”고 강조했습니다.

Claude Code 팀도 “작업 검증 방법을 제공하면 좋다. 예를 들어 Svelte에서는 Puppeteer MCP 서버를 써서 브라우저에서 결과를 확인하게 할 수 있다”고 권장합니다.

핵심: AI를 “에이전트 루프”처럼 다루세요. 목표 조건을 주고 스스로 반복하게 만드세요.

📚 관련 자료: Prompting the Agent Loop

---

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

“아니야, 이렇게 바꿔줘” 3번 반복 = 품질 붕괴

AI가 만든 코드가 마음에 들지 않을 때, 계속 “아니야 이건 이렇게, 저건 저렇게” 요청하면 코드는 점점 엉망이 됩니다. Hacker News 커뮤니티에서는 “실행 단계에서 방향을 틀면 품질이 빠르게 무너진다”고 경고했습니다.

올바른 수정 방식

1. 결과가 마음에 안 들면: 코드 수정 요청 ❌
2. 계획 문서 수정: plan.md 또는 프롬프트 수정 ✅
3. 새 세션 시작: 깨끗한 컨텍스트에서
4. 수정된 계획으로 재실행: 처음부터 다시

비교: 땜질 vs 재실행

땜질 방식 (비추천)	재실행 방식 (추천)
“아니야, 함수명 바꿔줘”	plan.md 수정: 함수명 규칙 명시
“이 부분 다시 해줘”	새 세션에서 전체 재실행
5번 왔다갔다 후 포기	2번 만에 원하는 결과
코드 품질 60점	코드 품질 85점

실전 예시

Bad: 땜질 방식

"UserCard 컴포넌트 만들어줘"
→ (결과 나옴)
"아니야, props는 destructuring 해줘"
→ (수정됨)
"그리고 TypeScript 타입 추가해줘"
→ (또 수정)
"스타일은 Tailwind로 바꿔줘"
→ (코드 엉망)

Good: 재실행 방식

"UserCard 컴포넌트 만들어줘"
→ (결과 마음에 안 듦)
→ 프롬프트 수정:
"UserCard 컴포넌트 만들어줘.
요구사항:
- Props destructuring 사용
- TypeScript interface 정의
- Tailwind CSS 사용"
→ (새 세션에서 재실행)
→ 한 번에 원하는 결과

superpowers 도구를 만든 Hacker News 사용자는 “디자인 문서를 먼저 작성하고, 새 Claude 창에서 단계별 실행 및 커밋. 세 단계마다 자체 리뷰. 2주째 쓰는데 거의 실패한 적이 없다”고 경험을 공유했습니다.

---

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

“좋은 코드 작성하세요”는 거의 효과 없습니다.

추상적 지시는 AI도 이해 못 합니다. Before / After 예제를 보여주는 게 100배 효과적입니다.

예제 기반 프롬프트

Bad: 추상적 지시

"이 코드를 idiomatic하게 바꿔줘"

Good: Before/After 예제

"이 코드를 아래 스타일로 바꿔줘.

Before:
function getUser(id) {
  return fetch('/api/users/' + id)
}

After:
async function getUser(id: string): Promise<User> {
  const response = await fetch(`/api/users/${id}`);
  if (!response.ok) throw new Error('Failed to fetch');
  return response.json();
}

이제 getUserPosts 함수도 같은 스타일로 바꿔줘."

좋은 예 / 나쁜 예 제시

# Code Style Guide

## ✅ Good Example
```typescript
// API 호출 함수
async function fetchUserData(userId: string): Promise<UserData> {
  try {
    const response = await api.get(`/users/${userId}`);
    return response.data;
  } catch (error) {
    logger.error('Failed to fetch user', { userId, error });
    throw error;
  }
}

❌ Bad Example (피해야 할 패턴)

// 이렇게 하지 마세요
function getUserData(id) {
  return api.get('/users/' + id).data; // 에러 핸들링 없음
}

Hacker News 사용자는 "'Idiomatic code'를 원한다면 먼저 자신이 생각하는 스타일을 세세히 정의해야 한다. 좋은/나쁜 예시를 작게 나누고 Opus 4.5의 Plan 모드에 넣어 계획을 세운 뒤 실행하라"고 조언했습니다.

---

## 🎤 9. 음성 입력으로 의도를 명확히 전달하기

**타이핑보다 말할 때 생각이 더 자연스럽게 이어집니다.**

이건 의외의 팁입니다. Hacker News에서 여러 개발자가 "음성 입력을 활용하면 모델이 의도를 더 정확히 이해한다"고 경험을 공유했습니다.

### 왜 음성인가?

1. **더 긴 프롬프트**: 타이핑은 귀찮아서 짧게 쓰게 되지만, 말은 500단어도 쉽게 전달
2. **자연스러운 맥락**: "이건 이렇고, 그런데 저건 저렇고..." 식으로 맥락이 자연스럽게 이어짐
3. **질문 유도**: "계획을 세우고 질문이 있으면 물어봐"라고 말하면 Claude가 실제로 질문함

### 실전 활용 사례

laboratory.love를 만든 개발자는 "음성으로 거의 전부 만들었다. 단축키로 '코드 작성 전 문제와 요구사항을 분석하고 모호한 점을 물어봐'라는 문장을 자주 쓴다"고 경험을 공유했습니다.

### 음성 프롬프트 예시

“UserCard 컴포넌트를 만들고 싶은데, 이전에 만든 ProductCard 스타일을 그대로 따라가야 해. 그러니까 props는 destructuring 하고, TypeScript 타입은 interface로 정의하고, 스타일은 Tailwind CSS로 하는 그런 방식이야.

근데 UserCard는 ProductCard와 달리 프로필 이미지가 원형이어야 하고, 온라인 상태를 보여주는 초록색 점도 있어야 해.

계획을 먼저 세우고, 모호한 부분 있으면 질문해줘.”

이렇게 말하면 AI가 훨씬 풍부한 컨텍스트를 받습니다.

**주의**: 누군가 듣고 있을 때 AI에게 말하는 건 좀 어색할 수 있습니다 😅

---

## 🤝 10. AI를 팀원처럼 대하기 (강점과 약점 파악)

**AI는 "마법 도구"가 아니라 "주니어 개발자"처럼 다뤄야 합니다.**

Hacker News 사용자는 "에이전트를 팀원처럼 대하는 관점이 중요하다. 서로의 강점과 약점을 관찰하며 협업 방식을 조정해야 한다"고 조언했습니다.

### AI의 강점과 약점

| AI가 잘하는 것 ✅ | AI가 못하는 것 ❌ |
|-----------------|-----------------|
| 반복적인 코드 생성 | 추상적 설계 |
| 패턴 기반 작업 | 트레이드오프 판단 |
| 문서 → 코드 변환 | 미적/구조적 판단 |
| 테스트 코드 작성 | 시각적 UI 리팩터링 |
| 빠른 프로토타입 | 보안/운영 critical 코드 |

### 작업 할당 전략

**사람이 해야 할 것:**
- 전체 아키텍처 설계
- 트레이드오프 결정 (성능 vs 가독성)
- 보안 critical 코드 (인증, 권한)
- UI/UX 최종 판단

**AI에게 맡길 것:**
- 반복적인 CRUD API 생성
- 테스트 코드 작성
- 타입 정의 보완
- 기계적 마이그레이션 (예: class → function)

### 실전 협업 예시

1. **사람**: "JWT 인증 구조 설계. httpOnly Cookie 사용 결정"
2. **AI**: "로그인 API 엔드포인트 구현"
3. **사람**: "토큰 갱신 로직 검토 및 보안 체크"
4. **AI**: "로그아웃, 토큰 검증 API 생성"
5. **사람**: "전체 통합 테스트 및 최종 검토"

TDD 스타일 권장: "검증 가능한 문제나 실험용 코드에 에이전트의 힘을 집중한다. disposable 테스트로 리라이트를 유도하는 게 좋다"

---

## 🎯 11. 기대치는 "10% 개선"에서 시작하기

**"10배 생산성"을 기대하면 실망합니다. "10% → 50% → 200%" 점진적 개선이 현실입니다.**

Hacker News 커뮤니티에서 가장 많이 강조된 메시지가 바로 이겁니다: **"처음부터 10x를 기대하지 말라."**

### 점진적 개선 로드맵

| 단계 | 기대 효과 | 전략 |
|------|----------|------|
| **1개월** | 10-20% 개선 | 반복 작업만 AI에 맡기기 |
| **2-3개월** | 50% 개선 | Plan 모드, 테스트 루프 활용 |
| **4-6개월** | 100-200% 개선 | 워크플로우 완전 정착, CLAUDE.md 최적화 |

### 실제 사례: 점진적 성장 곡선

nori-profiles를 4개월간 실험한 개발자는 "Claude Code의 성능이 눈에 띄게 향상됐다. 하루 평균 10개 PR 처리"라는 결과를 얻었습니다.

### 핵심 원칙: 설계와 품질 기준을 포기하지 않기

**Bad: 품질 포기하고 속도만**

“일단 빨리 만들어줘” → 단기적 속도 ⬆️ → 장기적 유지보수 지옥 ⬇️

**Good: 품질 유지하며 점진적 개선**

“테스트 커버리지 80% 유지하며 리팩터링” → 단기적으로 조금 느림 → 장기적으로 안정적 성장

### 현실적인 기대치

| 작업 유형 | 시간 단축 효과 | 품질 수준 |
|----------|--------------|----------|
| 반복적 CRUD | 70-80% | 85-90% |
| 새로운 기능 설계 | 20-30% | 90% (사람 검토 필수) |
| 레거시 리팩터링 | 30-50% | 80% (테스트 필수) |
| 버그 수정 | 10-20% | 95% (사람 최종 확인) |

작은 개선을 누적하는 전략이 장기적으로 더 효과적입니다.

---

## ❓ 자주 묻는 질문

### Q1. Claude Code, Cursor, GitHub Copilot 중 뭐가 제일 좋나요?

**A**: 용도에 따라 다릅니다.

| 도구 | 강점 | 추천 대상 |
|------|------|----------|
| **Claude Code** | Plan 모드, 컨텍스트 이해력, 긴 대화 | 복잡한 리팩터링, 설계 논의 |
| **Cursor** | 빠른 속도, 인라인 편집, @codebase | 일상적 코딩, 빠른 반복 |
| **GitHub Copilot** | 자동완성 정확도, IDE 통합 | 코드 자동완성, 보일러플레이트 |
| **aider** | 대규모 코드베이스, 수동 컨텍스트 관리 | Golang 등 대규모 프로젝트 |

Hacker News에서 Golang 대규모 코드베이스를 다루는 개발자는 "aider는 거의 100% 정확했다. 파일 추가는 수동이지만 완전한 에이전트형이 아니라는 점이 장점"이라고 평가했습니다.

### Q2. CLAUDE.md 작성법이 궁금합니다.

**A**: 500-1000 토큰 이내로, "자주 틀리는 것만" 기록하세요.

```markdown
# Project: MyApp

## Code Style
- 파일명: kebab-case
- boolean 변수: is/has 접두사

## Common Mistakes
- ❌ useState 초기값 {} 금지 → null 사용
- ❌ API 호출에 에러 핸들링 필수

## Testing
- 각 함수 최소 2개 테스트

Claude Code 팀 Boris: “Claude가 자주 틀리거나 이해하지 못하는 부분만 CLAUDE.md에 적어두세요.”

Q3. Plan 모드가 계속 첫 계획만 참조하는 버그가 있다던데요?

A: 방향이 바뀌면 새 세션에서 다시 시작하세요.

최근 Claude Code에서 보고된 버그입니다. 세션이 길어지면 계획이 꼬일 수 있으니, 중요한 방향 전환 시에는 새 세션을 여는 게 안전합니다.

Q4. 음성 입력은 어떤 서비스를 쓰나요?

A: 대부분의 AI 도구가 내장 음성 입력을 지원합니다.

• Claude: 웹/앱에서 마이크 버튼
• ChatGPT: 모바일 앱 음성 입력
• Cursor: 운영체제 음성 입력 (macOS Dictation, Windows Speech Recognition)

Q5. AI로 보안 관련 코드도 작성해도 되나요?

A: 생성은 AI가 해도 되지만, 반드시 사람이 검토해야 합니다.

Hacker News 커뮤니티 권장사항:

• ✅ 프로토타입과 저위험 코드: AI 생성 후 간단 검토
• ⚠️ 보안·운영·장기 유지 코드: AI 생성 + 사람 철저히 검토
• ❌ critical 인증/권한 로직: 사람이 직접 작성 추천

“AI가 생성한 코드는 반드시 사람이 이해하고 검토. 보안·운영·장기 유지 코드에서는 이해가 품질의 전제”

Q6. “idiomatic code”를 AI에게 요청하면 잘 안 되는데요?

A: “idiomatic”은 추상적입니다. Before/After 예제를 제공하세요.

Hacker News 사용자: “‘Idiomatic code’를 원한다면 먼저 자신이 생각하는 스타일을 세세히 정의해야 한다. 좋은/나쁜 예시를 Opus 4.5 Plan 모드에 넣어라.”

Q7. 컨텍스트가 너무 빨리 차는데 어떻게 관리하나요?

A: Context Engineering 전략을 쓰세요.

1. 긴 프롬프트를 두려워하지 말 것: 대화 기록 자체가 컨텍스트를 풍부하게
2. 남은 컨텍스트 용량 의식: 필요 시 일찍 context clear
3. 문서로 상태 보존: plan.md로 관리

Hacker News: “이것이 바로 context engineering이다. 대화 기록 자체가 컨텍스트를 풍부하게 만들어준다.”

Q8. Opus 4.5 vs Sonnet 4.5, 뭘 써야 하나요?

A: 복잡한 작업은 Opus 4.5, 일상적 작업은 Sonnet 4.5

Claude Code 팀 Boris: “Opus 4.5를 추천한다. Sonnet 4.5보다 확실히 한 단계 업그레이드된 느낌.”

Hacker News 사용자: “Opus 4.5는 진짜 게임 체인저. 오래된 React 프로젝트 리팩터링할 때 큰 도움이 되었다.”

---

🎯 결론: AI 프로그래밍은 “전략”이 전부입니다

“AI가 내 코드의 90%도 못 만든다”는 불평과 “하루 10개 PR 처리한다”는 성공 사례의 차이는 단 하나, 전략입니다.

이 글에서 소개한 11가지 전략을 정리하면:

1. ✅ 반복 작업에만 AI 집중 – 판단은 사람, 구현은 AI
2. ✅ 계획부터 만들기 – Plan 모드로 2-3배 효과
3. ✅ 작업 단위를 작게 – 파일 하나, 함수 몇 개씩
4. ✅ 컨텍스트 자주 초기화 – 대화보다 문서로 상태 관리
5. ✅ 규칙 문서는 짧게 – CLAUDE.md 500-1000 토큰
6. ✅ 테스트·린터로 피드백 루프 – “테스트 통과까지 반복”
7. ✅ 계획 수정 후 재실행 – 땜질하지 말기
8. ✅ 예제 기반 학습 – Before/After 제공
9. ✅ 음성 입력 활용 – 더 풍부한 맥락 전달
10. ✅ AI를 팀원처럼 – 강점과 약점 파악
11. ✅ 10% 개선부터 – 점진적 성장 곡곤

지금 바로 실천할 것 3가지

1. CLAUDE.md 만들기: 프로젝트 루트에 “자주 틀리는 것” 3개만 적기
2. Plan 모드 써보기: 다음 작업에서 Shift+Tab 두 번 눌러보기
3. 테스트 루프 설정: “yarn test 통과할 때까지 반복” 프롬프트 써보기

마지막 조언

Hacker News 커뮤니티가 가장 강조한 메시지는 이겁니다:

“한 번에 완성(one-shot)은 실패한다. 작업을 검증 가능한 단위로 쪼개고, 계획→실행→검토→커밋을 반복하라. 핵심은 ‘Less is more’. 컨텍스트 창은 새로울수록 좋고, 500~750단어가 이상적이다.”

AI 프로그래밍은 마법이 아닙니다. 하지만 올바른 전략을 쓰면 10% → 50% → 200%의 점진적 개선은 충분히 가능합니다.

설계와 품질 기준을 포기하지 마세요. AI는 당신의 “도구”가 아니라 “어시스턴트”입니다. 잘 협업하세요! 🚀

---

📚 참고 자료

• Prompting the Agent Loop
• Averaging 10 PRs a Day with Claude
• nori-profiles GitHub
• superpowers GitHub
• Claude Code Skills

---

🏷️ 태그: #AI코딩 #ClaudeCode #Cursor #개발자생산성 #프로그래밍AI #코딩자동화 #프롬프트엔지니어링 #개발자도구 #HackerNews #테크팁