AI 코딩의 위험은 코드 생성보다 이해를 넘기는 데 있다는 주장

AI에게 버그를 고치고 다음 오류도 고치라고 반복하는 과정도, 결국 AI에서 좋은 결과를 끌어내는 법을 배우는 훈련일 수 있다고 봄.

좋은 결과가 나온다는 전제가 너무 큼. 확실히 늘어나는 건 토큰 청구서뿐일 수도 있음.

AI가 못 푸는 일이 생긴다는 전제부터 의심함. 다음 모델이면 그런 일도 풀 거라고 다들 말할 테니까.

나는 제한적인 코드 작성과 디버깅에 매일 AI를 쓰는데, 출력 검토를 멈추고 생산성 쾌감 때문에 승인만 누를 때 망가진다는 데 동의함. 다만 클러스터 여러 노드의 방대한 로그를 여러 실행 결과와 대조하는 일은 혼자 합리적인 시간 안에 못 했을 문제도 AI가 찾아줬고, 그 뒤 원인은 내가 이해하면 됨.

모델의 이득을 얻으면서 어떻게 통제권을 유지한다는 건지 설명이 빠졌음. 모델이 쓴 코드를 다시 공부해야 한다면 처음부터 직접 쓰는 편이 낫다는 반론도 가능함.

제일 어려운 건 내가 무엇을 잊었는지 아는 일임. 존재조차 모르는 빈틈은 검사할 방법이 없음.

LLM 때문에 설계와 구현이 분리되는 걸 보면서, 내가 엔지니어링에서 즐겼던 부분이 무엇인지 다시 묻게 됐음. 설계 문서를 쓰고 LLM에 구현을 맡긴 뒤 문서와 맞는지 검토하는 방식은 전통 공학에 가깝지만 쉽지 않더라. 주니어라면 여러 작업 방식을 직접 실험해봐야 함.

시스템 이해와 판단력이 좋은 개발자를 가른다는 말은 원래도 맞았음. AI는 그 이해에 이르기 전 단계의 순서를 바꿨을 뿐임. 여기서 시스템에는 기술 요소뿐 아니라 운영하는 사람과 절차도 포함됨.

AI가 설계까지 못 한다고 단정하진 않음. 최첨단 문제일수록 좋은 설계에 더 많은 사고가 필요하지만, '작동은 함' 수준도 가치가 있고 AI가 평균적인 설계를 많이 만들면 과도하게 복잡한 해법은 줄어들 수 있음.

왜 작동하는지 몰라도 해결책을 받아들이고 넘어가는 일은 삶 전반에 많음. 숙련자는 무엇을 깊게 파야 하는지와 어느 수준이면 충분한지를 구분하고, 그 판단도 시스템 직관에서 나옴.

안전 요구가 다른 분야를 구분해야 함. 터빈을 제어하는 PLC 코드는 모든 버그와 코드 줄을 사람이 이해할 가치가 있지만, 게임의 멀티플레이 키 바인딩 오류까지 완전한 디버깅 과정을 추적하는 건 시간 낭비일 수 있음. 대신 화면의 물고기 500마리를 GPU와 CPU 중 어디서 처리할지 같은 한계 조건은 반드시 이해해야 함.

영향 규모가 기준임. 그 게임을 구독료 내는 100만 명이 하고 있었다면 그 키 바인딩 버그도 끝까지 파고들 가치가 생김.