AI 코딩을 쓰면서 직접 코딩 훈련도 해야 한다

AI가 소프트웨어 개발을 맡게 하는 방법을 찾으려는 시도가 이어지고 있다. 항공업계는 자동화와 함께 일하는 법을 오래전부터 고민해 왔다. 이 글은 소프트웨어 엔지니어도 항공기 조종사처럼 자동화를 활용하되 직접 조종하는 능력을 훈련해야 한다고 주장한다.

여러 시간 비행하는 조종사는 이륙과 상승 일부, 착륙 직전 정도만 직접 조종하고 나머지는 자동화에 맡기기도 한다. 그래도 조종사들은 자동화가 작동하는 동안 감시하며, 정기적으로 비싼 비행 시뮬레이터에서 자동화를 끈 채 엔진 화재나 유압 고장 같은 상황을 훈련한다. 사용하지 않는 기술은 조용히 퇴화하기 때문이다.

항공업계가 자동화에 대응한 방식

1914년 로런스 스페리(Lawrence Sperry)는 자이로컴퍼스를 바탕으로 자이로스코프 안정 장치를 개발했다. 파리 시연에서 자동화 장치는 스페리가 조종석에서 손을 든 상태에서도 항공기를 수평으로 유지하고 항로를 따르게 했다. 자동 비행은 비행의 역사만큼이나 오래됐다.

자동화는 계속 발전했다. 미군 C-54는 1947년 자동 제어로 대서양을 횡단해 당시 보도에 등장했다. 자동 착륙은 1960년대 여객기에 도입됐고, 1980년대 후반에는 Airbus A320이 디지털 플라이바이와이어를 여객기에 적용했다. 시뮬레이터가 조종사 훈련에 쓰이기 시작했지만, 수십 년 동안 미국 항공사 훈련에서는 자격 심사의 기본을 넘는 수동 조종 훈련이 많지 않았다. 자동화가 잘 작동하자 수동 조종은 일상에서 점차 사라졌다.

2009년 두 차례 추락 사고가 논의를 바꿨다. 2월 Colgan Air Flight 3407은 실속 경고에 승무원이 요구되는 조치와 반대로 대응한 뒤 추락했다. 6월에는 속도 센서가 얼음으로 막혀 자동조종장치가 해제된 뒤, 순항 고도에서 갑자기 수동 조종을 맡은 승무원들이 항공기의 상태를 파악하지 못해 Air France 447이 대서양에서 실종됐다. 두 사고의 조사에서는 조종사들이 훈련을 충분히 받지 못했고 자동화에 지나치게 의존해 수동 조종 기술과 직감을 잃었다는 문제가 지적됐다.

2013년 초 미 연방항공청(FAA)은 항공사에 수동 비행을 장려하라는 안전 경보를 발표했다. 같은 해 의회의 지시에 따라 새로운 훈련 규정이 마련돼 조종사들은 실속 회복과 비정상 자세 회복 등을 연습하게 됐다. 현재 미국 항공사 조종사들은 기종별로 느린 속도 비행, 신뢰할 수 없는 속도 정보에 대응하는 법 등을 정기적으로 훈련한다.

AI 코딩에서도 필요한 감시와 훈련

이 글은 소프트웨어 업계가 규제기관의 개입 없이 항공업계의 역사를 되풀이하고 있다고 본다. 한쪽에는 AI 도구를 거부하고 모든 코드를 직접 써야 한다는 사람들이 있다. 기술이 중요하다는 점은 맞지만, 도구를 거부하는 것이 기술을 지키는 방법은 아니라는 주장이다. 다른 쪽에는 몇 달 동안 직접 조건문을 쓰지 않고, 원하는 내용을 설명해 AI가 만든 코드와 테스트를 확인한 뒤 배포하는 사람들이 있다. 코드가 어떻게 작동하는지 물으면 답하지 못하는 상황도 생긴다고 글은 지적한다.

AI가 만든 코드는 컴파일러가 생성한 어셈블리와 다르다. 컴파일러 출력은 보통 직접 검토하거나 확장하지 않으며, 문제가 생기면 원본 코드를 고쳐 다시 컴파일한다. 반면 AI가 만든 코드는 팀이 읽고 수정하며 장애 상황에서 설명해야 하는 소스 코드다. 자동화 사용 여부만 따질 것이 아니라, 자동화를 쓰면서도 조종사로서의 기술을 어떻게 유지할지 물어야 한다는 것이다.

AI 보조 코딩은 반복 작업을 덜고, 사람보다 더 안정적으로 고도를 유지하는 자동조종장치처럼 개발자의 주의를 덜 소모하게 할 수 있다. 그만큼 사람은 무엇을 만들지, 코드 구조가 적절한지, 나중에 이해하고 바꿀 수 있는지, 장애가 나면 누가 대응할지에 집중해야 한다.

