AI에 막대한 자금을 투입하면서도 기업이 그에 걸맞은 성과를 내지 못하는 사례가 늘고 있다. 변화를 이끌어야 할 주체가 잘못 설정된 탓일 수 있다.

AI는 개발자를 없애기보다는 개발자에게 요구되는 역량을 바꿀 가능성이 높다. 대규모 언어 모델이 코드를 더 빠르고 저렴하게 작성할 수 있는 세상에서 주니어 개발자가 여전히 필요한지에 관한 논쟁이 이어지고 있다. 그러나 이 논쟁이 간과하는 것이 있다. 젊은 개발자들의 상대적 미경험이 오히려 소프트웨어 개발의 규칙을 다시 쓰는 데 꼭 필요한 자질일 수 있다는 점이다.

이 생각은 제임스 거버너가 벤 그리피스의 글을 인용해 쓴 글을 읽으며 떠올랐다. 그리피스는 한 컨퍼런스 발표에서 연사가 젊은 청중을 향해, 컴퓨팅 역사를 만든 몇몇 원로들을 모른다며 부끄러워하라고 꾸짖는 장면을 목격했다고 회고했다. 그리피스가 짚은 아이러니는 이렇다. 그 ‘원로들’ 중 다수가 세상을 바꾼 업적을 이룩한 것은, 정작 강의를 듣고 있던 청중보다 더 젊었을 때였다는 점이다. 빌 조이는 22세에 vi를 작성했고, 존 카맥은 23세에 둠을 만들었으며, 리누스 토르발스는 22세에 리눅스를 공개했다. 업계의 거인들 중 다수는 수십 년의 경험을 쌓기 전에 가장 큰 기여를 해냈다.

핵심은 젊은이가 더 똑똑하다는 게 아니다. 그렇지도 않다. 경험 많은 개발자를 무시하는 것이 AI 성공의 열쇠라는 뜻도 아니다. 그것은 어리석은 생각이다. 그리피스의 더 큰 주장이 옳다는 얘기다. 큰 전환의 시작점에서 경험은 양날의 검이 될 수 있다. 위험을 보는 눈을 길러주기도 하지만, 낡은 방식에 대한 과신을 심어주기도 한다. 가장 성공적인 기업은 젊은 혁신과 경험 있는 가드레일을 균형 있게 결합하는 방법을 찾아낼 것이다.

공장은 스스로를 재설계하지 않는다

자라 장은 최근 폴 데이비드가 1990년에 발표한 고전 논문 “다이나모와 컴퓨터”를 인용하며, 많은 기업이 AI를 ‘도입’하고도 별다른 성과를 내지 못하는 이유를 설명했다. 데이비드의 논지를 단순화하면 이렇다. 전기가 공장을 즉각적으로 바꾸지는 않았다. 오랫동안 공장들은 중앙 증기 엔진을 전기 모터로 교체하면서도 기존 레이아웃, 워크플로, 전제를 그대로 유지했다.

전기는 새로운 기술이었지만, 낡은 공장 시스템에 억지로 끼워 넣으면서 잠재력은 대부분 억눌렸다.

생산성의 큰 도약은 그 이후에 찾아왔다. 공장들이 전기를 더 깨끗한 증기 엔진으로 취급하기를 멈추고, 공장 전체에 분산된 소형 모터를 중심으로 작업을 재설계하기 시작했을 때다. 각 기계가 자체 모터를 갖게 되자, 공장은 더 이상 단일 구동축을 중심으로 구성될 필요가 없어졌다. 작업은 생산 흐름에 맞게 재편될 수 있었다.

오늘날 많은 기업이 AI를 대하는 방식이 이와 다르지 않다. 코파일럿 라이선스를 수천 개씩 구매하고, 기존 애플리케이션에 에이전트를 연결하고 나서, 왜 결과가 들쭉날쭉한지 의아해한다. 필자가 앞서 썼듯, 증기 엔진을 전기 엔진으로 교체해 놓고 AI 현대화 작업이 끝났다고 선언하는 것과 마찬가지다. 끝나지 않았다. 전혀 가깝지도 않다.

