AI를 잘 쓰려면 개발을 잘 해야 한다
AX는 DX의 상위집합이다 — DX 없는 AX는 모래 위의 성이다
Anthropic 2026 Report: 개발자가 60% 위임하지만 0~20%만 신뢰 — 이 "위임 격차"의 원인은 AI가 아니라 DX입니다
AI가 수백 줄을 생성하지만, diff를 읽을 수 없고, 브랜치를 나눌 줄 모르고, 롤백을 못 한다. AI 코드가 통제 불능의 블랙박스가 된다.
AI는 "동작하는 것 같은" 코드를 만든다 — 업계에서 "Code Slop"이라 부르는 현상이다. 테스트 습관이 없으면 "AI 코드를 AI에게 검증시키는" 무한 루프에 빠진다. 프로덕션에서 터지고 나서야 안다.
"이거 고쳐줘"를 AI에게 던지면, AI는 코드를 더 복잡하게 만들어 "다른 방식으로" 깨뜨린다. 핑퐁 안티패턴의 시작이다.
"앱 만들어줘"는 프롬프트가 아니라 기도다. 문제를 분해할 수 없으면, AI에게 줄 수 있는 건 모호한 요구사항뿐이고 돌아오는 건 모호한 결과물이다.
좋은 프롬프트는 좋은 질문이다. Martin Fowler는 컨텍스트 엔지니어링이 AI 코딩에서 10x와 2x의 차이를 만드는 핵심 스킬이라 강조한다.
에이전틱 코딩 도구 대부분은 CLI 기반이다. 터미널, 환경 변수, 패키지 매니저를 다룰 줄 모르면 진입 장벽이 아니라 벽이다.
Fortune이 "감독자 계층의 부상"이라 부르는 변화 — Understanding · Directing · Verifying 3계층 스킬이 필요하다
branch, merge, resolve conflicts
AI 코드의 diff 검토, 실험 격리(worktree), 즉시 롤백, 커밋 히스토리를 AI 컨텍스트로 활용
git diff로 정확히 무엇이 바뀌었는지 보는 게 AI 코드를 한 줄씩 읽는 것보다 빠르다. 커밋 메시지와 히스토리는 AI에게 "이 프로젝트에서 뭘 했는지"를 알려주는 컨텍스트가 된다.
유닛 테스트, 통합 테스트, TDD
AI 생성 코드의 자동 검증, 기대 결과 기반 assertion, 회귀 테스트로 AI 변경 안전성 확보
AI에게 코드를 생성시키기 전에 테스트를 먼저 작성하라. 테스트가 기대 결과를 정의하면, AI의 출력이 맞는지 틀린지를 즉시 판단할 수 있다.
PR 리뷰, 페어 프로그래밍
AI 생성 코드를 비판적으로 검토, "왜 이 구현인가" 질문, 보안·성능·유지보수성 체크
AI 코드를 "맞는 것 같으니까" 수락하는 건, 인턴이 짠 코드를 리뷰 없이 머지하는 것과 같다. AI 코드일수록 더 엄격하게 리뷰해야 한다.
빌드, 테스트, 린트, 배포 자동화
AI 생성 코드 포함 자동 테스트, 프리커밋 훅으로 품질 게이트, AI 워크플로우의 파이프라인화
CI가 없으면 AI가 만든 코드가 기존 코드를 깨뜨리는 걸 배포 후에야 알게 된다. CI는 AI 코드의 자동 안전장치다.
README, API 문서, 코드 주석
CLAUDE.md, 시스템 프롬프트, 구조화된 컨텍스트, 프롬프트 자산화
과거의 문서화는 "사람이 읽기 위한 것"이었다. 지금의 컨텍스트 엔지니어링은 "AI가 정확하게 이해하기 위한 것"이다. 모범사례에 따르면, 효과적인 CLAUDE.md는 프로젝트 개요 → 아키텍처 원칙 → 컨벤션 → 테스트 전략 → 명령어 → 안티패턴 순으로 구성한다.
관심사 분리, 레이어드 아키텍처, 마이크로서비스
AI가 이해하고 수정하기 쉬운 명확한 모듈 경계, 파일 하나가 하나의 책임
AI는 1,000줄짜리 God 클래스를 이해하는 것 같지만 수정할 때 다른 부분을 깨뜨린다. 200줄 이하의 집중된 모듈은 AI가 정확하게 이해하고 수정할 수 있다.
셸 명령어, 스크립트, 터미널 워크플로우
MCP 서버 설정, 도구 정의, 에이전트에게 권한과 도구 부여
Claude Code, Codex, aider — 모두 터미널에서 돌아간다. MCP 서버를 설정하고, 도구를 정의하고, 에이전트의 권한을 관리하는 것이 새로운 "개발 환경 설정"이다.
브레이크포인트, 로깅, 프로파일링
AI 환각 식별, 프롬프트 디버깅, AI와 함께하는 원인 추론 (단, AI가 만든 코드의 디버깅은 직접)
디버깅은 AI에게 위임하면 안 되는 대표적인 영역이다. 하지만 디버깅 과정에서 AI를 활용할 수는 있다. 이 차이를 아는 것 자체가 DX 역량이다.
Docker, 환경 변수, 패키지 매니저, 가상 환경
API 키 관리, 모델 설정, 샌드박스 환경, 도구 권한 관리
AI 도구를 쓰려면 API 키를 안전하게 관리해야 하고, 에이전트가 파일 시스템에 접근할 때 적절한 샌드박스를 설정해야 한다.
REST API, GraphQL, SDK 설계
함수 호출 스키마, MCP 프로토콜, 구조화된 출력 정의
AI에게 도구를 주려면, 그 도구의 인터페이스를 명확하게 정의해야 한다. 파라미터 이름, 타입, 설명 — 이 모든 것이 AI가 도구를 올바르게 사용할지를 결정한다.
"나는 DX 시대를 겪었으니 괜찮다"고 생각하는 시니어도 주의가 필요합니다
| 영역 | 2020년 DX | 2026년 AX 시대 DX |
|---|---|---|
| 문서화의 소비자 | 사람 (동료, 미래의 나) | 사람 + AI |
| 코드 리뷰 대상 | 동료가 작성한 코드 | 동료 + AI가 생성한 코드 |
| 테스트의 목적 | 내 코드의 정확성 확인 | 내 코드 + AI 출력의 정확성 확인 |
| CLI 활용 | 개발 편의성 | 에이전트 운영의 필수 조건 |
| 아키텍처 기준 | 사람이 유지보수하기 좋은 구조 | 사람 + AI가 이해·수정하기 좋은 구조 |
AX를 하면서 DX를 배운다 — 병렬 학습 전략
AI 프로젝트에서 브랜치 워크플로우 적용. AI가 코드를 생성할 때마다 commit하고, diff를 읽고, 브랜치를 나눈다. GUI로 하던 작업 하나를 터미널로 전환.
테스트 선행 → AI 구현 패턴 3회 이상 실행. 프로젝트에 pre-commit hook이 없다면 린트 + 타입 체크만이라도 설정.
메인 프로젝트에 CLAUDE.md 작성 (1,500 토큰 이하 목표). AI에게 줄 컨텍스트를 정리하는 과정이 곧 프로젝트를 이해하는 과정.
가장 큰 파일 하나를 AI와 함께 분리 리팩터링. AI 코드 수락 전 리뷰 체크리스트 적용: 왜 이 방식인지, 보안 취약점은 없는지, 엣지 케이스는 처리하는지.
각 항목 1점. 솔직하게 체크하세요.
git diff를 읽고 AI 코드 변경을 판단할 수 있다