필요한 만큼 빌려 쓰는 CTO

CTO 대행은 정확히 무슨 일인가

코드를 대신 짜 주는 일이 아니라, 기술에 관한 결정을 대신 내리고 그 결정에 책임을 지는 자리를 시간제로 채우는 일입니다.

많은 조직이 개발 인력은 구할 수 있지만 기술 결정을 내려 줄 사람은 구하지 못한 상태로 몇 달을 보냅니다. 어떤 스택으로 갈지, 지금 서버를 옮겨야 하는지, 외주사가 넘긴 산출물을 받아도 되는지, 개발자를 한 명 더 뽑아야 하는지 두 명 더 뽑아야 하는지 — 이런 질문은 개발자의 질문이 아니라 기술 책임자의 질문입니다. 결정이 미뤄지는 동안 인건비와 인프라 비용은 그대로 나가고, 잘못 내린 결정 하나는 몇 달치 개발을 되돌리게 만듭니다.

CTO 대행(프랙셔널 CTO)은 그 자리를 상근 임원 채용 없이 채우는 방식입니다. 맘소프트가 이 이름으로 하는 일은 크게 세 가지로 정리됩니다. 첫째, 결정합니다. 선택지를 늘어놓고 고르라고 하는 대신 기준과 근거를 밝히고 하나를 권한 뒤, 그 판단을 문서에 남겨 나중에 되짚을 수 있게 합니다. 둘째, 검증합니다. 내부 개발팀이나 외주사가 만든 것이 약속대로 만들어졌는지, 지금 구조로 1년 뒤의 트래픽과 요구사항을 버틸 수 있는지 직접 확인합니다. 셋째, 남깁니다. 자문이 끝난 뒤 조직 안에 아무것도 남지 않으면 같은 문제가 같은 자리에서 반복되므로, 결정의 근거와 절차를 내부 사람이 이어서 고칠 수 있는 형태로 넘깁니다.

반대로 하지 않는 일도 처음에 분명히 해 두는 편이 좋습니다. 두꺼운 보고서만 내고 실행에서 빠지는 방식은 택하지 않습니다. 회의에 들어가고, 저장소를 직접 열어 보고, 필요하면 설계 초안과 예제 코드를 직접 씁니다. 다만 상시 운영 인력이나 야간 장애 대응 당직을 대신하지는 않습니다. 그 자리는 대행이 아니라 조직 안에 있어야 하고, 대행이 할 일은 그 체계를 설계해 주고 사람이 채워지도록 돕는 쪽입니다.

이런 상황에서 부릅니다

아래 다섯 가지는 기술 책임자 자리가 비어 있을 때 흔히 나타나는 국면입니다. 하나라도 해당한다면 상근 채용보다 대행이 먼저일 가능성이 높습니다.

• 제품은 있는데 기술 책임자가 없습니다. 대표가 기획과 영업을 하면서 개발 일정까지 챙기고 있고, 개발자들이 올린 기술적 요청을 판단할 사람이 없어 결국 "일단 해 보세요"로 넘어가는 상태입니다.
• 외주로 만든 시스템을 넘겨받아야 합니다. 계약서에 적힌 산출물이 무엇이었는지, 넘겨받은 코드로 다른 회사가 유지보수를 이어받을 수 있는지, 검수 확인서에 서명해도 되는지 판단할 내부 인력이 없습니다.
• 투자·인수·제휴를 앞두고 기술을 검증해야 합니다. 상대 회사의 기술이 설명대로인지, 혹은 우리 쪽 기술이 실사에서 어떤 지적을 받을지 미리 알아야 하는 상황입니다.
• 개발팀은 있는데 속도가 나지 않습니다. 사람은 늘었는데 릴리스는 느려지고, 배포할 때마다 크고 작은 장애가 나며, 코드 리뷰나 브랜치 규칙이 사람마다 다릅니다.
• AI 도입을 검토 중인데 판단 기준이 없습니다. 어느 업무에 붙여야 실제로 값을 하는지, 호출 비용은 어떻게 통제하는지, 어떤 데이터까지 외부 모델에 넘겨도 되는지에 대한 내부 기준이 없는 상태입니다.

