Cover · Issue 016
"끊어진 줄은 보이는데, 어디서 끊어졌는지는 보이지 않는다."
TSTF MAG · 2026
AI가 짠 코드의 버그는, 사람이 짠 코드의 버그와 결이 다르다. 재현 시나리오, 의도 추적, 책임 분배 — 디버깅이라는 오래된 기술이 어떻게 다시 짜이는가.
버그는 코드가 태어난 날부터 함께였다. 그런데 요즘 현장에서 조금 다른 이야기가 나오기 시작했다. "이번 버그, 뭔가 평소랑 다르다"는 말이다.
재현은 됐는데, 왜 이렇게 짰는지 모르겠다. 코드를 쓴 게 AI니까 — 의도를 물어볼 데가 없다.
— 편집부에 도착한 현장 이야기 · 2026.05사람이 코드를 짤 때, 버그 뒤에는 보통 이유가 있다. 조건문을 하나 빠뜨렸거나, 변수를 잘못 가리켰거나, 피곤한 오후에 복사해서 붙여넣었거나. 원인을 찾으면 "아, 이래서 그랬구나"가 나온다. 코드를 쓴 사람에게 물어볼 수도 있다.
AI가 짠 코드는 조금 다르다. 코드 자체는 있다. 실행도 된다. 버그도 난다. 그런데 "왜 이렇게 짰는가"라는 질문에 답할 수 있는 사람이 없다. AI는 의도를 갖고 코드를 쓴 게 아니라, 패턴을 보고 가장 그럴듯한 다음 줄을 이어 붙인 것이다. 버그도 같은 방식으로 태어났다. 그럴듯하게 틀렸다.
Note 여기서 말하는 AI 코드는 AI가 통째로 작성한 코드만이 아니다. 사람이 전체 방향을 잡고, AI가 함수 하나 또는 블록 단위를 채워 넣는 형태도 포함한다. 요즘 현장에서 흔한 방식이다. 이런 코드에서는 누가 어느 부분을 책임지는지 경계가 자연스럽게 흐려진다.
이 호는 그 변화를 세 조각으로 들여다본다. 버그가 어떻게 달라졌는지, 디버깅이라는 작업이 어디서 새로운 문제에 걸리는지, 그리고 우리가 지금 어떻게 반응하고 있는지.
버그를 고치는 일은 크게 세 단계다. 재현하고, 원인을 추적하고, 고친다. AI 코드가 늘어난 뒤로, 이 세 단계 각각에서 평소와 다른 일이 생기기 시작했다.
버그를 재현하는 일 자체는 전과 크게 다르지 않다. 특정 조건에서 특정 결과가 나온다는 걸 보여주면 된다. 그런데 그 다음 단계 — "왜 이 조건에서 이 결과가 나오는가" — 를 설명하려면 코드의 의도를 알아야 한다.
사람이 짠 코드라면 작성자에게 물어보거나, 커밋 메시지나 주석을 찾아보면 된다. AI가 채워 넣은 블록에는 그런 흔적이 없다. 주석이 있어도 코드 자체를 요약한 것이지, 왜 그렇게 판단했는지를 설명하지 않는다. 재현 시나리오는 있는데 의도 추적이 막힌다. 디버깅의 출발점이 달라지는 것이다.
사람이 실수로 만든 버그는 보통 어딘가 어색한 구석이 있다. 들여쓰기가 삐뚤거나, 변수 이름이 튀거나, 흐름이 갑자기 꺾이거나. 읽다 보면 "여기 뭔가 이상하다"는 느낌이 온다.
AI가 만든 버그는 그 느낌이 잘 안 온다. 코드 스타일이 일관되고, 변수 이름도 그럴듯하고, 전체 흐름도 매끄럽다. 겉으로는 완성된 것처럼 보이는데, 안에 조용히 틀린 부분이 있다. 이런 버그는 발견하기 더 어렵다. 무언가 이상하다는 신호가 눈에 잘 안 띄기 때문이다.
현장에서 이를 "자신감 있게 틀린 코드"라고 부르는 사람들이 생겼다. 틀렸지만 틀린 것처럼 보이지 않는 코드 — 이게 AI 코드 버그의 가장 특징적인 성질이다.
사람이 짠 코드에서 버그가 나면 책임 소재가 비교적 명확하다. 커밋 히스토리를 보면 누가 언제 그 줄을 썼는지 나온다. 팀 안에서 대화가 시작될 수 있다.
AI가 채워 넣은 코드에서 버그가 나면, 커밋에는 "AI 제안을 받아들인 사람"의 이름이 남는다. 하지만 코드를 실제로 쓴 건 AI다. 방향을 잡은 사람과 코드를 채운 존재가 다르다. 이게 팀 안에서 새로운 형태의 어색함을 만들고 있다. "내가 이 코드를 검토했어야 했나", "AI를 믿은 게 실수였나" 같은 질문이 생긴다. 책임을 나누는 방법 자체를 처음부터 다시 생각해야 하는 상황이다.
예전의 디버깅은 탐정 일에 가까웠다. 단서를 모으고, 흐름을 따라가고, 범인 — 즉 버그의 원인 — 을 찾는다. 탐정은 사건 현장을 이해하기 위해 그 안의 언어를 안다.
지금의 디버깅은 거기에 번역이 하나 더 붙는다. AI가 만든 코드를 이해하려면, 먼저 그 코드가 어떤 맥락에서 나왔는지를 재구성해야 한다. AI가 어떤 프롬프트를 받았는지, 그 시점의 컨텍스트가 무엇이었는지, 어떤 패턴을 참조했는지. 이 배경을 모르면 코드가 왜 그렇게 생겼는지 이해하기 어렵다.
탐정은 사건 언어를 안다. 번역가는 두 언어 모두를 알아야 한다.
— 편집부 메모이 변화는 디버깅에 필요한 능력의 구성을 바꾼다. 코드를 줄 단위로 읽는 능력은 여전히 필요하다. 거기에 더해, "AI가 이 코드를 왜 이렇게 썼을까"를 거꾸로 추론하는 능력이 새로 요구된다.
| 사람이 짠 코드의 버그 | AI가 채워 넣은 코드의 버그 | |
|---|---|---|
| 의도 추적 | 작성자에게 물을 수 있다 | 역방향으로 재구성해야 한다 |
| 겉모습 | 어색한 구석이 보이는 경우 많음 | 매끄럽게 틀렸다 |
| 책임 소재 | 커밋 기록으로 추적 가능 | 방향과 구현이 분리되어 있다 |
| 재현 이후 | 원인 설명이 비교적 쉽다 | 설명이 막히는 경우가 생긴다 |
| 고치는 방법 | 해당 줄 수정 | 맥락 재설정이 필요할 수 있다 |
표에서 가장 흥미로운 줄은 마지막이다. AI가 만든 버그를 고칠 때, 그 줄만 수정하면 되는 게 아닐 수 있다. AI가 그 줄을 그렇게 쓴 이유가 그 전후의 맥락과 연결되어 있다면, 줄 하나를 고쳤더니 다른 곳에서 또 다른 문제가 나오는 경우가 있다. 버그를 고쳤는데 버그가 옮겨간다. 이건 사람이 짠 코드에서도 일어나는 일이지만, AI 코드에서 더 자주 보인다는 게 현장의 이야기다.
이 변화를 현실로 받아들이면, 몇 가지가 따라온다. 지금 당장 게임 개발 현장에서 느낄 수 있는 것들이다.
게임은 다른 소프트웨어보다 버그에 더 민감한 편이다. 유저가 직접 손으로 만지고 눈으로 본다. UI 하나가 살짝 틀려도 바로 커뮤니티에 올라온다. 라이브 서비스 중이면 버그가 곧 매출과 이어진다.
그래서 AI 코드가 늘어나는 흐름은, 게임 팀에게는 특히 조심스러운 이야기다. 속도는 분명히 빨라진다. 그런데 버그의 성격이 바뀌면서, 사후 대응의 비용이 함께 올라가는 구조가 될 수 있다.
결국 이 이야기의 끝은 "AI 코드를 쓰지 말자"가 아니다. AI 코드가 늘어날수록, 그 코드를 사람이 얼마나 이해하고 있는가가 팀의 실질적인 위험 수준을 결정한다는 것이다. 디버깅 능력은 예전보다 더 중요해졌다. 방법만 조금 달라졌다.
결론을 내리는 대신, 질문을 남긴다. 이번 주 점심 자리에서 한 번쯤 꺼내볼 만한 것들이다.
구분이 된다면 어떻게 되어 있는가. 구분이 안 된다면, 버그가 났을 때 어떻게 접근하고 있는가. 지금 방식이 충분하다고 느끼는가.
AI를 쓰자고 결정한 사람인가. 그 코드를 리뷰한 사람인가. 프로덕션에 넣은 사람인가. 아니면 AI 도구 자체인가. 팀 안에서 이 기준이 맞춰져 있는가.
지금보다 더 많은 부분을 AI가 맡게 될까. 아니면 AI가 만든 버그를 사람이 더 깊이 파고드는 일이 늘어날까. 그때 필요한 능력을 지금 우리가 기르고 있는가.
이번 호를 쓰면서 계속 머릿속에 맴돈 장면이 하나 있었다. 버그를 앞에 두고, 코드를 읽는데, 코드는 매끄럽다. 어디가 틀렸는지는 모르겠고, 왜 이렇게 생겼는지도 모르겠다. 물어볼 사람이 없다.
이 장면이 낯설지 않다면, 이미 AI 코드와 씨름해본 사람이다. 그 경험은 불편하다. 그런데 생각해보면, 불편함 자체는 나쁜 신호가 아니다. 우리가 코드를 제대로 이해하지 않고 넣었다는 걸 버그가 알려주는 것이기 때문이다.
디버깅이 번역이 됐다는 말을 이 호에서 썼다. 번역가는 두 언어를 모두 알아야 한다. AI 코드가 늘어나는 지금, 우리가 키워야 할 능력은 "AI에게 더 잘 시키는 것"만이 아니다. "AI가 만든 것을 우리가 얼마나 이해하고 있는가"를 계속 점검하는 것이기도 하다. 그 점검을 게을리하면, 버그는 더 조용하고 더 자신감 있게 숨어든다.
버그가 새로워졌다고 해서 디버깅이 덜 중요해진 건 아니다. 오히려 반대일 수 있다.
— Desk γ검토 단계가 느려지면, 그 앞의 속도는 아무 의미가 없다.