AI Native 엔지니어링 팀의 새로운 운영방식

AI Native 엔지니어링 팀을 리드하기 위해서는 과거와는 다른 접근이 필요하다.

과거 통신 시스템에서 동작하는 소프트웨어를 만들어 납품하던 시절, 병목은 이른바 배포판을 만드는 것이었다.별도의 서버가 있었고, 코드의 성격에 따라 commit을 해야 하는 일정도 달랐다.
이렇게 만들어진 배포판을 수정하고 다시 손질을 하여 고객에게 납품하기 까지 상당한 시간이 걸렸다.
그 후 CI/CD 개념이 도입되었고, 클라우드가 등장했다.

소프트웨어 코딩 에이전트가 실무에 도입된 지금 우리는 개발 과정상의 병목지점이 기존과 달라지는 것을 목격하고 있다.
이번에는 코딩 자체가 더 이상 발목을 잡는 지점이 아니다. AI가 코드를 쓴다. 테스트를 만든다. 문서를 정리한다. 리팩토링도 한다.

그렇다면 과거의 개발팀이 일하는 방식이 아직 유효한가라는 질문을 해 보아야 한다.

앤트로픽에서 클로드 코드 개발팀을 이끄는 엔지니어링 매니저인 Fiona Fun은 최근 클로드 컨퍼런스에서 이 질문에 대해 자신의 경험과 생각을 공유했다.

클로드 AI의 최첨단 기술 이야기가 아니다. 소프트웨어 개발 조직내에서 변화를 대하는 태도, 그리고 관리자가 어떻게 자신을 재정립해야 하는가에 관한 이야기였다.

소프트웨어 개발 조직을 이끄는 리더라면 귀 기울일 만하다.

조용히 작동을 멈춘 프로세스들

가장 위험한 것은 갑자기 무너지는 시스템이 아니다. 천천히, 아무도 모르게 효용을 잃어가는 시스템이다.
공감이 되는 지적이다. 갑자기 무너지는 것은 대응 할 수 있다. 그러나, 아무도 모르게 효용을 잃어가고 있는 시스템과 그리고 그런 변화를 알면서도 침묵하는 집단의 안일함이다.
많은 팀의 기획 문서, 주간 회의, 코드 리뷰 절차가 그런 운명을 맞이하고 있다.

이 프로세스들은 처음에 분명한 이유로 만들어졌다.

명확한 인풋이 있으며 어떠한 산출물을 내야 하는지 그리고 그 과정에서 각자의 역할은 무엇이며 어떠한 일을 해야 하는지 명확한 선언과 정의가 있다.
개발자의 시간이 가장 귀한 자원이던 시절, 충분히 기획하고 검토하는 것은 개발 효율 측면 및 소프트웨어 품질 관리에서 합리적인 선택이었다.
그런데 AI 도구가 코딩 속도를 몇 배로 끌어올린 지금도 그 절차들은 그대로 남아 있다.
쌓이기만 할 뿐, 아무도 없애지 않는다. Fiona는 이것을 “조용히 작동을 멈춘 프로세스”라고 불렀다.

프로세스는 저절로 사라지지 않는다. 누군가 의식적으로 없애야 한다. 관리자의 역할이 바로 거기에 있다.

코드로 토론하고, 프로토타입으로 결론 내라

기술적 논쟁을 회의실에서 해결하려는 시도를 멈춰야 한다. 화이트보드에 적는 시간, 말로 설득하는 시간, 그것은 이제 비싼 자원이 되었다.
반면 코드를 작성하는 비용은 급격히 낮아졌다. 그 어떤 의사 소통 방식보다도 코드 자체가 효율적인 의사 소통 수단이 되고 있다.

예전에는 프로토타입은 “덜 만들어진 코드”, “이해를 돕기 위한 목업” 정도였다.
지금은 AI가 프로토타입을 실제 서비스 수준으로 빠르게 발전시킬 수 있다. 즉, 논의는 짧게 하고 실험은 빠르게 하는 팀이 이기는 시대가 됐다.

관리자가 “일단 만들어봐”라고 말하는 것이 “좀 더 검토해보자”보다 현명한 선택인 경우가 많아졌다.

새로운 병목은 ‘검증’이다

속도가 빨라졌다고 품질이 따라오지는 않는다. 오히려 반대다. 코드가 빠르게 쌓일수록 “이게 제대로 된 것인가”를 확인하는 일이 더 중요해진다. 코드의 변화 속도가 빨라 질수록 진짜 병목은 코딩이 아니라 검증이다.