다섯 가지의 공통점은 "무엇을 만들지"가 아니라 "무엇을 결정해야 하는지"에서 막혀 있다는 점입니다. 이 상태에서 개발 인력을 더 투입하면 결정되지 않은 것들이 코드로 굳어지면서 문제가 커집니다. 순서상 결정이 먼저입니다.

첫 진단은 이렇게 진행됩니다

계약 형태를 정하기 전에 짧은 진단을 먼저 합니다. 무엇이 문제인지 서로 같은 그림을 갖지 않은 채로 월 자문을 시작하면 양쪽 모두 손해이기 때문입니다.

진단은 메일 문의에서 시작합니다. 먼저 온라인 또는 방문으로 사전 대화를 하고, 이때 조직의 현재 상태와 가장 급한 질문 한두 개를 확인합니다. 자료 접근이 필요하면 비밀유지 각서를 먼저 체결한 뒤 자료를 봅니다. 저장소 접근이 어려운 상황이라면 화면과 문서, 인터뷰만으로도 진행할 수 있으나 판단의 해상도가 그만큼 낮아진다는 점을 미리 말씀드립니다.

실제로 들여다보는 것은 다음과 같습니다.

• 저장소와 이력 — 코드 구조와 모듈 경계, 커밋과 브랜치 흐름, 테스트가 존재하는지, 한 사람만 만질 수 있는 영역이 어디인지 봅니다. 특정 인물이 자리를 비우면 멈추는 구간은 기술 문제이기 전에 조직 위험입니다.
• 빌드와 배포 경로 — 배포가 사람 손에 얼마나 의존하는지, 되돌릴 수 있는지, 장애가 났을 때 원인을 찾을 로그와 지표가 남는지 확인합니다.
• 데이터 모델 — 스키마와 인덱스, 트랜잭션 경계, 트래픽이 늘었을 때 먼저 무너질 지점을 확인합니다. 성능 문제가 이 지점에서 시작되는 경우가 많습니다.
• 보안과 규제 — 계정·권한 관리, 개인정보 취급 범위와 보관 기간, 해당한다면 웹접근성이나 업종별 요구사항을 점검합니다.
• 사람과 절차 — 개발자·기획자·외주 담당자와 짧게 인터뷰합니다. 문서에 적힌 절차와 실제로 굴러가는 절차는 대개 다르고, 자문이 손대야 할 곳은 후자입니다.

진단이 끝나면 발견한 것을 심각도 순으로 정리한 요약본을 드립니다. 이때 항목을 지금 손대야 할 것, 다음 분기로 미룰 것, 지금은 건드리지 말아야 할 것 세 묶음으로 나눕니다. 세 번째 묶음이 중요합니다. 눈에 거슬린다는 이유로 멀쩡히 돌아가는 부분을 갈아엎는 선택이 기술 부채를 그대로 두는 것보다 위험할 때가 많기 때문입니다. 진단 결과만 받고 이후 계약을 하지 않으셔도 됩니다. 그 문서 하나만으로도 다음 판단에 쓸 수 있도록 씁니다.

계약 형태는 세 가지입니다

필요한 만큼만 빌려 쓰는 것이 이 서비스의 핵심입니다. 아래 세 가지 중 하나로 시작하고, 상황이 바뀌면 형태를 바꿉니다.

기간과 투입 강도는 진단 결과를 보고 함께 정합니다. 범위를 확정하기 전에 금액부터 제시하지 않습니다. 무엇을 해야 하는지 모른 채 산정한 금액은 양쪽 모두에게 의미가 없고, 나중에 범위를 두고 다투는 원인이 되기 때문입니다. 계약 이후 범위가 늘어나면 늘어난 만큼 다시 합의하고, 반대로 급한 불이 꺼져 결정 빈도가 줄면 투입을 줄이자고 먼저 말씀드립니다.

