Skip to content
←

Split View: AI 코딩 도구와 잘 일하는 다섯 가지 습관

|

AI 코딩 도구와 잘 일하는 다섯 가지 습관

들어가며 — 데이터는 나왔고, 남은 건 행동이다

앞선 글 AI는 정말 개발자를 빠르게 만드는가에서, 잘 설계된 무작위 대조 실험 두 개가 정반대의 답을 냈다는 이야기를 했습니다. 한쪽에서는 개발자가 55.8% 빨라졌고, 다른 쪽에서는 19% 느려졌습니다.

그 글이 "무엇이 측정되었는가"였다면, 이 글은 "그래서 내일 아침에 뭘 다르게 할 것인가" 입니다.

아래 다섯 개는 취향이 아니라 규칙입니다. 각각은 실제 연구에서 끌어냈고, 각각은 당신이 2주 안에 반증할 수 있는 한 줄로 끝납니다.

습관 1 — 익숙함과 검증 비용으로 작업을 고른다

METR은 19% 슬로다운을 설명할 만한 요인 다섯 개를 추렸습니다. 그중 둘이 개발자와 코드의 관계 에 관한 것입니다. 하나는 저장소에 대한 높은 친숙도, 다른 하나는 암묵적 저장소 맥락 — 문서화되지 않아 모델이 접근할 수 없는 지식입니다.

가장 날카로운 대목은 이것입니다. 개발자들은 자기가 더 익숙한 과제에서 더 많이 느려졌습니다. 익숙함이 방패가 아니라 세금이 된 것입니다.

정반대 방향에 Copilot 실험이 있습니다. 그린필드였고, 명세가 명확했고, 검증이 몇 초면 끝났습니다. 그리고 이득은 경력이 짧은 개발자에게서 가장 컸습니다.

두 결과를 한 문장으로 합치면 이렇게 됩니다. AI는 당신이 갖지 못한 맥락을 채워 줄 때 이기고, 당신이 이미 가진 맥락을 따라잡아야 할 때 집니다. 그러니 축은 두 개입니다.

검증이 싸다 (초/분)검증이 비싸다 (일/달)
낯선 영역최적 구간. 마음껏 쓰세요.가장 위험한 칸. 이해 못 하면 리뷰도 못 합니다.
익숙한 영역무난. 이득도 손해도 작습니다.METR의 칸. 직접 쓰는 게 빠릅니다.

오른쪽 위 칸이 진짜 함정입니다. 여기서 나온 AI 출력은 조용히 부채가 되고, 청구서는 몇 달 뒤에 옵니다.

규칙: 위임하기 전에 두 질문에 한 줄로 답을 적으세요. (1) 이게 틀렸다면 나는 언제 알게 되는가? (2) 나는 틀린 답을 알아볼 수 있는가? 2번이 "아니오"이고 1번이 "몇 달 뒤"라면, 도구가 아니라 학습을 먼저 넣으세요.

습관 2 — 리뷰할 수 없는 것은 머지하지 않는다

METR 참가자들은 AI가 생성한 코드의 44% 미만만 받아들였습니다. 그리고 56%는 AI 코드를 정리하려면 큰 수정이 필요했다고 답했습니다. 생성은 싸졌지만, 읽고 판단하고 버리는 시간은 그대로 남습니다 — 아무 산출물도 남기지 않은 채로요.

2025년 스택오버플로 설문(AI 섹션 기준 3만 명대 응답)이 같은 이야기를 다른 각도에서 합니다.

  • 가장 큰 불만은 66% 가 꼽은 "거의 맞지만 완전히 맞지는 않은" 답입니다.
  • 두 번째는 45.2% — AI가 만든 코드를 디버깅하는 게 더 오래 걸린다 입니다.
  • 그리고 75.3% 가, AI의 답을 믿지 못할 때 결국 사람에게 묻는다 고 답했습니다.

핵심은 이겁니다. 명백히 틀린 코드는 싸게 걸러집니다. 비싼 것은 리뷰를 통과할 만큼 그럴듯하고, 대가를 치를 만큼 틀린 코드입니다. 즉 리뷰는 일이 끝난 뒤의 잡무가 아니라, 일 그 자체 입니다.

흔한 자기기만 하나만 짚겠습니다. 모델에게 "네가 짠 diff를 설명해 봐"라고 시키는 것은 검증이 아닙니다. 그 설명 역시 생성물입니다. 진짜 검증은 실행하고, 테스트하고, 당신이 아는 불변식과 대조하는 것 뿐입니다.

