AI 활용 공부법, 검증 루틴에 시간을 쓰는 방법

3줄 요약

• AI 도구를 쓰는 사람은 84%인데 결과를 믿는 사람은 33%입니다. 그 사이의 틈을 메우는 일이 지금 사람 몫으로 남아 있습니다.
• 학습 시간을 유효기간으로 나눠 보면 프롬프트 요령은 도구 버전과 함께 낡고, 검증 루틴은 도구가 바뀌어도 남습니다. 저는 주당 5시간 중 3.5시간을 검증 쪽에 넣었습니다.
• 다음 주 회고 전에 팀의 "통과 기준" 한 줄만 문서로 적어보시면 됩니다. 이 글 마지막의 체크리스트를 그대로 쓰셔도 됩니다.

작년 겨울에 팀원 한 명이 1:1에서 이렇게 물었습니다. "리드님, 저 프롬프트 강의 하나 결제할까요?" 저는 그 자리에서 답을 못 했습니다. 하라고 하기도 애매하고, 하지 말라고 할 근거도 없었습니다. 그날 이후로 몇 달을 그 질문이 머릿속에 걸려 있었습니다. 결국 제 문제이기도 했으니까요. 저도 일주일에 몇 시간은 새로운 것을 배우는 데 쓰는데, 그 시간을 어디에 넣어야 할지 정하지 못하고 있었습니다.

선택지는 크게 두 갈래였습니다. 하나는 도구 쪽입니다. 프롬프트를 잘 쓰는 법, 에이전트를 붙이는 법, 새로 나온 기능을 먼저 만져보는 것. 다른 하나는 검증 쪽입니다. AI가 만든 결과물을 어떤 순서로 확인하고, 무엇을 통과 기준으로 삼고, 팀 안에서 그 기준을 어떻게 공유할지를 만드는 것. 둘 다 필요하다는 말은 맞지만, 주당 5시간이라는 한정된 예산 앞에서는 답이 되지 않습니다.

결론부터 적겠습니다. 저는 5시간 중 3.5시간을 검증 쪽에 넣었습니다. 이유는 두 선택지의 유효기간이 다르기 때문입니다. 프롬프트 요령은 모델과 도구가 바뀌면 상당 부분 다시 배워야 하지만, "무엇을 통과 기준으로 볼 것인가"는 도구가 바뀌어도 그대로 남습니다. 아래에 그 판단에 쓴 숫자와, 실제로 만들다가 막힌 세 곳을 적었습니다.

1. 먼저 숫자를 봤습니다

혼자 감으로 정하기가 싫어서 공개된 조사부터 뒤졌습니다. 가장 표본이 큰 것이 Stack Overflow 2025 개발자 설문의 AI 섹션이었습니다. 여기서 눈에 걸린 것은 사용률이 아니라 사용률과 신뢰도가 반대 방향으로 움직였다는 점입니다.

1-1. 쓰는 사람은 늘고, 믿는 사람은 줄었습니다

조사에서 AI 도구를 쓰거나 쓸 계획이라고 답한 비율은 84%로 전년 76%보다 올랐습니다. 전문 개발자 중 절반이 넘는 51%가 매일 씁니다. 그런데 같은 조사에서 결과물의 정확도를 신뢰한다는 응답은 33%였고, 신뢰하지 않는다는 응답이 46%로 더 많았습니다.

정확도 신뢰	전체 응답자	경력 10년 이상
매우 신뢰	3.1%	2.5%
어느 정도 신뢰	29.6%	28.6%
어느 정도 불신	26.1%	26.7%
매우 불신	19.6%	20.7%

표에서 제 눈이 오래 머문 칸은 경력 10년 이상의 "매우 신뢰" 2.5%입니다. 조사 본문은 이 집단을 두고 가장 조심스럽다고 적으면서, 책임이 따르는 역할일수록 사람의 검증이 필요하다는 해석을 붙였습니다. 저는 이 문장을 커리어 신호로 읽었습니다. 책임 있는 자리에 있는 사람일수록 결과를 그대로 받지 않는다면, 그 자리에서 실제로 하는 일은 "확인"이라는 뜻입니다.

1-2. 막히는 지점이 어디인지도 나와 있었습니다

같은 조사에서 AI를 쓰며 겪은 문제를 물었더니 답이 한쪽으로 쏠렸습니다.

겪은 문제	응답 비율
거의 맞는데 정확히 맞지는 않은 결과	66%
AI가 만든 코드의 디버깅이 더 오래 걸림	45.2%
스스로의 문제해결 자신감이 줄어듦	20%
코드가 왜 동작하는지 이해하기 어려움	16.3%