월 단위 자문은 실제로 이렇게 굴러갑니다

가장 많이 문의를 받는 형태이므로 진행 리듬을 구체적으로 적어 둡니다. 계약서에 적힌 시간보다, 결정이 언제 어떤 자리에서 내려지는지가 중요합니다.

시작할 때 보고선을 먼저 정합니다. 대행의 권고가 중간 관리 단계에서 걸러지는 구조면 자문은 문서만 쌓고 끝나므로, 대표 또는 그에 준하는 결정권자와 직접 연결되는 것을 시작 조건으로 둡니다. 그다음 정기 회의 주기를 정합니다. 주 1회의 짧은 기술 회의와 월 1회의 경영진 브리핑이 기본 형태이고, 조직 상황에 따라 조정합니다. 회의 사이에는 메신저와 메일로 질문을 받되, 즉답이 필요한 사안과 다음 회의로 미뤄도 되는 사안을 구분하는 기준을 미리 합의해 둡니다. 모든 질문에 즉시 답하려 들면 정작 결정에 필요한 검토 시간이 사라집니다.

주간 회의에서는 지난주에 내려진 결정과 그 결과, 이번 주에 결정해야 할 항목, 막혀 있는 항목을 순서대로 봅니다. 결정된 사항은 회의가 끝나기 전에 문장으로 정리해 남기고, 결정을 내리기에 정보가 부족하면 "무엇을 확인하면 결정할 수 있는지"와 기한을 함께 적습니다. 판단이 필요한 자리에서 결론을 미루는 것 자체는 문제가 아니지만, 무엇을 기다리는지 적어 두지 않은 보류는 그냥 방치가 됩니다.

월 1회 브리핑은 개발팀이 아니라 경영진을 대상으로 합니다. 기술 용어를 그대로 옮기지 않고 일정·비용·위험이라는 언어로 번역해 전달합니다. 이 자리에서 다루는 것은 대체로 세 가지입니다. 이번 달에 무엇을 결정했고 왜 그렇게 결정했는지, 지금 남아 있는 위험 중 경영 판단이 필요한 것은 무엇인지, 다음 달에 돈과 사람이 어디에 들어가야 하는지입니다.

초반 한두 달은 진단에서 나온 항목을 정리하고 급한 위험을 막는 데 대부분의 시간이 갑니다. 그 구간을 넘기면 성격이 바뀌어, 결정 자체보다 조직이 스스로 결정할 수 있게 만드는 쪽으로 무게가 옮겨 갑니다. 리뷰 기준을 팀에 넘기고, 아키텍처 결정 기록을 내부 인력이 쓰게 하고, 채용으로 자리를 메우는 일이 여기에 들어갑니다. 자문 기간이 길어질수록 대행이 회의에서 말하는 양이 줄어드는 것이 정상입니다.

무엇이 산출물로 남는가

자문이 끝난 뒤 조직에 남는 것이 기억뿐이라면 그 자문은 실패한 것입니다. 계약 형태에 따라 다음 문서들이 남습니다.