실질적인 성과는 AI에게 같은 티켓을 조금 더 빠르게 처리하도록 시키는 데서 나오지 않는다. 팀이 업무를 정의하는 방식, 개발자가 무엇을 어떻게 만드는지를 바꾸는 데서 나온다. ‘공장’ 자체가 바뀌어야 한다.

그렇다면 불편한 질문을 던져보자. 새로운 공장을 만들 가능성이 가장 높은 사람은 누구인가?

경험은 양날의 검

젊음을 낭만화하는 것에는 명백한 위험이 따른다. 무한한 자신감과 제한된 맥락 이해를 가진 사람들이 형편없는 소프트웨어를 양산한 사례는 적지 않다. 기업에는 ‘작동하는’ 소프트웨어가 필요하며, ‘작동한다’는 것은 규정을 준수하고, 확장 가능하며, 보안 경계를 존중하는 것 등을 의미한다.

바로 여기서 경험 많은 개발자의 역할이 중요해진다. 크게.

필자가 최근 지적했듯, 에이전트 시대는 엔지니어링 판단력을 그 어느 때보다 중요하게 만들고 있다. AI는 코드 생성을 쉽게 만들지만, 코드 생성이 쉬워지면 기술 부채 생성도 쉬워질 수 있다. 따라서 제한 요인은 ‘무언가를 만들 수 있는가’에서 ‘올바른 것을, 올바른 곳에, 올바른 제약 조건 하에 만들 수 있는가’로 이동한다. 다시 말해, 안목이 필요하다.

시니어 엔지니어들은 이런 제약 조건을 더 잘 파악하는 경향이 있다. 경험에서 비롯된 ‘안목’이 있기 때문이다. 이상해 보이는 유효성 검사 규칙이 왜 존재하는지 알고, 문서화되지 않은 동작에 의존하던 고객을 기억한다. 단순한 스키마 변경이 수 주에 걸친 마이그레이션으로 이어질 수 있다는 것도 이해한다.

그러나 경험에는 그림자도 따른다. 현재의 프로세스를 당연한 것으로 느끼게 만들 수 있기 때문이다. 시니어 엔지니어는 AI 어시스턴트를 더 빠른 자동완성 도구로 볼 수 있다. 기존 사고방식에 AI를 가장 쉽게 끼워 넣는 방법이 그것이기 때문이다. 반면 기존 워크플로에 덜 매몰된 주니어 개발자는 더 흥미로운 질문을 던질 수 있다. 이 티켓을 애초에 왜 처리하고 있는 걸까? 스펙은 왜 실행 가능한 형태가 아닐까? 에이전트가 테스트 하네스를 먼저 생성할 수는 없을까?

경험 많은 개발자들이 이런 질문을 모른다는 게 아니다. 다만 기존 체계에 맞서 싸울 에너지가 남아 있지 않을 수 있다.

미경험의 가치

AI 시대에 주니어 개발자를 활용하는 가장 나쁜 방식은 시니어 개발자의 저렴한 버전으로 취급하는 것이다. 그런 취급은 언제나 잘못된 생각이었지만, AI로 인해 더욱 나빠졌다. ‘티켓을 받아 코드를 생성하고 시니어에게 검토를 넘기는’ 역할이라면, 주니어 개발자는 코딩 어시스턴트를 감싸는 인간 래퍼로 전락한다. 누구에게도 이롭지 않다. 주니어는 제대로 배우지 못하고, 시니어는 검토 업무에 치이며, 기업은 더 많은 코드만 얻게 된다. 필자가 거듭 말했듯, 코드의 양이 많다고 해서 좋은 것이 아니다.

대신 주니어 개발자에게는 경험 있는 동료들의 적절한 감독 아래 새로운 워크플로를 탐색할 공간이 주어져야 한다. 예를 들어 이런 질문들을 던져볼 수 있다.

• 모든 내부 API에 실제로 작동하는 AI 가독 계약과 예시가 있다면, 온보딩을 어떻게 재설계할 수 있을까?

• 에이전트가 모든 풀 리퀘스트마다 변경 요약, 테스트 증거, 의존성 위험, 롤백 계획을 함께 생성한다면, 코드 리뷰 방식은 어떻게 달라질까?

• 프로덕트 요구사항을 모호한 산문이 아닌 실행 가능한 인수 테스트 형태로 작성한다면, 기능을 어떻게 구축할 수 있을까?

