Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
공유하기
Authors

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

앞선 글 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주치 로그를 이기지 못합니다. 다섯 번째 습관이 마지막에 있는 건 우연이 아닙니다.

참고 자료

Discuss on Twitter • View on GitHub