• 아키텍처 결정 기록 — 무엇을 왜 그렇게 정했는지, 어떤 대안을 왜 포기했는지 한 건씩 남깁니다. 담당자가 바뀐 뒤에도 결정을 되짚을 수 있게 하기 위해서입니다.
• 시스템 구성도와 데이터 흐름 — 서버·저장소·외부 연동을 한 장으로 보는 그림입니다. 신규 인력 온보딩과 장애 대응에서 가장 먼저 쓰입니다.
• 리스크 등록부 — 발견한 문제를 심각도·발생 가능성·대응 방안과 함께 표로 관리합니다. 해결된 항목도 지우지 않고 처리 이력을 남겨, 같은 문제가 다시 올라올 때 근거로 씁니다.
• 개발 프로세스 문서 — 브랜치 전략, 코드 리뷰 기준, 릴리스와 롤백 절차를 조직 규모에 맞춰 정합니다. 큰 조직의 절차를 그대로 복사해 오면 지키지 못할 규칙만 늘어납니다.
• 채용 기준과 면접 질문지 — 어떤 역량을 가진 사람을 어떤 순서로 뽑아야 하는지, 무엇을 물어 확인할지 정리합니다. 필요하면 기술 면접에 직접 참여합니다.
• 외주 평가·검수 기준 — 제안 평가 항목, 산출물 목록, 검수 체크리스트를 계약 전에 만들어 둡니다. 검수 시점에 만들기 시작하면 이미 협상력이 없습니다.

문서는 특정 도구에 갇히지 않는 형식으로 드립니다. 내부에 위키가 있으면 그 위키에, 없으면 저장소 안 문서 파일로 남겨 이후에 담당자가 직접 고쳐 쓸 수 있게 합니다. 읽을 사람이 열지 못하는 형식이나 결제가 끊기면 사라지는 도구에 넣어 두는 것은 남긴 것이 아니라고 봅니다.

상근 CTO 채용과 무엇이 다른가

대행이 언제나 나은 선택은 아닙니다. 기술 자체가 제품의 핵심이고 매일 결정이 쏟아지는 조직, 개발 인원이 많아 상시 평가와 관리가 필요한 조직, 장기간 지분과 헌신을 함께 걸 사람이 필요한 조직이라면 상근 CTO를 뽑는 것이 맞습니다. 대행은 그 자리를 영구히 대신하는 방식이 아니라, 뽑을 준비가 될 때까지 또는 상근을 둘 만큼 결정이 잦지 않은 구간을 메우는 방식입니다.

차이는 세 가지로 정리됩니다. 비용 구조가 다릅니다. 상근 임원은 고정비이고 대행은 계약한 범위만큼의 변동비입니다. 권한이 다릅니다. 대행에게는 조직 내 인사권과 평가권이 없습니다. 그래서 의사결정권자와 직접 연결되지 않으면 권고가 실행되지 않고 흐지부지됩니다. 시작할 때 보고선을 조건으로 삼는 이유가 여기에 있습니다. 지식이 남는 방식도 다릅니다. 상근은 사람 안에 지식이 쌓이지만 그 사람이 떠나면 상당 부분이 함께 사라집니다. 대행은 애초에 떠나는 것을 전제하므로 처음부터 문서로 남기는 쪽에 무게를 둡니다.

대행이 맡는 일 중에는 상근 CTO 채용을 돕는 일도 포함됩니다. 어떤 역량이 필요한지 정의하고, 채용 공고와 면접 기준을 만들고, 기술 면접에 함께 들어가고, 입사한 분에게 그동안의 결정 기록을 인계한 뒤 빠지는 순서입니다. 대행이 오래 남는 것이 목표가 아닙니다. 자리를 비워 둔 채로 흘려보낸 시간을 줄이는 것이 목표입니다.

판단의 근거

맘소프트는 경기도 시흥에 있는 개인사업자이며 대표는 윤수현입니다. 사업자등록번호는 505-63-00683, 소재지는 경기도 시흥시 옥구상가1길 23, 4층 103호이고 문의는 [email protected]로 받습니다. 19년이 넘는 기간 동안 제안과 기획 단계부터 아키텍처 설계, 개발, 배포, 운영까지 프로젝트 전 주기를 맡아 왔습니다.

맘소프트가 사업자로서 수행한 일은 다음과 같습니다. CONTEC AX 자문, CONTEC 프로젝트 비용관리 시스템 구축 및 고도화, 전국은행연합회 소비자포털 웹접근성 인증 갱신, J2H 응급전원협진망 앱 자문, 한국지식재산보호원 기술 자문위원, 디에이치소프트 기술 자문입니다.