"거의 맞는데 아닌 것"이 1등입니다. QA를 오래 한 사람에게 이 문장은 낯설지 않습니다. 완전히 틀린 것은 아무나 잡습니다. 비용이 드는 쪽은 늘 그럴듯하게 틀린 것이었습니다. 제 해석으로는, 이 조사가 말하는 병목은 생성 능력이 아니라 판별 능력입니다.

한 가지 더 붙이겠습니다. 미래에 AI가 대부분의 코딩을 해도 사람에게 묻고 싶은 상황이 언제냐는 질문에, 1위 답변이 "AI의 답을 믿지 못할 때"로 75.3%였습니다. 사람에게 남는 역할이 무엇인지에 대한 응답자들의 집단적 예측인 셈입니다.

이 숫자들을 놓고 저는 며칠을 고민했습니다. 조사가 미국 중심이고 응답자 구성도 제 상황과 같지 않으니 그대로 옮길 수는 없습니다. 다만 방향은 제 경험과 맞았습니다. 지난 반년 동안 제가 리뷰에서 가장 오래 붙들었던 변경들은 하나같이 겉보기에는 멀쩡했습니다. 테스트도 통과했고 구조도 깔끔했는데, 특정 조건에서만 다르게 동작했습니다. 그런 것을 잡는 데 드는 시간은 코드를 처음부터 쓰는 시간과 크게 다르지 않았습니다. 조사에서 45.2%가 "디버깅이 더 오래 걸린다"고 답한 이유를 저는 그렇게 이해했습니다.

2. 유효기간으로 나눠 계산했습니다

숫자를 보고 나서 제가 쓴 기준은 하나입니다. "이 시간이 몇 년 뒤에도 남는가."

2-1. 남는 것과 사라지는 것

저는 학습 시간을 두 종류로 나눕니다. 하나는 특정 도구의 사용법입니다. 이건 도구가 바뀌면 대부분 폐기됩니다. 다른 하나는 판단의 틀입니다. 어떤 조건에서 무엇을 확인해야 하는지, 어디까지가 통과인지에 대한 기준입니다. 이건 도구를 갈아치워도 옮겨집니다.

제가 이 구분을 신뢰하게 된 계기는 20년 전 일입니다. 그때 저는 어떤 테스트 도구의 스크립트 문법을 열심히 외웠습니다. 그 도구는 몇 년 뒤 사라졌고 외운 것도 같이 사라졌습니다. 반면 같은 시기에 배운 "경계값을 먼저 본다"는 습관은 도구를 네 번 바꾸는 동안 한 번도 버린 적이 없습니다.

항목	프롬프트·도구 숙련	검증 루틴 구축
효과가 나타나는 시점	며칠	몇 주
도구 교체 시 잔존율	낮음 — 문법·기능 의존	높음 — 기준은 도구 밖에 있음
팀에 이전 가능한가	개인기로 남기 쉬움	문서로 남으면 그대로 이전됨
대체 가능성	도구 자체가 점점 알아서 함	책임이 사람에게 남아 있음
실패했을 때 손실	시간 손실에 그침	잘못된 기준이 팀에 퍼짐

표의 마지막 줄은 검증 쪽의 약점입니다. 잘못 만든 기준은 개인 손실로 끝나지 않고 팀 전체를 잘못된 방향으로 밀어냅니다. 그래서 저는 검증 루틴을 만들 때 처음부터 완성본을 노리지 않고, 매주 조금씩 고치는 형태로 갔습니다.

2-2. 5시간을 이렇게 쪼갰습니다

# 주당 5시간 배분 (2026년 상반기 기준, 매주 일요일 저녁에 조정)

검증 루틴 3.5h
  ├─ 1.5h  통과 기준 문서 고치기 (지난주에 놓친 것 반영)
  ├─ 1.0h  AI가 만든 변경 1건을 골라 직접 리뷰하고 근거 기록
  └─ 1.0h  팀 회고에서 나온 결함 유형을 기준 문서에 반영

도구 숙련 1.5h
  ├─ 1.0h  실제 업무 과제 하나를 AI와 같이 처리하며 관찰
  └─ 0.5h  새 기능 릴리스 노트 훑기 (깊게 파지 않음)

# 도구 숙련을 0으로 두지 않은 이유:
# 검증 기준을 만들려면 도구가 어떻게 틀리는지 직접 봐야 합니다.