규칙: 사람이 쓴 PR에 적용하는 크기 상한을 AI가 쓴 PR에도 똑같이 적용하세요. 리뷰가 불가능할 만큼 큰 diff는 머지가 불가능한 diff입니다. 그리고 리뷰 시간을 캘린더에 실제로 예산으로 잡으세요.

검증이 병목이라면 읽기 쉬운 코드는 취향이 아니라 처리량 문제입니다 — AI가 유지보수해도 사람을 위해 쓴다와 LLM 번아웃에서 다룬 그대로입니다.

습관 3 — 산문 규칙 대신 기계 가드레일을 세운다

앤트로픽의 Building Effective Agents는 도구 설계에서 포카요케(poka-yoke) 를 권합니다. 인자 자체를 바꿔서 "실수하기 더 어렵게" 만들라는 것입니다. 문서에 나오는 예시가 정확히 이 정신입니다 — 모델이 자꾸 상대 경로를 틀리면, 프롬프트로 주의를 주는 대신 절대 경로를 요구하도록 도구 시그니처를 바꿉니다. 같은 문서는 사람을 위한 인터페이스(HCI)에 쏟는 만큼 에이전트를 위한 인터페이스(ACI)에도 투자하라고, 그리고 도구를 실제로 돌려 보며 어떤 실수를 하는지 관찰하라고 말합니다.

여기서 나오는 원칙은 단순합니다. 규칙 문서의 한 문장은 요청이고, 실패하는 타입 체크는 사실입니다. 산문은 확률적으로 지켜지고, 컴파일러는 결정적으로 지켜집니다.

// 산문 규칙: "통화 값에 raw number를 쓰지 마세요"  → 모델이 지킬 수도, 안 지킬 수도 있습니다.
// 기계 가드레일: 애초에 통과하지 못하게 만듭니다.
type Cents = number & { readonly __brand: 'Cents' }

export function charge(amount: Cents): Promise<Receipt> {
  /* ... */
}

charge(1000) // 타입 에러. 사람이든 모델이든 여기서 막힙니다.
charge(toCents(1000)) // 통과.

이건 AI 시대에 새로 생긴 원칙이 아닙니다. 다만 코드 생산량이 늘어나면서 가드레일의 수익률이 급격히 올라갔을 뿐 입니다.

규칙: 같은 실수를 모델에게 두 번 지적했다면, 규칙을 한 줄 더 쓰지 말고 체크를 하나 만드세요. 타입, 린트 규칙, 테스트, CI 게이트, 더 좁은 함수 시그니처 중 하나로 옮기면 됩니다. 옮길 수 없다면 그건 애초에 사람에게도 지켜지지 않던 규칙입니다.

습관 4 — 전부가 아니라 맞는 조각을 준다

METR이 짚은 요인 중 하나가 암묵적 저장소 맥락 이었습니다. 5년치 경험을 가진 개발자의 머릿속에는 있지만 어디에도 적혀 있지 않은 지식 말입니다.

여기서 흔한 오해가 나옵니다. "그럼 다 넣어 주면 되겠네." 아닙니다. 저장소 파일 200개를 컨텍스트에 밀어 넣는 것은 불변식을 알려주는 일이 아닙니다. 불변식은 대개 한 문장이면 됩니다 — "이 테이블은 append-only다", "이 함수는 트랜잭션 안에서만 호출된다", "이 캐시는 배포 시점에 비워지지 않는다". 200개 파일은 이걸 말해 주지 않고, 한 문장은 말해 줍니다.

앤트로픽 문서도 같은 방향입니다. 가장 단순한 해법에서 시작하고 필요할 때만 복잡도를 올리라고, 많은 경우 검색과 예시를 붙인 단일 호출이면 충분하다고 말합니다. 컨텍스트 엔지니어링은 더 많이 넣는 기술이 아니라 무엇을 뺄지 정하는 기술 입니다.

규칙: 작업을 시작하기 전에, 이 코드를 처음 보는 사람이 어길 만한 제약 3~5개 를 적으세요. 그 목록이 당신의 컨텍스트입니다. 못 적겠다면, 당신은 습관 1의 위험한 칸에 있는 겁니다.

부수 효과가 하나 있습니다. 그 목록은 대개 팀 문서로 그대로 쓸 수 있습니다. 모델에게 설명하려고 억지로 적어 낸 암묵지는, 사실 당신의 동료도 갖고 있지 않던 지식입니다.

습관 5 — 느낌 말고 자기 처리량을 잰다