이와 별개로 삼성전자 제품트래킹과 갤럭시노트 WebGL 3D, KB국민은행 종합부동산정보시스템, SKT 빅데이터 플랫폼, CJ 키오스크 관리시스템, JTBC OOH 플랫폼, 한화시스템 RPA 등은 대표가 개업 이전 재직 기간 중 수행한 경력입니다. 맘소프트의 수행 실적과는 구분해 표기합니다. 판단의 근거로는 유효하지만 맘소프트라는 사업자의 계약 이력은 아니기 때문입니다.

자문만 하는 것이 아니라 직접 만들어 운영도 합니다. 자체 IP 게임 네 종(TDF: Neon Siege, MINDBLOCK, 에그펫, MindDozer 3D)을 Google Play에서 서비스하고 있고, 글귀 알림 앱 WiseWhisper와 가입 없이 쓰는 무료 웹 도구 모음 유틸로(utilo.co.kr)를 운영합니다. 사내에서 쓰는 솔루션으로 WIKI · VMS · PMS · GW를 직접 만들어 씁니다. 게임물 제작업 등록과 통신판매업 신고를 마친 사업자입니다. 주력 스택은 Java와 Spring Boot 3, JPA/QueryDSL, PostgreSQL, Redis, Vue 3, Flutter, Firebase, Astro, WASM입니다. 스토어 심사와 장애 대응, 결제와 개인정보 처리를 직접 겪어 본 자리에서 나온 판단이라는 점이 자문의 밑바탕입니다.

다만 대표 1인 체제라는 점은 분명히 말씀드립니다. 동시에 맡을 수 있는 건수에 한계가 있고, 그래서 이미 진행 중인 일정과 겹치면 시작 시점을 미루자고 먼저 제안드립니다. 인력을 급히 채워 넣고 이름만 걸어 두는 방식은 하지 않습니다. 규모가 필요한 개발 실행은 협업 인력을 붙여 진행하되, 누가 무엇을 맡는지는 계약 전에 밝히고 시작합니다.

이 서비스가 맞지 않는 경우

맞지 않는 요청을 받아 두는 것이 서로에게 가장 손해입니다. 아래에 해당한다면 문의 단계에서 그렇게 말씀드립니다.

• 필요한 것이 개발 인력일 때 — 만들 것이 이미 정해져 있고 손이 부족한 상황이라면 자문이 아니라 개발 계약이 맞습니다. 이 경우 소프트웨어 개발 쪽으로 안내해 드립니다.
• 결정권자와 만날 수 없을 때 — 권고가 중간에서 걸러져 결정권자에게 닿지 않는 구조라면 자문은 문서만 쌓고 끝납니다. 보고선을 열 수 없는 상황이면 시작하지 않는 편이 낫습니다.
• 이미 내린 결론에 서명만 필요할 때 — 특정 업체나 특정 결론을 정당화해 줄 근거가 필요한 요청은 받지 않습니다. 실사 보고서의 값어치는 그 반대편에 있습니다.
• 상시 운영·당직이 필요할 때 — 24시간 장애 대응이나 상시 헬프데스크는 대행의 범위가 아닙니다. 운영 체계와 당직 절차를 설계해 드릴 수는 있습니다.
• 실사 대상 자료에 접근할 수 없을 때 — 코드도 문서도 볼 수 없는 상태에서 나온 실사 결과는 근거가 없습니다. 접근 범위를 먼저 합의해야 시작할 수 있습니다.

맞지 않는다고 말씀드리는 자리에서도, 지금 상황에 무엇이 더 맞는지는 함께 정리해 드립니다. 계약으로 이어지지 않는 대화라도 판단에 필요한 정보는 남는 편이 낫다고 봅니다.

자주 묻는 질문

상근 CTO를 뽑을 때까지만 맡길 수 있나요?

