AI로 인해 구현 속도는 비약적으로 빨라졌습니다. 평소 3일씩 걸릴 일을 1시간이면 완성하게 되었습니다. 그런데 속도가 붙을수록 이상하게도 출발 전에 더 오래 멈추게 되었습니다. 빠르게 만들 수 있다는 것은, 결국 잘못된 것을 빠르게 만들 수 있다는 뜻이기도 합니다. 그렇기에 무엇을 만들지 묻는 질문이 그 어느 때보다 중요해졌습니다.

AI가 내놓는 것들은 결과물이 아니라 후보입니다. 코드도, 구조 제안도, 방향도 전부 선택지입니다. 처음에는 이 속도 자체가 능력처럼 느껴졌습니다. 빠르게 뽑아낼수록 잘하고 있다는 착각을 불러일으키기도 했습니다. 그런데 후보가 많아질수록 오히려 결정이 느려지는 순간이 찾아왔습니다.

컴포넌트 구조를 설계하는 과정에서 AI에게 방향을 물었더니 세 가지 안을 동시에 내놓은 적이 있었습니다. 각각 나름의 근거가 있었고, 어느 쪽이 틀렸다고 보기도 어려웠습니다. 결국 트레이드오프를 비교하고 선택하는 데 걸린 시간이 구현보다 더 길었습니다. 빠르게 만들 수 있다는 것이 곧 빠르게 결정할 수 있다는 뜻은 아니었습니다.

AI가 생성한 결과를 그대로 쓰지 않게 된 것도 이즈음이었습니다. 검증하고, 맥락을 다시 확인하고, 이 방향이 맞는지 한 번 더 묻는 과정이 생겼습니다. 차이는 선택지를 많이 뽑는 능력이 아니라, 버리는 기준이 있는 쪽에서 났습니다.

선택보다 한 단계 앞서 해야 하는 질문이 있습니다. '무엇을 풀어야 하는가'가 바로 그것입니다. 구현 속도가 빨라졌다는 건, 동시에 잘못된 문제를 빠르게 풀어버리는 비용도 커졌다는 의미입니다. 이전에는 구현하는 데 시간이 걸렸기 때문에 중간에 방향을 돌아볼 틈이 있었습니다. 지금은 그 틈이 사라지고 있습니다. 생각 없이 진행하다 보면 다 만들어놓고 나서야 "이게 맞는 문제였나"를 묻게 됩니다.

한 번은 기능 구현을 거의 마친 시점에서, 애초에 풀어야 할 문제가 달랐다는 걸 뒤늦게 확인한 적이 있었습니다. AI 덕분에 구현 자체는 빠르게 끝났지만, 방향이 처음부터 어긋나 있었습니다. 결국 상당 부분을 다시 작업해야 했고, 총 걸린 시간은 이전과 다르지 않았습니다. 속도가 붙었다는 건, 실수의 속도도 함께 붙을 수 있다는 의미였습니다.

좋은 편집자는 원고를 직접 쓰지 않지만, 무엇이 좋은 글인지 안다고 합니다. 개발자의 역할도 그쪽으로 이동하고 있다는 생각이 들었습니다. 요구사항을 얼마나 빠르게 구현하는가보다, 어떤 문제를 풀어야 하는지를 먼저 묻는 사람. 1편에서 AI가 "더 본질적인 질문에 집중할 수 있게 해줬다"고 했던 그 본질적인 질문이 바로 이것이었습니다.

결국 이런 판단력은 맥락을 많이 가진 사람, 그리고 실패를 해석할 줄 아는 사람에게서 옵니다. AI는 실패를 해석해 주지 않습니다. 무엇이 틀렸는지, 왜 그 방향이 아닌지를 설명하는 것은 여전히 사람의 몫입니다.

AI 시대의 역량은 생성이 아니라 해석에 가깝습니다. 더 많이 만들어내는 것이 아니라, 만들어진 것들 사이에서 무엇이 맞는지를 아는 것. 그리고 그 감각은 경험이 쌓이고 실패가 누적될수록 조금씩 선명해집니다. 더 나아가 같은 문제를 다른 시각으로 보는 사람이 곁에 있을 때, 판단은 더 단단해집니다.