내 가난한 사람을 위한 AI 코딩 설정 (2026년 1월)
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the text, I’ll keep the source link unchanged and translate the rest into Korean while preserving all formatting, markdown, and technical terms.
내 설정
저는 Codex와 Claude Code를 모두 사용하며 작업에 따라 전환합니다.
VS Code / Cursor IDE 확장 프로그램을 통해 컨텍스트를 추가하고, 코드를 확인하며, 빠르게 조정할 수 있습니다.
요즘은 Cursor Agent Mode나 Composer를 거의 사용하지 않습니다. (Opus 4.5를 사용해도 하네스가 중요합니다 – Claude Code CLI나 확장 프로그램을 사용할 때 더 좋은 결과를 얻습니다.)
Cursor는 여전히 브라우저 편집과 같은 편리한 기능을 제공하며, 이는 프론트엔드 작업에 특히 유용합니다.
저는 종종 두 모델을 동시에 다른 코드 부분이나 보완적인 작업에 실행하고, Codex에게 Claude의 출력물을 검토하고 후속 변경을 하도록 요청합니다.
IDE 확장 프로그램! 신성모독! 나가라! 😂 나와 함께 있어!
Codex GPT 5.2 (고수준 사고)
Codex는 많은 컨텍스트, 계획, 복잡한 프롬프트가 필요하지 않습니다 – 올바른 힌트만 주면 보통 첫 번째 시도에서 정확히 맞춥니다. 하지만 매우, 매우 느립니다.
저는 주로 깊은 사고가 필요한 복잡한 작업에 사용합니다:
- 복잡한 버그
- 강력한 타입 지정
- 고데이터 정확도 작업(예: 환각 없이 데이터 변환 또는 스크래핑)
- 코드 리뷰
- 리팩터링
- 코드베이스 또는 개별 코드 조각 설명
선호하는 후속 프롬프트
- “리팩터링해야 할 부분이 있나요?”
- “이 파일을 간소화해 주세요.”
- “작동은 하지만, 유지보수, 보안, 혹은 아키텍처상의 문제가 있나요?”
- “작동은 하지만, 동일한 결과를 얻는 더 좋은 방법이 있나요? 옵션을 보여 주세요.”
Claude Code / Opus 4.5
Claude Code와 Opus 4.5 조합은 매우 빠르고 정확합니다. 때때로 Codex보다 조금 더 손길이 필요하고, 질문을 하거나 계획을 추가하곤 합니다. “plan mode”를 수동으로 트리거할 수도 있습니다. 계획 모드에 대한 결과는 엇갈리는데, 저는 괜찮지만 기존 코드베이스에서는 작은, 캡슐화된 변경을 선호합니다; Codex는 계획 없이도 보통 더 잘 작동합니다.
저는 대부분의 코딩 작업에 이를 사용합니다:
- 새 기능
- 테스트/타입 추가
- React 컴포넌트 생성
- 빠른 프로토타입
선호하는 프롬프트
- “라이브러리 인터페이스 설계.”
- “이 패턴을 기반으로 유사한 메서드 구현.”
- “X를 수행하는 컴포넌트 생성”(훌륭한 UX로 한 번에 구현).
- “이 함수/파일 이름을 바꾸고 모든 참조와 테스트를 업데이트해 주세요.”
Claude Code와 Codex CLI
저는 또한 CLI를 설치해 두었습니다. 전해지는 바에 따르면 CLI는 더 강력한 하네스를 가지고 있으며, 일부 기능은 IDE 확장 프로그램보다 먼저 CLI에서 나타납니다.
- IDE 확장 프로그램은 단일 스레드 워크플로를 제공합니다: 모델을 지속적으로 조정하고, 생성된 모든 라인을 검토하며, 인라인 변경을 하고, 테스트하고, 검증합니다. 동시에 하나의 세션만 가능하며(레포를 별도 폴더에 복제하고 다른 IDE 창을 열 경우는 예외), 저는 가끔 그렇게 합니다.
- CLI는 더 병렬적이고 손을 놓는 작업을 가능하게 합니다(“바이브 코딩”과 혼동하지 마세요 – 여전히 코드를 읽고, 검증하고, 기대한 대로 동작하는지 확인해야 합니다).
- CLI를 같은 코드베이스에서 동시에 실행할 경우 충돌, 브랜치, 워크‑트리 관리에 대해 생각해야 합니다. 때때로 서로 간섭하지 않지만 항상 그런 것은 아닙니다. 저는 이를 약간 번거롭게 느껴서, 한 번에 많은 작업을 밀어넣어야 할 때가 아니라면 피합니다.
모든 종류의 작업과 레포가 CLI를 이용한 병렬 코딩에 적합한 것은 아닙니다.
CLI가 유용한 상황
- 일회성 POC
- 마이그레이션(아래 Ralph Loop 코딩 참조)
- IDE에서 직접 편집하기 전 시작점으로
- 강력한 검증 루프(테스트)가 있는 프로젝트에서 명확히 정의된 작업
Ralph L
oop Coding
모두가 이야기하고 있는 기술… 직접 실험해 보니 핸즈‑오프 / 병렬 자동 작업의 최종 목표처럼 보입니다.
Codex는 한 번에 하나의 프롬프트로 작은 마이그레이션을 수행하는 데는 뛰어나지만, 더 길고 복잡하며 반복 가능한 작업(예전에는 성능이 좋지 않았던 “codemod”을 생각해 보세요)에서는 CLI를 루프 안에서 실행하면 놀라운 결과를 얻을 수 있습니다.
핵심은 모델이 한 번에 하나의 작업만 수행하도록 하고, 멈추고 검증한 뒤 다음으로 넘어가는 것입니다. 이 “루프” 접근 방식은 모델이나 코드베이스에 과부하를 주지 않으면서도 많은 작은, 신뢰할 수 있는 변환을 연속적으로 연결할 수 있게 해줍니다.
기타 / 팁과 요령
-
MCP는 어떻게 할까요?
필요할 때만 사용하세요 (예: 프론트엔드 코드를 위한 Chrome/Playwright, 문서를 위한 Context7 등). -
Cursor Rules,
Agents.md,Claude.md는 어떻게 할까요?
모델이 스스로 올바른 컨텍스트를 찾는 능력이 향상되고 있지만, 같은 실수를 반복한다면 해당 규칙을 적절한.md파일에 추가하세요. (코드 리뷰 중에 트리거할 수 있는 편리한 GitHub Action이 있어 파일들을 업데이트할 수 있습니다.) -
음성 모드
Wisprflow를 더 많이 사용하기 시작했지만, 생각을 정리할 수 있게 타이핑하는 것이 여전히 좋습니다. -
컨텍스트 윈도우
요즘은 크게 걱정할 필요가 없습니다 (Codex는 매우 뛰어나고, Claude는 auto‑compact 기능이 있습니다). 가능한 한 자주 새 세션을 시작해 컨텍스트 윈도우를 초기화하는 것을 권장합니다—물론 컨텍스트를 잃지 않으면서 말이죠. -
반복 작업 자동화
Claude Code는 슬래시 명령과 서브‑에이전트를 지원하여 푸시, 커밋, 리뷰, 테스트 실행 등과 같은 작업을 자동화할 수 있습니다.
Caveats / Constraints – Production 소프트웨어와 작업하기
AI를 사용해 그린필드 프로젝트를 코딩하는 방식은 오래된/프로덕션 코드베이스를 코딩하는 방식과 크게 다릅니다. 최신 모델은 대규모 리포지토리에서도 효과적으로 작동할 수 있지만, 알아두어야 할 제약이 있으며, 코드 자체를 개선하면 속도와 산출량을 크게 높일 수 있습니다.
1. 스파게티 코드
- 크고 연관성이 없는 코드 섹션이 컨텍스트 윈도우를 부풀리게 되어 모델이 느려지고 토큰 효율이 떨어집니다.
- 해결책:
- 순환 의존성을 줄입니다.
- 명확한 인터페이스 뒤에 컴포넌트를 캡슐화합니다.
- 잘 정의된 아키텍처와 모듈 경계를 강제합니다.
애플리케이션이 썩어 있으면 컨텍스트도 썩게 됩니다.
2. 재작성 여부
- 모델의 컨텍스트 윈도우가 가득 차면 **“컨텍스트 압축”**을 시도합니다.
- 레거시 코드베이스에도 동일한 원리가 적용됩니다: 기술 부채와 오래된 결정이 쌓이면 의도를 포착하고, 현재 상태를 요약한 뒤 새로 시작하는 것이 더 효율적일 수 있습니다(보통 재작성이라고 부릅니다).
무언가를 재작성하는 것이 이보다 저렴했던 적은 없었습니다!
3. 검증 루프 누락
- 스스로 출력을 검증할 수 없는 모델은 더 많은 조정이 필요하고 지속적으로 작업할 수 없습니다.
- 인간 검증은 커밋되고 저장되어야 합니다(예: 테스트, 린트 규칙, 타입 체크, 혹은 에이전트 컨텍스트를 통해).
- 모델은 테스트 생성에 뛰어나지만, 진정한 검증을 대체하지는 못합니다—시스템이 올바르다는 인간의 판단이 필요합니다.
4. 테스트 닭‑달걀 역설
- 비모듈화된 코드는 테스트하기 어렵습니다.
- 테스트가 없으면 검증 루프가 깨져, 변경 및 테스트가 어려운 코드를 만들게 됩니다.
- 해결책:
- 인간이 검증한 테스트를 작성하고 커밋합니다.
- 검증 루프를 닫아 새로운 코드와 개선 사항을 인간과 코딩 에이전트 모두 안전하게 추가할 수 있게 합니다.
5. 이제는 코드가 병목이 아니라 검증이 병목!
“풀 리퀘스트에 작동한다는 증거가 없으면, 더 빠르게 배포하는 것이 아니라 작업을 하류로 미루는 것에 불과합니다.” – Addy Osmani
- 에이전트는 신뢰할 수 있는 코드를 빠르게 생성할 수 있지만, 정확성을 보장하는 것이 현재 병목입니다.
- 주요 원인:
- 수동 코드 리뷰.
- 수동 테스트.
- 느린 자동화 테스트 스위트.
이 영역을 가속화하면(예: 테스트 병렬화, 더 빠른 CI 파이프라인 사용, 리뷰 도구 개선) 프로덕션에 코드를 배포하는 속도가 크게 증가합니다.
6. 모든 것을 다 넣는 역설
- 모델은 인간처럼 행동합니다: 더러운 싱크를 보면 그냥 위에 또 다른 접시를 얹어버립니다.
- 명시적으로 지시하지 않으면 코드를 리팩터링하거나 개선하지 않습니다.
- 변경을 할 때마다 모델에게 해당 부분에 개선을 적용하도록 요청하세요—특히 검증 관련(테스트, 타입 어노테이션, 린트 규칙 등) 부분에 대해 강조합니다.
7. 변경 위험이 제한 요인
- 코드는 이제 저렴합니다; 우리는 더 많이 실험하고 코드가 “오래됐다”거나 복잡하다고 해서 큰 변화를 회피하지 말아야 합니다.
- 대규모 변경의 주요 장애물은 리그레션 위험입니다.
- 견고한 검증 루프(포괄적인 테스트, 정적 분석, 지속적 통합)가 그 위험을 완화하는 핵심입니다.
훌륭한 테스트 관행(드물지만)이 있더라도, 코드와 변경이 많아질수록 버그와 위험도 늘어납니다—기업은 그 위험을 받아들이고 관리해야 합니다.
Production‑Ready AI‑Assisted Development 체크리스트
| 영역 | 작업 항목 |
|---|---|
| Architecture | 순환 의존성을 끊고, 명확한 모듈 경계를 정의합니다. |
| Rewrite Decision | 의도를 요약하고 현재 상태를 문서화한 뒤, 부채가 코드의 30 %를 초과하면 새로운 모듈을 시작합니다. |
| Verification Loop | 변경마다 테스트, lint 설정, 타입 정의, CI 상태를 커밋합니다. |
| Testing | 새로운 기능마다 최소 하나의 단위 테스트와 하나의 통합 테스트를 확보합니다. |
| Bottleneck Reduction | CI를 병렬화하고, 증분 빌드를 사용하며, 코드 리뷰 체크를 자동화합니다. |
| Model Prompting | 모델에게 리팩터링, 타입 힌트 추가, 테스트 커버리지 향상을 명시적으로 요청합니다. |
| Risk Management | 기능 플래그와 카나리 릴리스를 사용하고, 회귀 테스트 커버리지를 80 % 이상 유지합니다. |
이러한 제약을 해결하고 위 체크리스트를 적용하면, 프로덕션 코드베이스에서 AI‑지원 개발을 더 빠르고 안전하며 유지보수하기 쉬워집니다.
Conclusion
당신은 뒤처진 것이 아닙니다—단순하게 유지하고, 한번 시도해 보며, 매일 개선해 나가세요. 선일이 말했을 때 더 좋게 들립니다:
“당신은 뒤처진 것이 아니니, 단순하게 유지하고, 한번 시도해 보며 매일 개선하세요…”