오스마니 기술 — AI 코딩, 바로 맡기면 어디서 새나 | DAKER 커뮤니티
커서가 깜박이는 프롬프트 창 앞에서 가장 쉬운 선택은 “전부 구현해 줘”라고 쓰는 일이다. 몇 분 뒤 코드가 쏟아지면 속도는 이긴 것처럼 보인다. 하지만 Addy Osmani가 2026년 AI 코딩 워크플로에서 먼저 세운 장면은 정반대다. 코드를 맡기기 전에 문제를 고정하고, 일을 잘게 나누고, 품질문을 닫아야 한다.
무엇 : 오스마니 블로그의 오늘 핵심은 AI 보조 코딩을 자동 조종이 아니라 구조화된 협업으로 다루는 방식이다. 그는 스펙과 계획을 먼저 만들고, 작업을 작은 단위로 나눈 뒤, 테스트와 자동화 피드백으로 루프를 닫는 흐름을 강조한다. Claude Code나 Codex도 판단을 대신하는 존재가 아니라 빠른 페어 프로그래머이며, 방향·맥락·감독은 사람이 제공해야 한다.
언제 쓰나 : 새 기능을 Claude Code에 맡기기 전에 요구사항이 흐릿하거나, 한 번에 큰 diff가 나올 위험이 있을 때 쓴다. 예를 들어 대시보드 필터를 추가한다면 “필터를 만들어 줘”가 아니라 데이터 모델, UI 상태, 테스트 기준, 실패 시 롤백 지점을 먼저 적는다. 그다음 첫 번째 slice만 맡기고 결과를 읽는다. 화면 속 속도가 실제 품질로 바뀌는 지점은 프롬프트가 아니라 작업 경계다.
핵심 원리
- 계획 없는 대형 요청은 모델이 한 번에 너무 많은 결정을 하게 만든다. 오스마니는 먼저 문제와 해법을 정의하고, 스펙과 계획으로 개발의 바닥선을 만들라고 설명한다.
- 작은 반복 단위는 사람이 이해할 수 있는 diff를 만든다. 각 chunk는 구현, 테스트, 리뷰가 같은 맥락 안에서 끝나야 한다.
- 품질 게이트는 에이전트의 양심이 아니라 환경의 구조다. lint, 테스트, CI, 리뷰 피드백을 루프에 넣으면 실패 출력이 다음 수정 입력이 된다.
- AI는 실력의 대체재가 아니라 증폭기다. 설계, 테스트, 코드 리뷰, 버전 관리 같은 기존 엔지니어링 습관이 약하면 혼란도 함께 커진다.
- 비유로 말하면, Claude Code는 빠른 조수석 운전자다. 목적지와 차선, 멈춰야 할 신호를 정하지 않으면 속도는 곧 위험이 된다.
적용 방법
- 프롬프트 첫 줄에 결과물이 아니라 문제를 쓴다. 사용자가 막힌 화면, 성공 조건, 하지 말아야 할 변경을 함께 적는다.
- 에이전트에게 바로 구현시키기 전에 read-only 계획을 요구한다. 파일 후보, 위험 지점, 테스트 전략이 보이면 그때 실행으로 넘긴다.
- 작업을 하나의 reviewable slice로 자른다. UI, API, 데이터 마이그레이션을 한 번에 맡기지 말고 첫 번째 경계만 끝낸다.
- 완료 조건은 “구현됨”이 아니라 증거로 닫는다. 테스트 결과, lint 결과, 스크린샷, 로그, 변경 요약 중 해당 작업에 맞는 증거를 요구한다.
- 실패한 루프는 프롬프트 탓으로만 남기지 않는다. 다음에도 같은 실수를 막을 규칙, 테스트, 체크리스트를 저장소에 남긴다.
실수 방지 체크는 짧게 닫아야 한다.
- 한 번에 300줄 넘는 diff가 예상되면 먼저 쪼갠다.
- 테스트를 고친 PR에서는 테스트 변경을 구현보다 먼저 읽는다.
- 에이전트가 “완료”라고 말해도 실행 증거가 없으면 아직 완료가 아니다.
이미지 차트 : 대표 이미지는 코드 생성 전에 멈춰 서는 장면을 잡았다. 설명 차트는 스펙, 작업 분할, 구현, 테스트 피드백, 인간 리뷰가 한 루프로 닫히는 순서를 보여준다. 핵심은 AI에게 더 긴 지시를 쓰는 것이 아니라, AI가 벗어나기 어려운 작업 경계를 먼저 세우는 것이다.
공식 검증 : Addy Osmani 공식 사이트의 기술 글 3개를 비공개로 대조했다. 확인 항목은 스펙 우선 계획, 작은 반복 단위, AI 실험용 worktree, 자동화된 품질 게이트, 인간 감독과 책임의 위치다. 공개 링크는 DAKER 정책에 맞춰 내부 디렉터리만 남긴다.