Proton의 AI 엔지니어링 선언문

소프트웨어 엔지니어링이 늦어도 올해에는 돌이킬 수 없이 바뀌었다는 사실은 Proton의 누구에게도 놀라운 일이 아니어야 한다. 엔지니어링 부서라면 더더욱 그렇다. 대규모 언어 모델(LLM)과 관련 도구의 코드 작성 능력은, 며칠 전 Proton의 한 선임 엔지니어가 내게 이렇게 말했을 정도로 발전했다. 그대로 인용하겠다. “이제 {사업 부문 이름}에서는 아무도 코드를 쓰지 않는다.” 20세기에 전화번호를 외우거나 19세기에 말을 타던 것처럼, 훌륭한 코드를 직접 작성하는 것은 그 시대가 지나간 핵심 기술이다.

대체로 이것은 아주 좋은 일이다. 적어도 실제 운영 환경에서 대규모로 코드를 작성할 때, 그중 많은 부분은 예나 지금이나 시간을 잡아먹는 고역이다. 문서화와 테스트는 모두 필요하지만 즐겨 하는 사람은 드물다. 그동안 두 가지를 소홀히 하는 일이 잦았고, 소통의 부실, 비효율, 신뢰성 저하라는 대가를 치렀다. 상용구 코드(boilerplate)는 소프트웨어 엔지니어링의 고역을 보여주는 전형이며, 앞으로는 인간이 다시는 신경 쓸 필요가 없을지도 모른다. 이제 모델은 아키텍처와 시스템 설계에 관해 조언하고 제안할 수 있다. 그 제안은 종종 불완전하지만 논의와 의사결정, 교육에 실질적으로 기여한다.

Proton 밖에서는 AI 혁명이 전 세계를 휩쓸고 있다. 그중 상당수는 실속이 없고 피상적이다. 진정으로 혁신하기보다 혁신적으로 보이려는 겉치레 캠페인이다. 하지만 상당 부분은 아주 현실적인 변화이며, 경쟁사를 포함한 그 기업들이 지금 하는 투자는 앞으로 우리가 활동할 사업 환경을 결정할 것이다. 이것은 유행을 쫓는 문제가 아니다. 우리는 지금 뒤처지고 있으며, 이는 사명 자체의 성공을 위협하는 존립의 문제다.

그렇다면 왜 Proton에서는 혁명이 왔다는 느낌이 들지 않는가? 모두가 이미 LLM을 늘 쓰고 있다면, 왜 생산성은 극적으로 높아지지 않았는가? 나는 그 이유가 세 가지로 귀결된다고 본다. 다가오는 중인 시대가 아니라 오늘 이미 와 있는 새 시대에서 성공하려면, 우리는 이 세 가지를 모두 바로잡아야 한다.

첫 번째는 엔지니어링 문화와 엔지니어링 사고방식의 변화다. 당신의 업무는 근본적으로 바뀌었다. 이제 당신의 일은 코드를 작성하는 것이 아니며, LLM은 당신이 더 나은 코드를 더 빨리 쓰도록 도우러 온 것이 아니다. 당신의 일은 LLM이 더 나은 코드를 더 빨리 쓰도록 돕는 것이다. 이제 모든 엔지니어는 팀장이자 관리자이며, 직속 부하는 당신이 사용하는 모델과 에이전트다. 직접 방향을 제시하고 잘못했을 때 바로잡는 일도 물론 업무의 일부다. 하지만 두 사람이 늘 함께 페어 프로그래밍만 하는 팀은 제대로 된 팀이라고 하기 어려울 것이다. 팀장이 회의에 들어가면 아무도 일하지 않는 팀도 마찬가지다. AI는 사람이 일일이 돌봐주는 일을 점점 줄이면서도 자율적으로, 끊임없이 일할 수 있어야 한다. 당신의 일은 LLM이 혼자 해결하지 못하는 문제를 찾아내는 것이다. 이번에만 해결하도록 돕는 데 그치지 않고 다음에는 더 잘 해결하도록 도와야 한다. 당신 한 사람뿐 아니라 모두에게 도움이 되어야 한다. 저장소 단위의 맥락 파일, 공유 스킬과 프롬프트, 실패가 반복되면 반드시 조사와 수정으로 이어지게 하는 습관이 여기에 해당한다. 당신의 일은 LLM이 자율적으로 할 수 있는 일의 한계를 밀어붙이고, 할 수 없는 일에는 직접 개입하며, 현재 상태를 어떻게 개선할지 늘 생각하는 것이다.

이것은 전문성의 죽음이 아니다. LLM은 빠르다. 당신은 느리지만, 평생 쌓아온 경험과 판단, 이해를 지니고 있다. 또한 당신은, 바라건대, 환각을 일으키거나 잘못된 입력 또는 악의적인 입력에 속을 가능성이 훨씬 작다. 모델로서는 결코 할 수 없는 방식으로 자신과 동료, Proton에 책임을 진다. 함께라면 어느 한쪽이 혼자 할 때보다 훨씬 많은 일을 훨씬 빠르게 할 수 있다.