가능하며 오히려 권장하는 형태입니다. 필요한 역량 정의, 채용 공고와 면접 기준 작성, 기술 면접 참여, 입사자에 대한 결정 기록 인계까지 포함해 진행합니다. 인계가 끝나면 자문 범위를 줄이거나 종료합니다.

비용은 어떻게 산정하나요?

진단으로 범위를 확정한 뒤 형태(월 단위 자문 · 프로젝트 리딩 · 일회성 실사)와 투입 강도를 기준으로 산정합니다. 범위를 모르는 상태에서 견적부터 내지 않습니다. 계약 중 범위가 늘면 늘어난 부분을 별도로 합의합니다.

얼마나 걸리나요?

일회성 실사는 대상 시스템의 크기와 자료 접근 여부에 따라 달라지고, 프로젝트 리딩은 과제의 범위가 기간을 결정합니다. 월 단위 자문은 진단에서 나온 급한 항목을 정리하는 초기 구간과 조직에 넘기는 구간으로 나뉩니다. 어느 쪽이든 진단을 마친 뒤에 기간을 말씀드리며, 진단 전에 기간을 숫자로 약속하지 않습니다.

원격으로만 진행되나요?

기본은 원격 협업이며 정기 회의와 중요한 의사결정 자리에는 방문할 수 있습니다. 소재지가 경기도 시흥이라 수도권은 방문 부담이 적고, 그 밖의 지역은 일정과 빈도를 협의해 정합니다.

기존 개발팀이나 외주사와 부딪히지 않나요?

시작할 때 역할을 분명히 하는 것으로 대부분 정리됩니다. 대행은 팀을 평가하러 온 사람이 아니라 결정을 함께 지는 사람이라는 점을 첫 회의에서 공유하고, 지적은 사람이 아니라 구조와 절차를 향하도록 문서로 남깁니다. 외주사에 대해서도 마찬가지로 계약서와 산출물 기준으로만 이야기합니다.

보안과 비밀유지는 어떻게 처리하나요?

자료를 보기 전에 비밀유지 각서를 먼저 체결합니다. 접근 권한은 필요한 범위로 최소화해 요청하고, 계약이 끝나면 전달받은 자료와 접근 권한을 정리합니다. 다른 고객사의 정보를 근거로 이야기하지 않습니다.

기술 실사는 어디까지 봐 주나요?

코드와 아키텍처, 배포·운영 체계, 데이터 모델, 오픈소스 라이선스와 의존성, 보안 및 개인정보 처리 현황, 그리고 이를 유지하는 데 드는 인력과 비용의 추정까지 봅니다. 반대로 법률 자문이나 회계 실사는 범위가 아니며, 해당 영역은 그 분야 전문가와 함께 진행하셔야 합니다.

자문과 개발을 함께 맡길 수 있나요?

가능합니다. 다만 실사나 검수처럼 객관성이 핵심인 일과 그 대상을 직접 만드는 일은 같은 계약 안에 두지 않는 편이 좋습니다. 이해가 충돌할 소지가 있으면 문의 단계에서 먼저 말씀드리고 범위를 나눕니다.

어떤 조직에 맞는 방식인가요?

개발자가 없거나 한두 명인 조직, 외주로 시스템을 만들어 운영 중인 조직, 그리고 개발팀은 있으나 기술 총괄 자리가 비어 있는 조직에 맞습니다. 반드시 스타트업일 필요는 없으며, 업력이 오래된 회사가 오래된 시스템을 다음 단계로 옮길 때도 같은 방식이 유효합니다.

중간에 그만두면 어떻게 되나요?

그때까지 정리된 결정 기록과 리스크 등록부, 작성 중이던 문서를 그대로 넘겨드립니다. 자문을 문서 중심으로 진행하는 이유 중 하나가 이것입니다. 중단 시점이 인계 시점이 되도록 만들어 두면, 관계가 끝나도 조직에 남는 것이 있습니다.