AI가 코드를 써도 엔지니어의 책임은 남는다

코딩 자동화가 곧 엔지니어링 자동화를 뜻하지는 않는다. 소프트웨어 엔지니어링에는 정답이 하나로 정해지지 않는 선택과 위험이 따르며, 이 때문에 당분간 사람은 설계의 절충점을 이해하고 결과에 책임져야 한다는 의견이다.

모델은 빠르게 발전했고, 에이전트가 밀레니엄 문제 하나를 풀었다. 다리오는 2월에 엔지니어가 6~12개월 안에 일자리를 잃을 것이라고 말했다. 하지만 글쓴이는 AI 코딩 능력이 1년 전과 대체로 비슷하다고 느끼며, 엔지니어링의 종말을 말하기는 이르다고 본다. 에이전트 실행 환경 같은 인프라는 크게 개선됐지만, 엔지니어링 자체는 아직 해결되지 않았다는 주장이다.

이 주장의 근거는 소프트웨어의 목적을 명확한 수식으로 정의하기 어렵다는 데 있다. ‘좋은 사용자 경험’이나 분산 시스템의 ‘가용성’은 엄밀한 명세로 표현하기 쉽지 않다. 목적을 정의하더라도 가능한 프로그램과 입력의 조합이 방대하고, 어떤 접근이 옳았는지는 몇 달이나 몇 년이 지나야 드러날 수 있다. 따라서 도메인 지식을 가진 사람이 가정과 절충점, 아키텍처를 선택해야 한다는 설명이다.

이런 선택에는 위험을 감당할 주체도 필요하다. 글쓴이는 AI의 의사결정 과정을 이해하기 어렵고, 특정 작업에서 어떻게 수행할지 미리 알기 힘들다고 주장한다. 반면 사람은 동료와 공유하는 이해와 이해관계를 바탕으로 신뢰를 쌓을 수 있다고 본다. 특히 ‘사용자 경험이 좋은가’처럼 검증하기 어려운 판단이나, 소프트웨어 구조를 바꿔 검증을 쉽게 만드는 일에서는 현재 사람이 더 강한 경우가 있다고 덧붙인다. AI가 이런 어려운 작업에서 큰 폭으로 발전하지 않는 한, 당분간 이 역할은 바뀌기 어렵다는 견해다.

그렇다고 사람이 모든 코드를 직접 작성해야 한다는 뜻은 아니다. 글쓴이는 미래의 소프트웨어 팀에서 AI 에이전트가 구현을 맡고, 사람은 유지관리자처럼 명세와 아키텍처를 다룰 수 있다고 제안한다. 사람이 시스템을 이해하고 기여하려면 코드 이해를 돕는 도구도 필요하다고 말한다.

그 예로 2019년 Go 프로젝트의 대응을 든다. 기여자는 많지만 유지관리자의 시간이 부족한 문제를 해결하기 위해, 낮은 수준의 코드 변경 요청 대신 상위 수준의 설계 문서와 동작 명세를 보내고, 가능한 설계 선택과 절충점을 설명하며, 제안에 프로토타입과 동영상을 첨부하는 방식을 살폈다. 관련 내용은 Russ Cox의 글에서 확인할 수 있다.

결론적으로 글쓴이는 AI를 소프트웨어 개발 과정에 폭넓게 활용하더라도 시스템에 대한 최종 책임은 사람에게 남을 것이라고 본다. 1979년 IBM 관련 글에 실린 “컴퓨터는 책임을 질 수 없으므로 경영 결정을 내려서는 안 된다”는 문구도 참고 자료로 제시한다.