하지만 자동화가 항상 뚜렷한 경고와 함께 멈추는 것은 아니다. 2013년 Asiana 214는 맑은 날 샌프란시스코에서 방파제에 부딪혔다. 자동 스로틀이 속도를 유지하지 않는 모드로 바뀌었지만 승무원들은 수동으로 상황을 구할 수 있는 때가 지난 뒤에야 이를 알아챘다. 대부분의 접근 과정에서 자동화는 승무원들이 생각한 것과 다르게 조용히 작동하고 있었다.

글은 AI 생성 코드의 실패도 이와 비슷할 수 있다고 경고한다. 새벽 2시에 발생한 운영 장애에서 생성 코드가 미묘하게 잘못 작동하면, 개발자는 압박 속에서 코드를 읽고 이해해 고쳐야 한다. 도구가 모듈 절반을 자신 있게 리팩터링했을 때 결과가 여전히 올바른지 판단하는 일도 사람의 몫이다. 이를 알아챌 경보는 없으며, 무엇이 올바른지 아는 사람만이 경고 체계가 될 수 있다는 주장이다.

항공기에는 비행 경로를 책임지는 조종사와 계기를 확인하고 이상을 알리는 감시 조종사가 있다. AI 보조 개발에서는 엔지니어 한 명이 두 역할을 모두 맡는 경우가 많다. 배포 결과에 책임지는 동시에 AI가 만든 코드를 검토한다. 글은 코드를 요청한 사람이 유일한 검토자가 되어서는 안 되며, 검토자는 대화 기록을 열지 않고도 변경 내용을 설명할 수 있어야 한다고 제안한다. 다만 감시 능력은 가장 빨리 퇴화하는 기술이라고 지적하며, 이를 뒷받침하는 연구 자료를 연결한다.

AI 도구를 금지하는 것은 고생을 기술과 혼동하는 일이며, 도구를 쓰는 것은 허용하되 “AI가 이해했으니 나도 알 필요가 없다”고 여기는 것은 자동화의 능력을 자신의 능력으로 착각하는 일이라는 게 글의 논지다. 항공업계는 수동 조종을 선택 사항으로 두지 않고 의무화하고 일정에 넣어 확인했다. 조종사가 시뮬레이터 훈련을 하기 싫다고 선택할 수는 없다.

팀에 맞는 ‘시뮬레이터’ 훈련

소프트웨어 엔지니어도 자동조종장치를 끄고 정기적으로 의도적인 연습을 해야 한다는 것이 글의 제안이다. 이는 처벌이나 순수성 시험이 아니라 기계를 감독할 자격을 유지하는 훈련이다. 시뮬레이터는 숙련자의 기술을 유지하는 데만 쓰이지 않는다. 항공사 조종사들은 새 기종 자격을 딸 때 실제 기종을 타 보지 않고 훈련을 마친 뒤, 훈련 기장과 함께 첫 상업 비행을 하기도 한다. 글은 비슷한 훈련이 신입 엔지니어를 키우는 방법이 될 수 있다고 본다.

글은 팀 상황에 따라 다음과 같은 방안을 예로 든다. 이는 보편적인 교육 과정이 아니라 논의를 위한 제안이다.

• 출시를 서두르는 스타트업은 몇 주에 한 번 오후 한나절 동안 AI 도움 없이 일할 수 있다. 최근 AI 생성 코드 PR을 도구를 닫은 채 줄 단위로 검토하거나, 과거 장애를 직접 재현해 디버깅하는 방식이다.
• 규모가 크고 신중한 조직은 분기별로 AI를 끈 장애 훈련을 하고, 정기적으로 하루 동안 도움 없이 일할 수 있다.
• 신입 중심 팀은 입사 후 처음 몇 달 동안 세 번째 티켓마다 AI 도움 없이 처리하게 하고, 선임과 짝을 이뤄 배포 전에 “왜 작동하는가?”를 묻도록 할 수 있다.

연습 빈도와 대상 작업은 팀마다 다를 수 있다. 중요한 것은 이를 개인의 의지에만 맡기지 않는 일이라고 글은 주장한다. 조종사들이 성실해서 시뮬레이터를 찾는 것이 아니라 규정과 일정이 있고 누군가 확인하기 때문에 훈련한다는 설명이다. 엔지니어가 실제로 새벽 장애를 해결하고, 검토자가 잘못된 마이그레이션을 찾아내며, 신입이 프롬프트 작업자에 머물지 않고 숙련자로 성장하기를 바라는 관리자라면 훈련 시간을 확보해야 한다. 금융·의료·인프라 분야에서는 규제기관의 요구가 있을 수도 있다.

AI를 활용하되, 중요한 순간에 직접 조종할 수 있어야 한다. 자동조종장치가 대부분의 시간 동안 일하게 하면서도 불이 나지 않았을 때 일부러 직접 조종하는 연습을 해야 한다는 것이 이 글의 결론이다.