헤드라인에서는 AI가 소프트웨어 개발자를 쓸모없게 만들 것이라고 끊임없이 말합니다. 저는 믿지 않습니다. 진짜 위험은 기계가 엔지니어링을 장악하는 것이 아닙니다. 진짜 위험은 엔지니어가 '생각하는' 고된 작업을 멈추는 것입니다.

소프트웨어는 결코 구문을 타이핑하는 작업이 아니었습니다. 그것은 언제나 머릿속에 복잡성을 담아내고, 실패 모드를 이해하며, 완벽한 옵션이 없을 때 트레이드오프를 결정하는 일이었습니다. AI는 코드를 생산하는 속도를 바꾸었지만, 왜 인간이 과정에 개입해야 하는지에 대한 이유는 바꾸지 못했습니다. 오히려 AI는 명확한 사고를 더욱 가치 있고 희소하게 만들었습니다.

초안은 엔지니어링이 아니다

점점 더 많은 주니어 개발자들이 ChatGPT나 Claude를 바로 옆자리에 앉은 시니어 엔지니어처럼 대하는 것을 목격합니다. 티켓 설명을 붙여넣고, 응답을 복사하고, 테스트를 실행한 뒤 커밋합니다. 컴파일만 되면 작업은 종료됩니다. 이 루프는 빠르고, 마찰이 없으며, 위험합니다.

AI를 사용하는 것이 문제는 아닙니다. 저도 사용합니다. 제가 아는 대부분의 생산적인 엔지니어들도 사용합니다. 문제는 AI가 그 방의 유일한 엔지니어가 될 때 시작됩니다. 단순히 작동한다는 이유로 첫 번째 솔루션을 수용하는 것은 엔지니어링이 아닙니다. 그것은 사용자의 요구사항, 비즈니스 제약 조건, 혹은 새벽 2시에 당신의 스택이 마지막으로 무너졌던 상황을 전혀 이해하지 못하는 모델에게 판단을 외주 주는 행위입니다.

거대 언어 모델은 완전히 틀렸을 때조차 불안할 정도로 자신만만하게 답변을 내놓습니다. 한 엔지니어가 AI에게 확장 가능한 아키텍처를 설계해 달라고 요청했습니다. 모델은 실제 제품에는 존재하지 않는 기능을 중심으로 상세하고 권위 있는 제안서를 내놓았습니다. 겉보기에는 정확해 보였고, 내부적으로도 일관성이 있었습니다. 하지만 그것은 쓸모없는 것이었습니다. 위험은 단순히 AI가 환각을 일으킨다는 점에 있지 않습니다. 진짜 위험은 너무 많은 사람이 그 환각을 신뢰하게 된다는 점입니다. 거짓을 찾아낼 맥락을 더 이상 파악하지 못하기 때문입니다.

마찰을 통해 배운다

제가 주니어 개발자에서 시스템을 책임질 수 있는 사람으로 성장하게 된 계기를 생각해보면, 암기했던 구문은 기억나지 않습니다. 대신 장애가 기억납니다. 직접 추적해야 했던 느린 쿼리, 운영 환경의 부하 상황에서만 나타났던 레이스 컨디션, 그리고 로컬 환경이 실제 환경과 전혀 달라서 실패했던 배포들이 기억납니다.

학습은 디버깅 과정에서 일어납니다. 코드를 수동으로 한 단계씩 따라가다 보면 시스템이 실제로 왜 실패하는지 알게 됩니다. 병목 현상이 어디서 발생하는지 발견합니다. 사용자 10명의 데모 환경에서 1만 명의 동시 요청을 처리하는 운영 시스템으로 넘어갈 때 아키텍처가 어떻게 작동하는지 배우게 됩니다. 잘 짜인 데모와 실제 운영 환경이 어떻게 다른지 뼛속 깊이 체득하게 됩니다.

그러한 지식은 생성된 답변을 수용한다고 해서 얻어지는 것이 아닙니다. 문제와 씨름하는 과정에서 얻어지는 것입니다. 만약 AI가 모든 고충을 없애주고, 코드를 쓰고, 버그를 고치고, 실패의 이유를 다 설명해 준다면, 다음 세대의 개발자들은 어떻게 시니어로서의 역량을 쌓을 수 있을까요? 경험은 다운로드할 수 있는 인증서가 아닙니다. 그것은 운영 중 발생한 사고와 실패한 배포를 통해 쌓아 올린 흉터 조직과 같습니다. 마찰을 없애버리면 성장도 사라집니다.

판단이 생성보다 중요하다

한동안 업계에서는 프롬프트 엔지니어링을 이력서에 적어야 할 뜨거운 신기술처럼

AI는 개발 라이프사이클의 거의 모든 부분을 가속화할 수 있지만, 여전히 인간의 영역으로 확고히 남아야 할 핵심 관행들이 있습니다. 시스템 설계는 비용, 지연 시간, 신뢰성, 그리고 향후 유지보수성이라는 상충하는 제약 조건들 사이의 균형을 맞추는 작업입니다. 아키텍처 리뷰는 조직의 경험적 기억과 2차적 효과를 예측하는 능력에 의존합니다. 멘토링에는 자신이 경고하려는 실패 사례들을 실제로 겪어본 사람이 필요합니다. 제품에 대한 깊은 이해는 학습 데이터를 읽는 것이 아니라, 사용자와 대화하고 실제 환경에서의 행동을 관찰하는 데서 나옵니다.

엔지니어링적 판단은 이러한 경험들의 총합입니다. 그것은 코드 리뷰를 통과했더라도, 금요일 오후에 마이그레이션을 배포하기에는 너무 위험하다고 말해주는 조용한 목소리입니다. 지금의 성능 최적화가 나중에 보안 취약점을 만들 수도 있다는 직관입니다. LLM에는 직관이 없습니다. 패턴이 있을 뿐입니다. 패턴은 유용하지만, 판단은 아닙니다.

현재 채용 중인 기업들은 단순히 AI 도구를 잘 사용하는 사람을 찾는 데 최적화하는 것을 멈춰야 합니다. AI에 의문을 제기할 수 있는 사람을 채용하십시오. 생성된 결과물을 잠시 멈춰서 주의 깊게 읽고, 왜 그것에 동의하지 않는지 설명할 수 있는 후보자를 찾으십시오. 그런 엔지니어들이야말로 생성된 코드가 복잡한 실제 운영 환경과 맞닥뜨렸을 때 시스템을 건강하게 유지해 줄 사람들입니다.

나침반 없는 가속

AI를 가속 페달이라고 생각하십시오. ~가 있는 자동차에서