목차
- 코드는 늘었는데 이해는 왜 줄었을까?
- 왜 하필 디버깅이 주니어의 핵심 능력이 됐을까?
- "에러 붙여넣고 고쳐줘"는 왜 계속 실패할까?
- 1단계 — 버그를 내 손으로 다시 일으킬 수 있는가?
- 2단계 — 코드를 읽지 않고 범위를 자를 수 있는가?
- 3단계 — 고치기 전에 원인을 한 문장으로 말할 수 있는가?
- 실제 버그 하나를 3단계로 잡으면 어떤 모습일까?
- 무엇을 AI에 넘기고 무엇을 내 손에 남길까?
전체 지도
자, 오늘 지도는 좀 다르게 생겼습니다. 앞선 편들이 "이렇게 만들면 됩니다"라는 조립 설명서였다면, 오늘 지도 한가운데에는 불이 켜진 경고등이 하나 놓여 있어요. 왼쪽 위에서 출발합니다. 코드는 잔뜩 쌓였는데 이해는 오히려 얇아진 현장, 그리고 그게 왜 하필 주니어에게 더 아프게 오는지를 숫자로 확인할 겁니다. 가운데로 내려오면 우리 모두가 한 번쯤 해본 잘못된 습관 하나에 이름을 붙여줄 거고요. 지도의 몸통, 그러니까 굵은 화살표 세 개가 왼쪽에서 오른쪽으로 이어지는 그 자리가 오늘의 핵심입니다. 재현 → 격리 → 설명, 이 세 단계죠. 오른쪽 아래에서는 실제 버그 하나를 이 세 단계로 끝까지 잡아볼 거고, 마지막 전구 아이콘 자리에서 "그래서 뭘 AI에 넘기고 뭘 내 손에 남길 것인가"로 시리즈를 닫겠습니다. 그럼 출발해볼까요?
1. 코드는 늘었는데 이해는 왜 줄었을까?
지도 왼쪽 위, 노트북 화면에 빨간 느낌표가 떠 있는 그 칸에서 시작합니다.
장면 하나를 그려볼게요. 어제 오후, AI한테 "회원 목록 화면 만들어줘"라고 했더니 정말 하루 만에 뚝딱 나왔습니다. 잘 돌아가더군요. 그런데 오늘 아침, 그 화면이 텅 비어 있습니다. 로그를 열어봤더니 처음 보는 함수 이름이 줄줄이 찍혀 있어요. 내가 쓴 적 없는 이름이죠. 자, 어디부터 봐야 할까요?
이게 요즘 개발 현장에서 매일 일어나는 일입니다. 예전에는 코드를 쓰는 시간이 개발의 대부분이었는데, 지금은 남이 — 정확히는 AI가 — 써준 코드를 읽고 판단하는 시간이 훨씬 길어졌습니다. 2026년 초 조사에서 개발자들은 근무 시간의 약 38%, 그러니까 주 5일 중 이틀 가까이를 AI가 만든 코드의 디버깅과 검증에 쓰고 있다고 답했습니다. AI가 만든 변경의 43%는 품질 검사와 스테이징(실제 서비스와 똑같이 만들어둔 연습용 서버)을 통과하고도, 진짜 서비스에서 사람 손을 다시 탔고요.
남의 집 두꺼비집을 찾는 상황과 똑같습니다. 우리 집이면 눈 감고도 찾지만, 남의 집은 배선도부터 없죠. AI가 만든 코드베이스는 하루아침에 "남의 집"이 되어버린 우리 집입니다.
그래서 오늘 글의 주장은 한 문장입니다. 디버깅은 이제 곁다리 잔기술이 아니라, 주니어 개발자의 핵심 직무 능력입니다.
여기서 실제로 할 일: 최근 일주일 동안 AI가 만들어준 파일 중에서 "지금 당장 남에게 설명하지 못하는 파일"이 몇 개인지 세어만 보세요. 고치지 말고, 숫자만.
참고 자료:
2. 왜 하필 디버깅이 주니어의 핵심 능력이 됐을까?
그 숫자가 왜 하필 주니어에게 더 아픈지, 지도 왼쪽 아래 저울 아이콘 자리에서 근거 세 개만 짚고 가겠습니다. 길게 끌지 않을게요.
첫째, 산출량이 가장 빨리 늘어나는 쪽이 주니어입니다. MIT·마이크로소프트 연구진이 세 회사에서 진행한 대규모 실험에서 AI 도구는 주당 완료 작업을 평균 26% 늘렸는데, 경력별로 뜯어보니 신입·저연차는 27~39%, 시니어는 8~13% 늘었습니다. 좋은 소식처럼 들리죠? 그런데 뒤집어 읽으면 이렇습니다. 판단해야 할 코드가 가장 빠르게 불어나는 사람이, 판단 경험은 가장 적은 사람이라는 뜻이에요.
둘째, 체감과 실제가 어긋납니다. METR이라는 연구 기관이 숙련 개발자 16명에게 자기 프로젝트의 실제 이슈 246건을 맡기고 AI 사용 여부를 무작위로 나눠봤습니다. 참가자들은 AI가 24% 빠르게 해줄 거라 예상했지만 실제로는 19% 느렸고, 더 놀라운 건 실험이 끝난 뒤에도 여전히 "20% 빨라졌다"고 믿고 있었다는 점입니다. 느낌은 증거가 아니라는 얘기죠.
셋째, AI가 비워둔 자리가 정확히 여기입니다. 2026년 스택 오버플로 조사에서 개발자들이 꼽은 최대 불만 1위는 "거의 맞는데, 딱 맞지는 않는 답"(66%)이었고, 45%가 AI 코드 디버깅에 시간을 크게 쓴다고 답했습니다. AI 출력을 "매우 신뢰한다"는 응답은 3%에 그쳤고요. 2025년 DORA 보고서는 이걸 한 문장으로 정리합니다. "AI는 팀을 고쳐주지 않는다. 이미 있는 것을 증폭할 뿐이다." 실제로 AI 도입은 배포 처리량과는 양의 관계였지만, 배포 안정성과는 여전히 음의 관계였습니다.
증폭기(앰프) 비유가 딱 맞습니다. 좋은 연주를 넣으면 크게 들리고, 잡음을 넣으면 잡음이 크게 들립니다. 앰프는 연주를 고쳐주지 않아요. 무엇이 잘못됐는지 정의하는 일, 그 자리는 지금도 사람 몫으로 남아 있습니다.
여기서 실제로 할 일: 이번 주 AI에게 맡긴 작업 하나만 골라 시작 시각과 끝난 시각을 적어보세요. 체감 대신 숫자를 한 줄 남기는 겁니다.
참고 자료:
- How generative AI affects highly skilled workers | MIT Sloan
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity | METR
- Announcing the 2025 DORA Report | Google Cloud
3. "에러 붙여넣고 고쳐줘"는 왜 계속 실패할까?
숫자는 그렇다 치고, 실제로 우리가 버그 앞에서 하는 행동을 한번 정직하게 복기해봅시다. 지도 가운데, 망치를 든 손이 그려진 칸입니다.
패턴은 늘 같습니다. 에러 메시지를 통째로 복사해서 붙여넣습니다. AI가 새 코드를 줍니다. 붙여넣고 돌립니다. 다른 에러가 납니다. 또 복사합니다. 또 새 코드가 옵니다. 그렇게 삼십 분쯤 지나면 코드는 처음보다 두 배로 불어나 있고, 원인은 여전히 모릅니다. 심지어 처음 그 버그가 아직 살아 있는지도 확실치 않아요.
이걸 "두더지 잡기 디버깅"이라고 부르겠습니다. 오락실 두더지 잡기 게임 아시죠? 튀어나온 놈을 때리면 다른 구멍에서 또 튀어나옵니다. 재미는 있는데, 아무리 때려도 두더지 총 마릿수는 줄지 않습니다. 게임기 안쪽 구조를 안 봤으니까요. 에러 메시지만 때리는 디버깅이 정확히 이겁니다.
여기서 규칙을 하나만 정합시다. 같은 버그를 세 번 물어봤는데도 안 고쳐지면, 거기서 멈춥니다. 네 번째 프롬프트는 통계적으로 여러분을 구해주지 않아요. 세 번째에서 멈추고, 지금부터 설명할 3단계로 갈아타는 겁니다. 이 규칙 하나만 지켜도 하루가 통째로 날아가는 일은 크게 줄어듭니다.
여기서 실제로 할 일: "같은 버그 3번이면 멈춤"을 프로젝트 README 맨 윗줄이나 에디터 메모에 적어두세요. 30초면 됩니다.
참고 자료:
4. 1단계 — 버그를 내 손으로 다시 일으킬 수 있는가?
멈췄으면 이제 첫 번째 굵은 화살표로 들어갑니다. 지도 몸통의 맨 왼쪽, 되감기 아이콘이 그려진 칸입니다.
목표는 한 줄입니다. 언제든 100% 다시 일으킬 수 있는 조건을 고정한다.
구체적으로는 "가끔 안 돼요"를 "로그인 안 한 상태에서 새로고침하면 항상 안 돼요"로 바꾸는 작업입니다. 이 문장이 손에 잡히기 전까지는 코드를 열지 않습니다. 왜냐고요? 재현이 안 되면 고쳤는지 아닌지도 확인할 수 없기 때문입니다. 의사가 "가끔 아파요"만 듣고 수술에 들어가지 않는 것과 같습니다. 어떤 자세로, 언제, 어디가 아픈지가 나와야 검사가 시작되죠.
AI는 여기서 이렇게 씁니다. 원인을 물어보지 마세요. 대신 방금 고정한 재현 조건을 그대로 옮겨서 실패하는 테스트 코드를 만들어달라고 하세요. "토큰이 없는 상태로 회원 목록 화면을 렌더링했을 때 목록이 비어 있는지 확인하는 테스트를 써줘." 지금 이 테스트는 반드시 실패해야 정상입니다. 실패하는 테스트는 앞으로 여러분의 심판이 되어줍니다.
흔한 실수는 하나뿐입니다. 재현 조건을 못 잡은 채로 코드부터 읽기 시작하는 것. 그 순간부터는 디버깅이 아니라 독서입니다.
여기서 실제로 할 일: 지금 붙잡고 있는 버그를 "○○한 상태에서 △△하면 항상 □□된다" 형식의 한 문장으로 적어보세요. 안 써지면 아직 1단계입니다.
참고 자료:
5. 2단계 — 코드를 읽지 않고 범위를 자를 수 있는가?
재현이 손에 들어왔다면, 이제 많은 분들이 곧장 하는 그 행동을 참아야 합니다. 지도 가운데 굵은 화살표, 가위 아이콘이 그려진 칸입니다.
목표는 이겁니다. 전부 이해하려 하지 말고, 정상과 비정상의 경계선을 찾는다.
핵심은 이분 탐색입니다. 사전에서 단어 찾을 때 첫 장부터 넘기지 않고 가운데를 펼치잖아요. 코드도 똑같이 대합니다. 전체를 읽는 게 아니라 절반씩 잘라 나가는 거예요. 도구는 딱 세 개면 충분합니다.
하나, 경계마다 값 찍어보기. 함수 들어갈 때와 나올 때 값을 출력해서, 어느 지점까지는 값이 멀쩡한지 확인합니다. 둘, git bisect. "어제는 됐는데 오늘 안 돼요"라면 이게 최강입니다. 정상인 커밋과 고장 난 커밋을 알려주면 Git이 중간 지점들을 자동으로 짚어가며 어느 커밋부터 깨졌는지를 찾아줍니다. 셋, 의심 구간 주석 처리. 지웠는데 증상이 사라지면 그 안에 범인이 있는 겁니다.
AI는 여기서 이렇게 씁니다. "왜 안 돼?"라고 묻지 마세요. 읽기 보조로만 씁니다. "이 함수가 어떤 값을 받아서 어떤 값을 내보내는지 세 줄로 요약해줘." 판단은 여러분이 하고, AI에게는 번역만 시키는 겁니다.
흔한 실수는 시작부터 원인을 찍어놓고 그 추측을 확인하는 증거만 모으는 것입니다. 이걸 확증 편향이라고 부르죠. 범인을 정해놓고 수사하는 형사는 반드시 엉뚱한 사람을 잡습니다.
여기서 실제로 할 일:
git log --oneline | head -20으로 최근 커밋 20개만 훑어보세요. "어제는 됐다"면 범위는 이미 스무 줄 안에 있습니다.
참고 자료:
6. 3단계 — 고치기 전에 원인을 한 문장으로 말할 수 있는가?
범위가 좁혀졌습니다. 이제 고치면 될까요? 아직입니다. 지도 몸통 오른쪽 끝, 말풍선 아이콘이 그려진 마지막 화살표가 남았습니다.
목표는 이렇습니다. 코드를 건드리기 전에, 원인을 한 문장으로 말한다.
템플릿을 드릴게요. 빈칸만 채우시면 됩니다.
"○○ 때문에 △△가 발생한다. 그래서 □□을 고치면 된다."
이 문장이 안 써지면, 아직 고칠 때가 아닙니다. 이건 잔소리가 아니라 기준선이에요. 시리즈 1편에서 머지 전에 확인할 다섯 줄 중 마지막 줄이 "이 코드를 남에게 설명할 수 있는가"였죠. 그 체크와 이 문장은 정확히 같은 지점에서 만납니다. 설명할 수 있으면 통과시켜도 되고, 설명 못 하면 아직 아무것도 끝나지 않은 겁니다.
AI는 여기서 이렇게 씁니다. 답을 물어보는 게 아니라, 내가 쓴 원인 문장을 반박해보라고 시킵니다. "내 가설은 이것이다. 이 가설이 틀렸다면 어떤 경우겠는가?" AI를 조언자가 아니라 반대편 변호사로 세우는 거예요. 이 한 번의 반박이 엉뚱한 곳을 고치는 하루를 아껴줍니다.
흔한 실수는 가장 달콤한 함정입니다. 증상이 사라진 걸 원인이 해결된 걸로 착각하는 것. 화재경보기가 시끄럽다고 배터리를 빼면 소리는 멈춥니다. 불은 계속 타고 있고요.
여기서 실제로 할 일: 위 템플릿에 지금 버그를 넣어 한 문장으로 써보고, 그 문장을 AI에게 던져 반박을 받아보세요. 5분이면 됩니다.
참고 자료:
7. 실제 버그 하나를 3단계로 잡으면 어떤 모습일까?
말로만 들으면 다 쉬워 보이죠. 그래서 시리즈에서 계속 써온 회원 목록 화면으로 실제 버그 하나를 끝까지 따라가 보겠습니다. 지도 오른쪽 아래, 돋보기 아이콘 자리입니다.
증상: 회원 목록 화면이 가끔 "회원이 없습니다"로 뜬다. 다시 들어가면 잘 나온다.
앞에서 든 의사 비유를 그대로 이어가겠습니다. 여기서부터는 문진이 끝나고 엑스레이를 찍는 단계예요.
1단계 · 재현. "가끔"을 없애는 게 첫 일이었습니다. 로그인 직후 이동하면 정상, 그 화면에서 새로고침(F5) 하면 항상 빈 목록. 조건이 고정되는 순간 "가끔"은 사라졌습니다. 그리고 이 조건 그대로 실패하는 테스트를 하나 만들어 두었습니다.
$ npm test -- members
✕ 새로고침 직후에도 회원 목록이 렌더링된다 (기대 3명 / 실제 0명)
2단계 · 격리. 코드를 읽는 대신 경계에 값을 찍었습니다.
[fetchMembers] token = null ← 여기서 이미 이상하다
[fetchMembers] status = 401
[MemberList] members = [] ← 화면은 정상적으로 "회원이 없습니다"를 그림
토큰(로그인했다는 걸 증명하는 문자열)이 비어 있었고, 서버는 그래서 401(권한 없음)을 돌려준 겁니다. 화면 컴포넌트는 잘못이 없었어요. 요청이 나가는 순간 이미 토큰이 없었던 거죠. 언제부터였는지는 Git에게 물었습니다.
$ git bisect start
$ git bisect bad # 지금 커밋: 고장
$ git bisect good v0.3.0 # 3일 전 태그: 정상
# ... 네 번 정도 good/bad를 답하면
a91f2c0 is the first bad commit
"토큰을 전역 상태로 옮김"
3단계 · 설명. 여기서 바로 고치지 않고 한 문장을 먼저 썼습니다.
"새로고침 직후에는 저장소에서 토큰을 복원하는 작업이 아직 끝나지 않았기 때문에, 목록 요청이 토큰 없이 나가 401을 받는다. 그래서 토큰 복원이 끝난 뒤에 요청이 나가도록 고치면 된다."
AI에게 이 문장을 반박시켰더니 이렇게 되묻더군요. "토큰이 아예 없는 진짜 비로그인 사용자와는 어떻게 구분할 겁니까?" 좋은 지적이었고, 그 구분까지 넣어 고쳤습니다. 만약 3단계를 건너뛰고 "401이면 빈 배열로 처리" 같은 코드를 지우기만 했다면, 화면에는 에러가 뜨기 시작하면서 증상만 바뀌고 원인은 그대로 남았을 겁니다.
여기서 실제로 할 일: 지금 프로젝트에서
git bisect start/git bisect bad/git bisect good <옛날 커밋>을 한 번만 연습해보세요. 끝나면git bisect reset으로 원위치됩니다.
참고 자료:
8. 무엇을 AI에 넘기고 무엇을 내 손에 남길까?
자, 지도 맨 아래 전구 아이콘 자리까지 왔습니다. 오늘의 결론이자 시리즈의 마지막 칸이에요.
넘겨도 되는 것부터 짚죠. 반복되는 뼈대 코드, 문법 암기, 초안 작성, 낯선 함수를 세 줄로 요약해달라는 부탁. 이건 앞으로 더 많이 넘기셔도 됩니다. 아깝지 않습니다.
남겨야 하는 것은 오늘 걸어온 세 칸입니다. 재현하기, 범위 좁히기, 원인을 말로 설명하기. 이 셋의 공통점 보이시나요? 셋 다 타이핑이 아니라 판단입니다. 그래서 AI가 아무리 빨라져도 대신해줄 수 없는 자리에 남아 있는 겁니다. 자동차가 아무리 좋아져도 어디로 갈지는 운전자가 정하는 것과 같아요.
가르치고 뽑는 입장이라면 한 가지만 덧붙이고 싶습니다. 포트폴리오에서 "무엇을 만들었나"만 보면, AI 시대에는 변별력이 거의 사라집니다. 하루 만에 만든 화면은 누구나 보여줄 수 있으니까요. 대신 "고장 났을 때 어떻게 접근했나"를 물어보세요. 재현 조건을 어떻게 고정했는지, 범위를 어떻게 잘랐는지, 원인을 한 문장으로 말할 수 있는지. 이 세 질문은 지금도 사람을 정확하게 갈라냅니다.
그리고 이걸로 시리즈가 완성됩니다. [규칙 파일 한 장으로 AI 코드 스타일 통일하기 — AGENTS.md 입문]이 AI가 코드를 만들어내는 단계를 다뤘고, [AI가 짠 코드, 머지 전에 확인할 5줄 — 주니어를 위한 리뷰 체크리스트]가 그 코드를 통과시키는 단계를 다뤘다면, 오늘 글은 그렇게 통과한 코드가 고장 났을 때를 다뤘습니다. 만들고 → 통과시키고 → 고치는 이 세 칸을 다 밟을 수 있으면, 여러분은 이미 "AI를 쓰는 사람"이 아니라 "AI가 만든 것을 책임지는 사람"입니다. 그 자리는 당분간 아무도 대신 서주지 않습니다.
첫 주말 코스
| 순서 | 할 일 | 예상 시간 |
|---|---|---|
| 1 | 지금 열려 있는 버그를 "○○한 상태에서 △△하면 항상 □□된다"로 한 문장 쓰기 | 20분 |
| 2 | 그 조건 그대로 실패하는 테스트 하나 만들기 (AI에게 시켜도 됨) | 30분 |
| 3 | 경계 3곳에 값 찍고, 정상/비정상 경계선 찾기 | 40분 |
| 4 | git bisect로 깨진 커밋 찾아보기 — 여기서 대부분 막힙니다. good 기준 커밋을 너무 최근으로 잡는 게 원인이니, 확실히 정상이던 옛날 태그로 잡으세요 | 40분 |
| 5 | 원인 한 문장 쓰고, AI에게 반박시키기 | 15분 |
| 6 | 고치고, 2번 테스트가 통과하는지 확인 | 30분 |
참고 자료:
댓글
불러오는 중입니다…