AI가 쓴 코드를 다 이해하지 못한 채 배포하는 현실과 개발자들의 대응

해커뉴스에 "이해하지 못하는 AI 작성 코드를 어떻게 다뤄야 하나"라는 질문이 올라와 개발자들의 경험담이 이어졌다. 게시자 rzk는 메타에서 일하는 엔지니어가 링크드인에 남긴 글을 인용하며, 요즘 자신이 쓰는 코드가 블랙박스처럼 느껴진다는 토로에 공감을 표했다. 11점에 댓글 19개가 달린 작은 스레드지만, 내용은 실무의 구체적인 고민을 담고 있다.

인용된 메타 엔지니어가 꼽은 불편함은 두 갈래다. AI가 만든 코드를 한 줄씩 확인하면 작업 속도가 나오지 않고, 검토를 건너뛰면 전체 구조는 알아도 세부 동작은 파악하지 못한 시스템이 남는다는 것이다. "내가 만드는 것을 이해한다"는 엔지니어의 기본 전제와 정면으로 부딪히는 지점이다.

댓글의 반응은 크게 세 방향으로 갈렸다. 먼저 체념이다. 한 사용자는 시간이 지나면 받아들이게 된다고 짧게 적었고, 코드가 못생겼다는 평가가 나와도 일단 배포하라는 식의 농담도 붙었다. 다음은 런타임 방어다. 한 댓글러는 코드를 전부 읽는 대신 관측 가능성과 교차 검증, 알림을 두껍게 깔아 위험을 상쇄한다고 설명했다.

절차를 앞단에 두는 접근도 나왔다. 기능을 먼저 브레인스토밍하고 개발 계획을 세우면서 이미 보유한 코드와 라이브러리를 재사용하도록 지시한 뒤, 결과물을 놓고 접근 방식과 개선점을 되짚는 방식이다. 은퇴한 개발자라는 한 댓글러는 계획 단계에서 예외 상황과 테스트 케이스를 오래 다듬고, 체크인을 작게 유지하며, 여러 아키텍처에서 몇 시간씩 도는 릴리스 게이트를 붙여 6개월가량 운영해 왔다고 밝혔다. 그는 AI가 만든 코드 품질이 나쁘지 않았고, 오래 함께 일한 동료의 버릇에 적응하는 것과 비슷했다고 덧붙였다.

이 개발자가 만들고 있다는 자동 벡터화 컴파일러 사례에는 수치도 함께 제시됐다. clang으로 LLVM IR을 만든 뒤 자체 IR로 변환해 벡터화기에 넘기는 C 프런트엔드 실험에서, saxpy는 1,546µs에서 726µs로(2.1배), Mandelbrot은 394,238µs에서 2,110µs로(187배), nbody는 37,090µs에서 1,035µs로(36배), perlin은 78,016µs에서 1,850µs로(42배), mandel_deep은 73.2초에서 55.8ms로(1,312배) 빨라졌다는 결과다. 체크섬이 일치하는지로 정확성도 확인했다고 하며, C++ 프런트엔드는 다음 주쯤 준비된다고 한다.

왜 이런 논의가 나오는지는 댓글창의 다른 목소리에서 드러난다. 한 사용자는 블라인드에 올라온 메타 관련 글을 근거로, 병렬로 처리해야 하는 PR 수 때문에 상세한 계획을 세울 시간 자체가 없다고 주장했다. 또 다른 댓글러는 제품은 코드 이해 여부에 관심이 없으며 엔지니어링 인력 상당수가 유지보수 역할로 재편될 것이라고 내다봤다. 다만 이는 검증되지 않은 개인 전망이다.

실무적 함의는 "개념적 압축"이라는 비유로 정리된다. ORM이 SQL을 대신 감춰 주듯 AI가 구현 세부를 감춰 주지만, 장애가 나거나 데이터가 커지면 결국 밑단을 이해해야 한다는 것이다. 다만 그 중요도는 무엇을 배포하느냐에 따라 달라진다. 소셜 미디어 앱과 의료 영상 장비나 항공우주 소프트웨어에서는 같은 기준을 적용하기 어렵다.

이 스레드는 어디까지나 익명 게시판의 경험담 모음이다. 메타 엔지니어의 발언은 링크드인 글을 거쳐 인용된 것이고, 인력 재편 전망이나 사내 PR 압박에 관한 서술은 당사자 확인을 거치지 않았다. 벤치마크 수치도 개인 프로젝트의 자체 측정 결과이며, 사례를 공유한 개발자는 의사결정권자 없이 혼자 일하는 은퇴 개발자라고 스스로 밝혔다.