월급쟁이부자들 CTO가 그리는 AX 로드맵 월급쟁이부자들(Weolbu) CTO 인터뷰입니다. 합류 동기부터 CTO가 만들어 갈 AX의 정의, 로드맵, 지표, 전사 확장, 엔지니어가 얻는 기회, 그리고 함께할 팀의 모습까지 차례로 짚었습니다.
월급쟁이부자들 CTO가 그리는 AX 로드맵
월급쟁이부자들(Weolbu) CTO 인터뷰입니다. 합류 동기부터 CTO가 만들어 갈 AX의 정의, 로드맵, 지표, 전사 확장, 엔지니어가 얻는 기회, 그리고 함께할 팀의 모습까지 차례로 짚었습니다.
CTO 인터뷰
"단순 구현을 넘어, 새로운 워크프레임을 확보할 겁니다" 월급쟁이부자들 CTO가 그리는 AX 로드맵
Special Interview DIRECTOR'S CUT
월급쟁이부자들의 리더십 레벨은 임팩트를 만들기 위해 치열하게 고민합니다.
성과 이면에 놓인 비즈니스의 본질에 다가서는 기록을 전합니다.
인터뷰를 읽고나면
☑️ 월급쟁이부자들이 그리는 AX와 AI-Driven 로드맵을 들여다볼 수 있어요.
☑️ 개발 조직을 넘어 전사로 번지는 AI 리터러시의 방향을 확인할 수 있어요.
☑️ 엔지니어로서 여기서 어떤 커리어 기회를 확보할 수 있을지 이해할 수 있어요.
제목없음
삼성전자 무선사업부에서 11년, 이후 여러 스타트업의 최고기술책임자를 역임했던 김상효 본부장이 월급쟁이부자들에 CTO로 합류했습니다. 다음 도전 과제는 AX(AI Transformation)입니다.
신임 CTO가 그리는 로드맵은 단순 LLM 도입과는 결이 달랐습니다. 측정 가능한 생산성, 그리고 그것이 만드는 비즈니스 임팩트에 집중돼 있죠. 합류 동기부터 CTO가 만들어 갈 AX의 정의, 로드맵, 지표, 전사 확장, 엔지니어가 얻는 기회, 그리고 함께할 팀의 모습까지 차례로 짚었습니다.
월급쟁이부자들 IT커리어 커피챗 신청하기
Q. 새로운 도전으로써 월급쟁이부자들을 선택한 이유는 무엇인가요?
"사업이 검증된 회사에서, AX가 만드는 성공 사례를 직접 증명해보고 싶었습니다."
대기업과 스타트업을 모두 거치며 커리어의 한 사이클을 마무리한 시점이었습니다. 스타트업에서는 팀을 꾸리며 제로투원(0to1)을 경험했고, 규제 산업에서 디지털전환(DX)의 성공도 직접 만들어봤습니다.
문제 해결 뒤에는 늘 도전 과제가 생기죠. 다음으로 풀고 싶은 문제는 명확했습니다. AX(AI Transformation)였어요. 구체적으로는 스케일업 단계에 들어선 회사에서, AX의 임팩트를 숫자로 보여주는 일에 뛰어들어야겠다고 생각했습니다.
AX 성공 사례를 만들 최적의 조건을 갖춘 기업이라고 판단했어요. 사업 모델이 흔들리는 단계에선 AX의 효과를 분리해 측정하기 힘들고, 너무 큰 조직에서는 의사결정 사이클이 길어 도전 자체가 어려울 수 있습니다. 반면 월급쟁이부자들은 검증된 사업 역량을 보유하고 있고, 동시에 다음 도약을 위한 시스템 재설계가 필요한 단계를 겪고 있어요. 여기라면 스스로 AX 로드맵을 처음부터 끝까지 그려낼 수 있겠다고 봤습니다.
Q. LLM 도입과는 무엇이 다른가요? 월급쟁이부자들의 AX를 한 문장으로 정의해볼 수 있을까요?
"우리가 추구하는 AX는 기존 환경에 AI 도구를 도입하는 것이 아닙니다"
현재 추진하는 AX를 간단히 설명한다면 전체 워크플로우를 다시 짜는 것에 가깝습니다. AX는 한두 사람이 LLM을 활용해 개인 성과를 내는 것이 아니라, 전사적으로 기여할 때 의미가 있어요. 회사 차원의 비즈니스 임팩트는 워크플로우 전체를 효율화할 때 나옵니다. 그래서 표준화와 프로토콜 규약을 중요하게 봐야 합니다.
개인 단위 AI 도입은 한계가 명확합니다. 실제로 규모가 큰 회사에서도 클로드 코드나 GPT로 개개인이 단순 업무만 처리하는 경우가 많아요. AI를 채팅 도구에 한정해 활용하는 게 대부분이죠. 이렇게 되면 작업자 사이의 표준이 없고, 앞뒤 작업자가 주고받는 산출물의 규약도 정해지지 않습니다. 한 사람이 30분을 아껴도 다음 사람이 다시 정리하는 데 추가로 30분을 씁니다. 전체 업무 흐름에서 줄어든 시간이 사실은 없다는 뜻이죠.
Q. 새로운 워크플로우를 위해서 정교한 AX 로드맵이 필요해 보입니다. 구체적으로 설명해주신다면요?
월급쟁이부자들의 AX 로드맵은 이미 구체화됐습니다. 분석에서 시작해, 사람의 개입을 크게 줄이는 방향으로 설계했어요. 세밀하게 나눠본다면 6단계 정도로 구조화됩니다.
먼저, 체이닝 분석(Chaining Analysis)으로 워크플로우의 한 작업 단위를 정의하고 현재 상태를 정밀하게 파악합니다. 새로운 시도 전에 지금이 어떤 상태인지부터 알아야 다음 단계의 세부 계획을 수립할 수 있기 때문에, 엔지니어링 문제 해결의 시작 단계인 분석부터 진행하는 거죠. 여기까지는 이미 완료됐습니다.
다음으로 프로토콜 정의(Protocol Definition)를 진행합니다. 구성원은 업무 시 문서 혹은 코드, 디자인 리소스 등의 산출물을 생성하죠. 개발 프로세스에서는 어떤 값을 전달할지 정의하는 게 필수적입니다. Skill을 통해서 산출물을 생성하게 되는 AX에선 이전 산출물의 결과가 이후 산출물을 생성할 때 필요한 입력이 되기 때문입니다. 엔지니어링 관점에서 입력이 명확하면 출력도 명확하게 나옵니다. 입력 프로토콜을 규격화한다는 건 결국 입력의 노이즈를 통제하고, 정제된 입력으로 결과의 불확실성을 최대한 줄이는 일이에요. 지금 진행 중인 단계입니다.
세 번째는 표준화(Standardization)입니다. 정의한 프로토콜 규약을 모든 스쿼드 혹은 동일 직무로 수평 전개하는 단계예요. 한마디로 성공 사례를 확장하는 일이죠. 지금은 스쿼드마다, 또 같은 직무 안에서도 서로 다른 프로세스와 규약으로 업무가 파편화돼 있는데, 여기에 모범 사례(Best Practice)를 옮겨 심는 것만으로도 충분히 임팩트가 납니다. 이 단계도 병렬적으로 진행하고 있어요.
그다음이 하네스(Harness)입니다. 입력을 받아 결과물을 생성하고, 이를 실행해 평가하는 과정이 차례로 이어지는데, 앞선 프로토콜과 표준화가 끝나야 비로소 가능한 단계죠. 코드가 생성되면 평가하고, 다시 개선하는 사이클이 반복적으로 돌아갑니다. 이 과정에서 테스트를 더 견고하게 다지고 Skill을 한층 고도화하죠. 표준화 이후로는 가장 핵심적인 단계라고 보고 있습니다.
이어서 데이터 시각화(Data Visualization)입니다. 앞선 체이닝 분석에서처럼, AX도 업무 진행 상황이나 리드타임, 토큰 사용량, 병목 같은 데이터를 보면서 문제를 풀고 인사이트를 얻죠. AX를 한 단계 더 높은 수준으로 끌어올리려면 꼭 필요한 단계입니다. 세부 지표를 통해 무엇을 어떻게 개선할지 계획을 세우고요.
마지막은 어싱크 리뷰(Async Review)입니다. 현재 로드맵의 최종 목적지예요. 인간 개입이 극단적으로 줄어드는 단계로, 출시 전에 사람이 리뷰하는 과정을 줄이는 걸 목표로 합니다. 사실 지금도 AI가 만들어내는 코드를 사람이 일일이 리뷰하기는 버겁거든요. 추론 성능이 더 올라가면 인간의 개입 횟수나 시간 같은 지표는 자연스럽게 줄어들 거라고 봅니다.
Q. "AX는 측정 가능해야 한다"고 강조하셨습니다. 생산성 개선을 실제로 어떤 지표로 보고 계신가요?
"분석이 없으면 개선도 없다, 저는 이 원칙을 지표에도 똑같이 적용합니다."
핵심 지표는 리드타임입니다. 개발 프로세스로 보면, 아이디어에서 시장 배포까지 이어지는 전체 워크플로우의 리드타임, 그리고 구간별 리드타임이 줄어드는지를 봅니다. 이건 단순한 개발 속도가 아니라 실제 경영상의 지표이기도 해요.
여기에 사람이 개입한 시간과 횟수를 함께 봅니다. AX가 얼마나 고도화됐는지를 가장 정직하게 보여주는 신호거든요. 그 외에 토큰 사용량, 산출물 대비 토큰 같은 지표도 함께 추적합니다. 더 상세한 세부 지표를 보기 위한 AX 분석 시스템도 로드맵에 올라가 있어요. 분석이 없으면 개선도 없다, 저는 이 원칙을 지표에도 똑같이 적용합니다.
Q. AX는 전사로 확장될 때 임팩트가 가장 크다고 보셨습니다. 결국 무엇이 가능해질까요?
"같은 비용에서 더 나은 결과를 내는 것, 그게 제가 보는 생산성입니다."
AX로 얻는 건 결국 생산성 향상과 결과물의 품질 향상입니다. 특히 모든 기업의 숙제인 생산성 제고에 집중하고자 합니다. 개발본부의 성공 사례를 시작으로 전사로 확대할 계획입니다. 같은 시간과 비용으로 프로덕트 본부는 더 많은 가설을 검증하고, 개발본부는 더 많은 기능을 배포하죠. 전사 구성원들은 AI 기반 지식 체계를 통해 훨씬 적은 시간으로 필요한 정보에 닿을 수 있습니다.
확장 방식은 명확해요. 비개발 부서의 문제를 모아 ‘4-RETS’라는 기준으로 판단합니다. 시간이 오래 걸리는지, 반복적인지, 명확하게 정의되는지, 휴먼 에러가 발생할 여지가 큰지 확인하는 거죠. 여기에 해당하는 일에 보통 리드타임 감소를 목표로 잡고, 그걸 달성해 나가는 과정에서 성공 사례가 부서를 넘어 확장됩니다.
생산성을 비즈니스 임팩트 관점에서 보면 두 가지예요. 같은 결과를 더 적은 비용으로 내는 길이 있고, 같은 비용에서 더 나은 결과를 내는 길이 있죠. 제가 보는 건 후자입니다. 결국 구성원 한 사람 한 사람의 생산성이 올라가는 거고, 그러면 우리는 주어진 시간 안에 경쟁사보다 더 많은 목표를 달성하며 성장할 수 있습니다.
Q. AI-Driven 계획이 이미 상세히 정렬된 환경에서 전사 AI 리터러시도 향상될 것으로 보입니다. 이런 조직에서 일할 때 체감하는 가장 큰 차이는 무엇일까요?
AX가 자리 잡았을 때 가장 눈에 띄는 변화는 협업 비용이 크게 줄어든다는 점이죠. 개발 조직의 워크플로우를 먼저 개선하면, 그 뒤로 비개발 조직의 워크플로우에도 빠르게 AX가 진행될 예정입니다. 프로토콜 규약이 정해져 있으니 협업에 드는 소통 비용이 줄고, 스트레스도 덜하고, 결과적으로 시간이 남습니다.
이미 실제로 비개발 직군에서도 AI로 직접 업무를 풀어보려는 시도가 빠르게 늘고 있어요. 개발이 먼저 닦아둔 표준이 옆 부서로 옮겨가면서, 전사의 AI 활용 수준 자체가 함께 올라갑니다. 전사적으로 4-RETS에 해당하는 일이라면, 자연스럽게 'AX로 풀어보자'는 문화도 생길 거라고 봐요.
Q. 'Async Review'처럼 인간의 리뷰 단계를 줄인다는 건 꽤나 도전적인 목표로 보입니다. 여기서 엔지니어에게 필요한 역량은 무엇일까요?
"AI는 잘못이 없습니다. 사람이 어떻게 지시하느냐가 관건이죠."
구현하는 능력보다 설계하는 능력이 더 강조될 수밖에 없어요. 인간의 리뷰를 줄인다는 건 결국 AI가 더 좋은 결과를 내게 만든다는 뜻입니다. 여기서 중요한 게 컴퓨터 사이언스, 구체적으로는 설계 원칙을 어떻게 주입하느냐예요. 사람도 그렇지만 AI도 좋은 설계 원칙이 주어졌을 때 더 나은 결과를 냅니다.
예를 들어 같은 문제를 푸는 코드라도 더 단순하고 테스트하기 좋게 짜게 만들면, 복잡도가 낮은 코드는 사람도 기계도 훨씬 잘 만들어냅니다. 결국 AI에게는 잘못이 없어요. 어떻게 지시하느냐가 관건이고, 그래서 코드 설계에 대한 지식과 인사이트가 갈수록 더 중요해질 겁니다.
Q. 과정에서 개발 조직 강화는 필연적이겠습니다. 새롭게 합류할 엔지니어에게는 어떤 기회가 있을까요?
엔지니어 조직 전체가 전사 차원의 AX를 이끌고 시스템을 직접 구축할 계획입니다. 개발자라면 누구나 여기에 주도적으로 참여할 수 있습니다. 중소 규모 개발 조직은 보통 전체 워크플로우보다 개인의 LLM 활용이나 Skill 사용에 집중돼 있습니다. 반대로 AX 전담 조직을 따로 둔 대규모 조직은, 그 팀이 아니라면 오히려 LLM 사용 자체에 제약이 따르는 경우도 많고요. 제가 그리는 팀은 이와는 다를 겁니다.
좀 더 구체적으로 설명하자면 엔지니어가 확보할 기회요인은 크게 세 가지라고 봅니다.
먼저, AX 시스템을 제로에서 하나로 직접 구축하는 경험이에요. 시스템을 새로 세우다 보면 마주하는 문제가 많은데, 그 과정에서 여러 트레이드오프를 따져 직접 의사결정에 참여하고 제로투원을 주도하게 됩니다.
두번째로는 설계와 기술 스택에 대한 결정권입니다. AX 프로젝트에 들어오면 다양한 의사결정에 직접 참여하게 돼요. 전체 AX 목표 기준에 맞는 솔루션을 스스로 찾아 제시하고, 끝에는 비즈니스 임팩트라는 성과까지 확인할 수 있습니다.
마지막으로는 시스템을 구축해본 경험 그 자체예요. 시스템 구축 경험은 리더로 성장하는 데 꼭 필요한데, 그게 AI 관련 시스템이라면 의미가 더 큽니다. 여기서 쌓은 경험은 이후 다른 시스템을 만들거나 조직 차원의 문제를 풀 때도 분명히 도움이 될 거예요.
Q. 앞으로 이 로드맵을 함께 완성할 팀을 어떻게 그리고 계신가요? 어떤 동료와 일하고 싶으신가요?
“AI에게 일을 잘 시킬 수 있는 팀을 만들고 싶습니다."
제가 만들고 싶은 건 AI에게 일을 잘 시킬 수 있는 팀이에요. 이제 단순 구현은 크게 의미가 없습니다. 그러려면 컴퓨터 사이언스에 대한 이해, 그리고 LLM을 응용해 문제를 해결하는 능력이 필요합니다.
조직은 두 갈래로 그리고 있어요. 스쿼드는 신규기능을 위해 가볍고 빠르게 움직이는 제너럴리스트로 가져가고, 플랫폼팀은 기술적 문제를 해결하는데 집중하고 AX를 구축,그리고 인프라를 설계하는 스페셜리스트로 둘 생각입니다. 직무나 도메인은 달라도 공통적으로 기대하는 건 하나예요. 높은 수준의 AI 활용 능력입니다.
월급쟁이부자들의 AX 비전은 새로운 표준을 세우는 일입니다. 도전적인 목표죠. 아직은 가설에 머무르는 AI 기반 비즈니스 임팩트를 팀과 함께 숫자로 증명해 낼 분들의 합류를 기대하겠습니다.
제목없음
월급쟁이부자들 개발 조직은 기능 구축에 그치지 않고, 비즈니스를 바꾸는 문제에 도전하고 있습니다. AX 시스템을 제로에서 직접 설계하고, 측정 가능한 생산성 향상을 이끄는 여정에 함께할 동료를 기다립니다.
