안녕하세요? 정리하는 개발자 워니즈입니다.
AI 가 만든 가장 큰 변화는 코드를 더 잘 쓰게 된 것이 아니라 사람이 읽고 검토하는 속도보다 코드가 만들어지는 속도가 빨라진 것이고 그 격차는 코드 리뷰 자리에서 가장 먼저 드러났습니다. 필자도 검사를 자동화해두면 이 격차가 저절로 메워질 것이라고 기대하고 있었는데요 막상 겪어보니 검사기가 통과를 내주면서 정작 그 항목을 보고 있지 않던 자리가 몇 군데 있었던 것 같습니다.
당장 쓸 수 있는 기준은 한 줄인데요 검사기가 통과라고 말했을 때 그 말을 믿는 대신 이미 틀린 줄 아는 옛 원고를 다시 집어넣어 정말 막히는지 확인하는 것입니다.
- 검사가 통과한 것은 사실이었고 틀린 것은 그 통과를 안심으로 읽은 쪽이었습니다.
- 검사 대상이 아닌 항목의 결함은 그 검사로 구조적으로 잡히지 않습니다.
- 검사 범위는 한 번 정하면 끝나는 설정이 아니라 계속 조정해야 하는 판단이었습니다.
통과했다는 보고보다 막혔다는 확인이 훨씬 믿을 만합니다. 검사기를 고칠 때마다 이미 틀린 줄 아는 원고를 되넣어 정말 차단되는지 같이 봅니다.
코드가 만들어지는 속도가 읽는 속도를 앞질렀습니다
GeekNews 에 올라온 코드를 다 읽을 수 없게 된 상황을 다룬 글을 읽었는데요 글쓴이는 AI 가 가져온 가장 큰 변화를 코드 품질이 아니라 속도의 역전으로 정리하고 있었습니다. 코드가 만들어지는 속도가 사람이 읽고 판단하는 속도를 넘어서면 그 격차가 가장 먼저 드러나는 자리는 코드 리뷰이고 리뷰가 맡아온 책임인 의도 확인과 트레이드오프 판단은 없어지는 대신 다른 곳으로 옮겨간다는 이야기였습니다. 필자는 이 주장을 개인 블로그 자동 발행 장치에 그대로 대입해보고 싶었는데요 마침 그 장치에도 발행 전 검사를 자동화해둔 항목이 여러 개 있어서 옮겨간 책임이 어디에 쌓였는지 확인해볼 수 있었습니다.
검사가 통과했는데 왜 결함이 남아 있었을까요?
검사가 보는 범위와 결함이 앉아 있는 자리가 다르면 통과는 사실이면서도 아무것도 보장하지 않습니다. 검사기는 자기가 세도록 정해진 것만 세기 때문에 대상 밖의 결함은 통과 표시와 함께 그대로 발행됩니다. 그래서 통과라는 결과를 볼 때 같이 물어야 하는 것은 무엇이 검사되지 않았는지입니다.
필자가 겪은 첫 번째 함정이 정확히 이 모양이었는데요 발행 전 문체 검사 항목이 정상을 내줬는데 그 검사는 본문 텍스트만 세고 있었고 제목은 애초에 검사 대상이 아니었습니다. 그러니 제목이 어색하다는 결함은 그 검사로는 잡을 방법이 없었고 실제로 구글 검색결과에서 제목이 다시 쓰인 사례를 확인하고 나서야 제목 쪽을 들여다보게 됐습니다. 통과 자체는 거짓이 아니었고 틀린 것은 통과를 보고 제목까지 괜찮다고 넘긴 필자의 판단이었던 것 같습니다.
검사기가 못 보는 형태로 문제가 숨어 있었습니다
두 번째는 같은 검사를 통과한 글에서 나왔는데요 걸러내야 할 값이 본문 문장이 아니라 이미지 안에 픽셀로 그려져 있던 경우였습니다. 검사기는 글자를 읽는 도구이므로 그림 안에 들어간 값은 처음부터 보이지 않았고 사람이 이미지를 직접 열어봐야만 드러나는 상태로 남아 있었습니다. 규칙을 장치로 옮겨두면 사람이 기억할 일이 줄어드는 것은 맞지만 규칙을 장치로 옮길 때 남는 구멍이 바로 이런 자리인 것 같습니다. 장치가 읽을 수 없는 형식으로 내용이 들어가면 규칙은 살아 있는데 검사만 조용히 비게 됩니다.
검사 범위를 넓히면 왜 오탐이 늘어날까요?
범위를 넓히면 무관한 문장까지 걸리고 조건을 좁히면 다시 놓칠 여지가 생깁니다. 두 방향의 실수는 한쪽을 줄이면 다른 쪽이 늘어나는 관계라서 한 번의 설정으로 정답을 고정할 수 없습니다. 그래서 검사 범위는 설정이 아니라 계속 손보는 판단으로 다루는 편이 맞습니다.
세 번째 함정이 여기였는데요 검사 항목을 하나 추가했더니 이번에는 전혀 무관한 문장이 걸러낼 값으로 잡혔습니다. 한 번에 다 지우지 말고 1,000건 단위로 나눠 돌린다는 배치 크기 설명이었는데 숫자와 단위가 붙어 있다는 이유로 검사에 걸린 것이었습니다. 조건을 좁혀서 이 오탐은 없앴지만 좁힌 만큼 다시 못 보는 구간이 생겼다는 사실도 같이 남았습니다.
검사기가 잡는 것과 사람이 봐야 하는 것을 갈라봤습니다
세 가지를 겪고 나서 항목별로 경계를 적어두니 어디까지 장치에 맡길 수 있는지가 훨씬 분명해졌습니다.
| 항목 | 검사기가 판정하는 범위 | 사람이 직접 봐야 하는 부분 |
|---|---|---|
| 문체 | 본문 텍스트 | 검사 대상에서 빠진 제목 |
| 걸러낼 값 | 글자로 적힌 문장 | 이미지 안에 그려진 값 |
| 검사 범위 | 정해둔 조건에 맞는지 | 조건을 어디까지 좁힐지 |
| 통과 판정 | 규칙 위반이 없다는 사실 | 그 규칙이 결함을 덮는지 |
통과 보고 대신 옛 원고를 되넣어 확인합니다
그래서 방법을 바꿨는데요 검사기가 내놓는 통과 보고를 근거로 삼지 않고 이미 틀린 줄 아는 옛 원고를 다시 집어넣어 정말 차단되는지 봅니다. 통과는 검사가 그 항목을 보고 있다는 증거가 되지 않지만 차단은 검사가 그 자리를 실제로 보고 있다는 증거가 되기 때문인데요 이 차이는 AI 가 내놓는 완료 보고를 확인해본 기록에서 겪은 것과 성격이 같습니다. 완료했다는 말과 완료됐다는 확인은 다른 정보이고 검사기의 통과도 같은 자리에 놓입니다.
지금은 검사기를 고칠 때마다 이 되넣기 확인을 같이 돌리고 있는데요 항목을 새로 추가한 날에는 그 항목이 잡아야 하는 옛 원고를 먼저 준비하는 편이 순서상 편했습니다. 손이 조금 더 가지만 검사가 살아 있는지를 매번 눈으로 보게 되니 통과 표시를 안심으로 오해할 일이 줄어들었습니다.
코드 리뷰가 맡아온 책임은 어디로 옮겨갔나
옮겨간 곳은 검사 항목을 정하고 그 검사가 정말 작동하는지 확인하는 자리였습니다. 산출물을 한 줄씩 읽어 내려가는 일은 속도 차이 때문에 점점 어려워지지만 무엇을 검사할지 고르는 판단과 그 장치가 실제로 그 자리를 보고 있는지 확인하는 일은 여전히 사람 몫으로 남습니다. 기사가 말한 책임이 사라지지 않는다는 문장은 필자 쪽 언어로도 그대로 맞았습니다.
코드 리뷰를 세 관점으로 나눠 봤던 정리에서도 사람이 남아야 하는 자리는 의도와 트레이드오프였는데요 검사를 자동화한 다음에는 거기에 검사 자체를 검사하는 일이 하나 더 붙는 것 같습니다. AI 가 산출물을 빨리 내줄수록 통과 보고를 그대로 받아들이는 습관이 가장 비싼 습관이 되어가는 것으로 보입니다.