좋은 엔지니어링 관행의 죽음도 아니다. 아키텍처가 잘 잡힌 코드베이스에서는 유지보수성과 개발 속도가 더 높다. 문서화와 테스트는 여전히 중요하다. 다만 비용과 역량이 달라지면 모범 관행도 바뀔 수 있다는 점을 받아들여야 한다. 테스트가 좋은 예다. 기존의 모범 관행에 따르면, 테스트를 작성하고 유지하는 비용이 큰 환경에서는 테스트가 너무 많으면, 특히 종단 간 테스트가 너무 많으면, 얻는 것보다 잃는 것이 많다. 테스트를 작성하고 유지하는 비용이 낮아진다면, 우리가 그 경계선을 긋는 위치도 달라질 가능성이 크다.

우리가 AI 혁명을 충분히 활용하지 못한 두 번째 이유는 거의 완전히 1단계에 머물러 있기 때문이다. 기존 업무 흐름 안에서 LLM으로 작업 속도를 높이는 단계다. 하지만 코드 작성만이 소프트웨어 개발 생명주기의 전부는 아니다. 병목 하나를 없애면 무슨 일이 생기는가? 다른 병목이 그 자리를 차지한다. 지속적 통합(CI)의 속도와 처리 용량일 수도 있다. 설계, 승인, 명세, 코드 검토일 수도 있다. 그렇다. 우리는 사람이 하는 코드 검토의 대부분을 끝내는 지점에 도달해야 하며, 그렇게 할 것이다. 업무 흐름 자체는 크게 바뀌지 않더라도, LLM 덕분에 이전에는 비용이 너무 커서 엄두를 내지 못했던 자동화에 마침내 투자할 수 있을지도 모른다. 모든 절차를 전체적으로 살펴보고 가차 없이 병목을 제거하지 않으면, 우리는 잠재력을 온전히 발휘하지 못할 것이다. 이런 병목을 없애려면 기존 업무 흐름의 일부를 최적화하는 데 그치지 않고, 흐름 전체를 다시 설계하고 다시 생각해야 하는 경우가 많다. 이것이 2단계이며, 우리는 지금 그 단계로 가야 한다.

세 번째 이유는 집단행동의 문제다. LLM을 효과적으로 사용해 코드를 작성하는 일은 개별 엔지니어가 혼자서도 할 수 있다. 팀 전체나 사업 부문 전체, 회사 전체의 CI 절차를 다시 구축하거나 최적화하는 일은 훨씬 더 큰 노력이며, 기회비용과 상충관계가 따른다. 불가능한 것은 아니다. Proton의 많은 사람이 혼자 힘으로 놀라운 일을 해냈고, 그중 일부는 널리 퍼졌다. 하지만 회사 전체의 일하는 방식을 바꾸려면, 우리가 아직 투자하지 않은 규모의 조직화와 자원 투입이 필요하다. 앞 문단에서 다룬 소프트웨어 개발 생명주기로 돌아가 보면, 우리는 병목을 찾아내는 데 필요한 도구에 투자하지 않았기 때문에 병목이 어디에 있는지조차 모르는 경우가 많다. 과거에는 어느 정도 신중할 필요가 있었을지도 모른다. 이 새로운 도구들을 가장 잘 사용하는 방법을 알아내는 데 시간이 걸렸으며, 앞으로도 실험을 장려할 것이다. 하지만 지금이 요구하는 변화에 조직 차원에서 전념하겠다고 결단했어야 할 때는 이미 지났다.

그렇다면 엔지니어인 당신에게 이것은 무엇을 뜻하는가? 당신의 자율성과 책임이 모두 커졌다는 뜻이다. 이제 당신은 일이 이루어지는 것뿐 아니라, 그 일이 어떤 방식으로 이루어지는지까지 책임진다. 따라서 지속적인 최적화와 최대한의 자동화에도 책임이 있다. 그 개선을 동료와 나누는 일도 포함한다. Proton에서 성공은 팀 스포츠다. 혼자 실행할 수 없는 필요한 개선을 알리고, 해결할 수 있는 상위 책임자나 조직에 제기하는 것 역시 당신의 책임이다. Proton은 2단계를 통과하고 AI 혁명의 잠재력을 온전히 실현하는 데 필요한 핵심 투자를 조직하고 자원을 배정할 것이다.

결론은 우리가 새로운 세상에 있다는 것이다. “프로그래밍”은 죽었다. 엔지니어링은 죽지 않았고, 전문성도 죽지 않았다. 당신의 옛 업무는 사라졌다. 기회를 붙잡는다면, 무언가를 만드는 사람으로서 맡을 새 업무는 당신이 어느 때보다 더 많은 일을 하고 더 큰 영향을 미치게 해줄 것이다. Proton은 당신이 그렇게 할 수 있도록 여건을 마련할 것이다. 앞으로 며칠, 몇 주에 걸쳐 그 노력에 관해 더 듣게 될 것이다. 실험의 시대는 계속되지만, 행동할 때는 바로 지금이다. 미래는 여기에 와 있다. 우리의 것으로 만들자.

-Bart