METR에서 가장 불편한 숫자는 19%가 아닙니다. 개발자들은 시작 전에 AI가 자신을 24% 빠르게 해줄 거라 예측했고, 실제로 19% 느려지는 경험을 한 뒤에도 자신이 20% 빨라졌다 고 추정했습니다. 사후 회고조차 부호가 반대였던 것입니다. 경제학·머신러닝 전문가들의 예측도 방향부터 틀렸습니다.

이유는 단순합니다. 생성은 눈에 보이고 검증은 눈에 보이지 않기 때문입니다. 모델이 3초 만에 40줄을 뱉는 순간은 기억에 남고, 그걸 읽고 절반을 버리는 20분은 그냥 "일하는 중"으로 느껴집니다.

그러니 설문과 회고는 이 주제에서 가장 못 믿을 도구입니다. 정확히 그 이유로, DORA와 스택오버플로 같은 자기보고 데이터도 낙관 쪽으로 기울어 있다고 가정하고 읽어야 합니다.

규칙: 2주, 두 칸이면 됩니다. 작업 시작 전에 예상 시간을 적고, 끝난 뒤에 실제 시간과 AI 사용 여부를 적으세요. 단, 재는 것은 "첫 diff까지"가 아니라 "머지되어 안정될 때까지" 입니다. "거의 맞지만 완전히 맞지는 않은" 코드의 세금은 언제나 초안 이후에 청구되기 때문입니다.

AI가 정말로 강한 자리

이 글이 "AI를 쓰지 마라"로 읽히면 곤란하므로, 이득이 진짜인 자리를 분명히 적어 둡니다.

  • 그린필드에 명세가 뚜렷한 일. Copilot 실험의 개발자 95명은 자바스크립트로 HTTP 서버를 짰습니다. Copilot 그룹은 평균 1시간 11분, 대조군은 2시간 41분이 걸렸습니다. 이 숫자는 진짜입니다.
  • 낯선 언어·API·프레임워크. 모델은 당신보다 그 문서를 많이 읽었습니다. 습관 1의 최적 구간입니다.
  • 검증이 몇 초인 것들. 일회성 스크립트, 스캐폴딩, 테스트 픽스처, 정규식, 데이터 변환. 틀리면 즉시 티가 납니다.
  • 읽는 방향의 작업. 남이 쓴 코드를 이해할 때. 모델의 주장을 코드에 곧바로 대조할 수 있으니 검증이 쌉니다.
  • 이미 테스트가 촘촘한 영역의 기계적 대량 변경. 가드레일이 이미 서 있는 곳입니다.

그리고 경력이 짧은 개발자일수록 이득이 컸다는 Copilot 실험의 결과는, 저자들 표현대로 소프트웨어 개발로 진입하려는 사람들에게 좋은 신호입니다.

이 규칙들을 과신하지 않기 위해

METR의 한계. 참가자 16명, 과제 246개, 2025년 상반기 모델, 성숙한 대규모 오픈소스 저장소. 저자들 스스로 이 연구가 "AI가 대부분의 개발자를 빠르게 하지 못한다"거나 "기존 AI를 더 잘 쓸 방법이 없다"는 것을 보여주지 않는다 고 명시합니다.

더 중요한 건, METR이 스스로 설계를 바꾸고 있다는 사실입니다. 2026년 2월 후속 글에서 그들은 심각한 선택 편향을 인정했습니다. 시간당 50달러를 줘도 AI 없이 일하기 싫어 참여를 거절한 개발자들이 있었고, 개발자의 30~50%가 AI가 잘할 것 같은 과제를 아예 제출하지 않았으며, 여러 에이전트를 동시에 돌리는 워크플로에서는 시간 측정 자체가 깨졌습니다. 새 데이터는 오히려 속도 향상을 시사했지만, METR은 그것을 "현재 생산성 효과에 대한 신뢰할 수 없는 신호"라고 스스로 못 박았습니다.

Copilot 연구의 한계. 과제가 하나이고, 그린필드이며, 측정한 것은 완료 시간이지 품질도 유지보수성도 아닙니다. 저자 중 GitHub 소속이 있다는 점도 기록해 둘 만합니다.

설문의 한계. 스택오버플로는 자기보고입니다. 그리고 METR이 보여준 바로 그 이유로, 자기보고는 이 주제에서 가장 믿기 어려운 계기입니다.

그러니 위의 다섯 가지는 법칙이 아니라 현재 가용한 최선의 증거에서 끌어낸 휴리스틱 입니다. 당신의 로그로 반증해 보십시오. 그게 습관 5의 요점이기도 합니다.

마치며

