AI 코딩을 바로 맡기기 전에 필요한 것들: Addy Osmani가 짚은 작업 경계와 품질 루프 | DAKER 커뮤니티
AI 코딩 도구가 익숙해질수록 가장 먼저 하게 되는 일은 프롬프트 창에 구현을 통째로 맡기는 일일지 모릅니다. 몇 분 만에 코드가 쏟아지면 개발 속도가 빨라진 듯 보이지만, 그 속도가 곧 품질을 뜻하지는 않습니다.
Addy Osmani가 2026년 AI 코딩 워크플로에서 먼저 강조한 지점도 여기에 있습니다. 코드를 맡기기 전에 문제를 분명히 하고, 작업을 잘게 나누고, 테스트와 리뷰로 결과를 닫아야 한다는 것입니다. AI를 자동 조종 장치처럼 쓰기보다, 구조화된 협업 상대로 다루는 태도가 중요하다는 이야기입니다.
AI 코딩의 핵심은 구현보다 작업 경계에 있습니다
오스마니가 말하는 오늘의 핵심은 AI 보조 코딩을 자동화된 대행이 아니라 구조화된 협업으로 다루는 방식입니다. 먼저 스펙과 계획을 만들고, 작업을 작은 단위로 나눈 뒤, 테스트와 자동화된 피드백으로 루프를 닫는 흐름이 중심입니다.
이 관점에서 Claude Code나 Codex는 판단을 대신하는 존재가 아닙니다. 빠르게 함께 일하는 페어 프로그래머에 가깝고, 방향과 맥락, 감독은 사람이 맡아야 합니다.
화면 속 속도가 실제 품질로 바뀌는 지점은 프롬프트가 아니라 작업 경계다.
새 기능을 Claude Code에 맡기기 전에 요구사항이 흐릿하거나, 한 번에 큰 diff가 나올 위험이 있을 때 특히 이 방식이 유효합니다. 예를 들어 대시보드 필터를 추가한다면, 단순히 필터를 만들어 달라고 하기보다 데이터 모델, UI 상태, 테스트 기준, 실패 시 롤백 지점을 먼저 적어 두는 편이 좋습니다. 그다음 첫 번째 slice만 맡기고 결과를 읽는 흐름이 더 안정적입니다.
왜 큰 요청이 위험해지는가
계획 없는 대형 요청은 모델이 한 번에 너무 많은 결정을 하게 만듭니다. 문제 정의, 해법 선택, 파일 구조, 예외 처리, 테스트 방식까지 한 번에 떠안게 되면, 결과는 빨라 보여도 사람이 검토하기 어려운 형태로 커지기 쉽습니다.
오스마니는 먼저 문제와 해법을 정의하고, 스펙과 계획으로 개발의 바닥선을 만들어야 한다고 설명합니다. 이 바닥선이 있어야 AI가 어디까지 바꿔도 되는지, 무엇은 건드리면 안 되는지 경계가 생깁니다.
AI는 판단을 대신하는 존재가 아니라 빠른 페어 프로그래머이며, 방향과 책임은 사람이 제공해야 한다.
작은 반복 단위가 중요한 이유도 같습니다. 작업을 잘게 나누면 사람이 이해할 수 있는 diff가 만들어지고, 각 chunk 안에서 구현과 테스트, 리뷰를 같은 맥락으로 묶을 수 있습니다. 반대로 UI, API, 데이터 마이그레이션이 한 번에 섞이면 속도는 나더라도 검토 비용이 급격히 커집니다.
품질 게이트는 AI의 성향이 아니라 환경의 구조입니다
오스마니가 강조하는 또 하나의 축은 품질 게이트입니다. lint, 테스트, CI, 리뷰 피드백은 에이전트의 양심을 기대하는 장치가 아니라, 실패를 다시 입력으로 돌려보내는 구조입니다. 이 루프가 있어야 잘못된 구현이 다음 수정으로 이어질 수 있습니다.
결국 AI는 실력의 대체재가 아니라 증폭기입니다. 설계, 테스트, 코드 리뷰, 버전 관리 같은 기존 엔지니어링 습관이 약하면 혼란도 함께 커집니다. 반대로 이런 습관이 이미 자리 잡은 팀이라면 AI는 반복 작업을 빠르게 줄여 주는 도구가 됩니다.
품질 게이트는 에이전트의 양심이 아니라 환경의 구조다.
오스마니의 비유를 빌리면, Claude Code는 빠른 조수석 운전자에 가깝습니다. 목적지와 차선, 멈춰야 할 신호를 정하지 않으면 속도는 곧 위험이 됩니다.
실제로 적용할 때의 흐름
적용 방법도 복잡하지 않습니다. 먼저 프롬프트 첫 줄에 결과물이 아니라 문제를 적습니다. 사용자가 어디에서 막히는지, 성공 조건이 무엇인지, 바꾸지 말아야 할 부분이 무엇인지 함께 적어 두면 됩니다.
그다음에는 에이전트에게 곧바로 구현을 맡기기보다 read-only 계획을 먼저 요구하는 편이 좋습니다. 파일 후보, 위험 지점, 테스트 전략이 보이면 그때 실행 단계로 넘기는 방식입니다. 이렇게 하면 구현 전에 경로를 검토할 수 있습니다.
작업은 하나의 reviewable slice로 자르는 것이 중요합니다. UI와 API, 데이터 마이그레이션을 한 번에 맡기기보다 첫 번째 경계만 끝내는 식이 더 안전합니다. 완료 조건도 단순히 구현됨으로 두기보다 테스트 결과, lint 결과, 스크린샷, 로그, 변경 요약처럼 증거로 닫는 편이 좋습니다.
실패한 루프가 생겼을 때도 프롬프트 탓으로만 남기지 않는 것이 중요합니다. 다음에도 같은 실수를 막을 수 있도록 규칙, 테스트, 체크리스트를 저장소에 남겨 두면 반복 오류를 줄일 수 있습니다.
짧게 점검할 수 있는 기준
실수 방지 체크는 짧게 닫는 편이 효과적입니다. 한 번에 300줄 넘는 diff가 예상되면 먼저 쪼개고, 테스트를 고친 PR에서는 테스트 변경을 구현보다 먼저 읽고, 에이전트가 완료라고 말해도 실행 증거가 없으면 아직 완료가 아닌 것으로 보는 기준이 여기에 해당합니다.
결국 중요한 것은 더 긴 프롬프트가 아닙니다
이 글의 요지는 AI에게 더 긴 지시를 쓰는 데 있지 않습니다. AI가 벗어나기 어려운 작업 경계를 먼저 세우고, 그 안에서 계획과 구현, 테스트, 인간 리뷰가 한 루프로 닫히게 만드는 데 있습니다.
속도는 이미 충분히 빠릅니다. 이제 차이를 만드는 것은 얼마나 많이 맡기느냐보다, 어디까지 맡기고 무엇으로 검증하느냐에 가깝습니다.
참고 자료
여러분은 AI 코딩 도구에 작업을 맡길 때 어떤 기준으로 작업 경계와 완료 조건을 정하고 있나요?