좋은 엔지니어링은 도구 선택으로 시작하지 않는다.
문제 정의와 성공 기준으로 시작한다.
요즘 팀에서 자주 보는 장면이 있다.
- 어떤 사람은 작업을 시작할 때 코드 범위·영향도·롤백을 먼저 본다.
- 어떤 사람은 “어떤 모델이 더 좋나요?” “플러그인 뭘 깔면 되나요?”부터 묻는다.
둘 다 AI 도구를 쓰지만 결과는 같지 않다.
전자는 실패를 줄이고, 후자는 그럴듯한 결과물과 재작업을 동시에 늘린다.
이 글은 사람을 비난하려는 글이 아니다.
최근 반복해서 본 패턴을 바탕으로, 문제 퍼스트와 툴 퍼스트의 차이, 그리고 팀이 착수 단계에서 고정해야 할 기준을 정리한다.
TL;DR
- AI 시대에도 시작점은 도구가 아니라 문제 정의다.
- 툴 퍼스트는 속도를 주지만, 방향이 비어 있으면 잘못된 방향으로 더 빨리 간다.
- 시니어의 역할은 “어떤 모델/플러그인”보다 무엇을·왜·지금 하는지를 날카롭게 고정하는 것이다.
- 착수 전 5문장 템플릿 하나만 있어도 에이전트·리뷰·CI가 제 역할을 한다.
왜 지금 이 얘기인가
최근 테스트·CI와 하네스 글에서 같은 결론이 반복됐다.
- AI는 생성만 빠르게 한다.
- 팀 속도는 검증 루프와 문제 정의가 결정한다.
- “완료됐다”고 말하는 출력을 잡아내는 건, 결국 명세가 있는지다.
커뮤니티에서는 Codex vs Claude 비교가 늘지만, 실무에서 비싼 건 모델 차이가 아니라 착수 문장이 비어 있는 순간이다.
Twelve Ways 큐레이션이 짚듯, 생성량·PR 수만 보면 Goodhart의 법칙에 걸린다. 문제를 먼저 정의하지 않으면 “더 많이 생성했다”는 착각만 커진다.
핵심 오해 하나
“도구를 더 잘 쓰면 결과가 좋아진다.”
아니다. 도구는 실행 속도를 올린다. 문제 정의가 없으면 잘못된 방향으로 더 빨리 간다.
팀이 흔들리는 지점은 보통 모델 성능이 아니다.
“일단 결과물부터 뽑아볼게요”가 “무엇을 해결하는 작업인지”보다 먼저 나올 때다.
문제 퍼스트 vs 툴 퍼스트
| 구분 | 문제 퍼스트 | 툴 퍼스트 |
|---|---|---|
| 첫 질문 | 문제·범위·성공 기준은? | 어떤 모델/플러그인이 좋나? |
| 시작 전 | 영향 코드·화면·롤백 경로 | 설치·프롬프트·에이전트 호출 |
| 실패 시 | “정의가 부족했는가?” | “도구가 부족했는가?” |
| AI와 결합 | 보장 조건 → 에이전트 → CI | 에이전트 출력 → 사후 설명 |
툴 퍼스트 자체가 악은 아니다. 질문 순서가 바뀌는 순간이 문제다.
툴 퍼스트 착수 신호 — 아래 중 두 개 이상이면 hold.
- “왜 하는지”보다 “어떻게 돌릴지”를 먼저 말한다.
- 코드 범위·영향도·검증 기준이 PR/스레드에 없다.
- 결과물은 있는데 설명 책임이 비어 있다.
착수 전 5문장 템플릿
작업·에픽·에이전트 세션 시작 전, 다섯 줄을 채우지 못하면 시작하지 않는다.
- 이번 작업의 문제는
___다. - 이번에 해결하는 범위는
___이고, 하지 않는 범위는___다. - 성공 기준은
___다. - 영향 범위(코드/화면)는
___다. - 실패 시 롤백/대안은
___다.
PR template 상단, 티켓 설명, Slack 스레드 첫 메시지 — 어디에든 붙일 수 있다.
위 표의 “문제 퍼스트” 열과 같은 내용이다. 다섯 줄이 있으면 툴은 강해지고, 없으면 툴은 팀을 피곤하게 만든다.
시니어가 실제로 하는 일
AI 시대에도 시니어의 본질은 크게 바뀌지 않았다. 다만 순서가 더 중요해졌다.
- 문제를 구조화한다 — 한 문장 요약 + 범위 닫기
- 리스크를 먼저 본다 — 결제·데이터·인증 등 손실 큰 경계
- 검증 루프를 설계한다 — lint/test/리뷰 순서
- 예외를 기록한다 —
이유 / 생략 / 후속3줄 - 도구를 붙인다 — 위 네 가지가 있을 때만
AI 스킬은 코드다에서 쓴 것처럼, 스킬·하네스·플러그인은 실전에서 틀린 걸 정의에 다시 써 넣는 루프다. 문제 정의 없이 스킬만 늘리면 “규칙은 많은데 방향은 없는” 팀이 된다.
순서가 맞으면 도구는 배율이 되고, 순서가 없으면 재작업 가속기가 된다.
에이전트에게도 순서가 있다
테스트·CI 글에서 “보장 조건을 사람이 먼저 써야 한다”고 했다. 에이전트 호출도 같다.
나쁜 예:
“이 컴포넌트 리팩터링해줘.”
좋은 예:
“
CheckoutSummary에서formatPrice(null)은 throw 대신'0'을 반환해야 한다.
범위는 이 파일 + 호출하는 2개 페이지. snapshot 테스트 금지.
완료 기준: tsc + 기존 unit 3개 green.”
보장 조건 한 줄이 없으면, 에이전트는 그럴듯하고 빠르게 틀린 방향으로 간다.
문제 퍼스트는 습관이자 프롬프트 첫 문단이어야 한다.
실제 운영 장면 (익명화)
장면 A — 문제 퍼스트 리뷰
CI 파이프라인 PR. 타이밍·중복 방지·분기 처리가 섞여 있어, diff만 보면 “왜 이렇게?”가 바로 안 잡힌다.
리뷰어는 Approve/Comment 결론을 먼저 쓰고, 변경 근거를 항목별로 나눴다. “머지 후 staging에서 job X 한 번 더 도는지” 같은 비블로커 검증도 PR에 남겼다.
머지 판단이 빨라졌고, 후속 확인 포인트가 채널에 남았다. “리뷰를 잘했다”기보다 근거로 작업 상태를 전달한 케이스다. 리뷰 스레드 운영 체크리스트와 같은 축이다.
장면 B — 툴 퍼스트 착수
신규 작업이 넘어왔는데, “무엇을 고칠지”보다 에이전트 설치·프롬프트 공유가 먼저 올라왔다.
PR은 400줄 diff인데, 티켓·스레드 어디에도 성공 기준이 없었다.
방향 재합의 → 범위 틀어짐 → 재작업. “도구가 없어서”가 아니라 착수 조건이 비어서 난 비용이다.
팀 운영 규칙 3개 (제안)
- 5문장 없으면 착수 hold — 1번(문제)과 3번(성공 기준)이라도 비어 있으면
- 리뷰 포맷 고정 —
결론 + 근거 + 다음 액션 - 예외는 3줄 —
이유 / 생략 범위 / 후속 티켓
규칙은 많을수록 좋은 게 아니다. 착수·리뷰·예외 세 지점만 고정해도 AI 도입 이후 드리프트가 줄어든다.
기록할 때 쓸 문장
사람을 평가하는 언어는 쉽다. 팀을 바꾸는 언어는 다르다.
| 대신 이렇게 말하지 말고 | 이렇게 기록한다 |
|---|---|
| “누가 못한다” | “어떤 착수 조건이 비어 있었는가” |
| “도구를 안 쓴다” | “보장 조건 없이 에이전트를 돌렸는가” |
| “시니어가 없어서” | “문제 정의를 누가 고정할 것인가” |
개인을 공격하지 않고도 기준은 날카로울 수 있다.
바로 적용 체크리스트
- PR template 상단에 5문장 템플릿 칸 추가
- 에이전트 프롬프트 첫 줄에 보장 조건 1문장 필수
- “일단 결과물” PR은 5문장 채울 때까지 merge hold
- 주간 회고에 툴 퍼스트 착수 패턴 1건 (이름 없이)
- 시니어 리뷰는 결론 + 근거 + 다음 액션으로 통일
마치며
툴은 모두에게 열려 있다. 문제를 먼저 정의하는 습관은 여전히 차이를 만든다.
하네스·CI·스킬은 문제가 정의된 뒤에 붙는 레이어다. 순서를 바꾸면 도구는 팀을 살리는 게 아니라 재작업을 가속한다.
한 줄 결: 도구가 팀을 살리는 게 아니다. 문제를 먼저 정의하는 습관이 도구를 살린다.
읽을 거리 (시리즈)
- 테스트와 CI가 진짜 생산성인 이유 — 보장 조건 · 검증 속도
- 「하네스 다 했어요」는 아직 시작 — 도구는 문제 정의 다음 레이어
- AI 스킬은 코드다 — 쓰면서 고쳐야 산다 — 실전 루프
- 리뷰 스레드 운영 체크리스트 — 근거 기반 커뮤니케이션
- Twelve Ways to Be Wrong About AI-Assisted Coding (Third Bit) — 측정·생성량 함정 (원문)
- Goodhart’s law (Wikipedia) — “측정 대상이 목표가 되면 왜곡된다”
특정 회사·특정 팀원·특정 사건을 지칭하지 않습니다.