다섯 개를 한 문장으로 줄이면 이렇습니다. AI는 당신이 갖지 못한 맥락을 채울 때 이기고, 당신이 이미 가진 맥락을 따라잡아야 할 때 집니다. 나머지 넷은 이 문장의 운영 세부사항입니다 — 그 문장에 맞게 작업을 고르고(1), 검증을 일급으로 예산에 넣고(2), 검증을 기계에 넘기고(3), 맥락을 압축해서 전달하고(4), 그게 실제로 먹히는지 재는 것(5).

그리고 마지막 하나. 이 글의 어떤 규칙도 당신의 2주치 로그를 이기지 못합니다. 다섯 번째 습관이 마지막에 있는 건 우연이 아닙니다.

참고 자료

Five Habits for Working Well with AI Coding Tools

Introduction — The Data Is In; What Is Left Is Behavior

In an earlier post, Does AI Actually Make Developers Faster, I walked through two well-designed randomized controlled trials that reached opposite conclusions. In one, developers were 55.8% faster. In the other, they were 19% slower.

That post was about what got measured. This one is about what you do differently tomorrow morning.

The five items below are rules, not vibes. Each is derived from an actual study, and each ends in one line you could falsify within two weeks.

Habit 1 — Pick Tasks by Familiarity and Cost of Verification

METR narrowed down five factors that likely contribute to the 19% slowdown. Two of them are about the relationship between the developer and the code: high developer familiarity with the repository, and implicit repository context — the undocumented knowledge the model has no way to reach.

The sharpest finding is this one: developers were slowed down more on tasks they knew better. Familiarity was not a shield; it was a tax.

The Copilot experiment sits at the opposite pole. Greenfield, clearly specified, and verifiable in seconds. And its gains were largest for the least experienced developers.

Compress both results into one sentence and you get: AI wins when it fills in context you lack, and loses when it has to catch up to context you already have. Which gives you two axes.

Verification is cheap (seconds/minutes)Verification is expensive (days/months)
UnfamiliarThe sweet spot. Use it freely.The danger zone. You cannot review what you do not understand.
FamiliarFine. Small gains, small losses.METR's quadrant. Writing it yourself is faster.

The top-right cell is the real trap. AI output from there turns quietly into debt, and the invoice arrives months later.

Rule: Before delegating, answer two questions in one line each. (1) If this is wrong, when do I find out? (2) Would I recognize a wrong answer? If (2) is "no" and (1) is "in a few months," what you need is not a better tool — it is to learn the area first.

Habit 2 — Never Merge What You Cannot Review

METR's participants accepted fewer than 44% of the code the AI generated. And 56% reported needing major changes to clean up AI code. Generation got cheap; the reading, judging, and discarding did not — and that time leaves no artifact behind.

The 2025 Stack Overflow survey (tens of thousands of respondents in the AI section) tells the same story from another angle.

  • The top frustration, cited by 66%, is AI answers that are almost right, but not quite.
  • Second, at 45.2%: debugging AI-generated code takes longer.
  • And 75.3% say that when they do not trust the AI's answer, they end up asking another person.

Here is the point. Obviously wrong code is cheap to catch. The expensive kind is code plausible enough to survive review and wrong enough to cost you. Which means review is not the chore that comes after the real work. Review is the work.

One piece of self-deception worth naming: asking the model to explain its own diff is not verification. The explanation is also generated. Real verification means running it, testing it, and checking it against invariants you actually know.

Rule: Apply the same size cap to AI-written PRs that you apply to human-written ones. A diff too large to review is a diff too large to merge. And put review time in the calendar as an actual budget line.

If verification is the bottleneck, readable code stops being a matter of taste and becomes a throughput problem — exactly the argument in Write Code for Humans and LLM Burnout.

Habit 3 — Build Machine Guardrails, Not Prose Rules

Anthropic's Building Effective Agents recommends poka-yoke in tool design: change the arguments themselves so it is "harder to make mistakes." The example in the piece captures the spirit exactly — when the model keeps getting relative paths wrong, you do not add a warning to the prompt; you change the tool signature to require absolute paths. The same document argues you should invest as much in the agent-computer interface (ACI) as in human-facing interfaces, and that you should actually run your tools to see what mistakes the model makes.

The principle that falls out is simple. A sentence in a rules file is a request. A failing type check is a fact. Prose is obeyed probabilistically; a compiler is obeyed deterministically.

// Prose rule: "never use a raw number for currency" -> the model may or may not comply.
// Machine guardrail: make it impossible to get through in the first place.
type Cents = number & { readonly __brand: 'Cents' }

export function charge(amount: Cents): Promise<Receipt> {
  /* ... */
}

charge(1000) // Type error. Human or model, you get stopped right here.
charge(toCents(1000)) // Passes.