Fiona가 강조한 것은 ‘더 이른 단계에서 문제를 잡는 것’이다. 이른바 업게에서 이야기 하는 “Shift Left”이다. 고객이 버그를 발견하는 것보다 팀이 먼저 발견하는 것이 낫고, 그보다 더 좋은 것은 자동화된 테스트가 코드가 작성되는 시점에 잡아주는 것이다.

AI가 코드 스타일 점검, 명세서 준수 여부 확인, 명백한 버그 탐지를 도와주지만, 위험 판단, 법적 검토, 제품 방향의 타당성은 여전히 사람의 몫이다.

그 중 가장 중요한 것은 제품 방향의 타당성이다.

코딩 에이전트는 현재 자신의 콘텍스트 메모리안에 있는 코드 베이스에 대한 이해와 입력 받은 구현 명세에 대하여 자신이 학습한 내에서 가장 적절한 변화를 생성해 낸다. 그리고 이런 변화는 확률에 의해 지배된다.

제품의 방향성은 이와는 다르다.

소프트웨어에 새로 추가 변경되는 기능에 대하여 어떤 형태로 변화가 생겨야 하고 이러한 변화를 어떻게 각 소프트웨어의 구성부분에 적용해야 하는지는 여전히 사람의 판단이 필요하다. 넓은 분야의 지식이 필요할 수도 있고, AI가 학습하지 못한 경험치도 중요한 역할을 한다.

자동화할 수 있는 것은 자동화하고, 사람이 해야 할 곳에 개발 역랼을 집중하도록 하는 것. 그것이 지금의 관리자에게 필요한 균형 감각이다.

단순히 툴 사용 여부의 점검이라던지 조직 내 사용 에이전트의 개수가 증가하는 것을 자랑스럽게 피티하는 건 하지말자.

역할의 경계가 흐려진다 이건 기회다

AI는 각자의 약점을 보완한다.

팀내 어떤 사람은 경력이 오래되고 상용 서비스에 대한 경험이 많아 이 사람의 주장이 힘을 얻을 때가 많다. 최근에 입사한 주니어 개발자들은 기존 경력자 대비 새로운 트렌드에 더 민감하여 개발 팀내 새로운 관점을 정립하기도 한다.

어떤 이는 프로덕트 코드에 더 성취감을 느끼며 다른 이는 테스트코드 영역에서 플레이하는 것이 더 편하기도 하다. 오래된 팀일수록 알게 모르게 이런 역할 분담이 생기며 고착화된다.

코딩 에이전트를 도입하면 이런 역할 분담 그리고 이로 인한 구성원들간의 역할 경계가 흐려질 수 있다. 주니어도 전문적인 디자인 패턴을 적용하여 멋지게 구조를 만들 수도 있고 프로더트 코드를 만드는 사람도 테스트 프레임에 대한 이해 없이 자신이 만든 코드에 대한 테스트 케이스를 작성할 수 있다.

역할의 경계가 흐려지는 것이 혼란이 아니라 확장이다. 확장된 영역에서의 산출물이 팀 결과물로 동작하기 위해서는 이른바 “Product ownership”이, 자신의 commit에 대해서는 책임감을 갖는 것이 중요하다.

이 변화는 팀 구성에 대한 사고도 바꾼다. Fiona는 두 종류의 역량에 집중한다고 했다. 제품 감각을 갖춘 창의적인 개발자와, 시스템을 깊이 이해하는 전문가. 전적으로 공감하는 부분이다.

이 두 종류의 사람이 AI를 도구로 활용할 때 팀의 역량은 이전과 다른 방식으로 커진다고 한다. iOS 팀과 Android 팀을 굳이 분리해야 하는가, 디자이너와 개발자의 업무 경계를 어디까지 유지해야 하는가 같은 질문들이 이제는 현실적인 고민이 되었다고 한다.

결론

병목이 이동하면, 그것에 맞춰 모든 것을 다시 살펴봐야 한다. 간단하다. 현재의 모든 절차는 기존 병목을 없애기 위해서 만들어진 것이다.

기획 방식, 회의 구조, 팀 구성, 역할 정의, 코드 리뷰 절차, 지식 공유 방식까지. Fiona가 소프트웨어 엔지니어링 조직 관리자에게 당부하는 말은 간단하다. 가장 번거롭거나 비용이 많이 드는 업무를 하나 골라서 스스로에게 아니면 구성원에게 이렇게 물어보자. “이게 아직도 제 역할을 하고 있는가?”

변화를 읽는 것은 개발자의 일이 아니다. 관리자의 일이다. 코딩이 더 이상 병목이 아닌 세상에서, 관리자가 붙들고 있어야 할 것은 낡은 프로세스가 아니라 변화를 직시하는 눈이다. 아는 만큼 보인다.