제 코드에 AI 리뷰봇을 붙여뒀습니다. 코드를 올리면 알아서 읽고 “여기 문제 있어요” 하고 코멘트를 달아주는 도구예요.
코드 리뷰: 코드를 합치기 전에 다른 사람이 읽고 문제를 짚어주는 절차. 그 일을 사람 대신 AI가 해주는 게 리뷰봇입니다. 저처럼 혼자 개발하면 봐줄 사람이 없으니 특히 반갑죠.
처음엔 무조건 고마웠습니다. 혼자 하는 작업이라 잘못을 짚어줄 사람이 없는데, 봇이 대신 봐주니까요. 그래서 지적이 뜨면 일단 고쳤습니다. “AI가 그렇다면 그런 거겠지” 하고요.
그런데 어느 하루, 같은 봇이 오전에는 맞고 오후에는 틀렸습니다. 그날 제가 뭘 보고 갈랐는지 정리해두려고 합니다.
1라운드 — 봇이 맞았습니다
제가 글의 분량을 재는 작은 스크립트를 만들었습니다. 규칙 문서에는 이렇게 적어놨어요. “분량은 공백을 포함해서 센다.”
봇이 지적했습니다. 규칙엔 공백을 포함한다고 써놓고, 정작 코드는 공백을 지우고 세고 있다고요.
맞는 말이었습니다. 규칙과 코드가 서로 다른 말을 하고 있었어요. 더 뼈아픈 건 그 스크립트를 만든 목적이 “정확하게 재기” 였다는 겁니다. 정확하게 재려고 만든 도구가 부정확했던 거죠. 봇이 아니었으면 한참 못 봤을 겁니다.
여기서 짚고 싶은 건, 이 지적이 “코드가 틀렸다”가 아니라 “코드와 문서가 어긋난다” 였다는 점입니다. 코드만 보면 아무 문제가 없어요. 잘 돌아갑니다. 규칙 문서와 나란히 놓고 봐야 어긋남이 보입니다. 이런 건 사람이 놓치기 딱 좋은데, 봇은 둘을 같이 읽으니 잘 잡습니다. 봇이 잘하는 영역이 분명히 있습니다.
2라운드 — 같은 봇이 틀렸습니다
몇 시간 뒤, 문서를 하나 고쳐 올렸습니다. 그 안에 output\_wordpress-blog\ 같은 윈도우 경로가 들어 있었어요.
봇이 지적했습니다. 요약하면 이렇습니다.
백틱 바로 앞에 역슬래시가 있으면 백틱이 이스케이프돼서, 코드 표시가 제대로 닫히지 않고 뒤 본문이 통째로 깨질 수 있다.
백틱(‘): 글에서 코드를 표시 할 때 감싸는 기호입니다.
이스케이프: 특수문자를 “기능”이 아니라 “그냥 글자”로 취급하게 만드는 것. 여기선 역슬래시(\)가 뒤에오는 백틱의 기능을 죽인다는 주장이었어요.
그럴듯했습니다. 게다가 봇은 친절하게 수정안까지 붙여줬어요. 예전 같으면 그냥 눌렀을 겁니다.
그럴듯한데, 확인은 해봤나?
여기서 잠깐 멈췄습니다. 봇의 설명이 논리적으로 들리긴 하는데, 제가 그걸 직접 본 적은 없다는 게 걸렸어요.
수학 문제도 답이 그럴듯하다고 넘기면 안 되잖아요. 검산을 해봐야 압니다.
찾아보니 마크다운 표준(CommonMark) 명세에 이렇게 적혀 있었습니다. “코드 스팬 안에서는 백슬래시 이스케이프가 작동하지 않는다.”
CommonMark 명세: 마크다운 문법의 표준 규격서. “이렇게 쓰면 이렇게 보여야 한다”를 정해둔 문서입니다. 코드 스팬: 백틱으로 감싼 짧은 코드 표시 부분.
즉 봇의 주장은 일반적인 문장에서는 맞지만, 백틱 안에서는 성립하지 않는 이야기였습니다. 명세가 그렇게 말하고 있었어요.
그래도 명세를 읽은 것만으로는 부족했습니다. 명세와 실제 프로그램이 다르게 동작하는 일은 흔하니까요. 그래서 실제로 렌더링해봤습니다.
렌더링: 마크다운 문법으로 쓴 글을 실제 보이는 화면(HTML)으로 바꾸는 것.
두 군데에 돌렸습니다. 하나는 제가 쓰는 변환 도구, 다른 하나는 깃허브 자체 렌더러였어요. 두 번째가 특히 중요했습니다. 이 문서를 실제로 보여주는 게 깃허브이니, 깃허브가 어떻게 그리는지가 진짜 답이거든요. 남의 도구에서 잘 되는 건 의미가 없습니다.
결과는 둘 다 정상이었습니다. 코드 표시가 정확히 닫혔고 본문도 멀쩡했어요. 봇이 말한 깨짐은 일어나지 않았습니다.
두 번째 지적은 “맞지만 안 맞았다”
봇은 하나를 더 제안했습니다. “경로를 역슬래시(\) 대신 슬래시(/)로 쓰라” 는 거였어요. 플랫폼에 상관없이 안전하다고요.
일반론으로는 맞는 말입니다. 그런데 제 프로젝트에는 안 맞았습니다.
- 이 프로젝트는 윈도우 전용입니다. 다른 OS를 고려할 이유가 없어요.
- 다른 문서들이 이미 역슬래시로 통일돼 있습니다. 여기만 바꾸면 표기가 갈립니다.
- 그 경로는 제가 탐색기에 그대로 붙여넣는 실제 값입니다. 슬래시로 바꾸면 오히려 틀린 표기가 돼요.
이게 제가 그날 배운 두 번째 갈래입니다. “맞는 말”과 “여기서 맞는 말”은 다릅니다. 봇은 일반적인 모범답안을 압니다. 하지만 제 프로젝트의 사정은 모르죠. 교과서 정답이 이 문제의 정답이 아닐 수 있는 것과 같습니다.
그래서 뭘 보고 가르나
두 라운드를 겪고 나서 제 기준이 생겼습니다. 지적이 오면 질문을 두 개 던집니다.
| 질문 | 확인 방법 | 결과 |
|---|---|---|
| ① 이게 사실인가? | 말이 되는지 따지지 말고 직접 돌려본다 | 1라운드 ✅ 사실 → 수용 |
| 2라운드 ❌ 재현 안 됨 → 거부 | ||
| ② 사실이라도, 여기에 맞나? | 내 프로젝트 사정과 대조한다 | 슬래시 제안 ❌ 안 맞음 → 거부 |
표를 이렇게 읽으시면 됩니다. ①을 통과해도 ②에서 걸릴 수 있습니다. 슬래시 제안이 그랬어요. 틀린 말이 아니었는데 제 상황에 안 맞았죠. 반대로 ①에서 이미 탈락하면 ②는 볼 필요도 없습니다.
그리고 ①의 확인 방법이 핵심입니다. “말이 되는가”가 아니라 “돌려보면 그런가” 예요. 봇의 설명은 항상 말이 됩니다. 문장을 매끄럽게 쓰니까요. 그럴듯함으로는 진위를 못 가립니다.
한 문장으로 요약하면: AI 지적은 “타당한가”와 “여기서 무해한가”를 갈라서 보고, 그 판단은 추측이 아니라 직접 돌려본 결과로 한다.
마무리
이 일에서 제일 크게 남은 건 양쪽 다 손해라는 감각입니다.
봇이 맞을 때 고집부리면 진짜 버그를 안고 갑니다. 1라운드가 그랬어요. 제가 “내 코드는 멀쩡해”라고 우겼으면 부정확한 측정 도구를 계속 썼을 겁니다. 반대로 봇이 틀릴 때 따라가면, 멀쩡한 걸 망가뜨립니다. 2라운드에서 봇 말대로 고쳤으면 잘 되던 문서를 건드려놓고 “고쳤다”고 믿었겠죠.
무조건 따르는 것과 무조건 무시하는 것은 사실 같은 태도입니다. 둘 다 확인을 안 하는 거예요. 편한 만큼 대가가 있습니다.
그래서 요즘은 지적이 뜨면 먼저 재현부터 해봅니다. 3분이면 끝나고, 그 3분이 “고칠지 말지”를 확실하게 갈라줍니다. 봇을 믿을지 말지 고민하는 것보다 훨씬 빠르더라고요.
혼자 코딩하는 분들께 특히 권하고 싶습니다. 봐줄 사람이 없으니 봇이 반갑고, 반가운 만큼 무비판적으로 받아들이기 쉽거든요. 봇은 훌륭한 조수지 채점자가 아닙니다. 최종 판단은 여전히 내 몫이에요.
한글 글자수를 셌더니 3배가 나왔습니다 — 바이트와 글자는 다르다
제가 쓴 명령은 유닉스의 wc라는 도구였습니다. 글자수를 세라고 wc -m을 줬죠.
wc: 유닉스 계열에서 글자·단어·줄 수를 세어주는 기본 도구.
-m은 “글자(character) 수를 세라”는 뜻입니다.
그럼 -m은 왜 바이트를 셌나
여기가 진짜 함정입니다. wc -m은 원래 글자를 셉니다. 단, 조건이 있어요. “이 시스템이 지금 어떤 언어·인코딩을 쓰는지”를 알려주는 설정(로케일)이 있어야 글자로 셉니다. 그 설정이 비어 있으면, wc는 “몰라, 그냥 바이트로 셀게” 하고 물러납니다.
로케일(locale): 시스템이 쓰는 언어·지역·인코딩 설정. 이게 있어야 프로그램이 한글을 “3바이트짜리 글자”로 제대로 인식합니다.
제 환경은 그 설정이 비어 있었어요. 그래서 -m을 줬는데도 글자가 아니라 바이트를 세어버린 겁니다. 명령은 맞게 줬는데, 환경이 그 명령의 전제를 안 갖추고 있었던 거죠.
확인: 3글자가 9로 나오나
원인을 추측만 하고 넘어가면 안 됩니다. 직접 확인해봤어요. 가나다 세 글자를 넣어봤습니다.
printf '가나다' | wc -m
# 결과: 9
3이 나와야 하는데 9가 나왔습니다. 딱 3배. 이걸로 “바이트를 세고 있다”가 확실해졌습니다. 세 글자 × 3바이트 = 9바이트니까요.
해결: ‘글자’를 확실히 세는 도구로 바꾼다
로케일 설정을 고칠 수도 있지만, 그건 환경마다 다르고 또 비어 있으면 같은 문제가 재발합니다. 그래서 아예 글자를 확실하게 세는 방법으로 바꿨습니다. 저는 윈도우라 PowerShell을 쓰는데, 여기선 문자열의 .Length가 항상 글자 수를 돌려줍니다(바이트가 아니라).
('가나다').Length # 결과: 3
같은 가나다인데 이건 정확히 3입니다. 바이트가 아니라 글자를 세는 도구를 쓰니 문제가 사라졌어요.