None of this is new to the AI era. What changed is that as code volume goes up, the return on guardrails goes up with it.

Rule: The second time you correct the model on the same mistake, stop writing rules and write a check. Move it into a type, a lint rule, a test, a CI gate, or a narrower function signature. If it cannot be moved, it was probably a rule humans were not following either.

Habit 4 — Give It the Right Slice, Not Everything

One of METR's factors was implicit repository context: the knowledge that lives in a five-year veteran's head and is written down nowhere.

This is where a common mistake begins. "Fine, then just give the model everything." No. Shoving 200 repository files into the context window does not tell it your invariants. An invariant is usually one sentence: this table is append-only; this function is only ever called inside a transaction; this cache is not cleared on deploy. Two hundred files will not say that. One sentence will.

Anthropic's guidance points the same way: start with the simplest solution possible and add complexity only when needed, since a single call with retrieval and good examples is often enough. Context engineering is not the art of adding more. It is the art of deciding what to leave out.

Rule: Before you start, write down the three to five constraints a newcomer to this code would violate. That list is your context. If you cannot write it, you are standing in Habit 1's danger zone.

There is a useful side effect. That list is almost always usable as team documentation. The tacit knowledge you were forced to write down for the model turns out to be knowledge your teammates did not have either.

Habit 5 — Measure Your Own Throughput, Not the Feeling

The most uncomfortable number in METR is not 19%. Before starting, developers forecast that AI would make them 24% faster. After actually living through a 19% slowdown, they still estimated they had been 20% faster. Even hindsight had the sign backwards. Economics and ML experts got the direction wrong too.

The reason is mundane. Generation is visible and verification is not. The moment the model emits 40 lines in three seconds is memorable. The 20 minutes you spend reading them and throwing half away just feels like "working."

So surveys and retrospectives are the least trustworthy instruments on this particular topic. For exactly that reason, self-reported datasets like DORA and Stack Overflow should be read on the assumption that they lean optimistic.

Rule: Two weeks, two columns. Before a task, write your estimate. After, write the actual time and whether you used AI. But measure time-to-merged-and-stable, not time-to-first-diff. The tax on code that is "almost right, but not quite" is always billed after the draft.

Where AI Genuinely Shines

This post should not read as "do not use AI," so let me be specific about where the gains are real.

  • Greenfield work with a clear spec. The 95 developers in the Copilot experiment wrote an HTTP server in JavaScript. The Copilot group averaged 1 hour 11 minutes; the control group 2 hours 41 minutes. That number is real.
  • Unfamiliar languages, APIs, frameworks. The model has read more of those docs than you have. This is Habit 1's sweet spot.
  • Anything verifiable in seconds. Throwaway scripts, scaffolding, test fixtures, regexes, data munging. If it is wrong, you know immediately.
  • Work in the reading direction. Understanding code someone else wrote. Its claims can be checked against the code right there, so verification is cheap.
  • Mechanical bulk changes in well-tested areas. The guardrails are already standing.

And the Copilot finding that gains were largest for less experienced developers is, as the authors put it, a promising signal for people transitioning into software careers.

Honest Limits on These Rules

METR's limits. Sixteen participants, 246 tasks, early-2025 models, large and mature open-source repositories. The authors state explicitly that their work does not show that AI fails to speed up most developers, nor that there is no better way to use existing AI tools.

More importantly, METR is revising its own design. In a February 2026 follow-up, they acknowledged serious selection effects: some developers declined to participate at all because they did not want to work without AI, even at 50 USD an hour; 30 to 50% of developers never submitted tasks they thought AI would handle well; and time tracking broke down once people ran several agents concurrently. Their newer data actually hints at a speedup — but METR itself calls that "an unreliable signal of the current productivity effect."

The Copilot study's limits. One task, greenfield, and what was measured is completion time, not quality or maintainability. It is also worth recording that some authors were affiliated with GitHub.

The survey's limits. Stack Overflow is self-reported. And for precisely the reason METR demonstrated, self-report is the least reliable instrument available on this topic.

So the five habits above are not laws. They are heuristics drawn from the best evidence currently available. Try to falsify them with your own log. That is rather the point of Habit 5.

Closing

Compress all five into one sentence: AI wins when it fills in context you lack, and loses when it has to catch up to context you already have. The other four are operational details of that sentence — choose tasks to match it (1), budget verification as first-class work (2), hand verification to machines (3), compress and deliver context (4), and measure whether any of it is working (5).

One last thing. No rule in this post beats two weeks of your own log. It is not an accident that the fifth habit comes last.

References