도구 쪽을 0으로 두지 않은 것이 중요합니다. 검증 기준은 도구를 안 써 본 사람이 만들 수 없습니다. 어떤 방식으로 틀리는지를 직접 봐야 무엇을 확인할지가 나옵니다. 다만 그 시간은 "기능을 다 아는 것"이 아니라 "실패 방식을 아는 것"에 씁니다.

3. 만들면서 막힌 세 곳

여기부터가 실제로 시간이 녹은 부분입니다. 세 번 막혔고 각각 이름을 붙여 뒀습니다.

3-1. 함정 1 — 기준 없는 체크리스트

처음 만든 것은 항목만 나열한 체크리스트였습니다. "테스트가 충분한가", "보안 이슈는 없는가" 같은 문장들이었습니다. 두 주 만에 아무도 안 봤습니다. 이유는 단순했습니다. "충분한가"에 답할 수 있는 사람이 없었기 때문입니다. 판단이 사람마다 갈리는 항목은 체크리스트가 아니라 논쟁 목록입니다.

고친 방법은 모든 항목을 "예/아니오로 답할 수 있는 문장"으로 다시 쓰는 것이었습니다. "테스트가 충분한가" 대신 "이 변경으로 바뀐 조건 분기마다 실패 케이스가 하나 이상 있는가"로 바꿨습니다. 문장이 길어졌지만 다툼이 없어졌습니다.

문장을 바꾸는 데 걸린 시간은 생각보다 길었습니다. 항목 여섯 개를 고치는 데 두 주가 갔습니다. 한 문장씩 회의에 올려서 "이 문장으로 판단이 갈리는 상황이 있느냐"만 물었고, 갈린다고 하면 그 자리에서 다시 썼습니다. 처음에는 이 과정이 소모적으로 느껴졌는데, 지나고 보니 그 논의 자체가 팀의 기준을 맞추는 작업이었습니다. 문서는 결과물이고 진짜 산출물은 그 대화였습니다.

3-2. 함정 2 — 리뷰어 한 사람에게 몰아준 구조

두 번째로 막힌 곳은 사람 배치였습니다. AI가 만든 변경이 늘어나니 리뷰 대기열이 길어졌고, 그 부담이 경력 많은 한 명에게 몰렸습니다. 그 사람의 다른 업무가 밀리기 시작했고, 리뷰 품질도 같이 떨어졌습니다. 검증 역량을 키우자고 시작한 일이 특정 개인의 병목으로 되돌아온 셈입니다.

DORA의 2025년 보고서는 AI를 증폭기로 설명합니다. 조직이 이미 가진 강점과 약점을 함께 키운다는 것이고, 가장 큰 성과는 도구가 아니라 그 밑의 조직 체계에 손을 댈 때 나온다고 적습니다. 제 상황에 대입하면, 원래 있던 "리뷰가 한 사람에게 쏠리는 구조"가 AI 때문에 더 선명해진 것이었습니다. 도구를 바꿔서 풀 문제가 아니었습니다.

해결은 리뷰를 두 단계로 쪼갠 것이었습니다. 1단계는 기준 문서만 보고 누구나 할 수 있는 기계적 확인, 2단계는 설계 판단이 필요한 부분만 경력자가 보는 것. 이 순서로 바꾼 뒤 회고에서 리뷰 병목 이야기가 다시 나오지 않았습니다.

3-3. 함정 3 — 기록하지 않아 같은 것을 세 번 발견

세 번째는 부끄러운 쪽입니다. 같은 유형의 결함을 세 번 발견하고서야 그게 반복이라는 걸 알았습니다. 매번 잡아서 고쳤지만 기록을 남기지 않아서 패턴이 보이지 않았던 겁니다. 검증 루틴의 핵심은 확인하는 행위가 아니라 확인한 결과가 쌓이는 것이었는데, 저는 앞쪽만 하고 있었습니다.

지금은 아래 형식으로 한 줄씩 남깁니다. 도구는 쓰던 노트 앱 그대로입니다.

## 2026-08-24 · 결제 모듈 변경
- 유형: 조건 분기 누락 (경계값)
- 어디서 잡았나: 2단계 리뷰
- 기준 문서에 있었나: 아니오 → 항목 추가함
- 다음에 1단계에서 잡으려면: "금액 0원과 상한값 케이스" 항목 신설

마지막 줄이 이 기록의 목적입니다. 잡은 사실이 아니라, 다음번에 더 싼 단계에서 잡을 방법을 적는 것입니다.

4. 석 달 뒤에 남은 것