• 에이전트가 명확히 정의된 경계 안에서 정기적인 마이그레이션, 의존성 업데이트, 인시던트 분류 등을 안전하게 수행할 수 있다면, 반복적인 수작업을 어떻게 줄일 수 있을까?

이 모든 질문은 사소한 문제가 아니다. ‘주니어가 할 업무’도 아니다. 기업이 필요로 하지만 대부분 기존 쳇바퀴를 돌리느라 외면해온 프로세스 재설계 과제 그 자체다.

균형 찾기

엔지니어링 리더는 무엇을 해야 할까? 첫째, AI 도입을 개인 생산성 경쟁으로 취급하는 것을 멈춰야 한다. ‘토큰 수가 많은 사람이 훌륭한 엔지니어’라는 인식에서는 이미 빠르게 벗어나고 있지만, 그런 발상 자체가 존재했다는 사실은 개탄스럽다. 산티아고 발다라마는 이 허망한 지표를 신랄하게 비판했다. 발다라마의 주장은 이렇다. 작성한 코드 라인 수로 AI 생산성을 측정하는 것은 어리석은 실수이며, 언젠가 모두가 처음부터 반대했다고 말하게 될 것이라는 것이다. 대신 이렇게 물어야 한다. 소프트웨어 개발 프로세스 중 더 이상 의미 없는 부분은 무엇인가? AI의 최대 성과는 소프트웨어를 명세하고, 테스트하고, 검토하고, 출시하는 방식을 바꿀 때 나온다.

둘째, AI 워크플로 팀을 다양하게 구성해야 한다. 위원회나 파워포인트나 찍어내는 탁월성 센터(Center of Excellence)를 말하는 게 아니다. AI 네이티브 도구에 이미 능숙한 주니어 개발자 두세 명과, 프로덕션·보안·아키텍처·기업 제약을 이해하는 시니어 엔지니어 두세 명을 결합하는 것이다. 그런 다음 의존성 업그레이드나 테스트 생성 같은 실제 워크플로를 재설계하는 과제를 부여해야 한다.

셋째, 시니어 엔지니어의 역할을 거부하는 것에서 다른 사람들이 긍정적 결정을 내릴 수 있는 가드레일을 정의하는 것으로 전환해야 한다. 필자는 ‘골든 패스(golden path)’가 AI를 효과적으로 활용하는 데 핵심이라고 주장해왔다. 우수한 시니어 엔지니어들은 포장된 도로, 즉 승인된 패턴, 테스트 요구사항, 관찰 가능성 기준 등을 정의해야 한다. 그리고 주니어 개발자와 에이전트가 그 경계 안에서 빠르게 움직일 수 있도록 해야 한다.

넷째, 삭제에 보상해야 한다. 이것이 가장 중요한 포인트일 수 있다. 공장 전기화 비유로 돌아가면, 낡은 프로세스를 제거하지 않고 AI만 추가한다면 AI 현대화는 실패할 것이다.

모두를 테이블로

소프트웨어 개발의 미래는 젊은 세대의 것도, 노련한 세대의 것도 아니다. 양쪽의 재능을 결합하는 팀의 것이 될 것이다.

신진 개발자는 흔히 참을성 없음을 무기로 삼는다. 기존 워크플로를 성역으로 받아들일 가능성이 낮고, 새로운 도구를 시도하고 예상치 못한 방식으로 결합하며, 엔터프라이즈 소프트웨어 개발이 왜 허가를 기다리는 의식처럼 느껴지는지를 의문시할 가능성이 높다.

경험 많은 개발자는 판단력을 가져온다. 소프트웨어에 사용자, 감사자, 공격자, 예산, 지연, 역사, 결과가 따른다는 것을 안다. 올바른 답이 종종 지루하다는 것도, 지루한 것이 좋은 것임도 안다.

기업에는 둘 다 필요하다. 공장이 왜 아직도 낡은 구동축을 중심으로 구성되어 있는지를 묻는 개발자도, 함부로 옮기면 누군가 다칠 기계가 어디 있는지를 아는 개발자도 필요하다. 결국 모든 개발팀에는 기존 시스템이 왜 존재하는지 아는 사람과, 그것을 모르는 사람이 모두 필요하다.
dl-itworldkorea@foundryco.com