정직하게 적겠습니다. 극적인 변화는 없었습니다. 제가 관찰한 것은 세 가지입니다. 회고에서 리뷰 병목 이야기가 다시 나오지 않았습니다. 기준 문서를 보고 주니어가 먼저 질문을 가져오는 일이 생겼습니다. 그리고 제가 리뷰에 쓰는 시간의 성격이 바뀌었습니다. 예전에는 "이게 맞나"를 매번 처음부터 판단했는데, 지금은 기준에 없는 것만 판단합니다.

수치로 말할 수 있으면 좋겠지만 팀 생산성을 숫자로 잰 근거가 제게는 없습니다. 그러니 위의 세 가지는 관찰이지 측정이 아닙니다.

반대로 잘 안 된 것도 적어 두겠습니다. 도구 쪽에 남긴 1.5시간은 계획대로 쓰이지 않은 주가 많았습니다. 급한 일이 생기면 가장 먼저 잘려 나갔고, 그러다 보니 새 기능을 한참 뒤에야 알게 되는 일이 몇 번 있었습니다. 검증 기준을 만들려면 도구를 계속 만져야 한다고 스스로 적어놓고도 그 시간을 지키지 못한 셈입니다. 지금은 이 시간을 회의처럼 캘린더에 고정해 두고 있는데, 아직 효과를 말하기에는 이릅니다.

평가 항목	프롬프트·도구 숙련	검증 루틴 구축
도입 난이도	낮음 — 혼자 시작 가능	중간 — 팀 합의가 필요함
유지보수 비용	중간 — 도구가 바뀔 때마다 다시	중간 — 매주 문서를 손봐야 함
팀 학습곡선	완만 — 각자 속도로	초반 가파름 — 기준 합의에 시간이 듦
효과 체감까지	며칠	4~6주
혼자 해도 되는가	예	아니오 — 혼자 쓴 기준은 안 지켜짐

표에서 가장 중요한 줄은 마지막입니다. 저 혼자 좋은 기준 문서를 쓰는 것은 아무 의미가 없었습니다. 팀이 같이 고친 문장만 실제로 지켜졌습니다.

5. 권할 만한 경우와 권하지 않는 경우

5-1. 권할 만한 경우

리뷰 대기열이 길어지고 있고 그 부담이 특정 인원에게 쏠린다면 검증 쪽에 시간을 넣을 값이 있습니다. 같은 유형의 결함이 반복된다고 느끼는데 근거를 못 대겠다면 기록부터 시작하시면 됩니다. 팀에 경력 편차가 크고 "이 정도면 되나요"라는 질문이 자주 온다면, 그 질문에 답하는 문서가 곧 검증 루틴입니다.

5-2. 권하지 않는 경우

혼자 일하거나 리뷰 상대가 없다면 우선순위가 아닙니다. 이 방식은 기준을 공유할 상대가 있어야 값이 생깁니다. 팀이 아직 AI 도구를 거의 안 쓰는 단계라면 순서가 뒤바뀝니다. 어떻게 틀리는지 본 적이 없는 상태에서 만든 기준은 상상으로 쓴 문서가 됩니다. 그리고 다음 분기 안에 눈에 보이는 성과가 필요하다면 이건 맞지 않습니다. 4~6주는 지나야 뭔가 느껴집니다.

5-3. 다음 주에 해볼 것

거창하게 시작하지 마시고 아래 다섯 줄만 채워보시면 됩니다. 저도 이 다섯 줄에서 시작했습니다.

[검증 루틴 최소 시작 체크리스트]

1. 지난 2주 동안 리뷰에서 잡은 것 중 가장 자주 나온 유형 하나를 적는다.
2. 그 유형을 "예/아니오로 답할 수 있는 한 문장"으로 바꾼다.
   - 나쁜 예: 테스트가 충분한가
   - 좋은 예: 바뀐 조건 분기마다 실패 케이스가 하나 이상 있는가
3. 그 한 문장을 팀이 볼 수 있는 곳에 둔다. 문서 이름은 아무래도 좋다.
4. 다음 회고에서 "이 문장이 도움이 됐는지"만 묻는다. 다른 건 묻지 않는다.
5. 도움이 됐으면 문장을 하나 더 늘리고, 아니면 문장을 고친다.

1:1에서 프롬프트 강의를 물었던 팀원에게는 뒤늦게 이렇게 답했습니다. 결제해도 되는데, 강의를 듣고 나면 그 도구가 어떤 방식으로 틀렸는지 세 가지만 정리해서 알려달라고요. 그 세 가지가 지금 기준 문서의 첫 항목이 됐습니다. 배우는 시간을 아예 안 쓰는 것보다, 배운 것을 어디에 남길지 정해두고 쓰는 편이 저에게는 더 남았습니다.

---