제1부 최고경영진의 역할과 법인 설립 기초

1.2 최고기술책임자(CTO)의 역할과 기술 비전 수립

이 장은 딥테크(Deep Tech) 기업의 최고기술책임자(Chief Technology Officer, CTO)가 책임지는 범위와 그 책임을 수행하는 방법을 다룬다. 핵심 질문은 다섯 가지이다. CTO와 최고경영자(Chief Executive Officer, CEO), 부사장급 기술 임원(VP of Engineering)의 직무 경계는 어디에 두는가, 기술 전략과 기술 로드맵은 어떤 방법으로 세우고 연구개발(R&D) 자원은 어떤 원칙으로 배분하는가, 하드웨어-소프트웨어 융합 개발 체계와 기술 조직은 어떻게 설계하는가, 오픈 소스·표준화·공동 연구·지식재산(IP) 전략 같은 외부 기술 전략은 어떤 기준으로 선택하는가, 기술 위험·연구개발 실패·기술 윤리는 어떤 거버넌스로 관리하는가이다.

독자는 딥테크 기업의 경영진·창업자·CTO·관리 담당자이다. CEO와 CTO의 권한 구분은 1.1.2가 정한 분류 기준(영향 범위, 비가역성, 자원 규모, 대외 구속력)을 따르며, 이 장은 CTO의 관점에서 같은 기준을 적용한다(1.2.2). 경영진 전체의 분담은 1.3가 다룬다. 개요 절(1.2.7)은 요지만 서술하고 본거지 장을 가리키며, 역할 분담(1.2.2)·기술 전략(1.2.4)·로드맵과 비전(1.2.5)·아키텍처 거버넌스(1.2.8)·융합 개발 체계(1.2.10)·조직 설계(1.2.11)·기술 위험과 연구개발 실패(1.2.19)는 이 장이 본거지이므로 깊이 서술하였다. 그 밖의 여러 절은 기술 부채(23.1), 기술성숙도(29.1), 연구개발 포트폴리오의 균형 배분(36.2)처럼 다른 장이 본거지인 주제를 CTO의 판단 기준 수준에서만 다루고 상세를 해당 장에 넘긴다.

읽는 법은 다음과 같다. 의사결정이 필요한 쟁점은 선택지 ①②③으로 펼쳐 장단점을 보이고, 추천은 "견해"로 표시한다. 딥테크 적용 예시는 "가정 예시"이며 실존 기업을 가리키지 않는다. 학술 문헌은 저자와 연도로 인용하며 수록지·권호·쪽수는 생략한다. 원문을 직접 열람하지 못한 문헌의 주장은 인용 전에 원문으로 재확인한다. 'CTO'는 「상법」상 기관 명칭이 아니므로 법적 책임은 대표이사·이사(등기 임원) 또는 집행임원의 지위를 기준으로 서술한다. 이 장은 법률 자문을 대체하지 않는다. 법령은 법제처 국가법령정보센터에서 조회한 판의 조문을 인용하며, 조회한 판의 시행일은 「상법」 2026-09-10, 「특허법」 2025-11-11, 「발명진흥법」 2025-10-01, 「부정경쟁방지 및 영업비밀보호에 관한 법률」 2026-05-28, 「국가연구개발혁신법」 2026-10-02이다.

기준일: 2026-11. 확인하지 못한 조항·수치는 (확인 필요)로 표기한다.

1.2.1 최고기술책임자(CTO)의 정의와 조직 내 위상

정의와 법적 지위

최고기술책임자(CTO)는 기업의 기술 전략, 기술 투자, 기술 조직, 기술 위험에 대하여 경영진 수준에서 책임을 지는 직책이다. 직무의 표준 정의는 없고 범위는 기업마다 다르다. 스미스(Roger D. Smith, 2003)의 연구는 CTO의 역할을 신기술을 추적하여 제품이나 서비스가 될 수 있는지 판단하는 일, 그리고 CEO·경영진·연구 조직·마케팅 책임자와 업무 관계를 구축하는 일로 설명한다(원문은 열람하지 못하고 서지 정보와 초록으로만 확인하였다). 이 책은 이 직무를 기술 전략, 연구개발 포트폴리오와 자원 배분, 아키텍처와 기술 의사결정, 기술 조직과 인재, 외부 기술 전략, 기술 위험과 윤리의 여섯 영역으로 정리한다(작업 틀, 견해). 이 구분은 학술적 합의가 아니라 이 장의 서술 편의를 위한 것이다.

「상법」은 CTO를 기관으로 정하지 않는다. CTO는 직함이므로 법적 지위는 등기 여부와 실제 업무집행에 따라 정해진다. 집행임원 설치회사에서는 CTO를 집행임원으로 선임할 수 있고, 집행임원의 권한은 설치회사의 업무집행과 정관이나 이사회 결의에 따라 위임받은 업무집행에 관한 의사결정이다(「상법」 제408조의4). 이사가 아닌 CTO도 이사에게 업무집행을 지시하거나 이사의 이름으로 업무를 집행하거나 업무를 집행할 권한이 있는 것으로 인정될 만한 명칭을 사용하여 업무를 집행하면, 그 업무에 관하여 이사의 책임 규정(제399조, 제401조, 제403조, 제406조의2)을 적용할 때 이사로 본다(「상법」 제401조의2 제1항). 같은 항 제3호가 열거하는 명칭은 명예회장·회장·사장·부사장·전무·상무·이사이고 "기타 회사의 업무를 집행할 권한이 있는 것으로 인정될 만한 명칭"을 포함한다. CTO라는 직함이 여기에 해당하는지는 직함이 아니라 실제 업무집행의 내용에 따라 개별적으로 판단될 사항이다(해당 판례는 확인하지 못하였다, 확인 필요). 등기 임원과 미등기 임원의 구분은 1.3.15, 이사의 지위와 의무는 1.5가 본거지이다.

역할 영역

위상의 선택지

CTO를 조직도의 어디에 두는지는 다음 세 가지로 나뉜다.

• ① CEO 직속 경영진: 기술 판단이 전략 결정에 직접 반영되고 CEO와 CTO의 권한 분배(1.2.2)를 명시하기 쉽다. CTO가 경영 전반의 제약(현금, 시장, 규제)을 함께 부담하므로 기술 조직에 대한 시간 투입이 줄어드는 비용이 있다.
• ② COO 등 다른 경영진 산하: 양산·운영과 기술의 연계가 강해진다. 반면 기술 전략이 운영 효율 기준으로 평가되어 탐색적 연구개발이 위축될 수 있고, 이사회와 투자자에게 기술 판단이 한 단계를 거쳐 전달된다.
• ③ 이사회 직접 접점(등기이사 겸직 또는 정기 기술 보고): 기술 위험의 독립적 견제가 가능하다. 이사의 의무와 책임이 함께 발생하므로 등기 여부와 보고 범위를 사전에 정해야 한다(1.5).

견해: 기본값은 ①로 두고 이사회에는 기술 위험과 로드맵의 정기 보고 경로를 별도로 두는 방식을 권한다. 1.1.2가 정한 "기술 사실은 CTO, 그 사실에 근거한 사업 약속은 CEO"라는 구분이 ①에서 가장 단순하게 운용되고, 이사회 접점은 ③의 견제 기능을 일부 확보하기 때문이다.

성장 단계별 CTO의 직무

이 표는 일반화한 견해이며 구성원 수 같은 구체적 전환 기준은 확인한 근거가 없어 제시하지 않는다. 전환 시점은 CTO의 시간이 어느 업무에 소모되는지로 점검한다.

함정

첫째, 가장 뛰어난 개발자를 CTO로 지정하는 경우, 개발 역량과 조직·전략 역량이 다르다는 점을 간과하기 쉽다. 직무 전환에 맞춘 역량 개발 계획이 없으면 직접 구현에 시간을 쓰면서 조직 설계가 지연된다. 둘째, 대외 직함은 CTO인데 실질 권한이 없는 경우로, 투자자와 고객은 CTO를 기술 성능의 보증인으로 기대하므로 책임만 남는 직함·권한 불일치가 생긴다(CEO에 대하여 같은 유형을 서술한 1.1.1 참조). 셋째, 직함의 인플레이션이다. 부서장 수준의 직무에 CTO 직함을 부여하면 CTO 직무의 범위가 모호해지고 이후 외부 영입 CTO와의 충돌 위험이 커진다(57.6).

1.2.2 최고경영자(CEO)와 최고기술책임자(CTO)의 역할 분담 및 협업 구조

분배의 기준 — 1.1.2와 같은 기준

CEO와 CTO의 권한 분배는 직함의 위계가 아니라 결정의 성질에 따라 정한다. 이 책은 CEO 측 서술(1.1.2)과 CTO 측 서술(이 절), 경영진 전체 서술(1.3.12)이 같은 기준을 쓰도록 한다. 결정마다 최종 결정자(Accountable, A) 한 명을 지정하고 수행 책임자(Responsible, R), 협의 대상(Consulted, C), 통보 대상(Informed, I)을 구분하는 책임·권한 매트릭스(RACI)를 사용하며, 결정의 성질은 영향 범위, 비가역성, 자원 규모, 대외 구속력의 네 가지로 분류한다. 이 절은 1.1.2의 표와 같은 판정을 CTO의 관점에서 다시 읽고, 그 표에 없는 하위 결정을 같은 기준으로 분류하는 방법을 제시한다. 표의 A는 내부 책임 배분이며 법적 책임의 배분이 아니다. 법적 책임은 이사나 대표이사의 지위, 그리고 실제 업무집행 여부로 정해진다(「상법」 제401조의2 제1항, 1.2.1).

1.1.2 표의 CTO 관점

표에서 CTO가 A인 항목은 기술 전문성이 결정의 질을 좌우하고 대외 구속력이 낮은 영역에 한정된다. 나머지 항목에서 CTO는 최종 결정이 아니라 결정의 근거가 되는 사실을 책임진다. CTO의 R은 단순한 실무 수행이 아니라, CEO가 결정하기 전에 기술 사실을 확정해 주는 책임이다. 사실 확인 산출물이 없으면 CEO의 결정은 근거 없는 약속이 된다.

표에 없는 하위 결정의 분류

실무에서는 위 아홉 항목보다 세부적인 결정이 훨씬 많다. 이를 항목마다 합의하려 하지 말고 네 가지 기준으로 분류한다. 아래는 가정 예시이다.

규칙은 세 가지이다. 첫째, 대외 구속력이 높거나(계약, 인증 신청, 투자자 진술) 자원 규모가 큰 결정은 CEO가 A이다. 둘째, 기술 부서 내부에서 되돌릴 수 있고 대외 구속력이 낮은 결정은 CTO가 A이며 CEO에게는 통보한다. 셋째, 기술 전문성이 결정의 질을 좌우하고 대외 구속력이 낮은 영역(아키텍처, 기술 스택)은 비가역성이 높더라도 1.1.2의 표에 따라 CTO가 A이되, 비가역성과 영향 범위가 모두 큰 결정은 CEO에게 사전에 통보하고 결정 기록을 남긴다. 1.1.1은 비가역성이 높고 전사에 영향을 미치며 대외 구속력이 있는 결정의 최종 승인을 CEO에게 남기도록 하며, 이 규칙은 그 기준과 1.1.2의 표에 맞춘 것이다.

협업 구조와 기본 규칙

협업 구조의 선택지(① CEO 주도형, ② 기능 분할형, ③ 이사회 중재형)와 견해는 1.1.2가 서술하였다. 이 절은 CTO가 ②를 운용할 때 필요한 장치를 정리한다.

• 경계 규칙: 기술적 사실에 관한 판단은 CTO가, 그 사실에 근거한 사업 약속(출시·계약·대외 진술)은 CEO가 최종 결정한다. CTO의 이견은 기록으로 남긴다(1.1.2). 기록은 이견의 내용, 근거가 되는 측정 조건, 결정 일시, 결정자로 구성하면 충분하다.
• 합의 문서: 결정 영역별 A·R·C·I, 상향 절차(당사자 합의, 대안 비교 문서화, 외부 자문 또는 이사회 상정), 기록 방식을 한 문서에 담아 CEO와 CTO가 서명한다. 회사 규모와 정관, 이사회 규정이 바뀌면 개정한다.
• 정기 접점: 로드맵 갱신, 위험 등록부 검토, 자원 재배분을 CEO와 CTO가 같은 회의에서 다루면 기술 사실과 사업 판단이 따로 움직이는 것을 막는다. 주기는 개발 주기와 자금 조달 일정에 맞춘다.
• 사실과 약속의 분리: 투자자·고객 대상 진술 전에 CTO가 사실 확인서를 작성한다. 사실 확인서가 없으면 CEO가 근거를 직접 확인하고 그 사실을 기록한 뒤에 진술한다.

CTO의 시각에서 본 실패 유형

CTO 측에서 자주 나타나는 실패는 다음과 같다. 첫째, 결정 전에 기술 사실을 제출하지 않고 결정 후에 반대하는 경우이다. 이견은 결정 전에 기록으로 제출해야 효력이 있다. 둘째, 기술적 한계를 비관적으로 일반화하여 사업 판단 영역까지 거부권을 행사하는 경우이다. CTO의 이견이 기술 사실에 대한 것인지 사업 약속에 대한 것인지를 구분해야 한다. 셋째, 기술 사실을 단일 수치(성공 확률, 일정)로만 보고하는 경우이다. 가정과 미해소 위험을 함께 제출해야 CEO가 약속의 손실을 가늠할 수 있다. 넷째, CTO 한 사람에게 핵심 기술 지식이 집중되어 이탈 시 개발이 중단되는 경우로, 지식 공유 체계(1.2.12, 6.6)와 후임 육성(1.2.25)이 대응책이다. 경영진 전체의 권한 분담과 RACI 설계는 1.3.12가 본거지이다.

1.2.3 부사장급 기술 임원(VP of Engineering)과의 직무 경계 설정

용어와 구분의 성격

부사장급 기술 임원(VP of Engineering)은 엔지니어링 조직의 운영과 전달(delivery)을 책임지는 직책으로 쓰이는 경우가 많다. 한국 기업에서는 개발 총괄 부사장이나 개발 본부장 같은 명칭으로 부르기도 한다. CTO와 VP of Engineering의 구분에 관한 표준이나 학술적으로 합의된 정의는 확인하지 못하였다. 따라서 이 절의 구분은 관행적 구분을 정리한 견해이며, 회사마다 직함이 다르게 쓰이므로 직함이 아니라 책임 영역을 기준으로 문서화해야 한다.

책임 영역의 구분(일반화 예시)

경계의 원칙은 CTO가 무엇을(방향), VP가 어떻게·언제(실행)를 책임진다는 것이다. 이 구분은 결정의 성질로도 확인할 수 있다. 비가역성이 높거나 전사 영향이 큰 기술 결정은 CTO, 되돌리기 쉬운 팀 단위 실행 결정은 VP가 최종 결정한다. 다만 CEO가 A인 결정은 1.2.2에 따른다.

구조의 선택지

• ① CTO가 두 직무를 겸임: 의사결정 단계가 적고 책임이 분명하다. 조직이 커지면 일정·인사 운영이 CTO의 시간을 잠식하여 전략과 대외 업무가 지연된다.
• ② CTO(방향·대외)와 VP of Engineering(실행)으로 분할: 전문성을 나누어 병행 처리할 수 있다. 책임 경계가 모호하면 방향 결정과 실행 결정이 어긋나고, CTO가 실행 권한이 없어 방향을 관철하지 못하는 문제가 생긴다.
• ③ CTO가 내부 총괄을 맡고 대외·연구 역할을 별도의 수석 연구자(Chief Scientist, Fellow 등)가 담당: 내부 운영의 일관성이 높고 연구 깊이를 확보하기 쉽다. 직함이 늘어 경영진 체계가 복잡해지고 CEO의 조정 부담이 커진다.

견해: 분할(②)을 검토하는 신호는 CTO의 시간 대부분이 일정·인사·프로세스 운영에 소모되어 기술 전략과 대외 업무가 정기적으로 지연되는 경우, 그리고 기술 조직이 커져 CTO가 모든 결정의 병목이 되는 경우이다. 분할의 시점을 구성원 수로 정한 근거는 확인하지 못하였다. 분할하기 전에 책임 경계표를 만들고 전환 기간의 번복 요건을 정해 두는 것을 권한다.

운영상의 주의

첫째, 분할 후 두 사람의 권한이 겹치는 영역(조직 개편, 채용 기준, 아키텍처 예외 승인)은 합의 문서에 A를 한 명으로 지정한다. 둘째, 보고 체계를 정한다. VP가 CTO에게 보고하는 구조인지 CEO에게 직접 보고하는 구조인지에 따라 CTO의 실행 권한이 달라진다. 셋째, 두 임원이 서로 다른 지표로 평가받으면 충돌한다. CTO는 기술 위험과 로드맵 달성, VP는 전달 일정과 품질을 평가하되 공통 목표(출시, 인증 통과)를 하나 이상 공유시킨다. 이 구분은 경영진 전체의 분담(1.3.12)과 CEO–CTO 분배(1.2.2)에 일치해야 한다. VP 직무의 승계와 후임 계획은 1.2.25에서 다룬다.

1.2.4 기술 전략 수립의 이론적 기초와 방법론

정의와 범위

기술 전략은 어떤 기술 역량에 투자하고, 어떤 역량은 외부에서 조달하며, 어느 시점에 어떤 제품과 시장에 연결할 것인지에 대한 선택의 집합이다. 기술 전략과 사업 전략의 정합을 확보하는 방법론은 1.1.8이 본거지이고, 이 절은 CTO가 기술 전략을 구성하는 이론적 기초와 방법을 다룬다. 이 절에서 인용하는 문헌 중 원문을 직접 확인하지 못한 것은 저자와 연도 수준의 귀속이며, 인용 전에 원문으로 재확인한다.

이론적 기초

루멜트(Rumelt)와 피사노(Pisano)의 요지는 해설 자료로만 확인하였으며(문헌에 따르면), 파괴적 혁신(Christensen, 1997)과 지배적 설계(Utterback, Abernathy, 1975), S-곡선 같은 기술 변화 이론은 36.4가 본거지이다.

방법론: 네 단계의 작업 틀(견해)

1. 진단: 외부(기술 변화의 속도, 경쟁 기술, 규제와 인증 일정, 공급망)와 내부(역량 지도, 자원, 현금 소진 속도, 인력)를 함께 평가하고 핵심 불확실성을 기술 위험과 시장 위험으로 구분하여 목록화한다. 진단이 없는 전략은 선택의 근거가 없다.
2. 선택: 기술 영역을 핵심(자체 개발로 차별화), 보완(제휴·공동 개발), 범용(구매·오픈 소스) 세 입장으로 분류하고, 선택하지 않는 기술 경로와 그 이유를 기록한다. 이 분류는 이 책의 작업 틀이다.
3. 실행 설계: 로드맵(1.2.5), 포트폴리오(1.2.6), 조직(1.2.11), 위험 관리(1.2.19)로 전환한다.
4. 갱신 규칙: 전략이 의존하는 가정의 목록과 갱신 트리거(시험 결과, 경쟁 기술의 출현, 규제 변경, 자금 조달 변동)를 정한다. 기술 예측 기법은 36.1이 다룬다.

쟁점: 자체 개발, 제휴, 도입의 선택

• ① 자체 개발: 통제와 차별화가 가능하고 학습이 내부에 축적된다. 시간과 비용이 크고 실패 위험을 전부 부담한다.
• ② 제휴·공동 개발: 역량을 보완하고 위험을 분담한다. 지식재산 귀속과 핵심 기술 노출의 문제가 있고 의존이 생긴다(1.2.17).
• ③ 도입(라이선스 인, 구매, 오픈 소스 사용): 속도가 빠르고 초기 비용이 낮다. 차별화가 어렵고 공급자·라이선스 조건에 종속된다(1.2.14, 1.2.16).

견해: 고객이 가치로 인식하는 차별 요소와 개선 속도를 좌우하는 학습이 필요한 영역은 자체 개발하고, 범용 영역은 도입하는 것을 기본값으로 둔다. 근거는 자원이 한정된 딥테크 기업이 모든 영역을 자체 개발하면 차별화에 필요한 자원이 분산된다는 점이다. 단, 안전·인증·보안과 관련된 영역은 도입하더라도 검증 책임이 회사에 남으므로 통제 수단을 함께 정한다.

기술 전략 문서의 구성

기술 전략 문서는 진단 요약, 영역별 입장(핵심·보완·범용), 선택하지 않은 경로와 이유, 핵심 가정과 갱신 트리거, 자원 요구, 위험과 중단 기준, 측정 지표로 구성한다. 이 문서는 CEO의 우선순위 결정(1.1.2에서 CEO가 A)과 이사회 설명(1.1.5의 일치 기준)의 근거가 된다.

함정

첫째, 기술적 선호를 전략으로 오인하는 경우이다. 기술 우수성이 시장 가치와 일치한다는 가정은 검증 대상이다. 둘째, 로드맵이나 목표 목록이 곧 전략이라고 보는 경우이다. 전략은 목표가 아니라 목표에 이르는 선택이다. 셋째, 모든 영역을 자체 개발하는 경우로, 개발 역량이 분산되어 핵심 영역의 진척이 느려진다. 넷째, 진단 없이 선택하는 경우로, 경쟁 기술과 규제 변화를 점검하지 않으면 전략이 첫 가정의 위반으로 성립하지 않게 된다. 다섯째, CEO의 사업 전략과 기술 전략의 가정이 서로 다른 경우이다. 동일한 가정 목록을 공유해야 한다.

1.2.5 기술 로드맵 설계와 장기 기술 비전 구축

비전과 로드맵의 관계

1.1.5는 기술 비전을 일정 시간 후(기간은 기술 영역마다 크게 다르다)에 회사가 어떤 기술적 위치에 도달하려는지를 나타내는 방향으로, 기술 로드맵을 그 방향에 이르는 기술 마일스톤, 마일스톤 간 의존 관계, 필요한 자원을 시간 축에 배열한 계획으로 정의한다. 이 절은 CTO가 둘을 작성하는 방법을 서술한다. 비전의 기간은 업종의 개발 주기에 따라 달라지며 규격이 정한 값이 아니다. 역할 구분은 1.1.5를 따른다. CEO는 비전이 연결되는 고객 문제와 수익 구조를 확정하고 우선순위와 중단 기준을 정하며 자원을 약속한다. CTO는 실현 가능성을 평가하고 로드맵을 작성한다. 기술 패러다임이 바뀌는 시기의 비전 제시는 36.4가 다룬다.

기술 비전의 구성

1.1.5가 제시한 세 가지 점검 기준을 작성 항목으로 풀면 다음과 같다.

• 검증 가능한 목표 상태: 성능 목표, 시장 위치, 비용 구조처럼 달성 여부를 판정할 수 있는 형태로 쓴다. 측정 조건(시험 환경, 데이터, 부하)을 함께 적는다.
• 선택하지 않은 경로: 검토했으나 택하지 않은 기술 경로와 이유를 기록한다. 이 항목이 없으면 비전은 선언에 그친다.
• 대외 설명과의 일치: 이사회와 투자자에게 설명하는 내용과 내부 로드맵이 같은 가정에 기초하는지 확인한다. 불일치는 신뢰 자본의 소모로 이어진다(1.1.11).

로드맵의 구조

기술 로드맵은 시간 축에 여러 계층(시장·제품·기술·자원 등)을 대응시켜, 시장의 요구가 어떤 제품 특성을 요구하고 그것이 어떤 기술 역량과 자원에 의존하는지를 보이는 도식으로 알려져 있다. Phaal, Farrukh, Probert(2004)는 이런 구조를 기업의 사업 계획에 기술 개발을 통합하는 방법으로 제시하고, 산업계와 함께 개발한 단기 착수 방법(fast-start)을 소개하였다(원문은 열람하지 못하고 서지 정보와 초록으로 확인하였다, 문헌에 따르면). 이 책은 계층의 수와 이름을 정하지 않고, 회사의 의사결정에 필요한 최소 계층으로 구성할 것을 권한다.

시간 지평은 업종에 따라 달라지므로 가정 예시이다. 원칙은 가까운 기간은 약속에 가깝게, 먼 기간은 가설로 다루는 것이다.

로드맵 항목의 필수 속성

하드웨어를 포함하는 기업은 인증과 양산 이관 일정을 로드맵 안에 넣는다. 기술이 시험실에서 검증되어도 제조성숙도가 따르지 않으면 제품 일정은 지연된다(29.1, 29.3).

갱신 규칙

1.1.5는 로드맵을 확정된 계획이 아니라 시간이 지날수록 갱신해야 하는 가설로 규정한다. 갱신은 두 방식으로 운영한다. 정기 갱신은 분기나 반기처럼 고정된 주기에 마일스톤 달성 상태와 가정을 점검한다. 트리거 갱신은 시험 실패, 경쟁 기술의 출현, 규제 변경, 자금 조달 변동처럼 사전에 정한 사건이 발생할 때 임시로 수행한다. 갱신 결과는 변경 이력으로 남기고, 갱신이 자원 재배분이나 중단 결정에 이르는 경로를 사전에 정한다. 변경 이력이 없으면 지연이 누적되어도 로드맵 상 일정만 이동하여 원인이 가려진다.

쟁점: 로드맵의 공개 범위

• ① 내부 상세·외부 요약: 내부에는 전체 로드맵, 투자자·고객에는 방향과 주요 마일스톤만 공개한다. 경쟁사 노출과 약속의 해석을 줄일 수 있으나 두 문서 사이의 불일치를 관리해야 한다.
• ② 투자자용 별도 요약본: 자금 조달 계획과 정렬된 요약을 별도로 만든다. 투자자 기대가 형성되므로 요약본의 가정이 내부 로드맵의 가정과 같아야 한다.
• ③ 고객 대상 제품 로드맵 공개: 구매 결정을 돕는다. 공개한 일정은 약속으로 읽히므로 지연이 곧 신뢰 문제가 되고, 계약상 책임으로 이어질 수 있다.

견해: ①을 기본으로 하고, 외부에 공개하는 모든 일정과 성능 수치는 CTO의 사실 확인서를 거친 뒤 CEO가 최종 결정한다. 1.1.2가 투자자·고객 대상 기술 성능 진술의 최종 결정자를 CEO로, 사실 확인을 CTO로 배분한 것과 같은 방향이다.

함정

첫째, 로드맵이 기능 목록이나 간트 차트로 환원되는 경우이다. 의존 관계와 가정이 빠지면 지연의 원인을 분석할 수 없다. 둘째, 계획이 낙관적으로 작성되는 경우이다. 카너먼과 트버스키(Kahneman, Tversky, 1979)가 지적한 계획 오류(Planning Fallacy)처럼 과제 완료 시점을 과소 추정하는 경향이 있으므로(귀속은 기억에 의존한 것이며 원문은 확인하지 못하였다, 확인 필요), 유사 과제의 과거 실적을 기준으로 삼거나 독립 검토를 둔다. 셋째, 갱신 없이 최초 로드맵을 유지하여 현실과 분리되는 경우이다. 넷째, 비전이 추상적 선언에 머물러 자원 배분에 쓰이지 못하는 경우이다. 포트폴리오와의 정렬은 36.2.27이, 기술 예측과의 연계는 36.1.13이 다룬다.

1.2.6 연구개발(R&D) 포트폴리오 구성과 자원 배분 원칙

정의와 이 절의 범위

연구개발 포트폴리오는 같은 자원을 두고 경쟁하는 연구개발 과제의 집합과 그 구성이다. 핵심(Core)·인접(Adjacent)·변혁적(Transformational) 범주의 균형 배분과 포트폴리오 거버넌스는 36.2이, 단계별 지속·중단 판단은 36.3이 본거지이다. 이 절은 CTO가 포트폴리오를 구성하고 자원을 배분하는 원칙까지를 서술하며, 범주별 비율의 수치는 제시하지 않는다.

자원의 범위

자원은 예산에 한정되지 않는다. 인력(특히 소수 핵심 인력의 시간), 시험 설비와 장비, 외부 자원(외주, 파트너), 경영진의 주의력이 모두 한정되어 있다. 딥테크 기업은 소수 핵심 연구자·엔지니어에 대한 의존도가 높으므로(1.1.3) 실제 병목은 예산이 아니라 핵심 인력의 시간일 수 있다. 따라서 자원 배분은 예산표와 함께 핵심 인력 배정표를 작성하여 점검한다.

자원 배분 원칙(견해)

1. 전략 정합: 모든 과제는 로드맵(1.2.5)의 마일스톤에 연결한다. 연결되지 않는 과제는 탐색 항목으로 분리하고 상한을 둔다.
2. 단계별 투자: 정보가 확보되는 만큼 자원을 늘린다. 불확실한 투자를 단계로 나누어 지속·중단·확대를 결정하는 실물옵션 관점은 1.1.10이 개관하였다.
3. 사전 중단 기준: 착수 시점에 중단 기준을 합의한다. 연구개발 프로젝트 중단의 최종 결정자는 CEO이므로(1.1.2) CTO는 기준 충족 여부를 평가하여 제출한다.
4. 용량 예비: 계획 용량 전부를 배정하지 않고 긴급 대응, 기술 부채 상환, 탐색을 위한 예비를 둔다. 예비의 적정 비율은 근거를 확인하지 못하였으며 회사의 사고 빈도와 변경 빈도로 정한다.
5. 핵심 인력의 분산: 한 사람에게 여러 핵심 과제를 중복 배정하지 않고, 특정 인력에 의존하는 단일 장애점의 목록을 관리한다.
6. 독립 검토: 과제 책임자는 자신의 과제에 낙관적이기 쉬우므로 중간 점검은 해당 과제 밖의 검토자가 수행한다.

예산 구조의 예시(가정 예시)

쟁점: 배분 방식

• ① 하향식: CEO와 CTO가 범주별 총량을 배정한다. 전략과 일관되고 빠르나 현장의 정보가 반영되지 않는다.
• ② 상향식: 과제 제안을 평가표로 점수화하여 선정한다. 현장 정보를 반영하나 단기 성과가 큰 과제에 편중되어 전체 균형이 깨질 수 있다.
• ③ 혼합: 범주별 총량은 하향식으로 정하고, 총량 안의 과제는 상향식으로 선정한다.

견해: 기본값은 ③이다. 총량은 전략과 자금 제약에 일관되어야 하고, 개별 과제의 타당성은 현장 정보가 필요하기 때문이다. 하이브리드 배분 프로세스의 상세 설계는 36.2.15가 다룬다.

CEO·이사회와의 관계

1.1.2는 연구개발 예산 총량과 자원 배분의 최종 결정자를 CEO로 두고 이사회는 예산 승인 단계에서 협의하는 것으로 예시한다. 1.1.10은 CEO의 책임을 개별 과제의 선택보다 전체 위험 한도의 설정에 두며, 한도는 고위험 과제에 허용하는 예산 비중의 상한, 단일 과제의 실패가 회사 존립에 미치는 영향의 한도, 중단 규율로 구성된다. CTO는 이 한도 안에서 과제를 구성하고 한도에 접근하면 CEO에게 보고한다. 이사회 수준의 포트폴리오 감독과 CTO의 거버넌스 역할은 36.2.24가 다룬다.

점검 지표

포트폴리오의 상태는 로드맵에 연결된 과제의 비율, 핵심 인력 배정의 집중도, 마일스톤 달성과 지연의 분포, 중단된 과제가 남긴 자산(학습 결과, 지식재산, 재사용 가능한 설비)으로 점검한다. 지표를 단기 성과로만 구성하면 탐색 과제가 구조적으로 불리해지므로, 탐색 과제는 학습 목표의 달성 여부로 별도 평가한다.

1.2.7 기술 부채(Technical Debt) 식별과 관리 전략의 개요(상세는 23.1)

기술 부채는 당장의 속도를 위해 택한 설계·구현상의 타협이 이후의 변경 비용을 높이는 현상을 금융 부채에 비유한 개념이다. 워드 커닝엄(Ward Cunningham)이 1992년 객체지향 프로그래밍 학회(OOPSLA)에서 발표한 경험 보고에서 제시한 비유로 알려져 있다(원문은 열람하지 못하고 2차 자료로 확인하였다, 문헌에 따르면). 유형 분류, 정량 측정, 상환 전략의 상세는 23.1가 본거지이며, 이 절은 CTO의 관리 책임까지만 서술한다.

CTO의 관리 책임은 세 가지이다. 첫째, 가시화이다. 부채를 항목별로 기록한 부채 대장을 두고 발생 원인, 영향 범위, 개발 속도에 미치는 비용(이자)을 함께 기재한다(23.1.13, 23.1.5). 보이지 않는 부채는 우선순위 결정에서 제외되기 때문이다. 둘째, 용량 정책이다. 연구개발 총량 안에서 부채 상환에 배정할 용량의 비율을 CEO와 합의한다(1.2.2, 1.2.6). 적정 비율의 수치 기준은 확인하지 못하였으며 제품의 변경 빈도와 사고 이력으로 정한다. 셋째, 의도적 부채의 승인이다. 출시 일정을 위해 설계상 타협을 택할 때는 CTO가 승인하고 상환 시점과 조건을 기록한다. 이는 부채를 금지하는 것이 아니라 비용을 인지한 채 선택하도록 하는 장치이다.

딥테크 기업에서는 부채가 소스코드에 한정되지 않는다. 하드웨어 설계의 임시 해결책, 펌웨어, 시험 자동화의 공백, 문서, 데이터 구조, 외부 오픈 소스 의존성이 모두 변경 비용을 높인다(23.1.25, 23.1.26, 23.1.27). 경영진에게는 부채를 기술 용어가 아니라 개발 속도 저하와 일정 지연 위험으로 번역하여 보고한다. 부채 비유는 상환 시점과 이자율이 확정되지 않는다는 점에서 금융 부채와 다르므로, 비용 추정은 가정으로 표기한다.

1.2.8 소프트웨어 아키텍처 거버넌스와 기술 의사결정 기록(ADR)

정의와 목적

아키텍처 거버넌스는 아키텍처에 관한 결정권, 원칙, 검토 절차, 예외 처리를 정하는 체계이다. 목적은 팀이 독립적으로 결정하도록 하면서 전사적 일관성과 위험 통제를 확보하는 것이다. 아키텍처 기술(description)에 관한 국제 표준으로 ISO/IEC/IEEE 42010이 있으며 2022년 11월에 제2판이 발행되었다. 목차상 아키텍처 결정과 근거를 다루는 조항을 두고 있으나, 본문은 열람하지 못하여 요건의 세부는 확인하지 못하였다(확인 필요).

거버넌스의 구성 요소

• 아키텍처 원칙: 인터페이스 우선, 안전 기능의 분리, 데이터 소유권처럼 짧고 위반 여부를 판정할 수 있는 형태로 정한다.
• 결정 등급: 영향 범위, 비가역성, 자원 규모, 대외 구속력의 네 기준(1.2.2)으로 중대 결정과 팀 결정을 나눈다. 중대 결정만 검토 절차를 거친다.
• 검토 절차: 중대 결정은 사전에 영향을 받는 팀과 전문가의 검토를 받는다.
• 예외 관리: 원칙을 따르지 못할 때는 예외 승인, 기한, 해소 계획을 기록한다. 기한 없는 예외는 기술 부채(1.2.7)가 된다.
• 결정 기록: 결정과 근거를 기록하여 후임과 감사에 대비한다.

아키텍처 원칙의 예시

원칙은 위반 여부를 도구나 검토로 판정할 수 있어야 한다. 판정할 수 없는 원칙은 선언에 그친다. 아래는 가정 예시이다.

기술 의사결정 기록(ADR)

ADR(Architecture Decision Record)은 중요한 아키텍처 결정을 짧은 문서로 기록하는 방식이다. 마이클 나이가드(Michael Nygard)가 2011년 11월에 공개한 글에서 제안하였고(발행일은 2차 자료로 확인하였다), 제목, 상태, 맥락, 결정, 결과의 항목을 두는 템플릿이 널리 쓰인다. 운영 규칙은 다음과 같다(견해).

1. 결정 시점에 작성한다. 사후에 재구성한 기록은 대안과 기각 이유가 누락된다.
2. 코드 저장소 같은 버전 관리 체계에 보관한다.
3. 승인된 기록은 수정하지 않고, 결정이 바뀌면 새 기록으로 대체하고 이전 기록의 상태를 갱신한다.
4. 대안과 기각 이유, 결정이 의존하는 가정을 포함한다.
5. 영향을 받는 요구사항, 안전 관련 항목, 인터페이스 문서와 연결한다.

작성 대상은 네 기준 중 비가역성이나 영향 범위가 높은 결정으로 한정한다. 모든 결정을 기록하면 기록이 부담이 되어 형식화된다.

쟁점: 거버넌스 모델의 선택

• ① 중앙 심의형: 아키텍처 위원회가 중대 결정을 승인한다. 일관성이 높으나 병목이 생기고 팀의 속도가 느려진다.
• ② 분산 자율형: 원칙과 제약 안에서 팀이 결정한다. 빠르고 팀의 책임감이 높으나 팀 간 불일치와 중복이 생긴다.
• ③ 자문형: 결정은 팀이 하되 영향이 큰 결정은 영향을 받는 팀과 전문가의 자문을 거치고 기록한다. 속도와 일관성을 절충하나 자문이 이행되는지 점검해야 한다.

견해: 기본값은 ③이고, 하드웨어 인터페이스·안전·보안처럼 되돌리기 어렵고 인증과 연결되는 결정은 ①을 적용한다. 근거는 되돌리기 어려운 결정은 심의 비용을 감수할 가치가 있고, 나머지 결정은 속도가 경쟁력이라는 점이다.

조직과의 관계

콘웨이(Melvin Conway, 1968)는 시스템을 설계하는 조직이 그 조직의 의사소통 구조를 복제한 설계를 산출하게 된다고 주장하였다. 원 논문은 실증보다 서술에 의존한다는 평가가 있으므로 법칙으로 받아들이기보다 점검 관점으로 사용한다. 아키텍처를 바꾸려면 팀 구조와 책임 경계도 함께 바꾸어야 하는지 점검한다(1.2.11).

운영 지표(견해)

거버넌스가 작동하는지는 중대 결정 중 기록이 있는 비율, 예외 승인의 건수와 기한 초과 건수, 중대 결정의 검토에 걸린 시간으로 점검한다. 목표 수치의 근거는 확인하지 못하였으므로 제시하지 않으며 추세를 본다. 검토에 걸린 시간이 계속 늘어나면 ① 중앙 심의형의 병목 신호이다.

딥테크 기업의 고려 사항

하드웨어 인터페이스, 안전 기능의 분리, 실시간 요구(1.2.21), 보안 구조에 관한 결정은 인증 심사에서 설계 근거를 요구받을 수 있으므로 결정 기록이 증빙 자료가 된다(요구 범위는 규격별로 확인한다). ADR에는 기술 노하우가 포함되므로 영업비밀 관리 대상이며 접근 통제를 적용한다(14.3.3, 14.3.20).

함정

기록만 남고 실제 결정은 다른 곳에서 이루어지는 형식화, 위원회의 병목, 승인 후 갱신되지 않아 현실과 어긋난 기록, 기록 부재로 후임이 결정의 근거를 복원하지 못하는 상황(1.2.25)이 대표적이다.

1.2.9 핵심 기술 역량 평가 및 기술 성숙도(TRL) 관리

핵심 기술 역량의 평가

CTO가 평가하는 역량은 CEO의 역량(1.1.4)과 달리 조직이 보유한 기술 역량이다. 평가는 기술 영역별 역량 지도로 정리한다. 항목은 전략적 중요도, 보유 수준, 특정 인력에의 의존도(단일 장애점), 지식재산 지위, 외부 의존도, 격차 해소 방식이다. 지도는 자체 개발할 영역(1.2.4)과 이를 뒷받침하는 인력 계획(1.2.11)의 근거가 된다. 역량 격차 분석과 보완 전략은 36.2.19, 36.2.20이 다룬다.

기술성숙도(TRL)의 척도

기술성숙도(Technology Readiness Level, TRL)는 기술이 시험실의 원리 확인에서 실제 운용 증명까지 어느 단계에 있는지를 아홉 단계로 나타내는 척도이다. 아래 표는 미국 국방부(DoD)의 2010년 국방획득지침서(Defense Acquisition Guidebook)에 수록된 정의를 번역한 것이다. 미국 국립학술원(National Academies)의 2014년 워크숍 보고서 부록이 DoD 기술성숙도 평가(TRA) 지침(2011)을 출처로 같은 정의의 TRL 5~7 행을 수록한 것을 대조하였다.

기관마다 문언이 같지 않다. 미국 항공우주국(NASA)의 지구과학기술실(ESTO) 웹페이지는 TRL 6의 정의 문장에 "운용 환경"(operational environment)을 적고 같은 행의 설명문에는 유사 환경에서 시제품을 운용한다고 적어, DoD의 "유사 환경"과 문언이 다르고 한 페이지 안에서도 용어가 섞여 있다. 국제표준 ISO 16290:2013은 우주 시스템 분야의 TRL 정의와 평가 기준을 규정하며 주로 우주 시스템의 하드웨어에 적용되는 표준이다(표준 본문은 유료로 열람하지 못하고 표준 기관의 카탈로그 설명으로만 확인하였다). 따라서 TRL을 사용할 때는 어느 기관의 정의를 따르는지를 먼저 정한다. 단계별 판정 기준과 정량 평가는 29.1(9단계 체계는 29.1.2)이 본거지이다.

CTO의 관리 원칙(견해)

1. 구성요소 단위로 평가한다. 일반적으로 시스템의 준비도는 가장 미성숙한 핵심 기술 요소에 의해 제약되므로, 제품 전체에 하나의 TRL을 매기기 전에 핵심 기술 요소를 식별한다(29.1.7).
2. 환경을 먼저 정의한다. 유사 환경과 운용 환경이 제품에서 무엇을 뜻하는지를 사전에 문서로 정한다. 정의가 없으면 같은 시험이 TRL 5로도 7로도 평가된다.
3. 증거로 판정한다. TRL은 주장이 아니라 시험 조건, 결과, 재현 여부의 증거로 정한다. 평가 대상 팀의 자가 평가는 낙관 편향이 있으므로 중요 판정은 독립 검토를 거친다.
4. 의사결정과 연결한다. 로드맵 마일스톤(1.2.5)과 단계별 지속·중단 판단(36.3)의 기준으로 사용한다.
5. 대외 제시 시 기준을 밝힌다. 투자자, 고객, 정부 과제 평가에 TRL 수치를 제시할 때는 정의의 출처, 증거, 평가자를 함께 밝히고 CTO가 사실 확인서에 포함한다(1.1.2).

쟁점: 평가 주체

• ① 자가 평가: 비용이 낮고 빠르다. 낙관 편향이 있다.
• ② 내부 독립 검토: 과제 밖의 엔지니어가 증거를 검토한다. 객관성과 비용의 절충이다.
• ③ 외부 전문가·기관 평가: 객관성이 가장 높다. 비용과 시간이 들고 기술 정보가 외부에 노출된다.

견해: 로드맵 마일스톤의 판정과 대외 제시용 수치는 ② 이상으로 한다. 평가 방법론과 독립 평가위원회의 구성은 29.1.9, 29.1.39가 다룬다.

한계

TRL은 기술의 준비도만 측정한다. 제조 가능성(제조성숙도, 29.1.17), 구성요소 간 통합(29.1.16), 규제 승인과 시장 준비는 별도로 평가해야 한다. 선형적 발전을 가정하므로 이미 달성한 단계로 되돌아가는 경우(29.1.15)를 설명하지 못하며, 소프트웨어와 인공지능 시스템에는 그대로 적용하기 어렵다(29.1.14, 29.1.28). 한국 국가연구개발사업에서의 적용은 29.1.12가 다룬다.

1.2.10 하드웨어-소프트웨어 융합 개발 체계의 설계와 운영

융합 개발의 특성

하드웨어와 소프트웨어를 함께 개발하는 제품(로봇, 드론, 의료기기, 자율주행 시스템 등)은 두 영역의 변경 비용과 주기가 비대칭이다. 하드웨어는 설계가 고정된 뒤의 변경 비용이 크고 부품 조달과 시제품 제작에 시간이 걸리며 시제품 횟수가 제한된다. 소프트웨어는 반복과 배포가 빠르다. 이 비대칭 때문에 인터페이스가 위험이 집중되는 지점이 되고, 하드웨어 시제품이 없는 동안에는 소프트웨어 시험이 제한된다. 이 절은 CTO가 체계를 설계하는 관점을 서술하고, 애자일 V 모델의 세부 운용은 10.3이, 폭포수와 V 모델의 검증·확인 설계는 10.1·10.2이 다룬다.

쟁점: 개발 모델의 선택

• ① 단계 순차형(V 모델 중심): 요구-설계-구현-검증의 추적성이 분명하고 인증 증빙에 유리하다. 요구 변경에 대한 대응이 느리다.
• ② 애자일 전면 적용: 반복이 빠르고 피드백이 빠르다. 하드웨어의 제약을 무시하면 인터페이스 변경이 반복되어 하드웨어 재제작으로 이어진다.
• ③ 혼합형: 하드웨어는 설계 동결 같은 단계 게이트로 통제하고, 소프트웨어는 반복하며, 인터페이스는 조기에 확정한다(10.3).

견해: 기본값은 ③이다. 되돌리기 어려운 하드웨어 결정은 게이트로 통제하고 소프트웨어의 반복 이점은 유지하기 때문이다. 순수 소프트웨어 중심 제품이나 하드웨어를 외부에서 조달하는 제품은 ②에 가까워질 수 있다.

체계의 설계 요소

시스템 수명주기 프로세스를 규정한 국제 표준으로 ISO/IEC/IEEE 15288이 있다. 2023년 제2판이 발행되었으며 특정 수명주기 모델이나 방법론을 규정하지 않는다는 점을 표준 기관의 카탈로그 설명으로 확인하였다(본문은 열람하지 못하였다). 프로세스 어휘를 정하는 참고로 쓰고 개발 모델은 위 쟁점으로 선택한다. 대규모 시스템 엔지니어링은 41.1이 다룬다.

검증의 층위

검증은 비용이 낮은 층위부터 높은 층위로 쌓는다. 단위 수준(소프트웨어 단위 시험, 하드웨어 부품 시험), 소프트웨어를 시뮬레이션 환경에 연결한 통합 시험(SIL), 실제 제어 하드웨어를 연결한 시험(HIL), 목표 환경에서의 시스템 시험의 순서이다. 상위 층위일수록 설비 가용성과 시험 시간이 제한되므로, 하위 층위에서 제거할 수 있는 결함을 먼저 제거하고 상위 층위는 하위에서 시험할 수 없는 항목에 집중한다. 실환경 시험은 기상이나 현장 접근성 같은 외부 조건에 좌우되므로 일정에 예비 기간을 둔다. 펌웨어와 소프트웨어의 현장 갱신 경로(원격 갱신 포함)는 설계 초기에 정하고, 갱신이 안전과 인증 상태에 미치는 영향을 변경 통제에 포함한다.

조직의 설계

• ① 하드웨어팀·소프트웨어팀의 기능 분리: 전문성이 깊어지나 인터페이스 책임이 불분명해지고 통합이 지연된다.
• ② 제품 단위의 교차 기능 팀: 통합이 빨라지고 책임이 분명하다. 전문 인력이 분산되고 공통 기반이 중복된다.
• ③ 시스템 엔지니어링 기능이 인터페이스를 소유하는 매트릭스: 인터페이스에 책임자가 생긴다. 이중 보고로 우선순위 충돌이 생긴다.

판단 기준은 인터페이스 변경의 빈도, 인증 단위, 공유 플랫폼의 비중이다. 인터페이스 변경이 잦고 인증 단위가 제품이면 ②나 ③이 맞고, 공유 플랫폼의 비중이 크면 플랫폼 팀을 별도로 둔다(1.2.11).

운영 리듬과 함정

하드웨어 마일스톤(설계 동결, 시제품 제작, 양산 이관)과 소프트웨어 릴리스를 하나의 통합 일정에 올리고 정기 통합 검토를 둔다(10.3.7). 대표적 함정은 다음과 같다. 첫째, 소프트웨어가 하드웨어 지연을 흡수한다는 암묵적 가정이다. 일정이 마지막 통합 시점에 집중되어 지연이 증폭된다. 둘째, 인터페이스 정의의 지연으로 양측이 서로 다른 가정으로 개발하는 경우이다. 셋째, 하드웨어팀과 소프트웨어팀의 평가 지표가 달라 협력의 유인이 없는 경우이다. 넷째, 시험용 하드웨어가 부족하여 팀 간에 자원 경합이 생기는 경우이다. 다섯째, 펌웨어 업데이트 경로를 사후에 설계하는 경우이다. 여섯째, 양산 이관과 제조 고려 설계를 개발 후반에 처음 검토하는 경우이다(29.2, 29.3). CEO에게는 개별 일정이 지연되지 않아도 통합에서 지연이 증폭될 수 있음을 보고하여 출시 약속(1.2.2)에 반영하도록 한다.

1.2.11 기술 인력 확보 전략과 엔지니어링 조직 구조 설계

인력 확보 전략

기술 인력 전략은 필요한 역량을 정의하고 확보 경로를 선택하는 일이다. 먼저 직군을 정하고(연구, 응용 개발, 시스템, 하드웨어, 펌웨어, 품질, 운영) 직군별로 핵심 인력을 구분한다. 핵심 인력은 희소하고 대체가 어려우며 이탈 시 개발이 중단되는 인력이다. 확보 경로는 공개 채용, 추천, 산학 협력, 외부 영입, 해외 인재, 외주와 파트너가 있고, 경로마다 속도, 비용, 지식 귀속, 통제가 다르다. 채용 브랜딩은 5.2, 기술 면접은 6.1, 보상은 5.6, 근로계약과 취업규칙은 5.1가 다룬다. 핵심 인력의 채용·보상은 1.1.2에서 CEO가 최종 결정자이므로 CTO는 후보 평가, 대체 가능성, 이탈 영향 분석을 제출한다.

핵심 인력이 이탈하면 기술 지식과 영업비밀이 함께 이동할 수 있다. 「부정경쟁방지 및 영업비밀보호에 관한 법률」은 영업비밀을 공공연히 알려져 있지 아니하고 독립된 경제적 가치를 가지는 것으로서 비밀로 관리된 생산방법, 판매방법, 그 밖에 영업활동에 유용한 기술상 또는 경영상의 정보로 정의한다(제2조 제2호). 비밀로 관리되었는지가 정의의 요건이므로 접근 통제와 비밀 유지 약정 같은 관리 조치가 법적 보호의 전제가 된다(14.3.17, 14.3.20). 어느 수준의 관리가 요건을 충족하는지는 판례에 따르며 확인하지 못하였다(확인 필요). 직무발명의 귀속과 보상 규정은 1.2.18과 13.2이 다룬다.

확보 방식의 선택

• ① 직접 채용: 지식과 통제가 내부에 남는다. 채용 기간이 길고 희소 인력은 보상 경쟁이 심하다.
• ② 외주·계약 인력: 단기간에 용량을 확보하고 고정비가 낮다. 지식이 외부에 남고 핵심 영역에서는 기밀과 종속의 문제가 있다.
• ③ 파트너·인수를 통한 영입: 팀 단위로 역량을 확보한다. 통합 비용과 핵심 인력 이탈의 위험이 있다(26.4).

기술 전략의 입장(1.2.4)에 맞추어 핵심 영역은 ①, 보완 영역은 ①과 파트너의 조합, 범용 영역은 ②를 기본으로 한다. 외주 인력이 접근하는 소스코드와 기술 자료의 범위는 접근 통제 정책으로 정한다(14.3.12). 핵심 인력을 유지하는 수단은 보상(5.6), 과제에서의 주도권, 성장 경로, 이탈 시 인계 계획이다. 보상 외의 요인도 유지에 영향을 주므로 보상 조건만으로 대응하지 않고 후임 계획(1.2.25)을 병행한다.

조직 구조의 선택

조직 구조는 아키텍처에 영향을 미친다. 콘웨이(1968)의 주장을 점검 관점으로 쓰면(1.2.8), 원하는 아키텍처가 있을 때 팀 경계와 소통 구조를 그에 맞게 설계하는 것이 합리적이다.

• ① 기능 조직(하드웨어·소프트웨어·품질 등 직능별): 전문성과 표준화에 유리하다. 제품 단위의 책임이 분산되고 협업 비용이 크다.
• ② 제품·미션 단위 교차 기능 조직: 제품 책임이 분명하고 의사결정이 빠르다. 공통 기반의 중복과 직능 전문성의 약화가 생긴다.
• ③ 매트릭스: 전문성과 제품 책임을 모두 확보한다. 이중 보고로 우선순위 충돌이 생긴다.
• ④ 플랫폼과 제품 팀의 병행: 공통 기반을 플랫폼 팀이 제공하고 제품 팀이 이를 사용한다. 플랫폼 팀이 고객 요구와 분리될 위험이 있다.

스켈턴과 페이스(Skelton, Pais, 2019)는 팀 유형을 가치 흐름에 정렬된 팀, 플랫폼 팀, 지원(enabling) 팀, 복잡한 하위 시스템 팀의 네 가지로, 팀 간 상호작용을 협업, 서비스로서 제공(X-as-a-Service), 촉진의 세 방식으로 구분하였다(저자의 공식 사이트와 2차 요약으로 확인하였다, 문헌에 따르면). 이 구분은 ④를 설계할 때 참고할 수 있으나 하드웨어 제품에 그대로 적용된 근거는 확인하지 못하였다.

판단 기준은 제품의 수와 독립성, 하드웨어와 플랫폼의 공유 정도, 인증과 규제의 단위, 인터페이스 변경 빈도이다. 견해: 제품이 하나이거나 소수일 때는 ②로 시작하고, 제품이 늘어 공통 기반의 중복이 문제가 되면 ④로 이행한다. 이행 시점의 정량 기준은 확인하지 못하였다.

규모에 따른 변화와 경력 경로

조직이 커지면 의사소통 경로가 늘어나 조정 비용이 증가한다. 브룩스(Frederick Brooks, 1975)는 지연된 소프트웨어 프로젝트에 인력을 추가하면 오히려 더 늦어질 수 있다고 지적하였다. 따라서 인력 증원은 과제의 분할 가능성과 신규 인력의 숙련 시간을 함께 따져야 한다. 관리자 한 명이 맡을 수 있는 인원 수에 관한 일반적 수치는 확인하지 못하였다.

기술 인력의 경력 경로를 관리직과 전문직(수석 엔지니어, 아키텍트 등)으로 이원화하면 우수한 엔지니어를 관리직으로 이동시켜야만 보상하는 구조를 피할 수 있다. 이원화의 유효성에 관한 근거는 확인하지 못하였으므로 회사 사정에 맞게 도입한다. 조직 구조 변경이 성과 평가와 보상(5.4, 5.6)에 미치는 영향을 함께 점검한다.

함정

첫째, 소수 핵심 인력의 이탈 대비 없이 채용을 확대하는 경우이다. 둘째, 조직 구조를 아키텍처와 별도로 변경하여 팀 경계와 모듈 경계가 어긋나는 경우이다. 셋째, 직군 간 이해 충돌을 구조의 문제가 아니라 개인 갈등으로 처리하는 경우이다(4.5). 넷째, 채용 기준이 기술 역량에 치우쳐 협업 역량이 평가되지 않는 경우이다. 협업 구조는 4.2, 4.4이 다룬다.

1.2.12 기술 조직의 수평적 의사소통과 전사적 지식 공유 체계

이 절은 CTO가 기술 조직의 소통과 지식 공유 체계를 설계하는 관점을 개관하며, 지식 베이스 구축과 지식 공유의 제도적 유인 설계는 6.6이, 지식 사일로의 원인 분석은 6.5가 본거지이다.

수평적 의사소통의 의미

수평적 의사소통은 직급과 무관하게 정보가 흐르는 구조이다. 이는 결정 권한의 위임과 정보 접근이 함께 있어야 성립한다. 정보 접근만 열고 결정 권한이 상위에 집중되어 있으면 의견은 오가지만 결정은 지연된다. CTO는 결정 권한의 범위(1.2.2, 1.2.8)를 명확히 한 뒤에 정보 흐름을 설계한다. 에드먼슨(Edmondson, 1999)은 팀에서 구성원이 대인 관계 위험을 감수해도 안전하다는 믿음(심리적 안전)이 학습 행동과 관련됨을 제조 기업의 팀에서 보였다. 이는 공개적 이견 제기와 실패 공유가 가능한 조건을 점검하는 근거로 쓸 수 있다(1.1.13).

지식 공유의 장치

노나카와 다케우치(Nonaka, Takeuchi, 1995)는 암묵지를 형식지로 전환하는 과정이 지식 창출의 핵심이라고 보았다. 암묵지는 문서만으로 이전되지 않으므로 문서 중심 장치와 대화 중심 장치를 함께 둔다. 문서는 보존과 규모에 유리하고 대화는 암묵지 이전에 유리하나 시간 비용이 든다.

정례 소통 구조의 예시(가정 예시)

회의가 늘면 구성원의 용량이 줄어들므로 목적과 산출물이 없는 회의는 폐지한다. 원격·분산 근무 환경에서는 대화로 전달되던 정보가 사라지므로 결정과 사유를 문서로 남기는 비중을 높인다. 근무 방식의 제도는 5.5이 다룬다.

CTO의 점검

지식이 특정인에게 집중되었는지를 핵심 시스템별 담당자 수로 점검한다. 담당자가 한 명인 시스템은 이탈 위험이 높다(1.2.2). 기술 문서에는 영업비밀이 포함되므로 공유 범위와 접근 통제는 14.3가 정한 정책에 따른다. 수평적 문화를 표방하면서 결정 책임을 불명확하게 두면 책임 소재가 사라지므로, 공유와 결정을 분리하여 설계한다.

1.2.13 프로덕트 오너(PO), 기획자, 스크럼 마스터와의 협업 인터페이스

이 절은 CTO가 제품 조직과 맺는 인터페이스를 서술하며, 프로덕트 오너(Product Owner, PO)와 서비스 기획자의 직무 상세는 4.1가, 스크럼 마스터의 권한은 4.3이 본거지이다.

책임의 구분

스크럼 가이드(Schwaber, Sutherland, 2020판)는 제품 가치의 극대화와 제품 백로그의 관리를 PO의 책임으로, 스크럼의 확립과 스크럼 팀의 효과성을 스크럼 마스터의 책임으로, 사용 가능한 증분(Increment)의 생성을 개발자의 책임으로 구분한다(원문은 열람하지 못하고 해설 자료로 확인하였다, 문헌에 따르면). 서비스 기획자는 스크럼이 정의한 직무가 아니며 회사별로 PO와 겹치거나 분리된다. CTO는 이 구분 위에서 기술 판단이 제품 우선순위 결정에 반영되는 경로를 설계한다. 스크럼은 소프트웨어 중심의 틀이므로 하드웨어를 포함하는 제품에는 10.3의 조정이 필요하다.

인터페이스의 다섯 지점

쟁점: 기술 요구사항의 반영 방식

• ① 백로그 항목화: 기술 항목을 제품 백로그에 올려 PO의 우선순위에 경쟁시킨다. 우선순위가 통합 관리되나 기능 요구에 밀려 지연된다.
• ② 용량의 고정 할당: 스프린트 용량 중 일정 비율을 기술 작업에 예약한다. 지연을 막으나 비율이 경직되어 상황 변화에 대응하기 어렵다.
• ③ 기술 책임자의 별도 백로그: 기술 책임자가 자체 우선순위로 운영한다. 기술 판단이 보호되나 제품 일정과 분리되어 갈등이 생긴다.

견해: 기본값은 ②에 ①을 병행하는 것이다. 예약된 용량 안에서는 CTO가 우선순위를 정하고, 예약을 초과하는 요청은 PO와 협의한다. 비율의 근거를 제시하는 문헌은 확인하지 못하였으므로 사고 이력과 변경 빈도로 정한다.

하드웨어를 포함하는 제품의 조정

PO는 하드웨어 요구와 소프트웨어 요구의 우선순위를 함께 조정해야 한다(10.3.13). 하드웨어 설계 동결, 부품 리드타임, 인증 일정은 스프린트 주기와 맞지 않으므로 제품 로드맵과 기술 로드맵(1.2.5)을 같은 일정 위에 놓고 동기화한다.

함정

PO가 기술 해법까지 지정하여 개발 조직의 판단 영역을 침범하는 경우, 반대로 CTO가 기술 선호로 제품 우선순위를 바꾸는 경우, 스크럼 마스터가 CTO의 관리 보고 수단으로 변질되어 팀의 자율이 약해지는 경우, 기획자의 요구에 인수 기준이 없어 완료 여부가 논쟁이 되는 경우가 있다. 직군 간 협업의 구조적 갈등은 4.5이 다룬다.

1.2.14 오픈 소스 전략과 외부 기술 생태계 활용

전략 유형

오픈 소스 소프트웨어는 소스코드가 라이선스 조건에 따라 공개되어 사용·수정·배포가 허용되는 소프트웨어이다. 라이선스에 따라 파생물의 소스 공개 의무 범위가 다르므로 라이선스 분류와 컴플라이언스는 23.5이 본거지이다. CTO는 오픈 소스를 사용, 기여, 공개의 세 방향으로 나누어 전략을 정한다.

• ① 사용 중심: 외부 프로젝트를 정책 범위 안에서 사용하고 기여는 최소화한다. 비용이 낮으나 의존하는 프로젝트의 방향과 취약점 대응을 통제하지 못한다.
• ② 사용과 기여의 병행: 자사가 의존하는 프로젝트에 기여하여 유지 부담을 분담하고 영향력과 채용 효과를 얻는다. 엔지니어의 시간이 들고 자사 코드 노출의 관리가 필요하다.
• ③ 자사 기술의 공개: 자사 프로젝트를 공개하여 커뮤니티와 표준화 효과, 인재 유치를 얻는다. 핵심 차별 요소가 노출되고 유지 비용이 발생하며 수익 모델이 필요하다.

판단 기준

외부 기술 생태계의 활용

외부 생태계는 클라우드와 플랫폼, 하드웨어 참조 설계, 개발자 커뮤니티, 표준 구현체를 포함한다. 활용은 속도와 비용 이점을 주지만 의존이 생긴다. CTO는 핵심 의존 대상의 목록과 대체 가능성을 관리한다. 생태계에서 자사의 위치(공급자, 보완자, 소비자)를 정하는 일은 전략의 일부이다(1.1.3).

정책의 구성

오픈 소스 정책은 사용 승인 절차와 라이선스 분류, 기여 정책, 취약점 대응(의존성 목록의 유지), 공개 승인으로 구성한다. 자사 소스코드의 오픈 소스 공개는 비가역성과 지식재산 영향이 커서 CEO가 최종 결정자이고 CTO는 평가를 제출한다(1.2.2). 이 기능을 맡는 조직을 오픈 소스 프로그램 오피스(OSPO)라 부르는 기업이 있으며, 소규모 회사에서는 CTO나 법무 담당이 겸임한다. 오픈 소스 하드웨어와 데이터 개방은 43.4이 다룬다.

함정

라이선스를 확인하지 않고 제품에 포함하는 경우, 공개한 프로젝트를 유지하지 않아 평판과 보안 문제를 일으키는 경우, 핵심 의존 프로젝트의 지속 가능성을 점검하지 않는 경우, 공개 시점이 특허 출원보다 앞서는 경우가 대표적이다. 도구와 프로젝트의 우열은 시점에 따라 달라지므로 특정 프로젝트의 우열은 이 절에서 단정하지 않는다.

1.2.15 기술 표준화 참여와 산업 컨소시엄 전략

이 절은 CTO가 표준화 참여 여부와 수준을 판단하는 기준을 서술하며, 표준화 기구의 구조, 의장직 확보, 기고서 작성 같은 참여 전략의 상세는 22.1가 본거지이다.

참여의 목적

표준화 활동은 네 가지 목적으로 구분한다. 첫째, 시장 형성과 상호운용성의 확보이다. 자사 제품이 다른 제품과 연결되어야 가치가 생기는 경우에 해당한다. 둘째, 규제와 인증 요구의 선제 파악이다. 안전·보안 규격이 인증의 기준이 되는 산업에서는 규격의 개정 방향이 제품 설계에 영향을 준다. 셋째, 기술 포지셔닝과 특허 전략이다(22.1.12, 34.3). 넷째, 인재와 네트워크의 확보이다. 목적을 정하지 않은 참여는 인력의 시간만 소모한다.

참여 수준의 선택

• ① 동향 추적: 문서와 회의록을 모니터링한다. 비용이 가장 낮으나 표준의 방향에 영향을 줄 수 없다.
• ② 회원 참여와 기고: 회의에 참여하고 기고서를 제출한다. 의제 형성에 영향을 주나 전문 인력의 시간이 지속적으로 든다.
• ③ 주도: 의장직이나 에디터십을 맡는다(22.1.14). 영향력이 가장 크나 비용과 책임, 중립성 유지의 부담이 크다.

판단 기준은 표준이 시장 진입 조건인지(인증이 표준을 인용하는지), 자사 기술이 상호운용성에 의존하는지, 경쟁하는 표준이 존재하는지, 투입할 수 있는 전문 인력이 있는지이다. 견해: 표준이 시장 진입 조건이면 최소한 ②를 택하고, 그렇지 않은 영역은 ①을 기본으로 하되 자사 특허의 표준 포함 가능성이 있을 때 ②로 올린다. 표준의 구조와 공적·사실상 표준의 비교는 22.1.2가 다룬다.

참여 시작 전 점검표

참여를 시작하기 전에 다음을 정한다. 참여 목적과 성공 기준, 담당 인력과 연간 투입 시간, 회의에서 공개할 수 있는 정보의 범위, 기구의 지식재산 정책(특허를 기고할 때의 실시 허락 의무의 범위), 참여 효과를 검토하는 주기와 종료 기준이다. 담당 인력의 표준화 활동이 직무와 평가에 명시되지 않으면 개발 일정에 우선순위를 빼앗겨 활동이 중단되기 쉽다. 기구의 지식재산 정책은 가입 전에 확인하고 법무와 함께 검토한다(22.1.13).

위험

표준에 자사 특허를 기고하면 표준필수특허(SEP)에 대한 공정·합리적·비차별적(FRAND) 조건의 실시 허락 약속이 따를 수 있으며, 이는 라이선싱 전략을 제약한다(22.1.11, 34.4). 회의에서 논의하는 기술 정보는 영업비밀 보호의 전제인 비밀 관리와 충돌할 수 있으므로 공개 범위를 사전에 점검한다. 경쟁사가 함께 참여하는 협의는 공정거래 쟁점이 될 수 있으나 구체적 기준은 확인하지 못하였다(확인 필요). 표준의 채택 시기가 지연되거나 방향이 자사 기술과 어긋날 위험은 대안 기술의 병행으로 대응한다.

한국의 표준화 지원 체계(한국 국가기술표준원, 한국정보통신기술협회)는 22.1.10이 다룬다.

1.2.16 신기술 탐색(Technology Scouting)과 기술 사업화 판단 기준

이 절은 CTO의 판단 기준과 탐색 체계까지를 서술한다. 탐색 방법론과 플랫폼은 33.3.6~33.3.8이, 라이선스 인과 기술 이전 전략은 33.3이, 기술 예측 기법은 36.1이 본거지이다.

탐색의 정의와 범위 설정

신기술 탐색(Technology Scouting)은 자사 전략과 관련된 외부 기술과 기술 보유자를 체계적으로 발굴하고 평가하는 활동이다. 탐색은 무제한으로 하지 않고 로드맵에서 도출한 질문에 한정한다. 질문의 원천은 기술 역량 지도의 격차(1.2.9), 위협이 되는 대체 기술, 새로운 기회이다.

탐색 파이프라인

탐색은 발굴, 1차 선별, 상세 평가, 시범 적용(개념 검증), 결정의 순서로 진행한다. 단계마다 투입 자원의 상한을 두어 많은 후보를 낮은 비용으로 선별한다. 탐색 과제는 포트폴리오의 탐색 범주(1.2.6)에서 용량을 배정하고 총량 상한을 둔다.

사업화 판단 기준

기술이 우수하다는 사실은 사업화 가능성을 보장하지 않으므로, 앞의 세 기준(전략 적합성, 기술 준비도, 사업화 경로)이 충족되지 않은 후보는 기술 우수성만으로 채택하지 않는다.

쟁점: 탐색 조직

• ① 상시 전담: 기술 스카우트를 지정하여 지속적으로 탐색한다. 축적과 네트워크가 쌓이나 상시 인건비가 든다.
• ② 프로젝트별 비정기: 필요할 때만 탐색한다. 비용이 낮으나 대응이 늦고 학습이 축적되지 않는다.
• ③ 외부 네트워크 의존: 대학, 벤처캐피털, 액셀러레이터, 컨설팅의 정보를 활용한다. 폭이 넓으나 정보의 선별 기준이 외부에 있다.

견해: 초기에는 ②와 ③을 조합하고, 로드맵의 격차가 반복적으로 외부 기술로 해소되면 ①로 전환한다. 전환 기준의 정량 수치는 확인하지 못하였다.

함정

새로운 기술을 추종하는 경향, 외부 기술을 배척하는 내부 개발 선호(Not-Invented-Here), 이미 선호하는 기술에 유리한 정보만 모으는 확증 편향, 탐색 결과가 결정으로 이어지지 않는 경우가 있다. 탐색 중 상대방의 기술 정보를 받을 때는 비밀유지 계약을 먼저 체결한다.

1.2.17 기술 파트너십 및 공동 연구개발 협력 체계

이 절은 CTO의 판단 기준과 협력 체계까지를 서술하며, 산학연 공동연구개발계약의 체결 실무는 33.2가 본거지이다.

협력 유형

위 표는 일반화한 정리이며 계약으로 달리 정할 수 있다.

유형 선택의 기준

기술 전략의 입장(1.2.4)이 핵심이면 통제를 유지하는 형태(위탁 연구나 지식재산을 자사에 귀속시키는 공동 연구)를, 보완이면 제휴를, 범용이면 도입을 택한다. 지식재산 민감도가 높을수록 통제와 귀속 확보를, 속도가 중요할수록 제휴를 택한다. 상대 유형은 다음과 같이 나뉜다.

• ① 대학·정부출연연구기관: 기초 역량이 깊고 비용이 낮다. 연구자의 논문 발표 일정이 특허 출원 시점과 충돌할 수 있고(1.2.18), 사업화 일정과 연구 일정이 어긋난다.
• ② 대기업·전략적 투자자: 사업화 자원과 고객에 접근한다. 협상력의 비대칭이 있고 핵심 기술이 노출될 위험이 있다.
• ③ 스타트업·중소기업: 속도와 유연성이 높다. 상대의 존속 위험과 역량의 불확실성이 있다.

협력 체계의 설계

협력 체계는 협력 시작 전에 다음을 문서로 정한다. 목적과 성과물의 정의, 마일스톤과 인수 기준, 지급 조건과의 연동, 운영 위원회와 상호 접점(양측 기술 책임자), 정보 공유 범위(필요한 사람에게 필요한 만큼), 배경 지식재산 목록의 확정, 전경 지식재산의 귀속과 출원 절차·비용 분담(33.2.12, 33.2.15, 33.2.16), 개량 발명의 귀속(33.2.18), 종료·이탈 조건과 기술 이전, 분쟁 해결이다. 정부 연구개발 과제를 협력 기관과 수행하는 경우 연구개발성과는 해당 과제를 수행한 연구개발기관이 연구자로부터 권리를 승계하여 소유하는 것을 원칙으로 하되 성과의 유형과 참여 비중에 따라 연구자 소유나 공동 소유가 가능하고(「국가연구개발혁신법」 제16조 제1항, 제2항), 중앙행정기관의 장이 공모 시 미리 공지한 경우에는 국가 소유로 할 수 있는 사유가 있다(같은 조 제3항). 성과의 실시를 허락할 때는 기술료를 징수하며, 대통령령으로 정하는 연구개발성과소유기관은 정부납부기술료를 납부해야 한다(제18조 제1항, 제2항). 이 규정은 협력 계약보다 먼저 확인하며, 적용 대상 기관과 감면의 세부 요건은 확인하지 못하였다(8.1, 확인 필요).

위험과 CTO의 책임

핵심 기술을 단일 파트너에게 의존하면 상대가 거래 조건을 일방적으로 바꾸는 홀드업(Hold-up) 위험이 생긴다. 공동 연구의 산출물에서 귀속이 불명확하면 사업화 단계에서 분쟁이 된다. CTO는 기술 평가, 협력 책임자의 지정, 산출물의 인수 기준, 협력 종료 시의 지식 이전 계획을 책임진다. 외부 기술 도입·제휴·라이선스의 최종 결정자는 CEO이며(1.2.2), 이사회 협의가 필요한 중요 계약은 1.1.2의 표에 따른다.

1.2.18 지식재산권(IP) 확보와 기술 라이선싱 전략 수립

이 절은 CTO의 전략 수립까지를 서술한다. 특허 등 확보 실무는 13.1가, 직무발명 규정 설계는 13.2이, 라이선싱 계약 실무는 13.3이 본거지이다. 인용한 법령은 도입부에 밝힌 판의 조문이며 개정될 수 있다.

보호 수단: 특허와 영업비밀

특허는 기술을 공개하는 대가로 일정 기간 독점권을 얻는 수단이다. 존속기간은 설정등록한 날부터 특허출원일 후 20년이 되는 날까지이다(「특허법」 제88조 제1항). 특허를 받으려면 산업상 이용할 수 있는 발명으로서 출원 전에 국내외에서 공지되었거나 공연히 실시된 발명, 간행물에 게재되었거나 전기통신회선을 통하여 공중이 이용할 수 있는 발명이 아니어야 하고(제29조 제1항), 그 발명이 속하는 기술분야에서 통상의 지식을 가진 사람이 쉽게 발명할 수 없어야 한다(제29조 제2항). 영업비밀은 공공연히 알려져 있지 아니하고 독립된 경제적 가치를 가지는 것으로서 비밀로 관리된 생산방법, 판매방법, 그 밖에 영업활동에 유용한 기술상 또는 경영상의 정보이다(「부정경쟁방지 및 영업비밀보호에 관한 법률」 제2조 제2호). 영업비밀은 존속기간이 법으로 정해져 있지 않으나 공개되면 요건을 잃는다.

쟁점: 보호 수단의 선택

• ① 특허 중심: 독점권이 명확하고 라이선싱과 투자 유치에 유리하다. 기술이 공개되고 출원·유지 비용이 들며 해외는 국가별로 출원해야 한다.
• ② 영업비밀 중심: 공개가 없고 기간 제한이 없다. 제품 분석으로 알 수 있는 기술은 보호되기 어렵고 유출 시 회복이 어렵다.
• ③ 병행: 제품에서 외부로 드러나는 구조와 방법은 특허로, 제품에서 알 수 없는 제조 조건, 학습 데이터, 조정 파라미터는 영업비밀로 분리한다.

견해: 기본값은 ③이다. 판단 기준은 제품 분석으로 알아낼 수 있는지, 기술의 수명이 20년보다 짧은지, 침해를 입증할 수 있는지, 공개를 수용할 수 있는지이다. 특허 명세서에 영업비밀이 노출되지 않도록 출원 전에 검토한다.

공개 전 통제

학회 발표, 논문, 고객 시연, 오픈 소스 공개(1.2.14), 투자 자료 배포는 출원 전 공지가 될 수 있다. 특허를 받을 수 있는 권리를 가진 자에 의하여 공지된 경우 그 날부터 12개월 이내에 출원하면 신규성과 진보성 판단에서 공지되지 않은 것으로 보는 규정이 있으며, 이를 적용받으려면 출원서에 그 취지를 적고 증명서류를 출원일부터 30일 이내에 제출해야 한다(제30조 제1항 제1호, 제2항, 보완 절차는 같은 조 제3항). 조약이나 법률에 따라 출원공개되거나 등록공고된 경우는 이 예외에서 제외된다. 해외 출원 계획이 있으면 국가별 예외 규정이 다를 수 있으므로 공개 전 출원을 기본으로 한다(국가별 규정은 확인하지 못하였다, 확인 필요). CTO는 외부 공개 전 검토 절차(1.2.23)를 운영한다.

직무발명 체계

직무발명은 종업원, 법인의 임원 또는 공무원이 그 직무에 관하여 발명한 것이 성질상 사용자의 업무 범위에 속하고 그 발명을 하게 된 행위가 종업원의 현재 또는 과거의 직무에 속하는 발명이다(「발명진흥법」 제2조 제2호). 발명을 한 사람 또는 승계인이 특허를 받을 수 있는 권리를 가지며 공동 발명은 권리를 공유한다(「특허법」 제33조). 사용자는 직무발명에 대한 특허권에 통상실시권을 가지되, 중소기업이 아닌 기업이 종업원과의 협의를 거쳐 미리 승계 계약·근무규정 또는 전용실시권 설정 계약·근무규정을 체결하거나 작성하지 않은 경우에는 그러하지 아니하다(「발명진흥법」 제10조 제1항). 제12조에 따라 통지를 받은 사용자가 미리 승계시키는 계약이나 근무규정을 정해 두었다면 권리는 발명을 완성한 때부터 사용자에게 승계되고, 사용자가 대통령령이 정한 기간 내에 승계하지 않겠다고 종업원에게 통지하면 그러하지 아니하다(제13조 제1항). 종업원은 권리를 승계시킨 경우 정당한 보상을 받을 권리가 있고, 사용자는 보상형태·보상액의 결정 기준과 지급방법을 명시한 보상규정을 작성하여 종업원에게 서면으로 알려야 한다(제15조 제1항, 제2항). 규정의 작성·변경 절차(종업원과의 협의, 불리한 변경 시 과반수 동의, 제15조 제3항)와 보상의 산정은 13.2이 다룬다. CTO는 사전 승계 규정과 보상규정이 갖추어졌는지, 발명 신고 절차가 있는지, 발명자 기록(8.4)이 남는지를 점검한다. 공동 연구에서의 귀속은 1.2.17에서 사전에 합의한다.

라이선싱 전략

라이선스 아웃은 자사 기술의 사용을 허락하여 수익과 확산을 얻는 수단이고, 라이선스 인은 외부 기술을 도입하는 수단이다(33.3).

• ① 독점 실시: 대가가 높고 상대의 투자를 유도한다. 자사의 사업 범위가 제한되고 상대가 실시하지 않을 위험이 있어 실시 의무와 회수 조건을 둔다.
• ② 비독점 실시: 확산이 빠르고 자사가 직접 사업을 유지한다. 대가가 낮고 통제가 약하다.
• ③ 분야·지역 분할: 자사가 하지 않는 분야나 지역만 허락한다. 협상과 관리가 복잡하다.

판단 기준은 자사 사업과의 경쟁 여부, 상대의 실시 능력, 개량 발명의 귀속 조건, 의존 발생 여부이다. 특허 풀과 표준필수특허는 34.3·34.4이, 방어적 포트폴리오는 13.5가, 특허관리전문회사 대응은 13.4이, 기술 가치 평가는 34.1이 다룬다.

CTO의 점검 체계

기술 영역별 권리 현황 지도, 출원 여부를 정하는 발명 평가 회의, 자유실시 검토, 출원·유지 예산, 퇴사자의 비밀 유지와 권리 승계 확인을 운영한다. 이 절은 법률 자문을 대체하지 않으며 전략의 틀을 제시한다.

1.2.19 기술 위험 관리와 연구개발 실패 대응 체계

위험의 범주

이 책은 위험을 목표 달성에 영향을 주는 불확실성으로 다룬다(작업 정의). 딥테크 기업의 기술 위험은 다음 범주로 나누면 담당과 완화 수단을 정하기 쉽다.

관리 프로세스

위험관리의 국제 지침으로 ISO 31000:2018이 있다. 원칙, 프레임워크, 프로세스의 세 부분으로 구성되고 프로세스는 소통과 협의, 범위·상황·기준의 설정, 위험 평가, 위험 처리, 모니터링과 검토로 이어지며, 인증 가능한 요건이 아닌 지침이라는 점을 해설 자료로 확인하였다(표준 본문은 열람하지 못하였다, 문헌에 따르면). 이 절은 이 틀을 기술 위험에 맞게 정리한다.

위험 등록부는 위험 항목, 범주, 가능성과 영향의 정성 평가, 선행 지표, 완화 수단, 대안(Plan B), 소유자, 재검토 일자, 상태로 구성한다. 소유자는 한 명으로 지정한다. 등록부는 정기 검토에 쓰이지 않으면 형식화되므로 로드맵 갱신(1.2.5)과 같은 회의에서 검토한다. 이사회와 투자자에 대한 보고에서 CEO가 최종 책임을 지고 CTO가 수행 책임을 진다(1.1.2). 전사 위험관리 체계는 39.3이 다룬다.

기술 위험의 해소 전략

• 위험 우선 해소: 가장 불확실한 요소를 먼저 시험한다. 쉬운 부분을 먼저 끝내면 진척은 보이나 실현 가능성이 늦게 드러난다.
• 개념 검증과 시범 구현: 핵심 가정을 작은 비용으로 시험한다.
• 설계 여유: 성능 목표에 여유를 두어 일부 요소의 미달을 흡수한다.
• 대안 경로의 운용: ① 순차 시도는 비용이 낮으나 일정이 길어진다. ② 병행 개발은 일정이 짧으나 비용이 대안의 수만큼 늘어난다. ③ 선택적 병행은 가장 불확실한 요소에 한정하여 대안을 병행하되 중단 시점을 정한다. 견해: 실패의 비용보다 일정 지연의 비용이 크고 대안이 독립적일 때만 병행하며, 기본값은 ③이다.

연구개발 실패의 구분과 대응

실패는 원인에 따라 대응이 달라진다. 첫째, 가설의 반증이다. 사전에 가설과 판정 기준이 있었고 시험으로 반증된 경우로, 학습의 성과이며 중단 또는 재설계의 근거가 된다. 둘째, 관리의 실패이다. 일정과 자원 통제의 실패, 기록 부재, 책임 불명으로 발생하며 예방할 수 있다. 셋째, 통제 밖의 요인이다. 공급 중단, 규제 변경, 시장 변화로 발생한다. 분류는 사후 검토에서 하되 분류의 근거를 기록한다. 가설 반증과 관리 실패를 구분하지 않으면 실패를 감추는 문화나, 반대로 모든 실패를 용인하는 문화로 쏠린다.

대응 체계의 구성은 다음과 같다. 착수 시 합의한 중단 기준(36.3.10, 36.3.11)과 조기 경보 지표를 두고, 실패 선언은 CTO가 근거와 함께 제안하며 연구개발 프로젝트 중단의 최종 결정자는 CEO이다(1.1.2). 중단 후에는 사후 검토를 통해 원인, 교훈, 회수 가능한 자산(코드, 데이터, 특허, 장비, 인력의 재배치)을 정리하고, 기록을 연구노트와 데이터 관리 체계에 남긴다(8.4). 이사회에는 기술 위험과 실패를 보고하되 CEO가 A, CTO가 R이다. 보고가 늦어지는 가장 흔한 원인은 낙관 편향과 보고자에 대한 부정적 평가이므로, 사전에 정한 트리거에 도달하면 보고하는 규칙과 부정적 보고를 보호하는 문화(1.1.13)가 필요하다.

정부 연구개발 과제에서의 실패

「국가연구개발혁신법」은 연구개발과제의 전체 연구개발기간을 10년을 초과할 수 없게 하고 여러 단계로 구분하여 수행할 수 있게 한다(제12조 제1항). 중앙행정기관의 장은 단계평가 결과에 따라 과제를 보완·변경·중단하거나 연구개발비를 감액·증액할 수 있다(제12조 제3항). 참여제한 또는 제재부가금의 사유에는 평가 결과 수행과정과 결과가 극히 불량한 경우, 의무를 고의로 이행하지 아니하여 과제가 변경 또는 중단된 경우, 부정행위, 정당한 사유 없이 수행을 포기한 경우 등이 있고(제32조 제1항 제1호~제4호), 제재 시에는 제재사유의 중대성, 고의 유무, 위반 횟수, 연구개발과제의 수행 단계와 진행 정도 등을 고려한다(제32조 제4항). 연구개발자료나 성과의 위조·변조, 거짓이나 그 밖의 부정한 방법으로 과제를 수행하는 행위는 부정행위로 금지된다(제31조 제1항 제1호, 제7호). 목표 미달이 어느 경우에 "극히 불량"에 해당하는지와 시행령·평가 지침의 세부 기준은 확인하지 못하였다(확인 필요). 실무상 정직한 실패 보고와 성과의 과장은 법적 결과가 전혀 다르므로 평가 보고서의 사실 확인을 CTO가 책임진다. 단계평가와 최종평가 대응은 8.5가, 사업의 이해는 8.1이 다룬다.

함정

위험 등록부가 갱신되지 않고 형식화되는 경우, 실패를 선언하지 못하고 매몰 비용 때문에 중단이 지연되는 경우(36.3.22), 위험을 보고하는 사람이 불이익을 받는 문화, 한 사람에게 위험 소유가 집중되는 경우, 정부 과제의 일정과 평가에 맞추기 위해 성과를 과장하는 경우가 대표적이다.

1.2.20 프로그래밍 언어 선정과 기술 스택 의사결정 프레임워크

이 절은 선정 프레임워크의 개관까지를 서술한다. 가비지 컬렉션(GC) 기반 언어는 11.2가, C/C++는 11.3이, Rust는 11.4가, 핵심 코어 언어의 전환 트리거와 조직 마이그레이션은 11.5가 본거지이다. 도구와 언어의 평가는 시점과 사용 맥락에 따라 달라지므로 이 절은 특정 언어나 제품의 우열을 단정하지 않는다.

의사결정의 귀속

기술 스택 선정은 기술 전문성이 결정의 질을 좌우하고 대외 구속력이 낮은 영역이어서 CTO가 최종 결정하고 CEO에게는 통보한다(1.1.2). 다만 선정이 인증 일정, 고객과의 계약, 장기 유지 비용에 영향을 주면 비가역성과 대외 구속력이 높아지므로 CEO와 협의한다(1.2.2). 결정은 결정 기록으로 남긴다(1.2.8).

평가 기준

절차

1. 요구 제약을 정리하고 통과·탈락의 필수 요건을 정한다.
2. 필수 요건으로 후보를 줄인 뒤, 남은 후보를 가중 평가한다. 필수 요건과 가중 평가를 분리하는 것은 한 기준의 낮은 점수를 다른 기준의 높은 점수로 상쇄하는 오류를 막기 위해서이다.
3. 핵심 위험 요소를 개념 검증으로 측정한다. 성능과 지연은 동일한 조건에서 직접 측정하고 공개 자료의 비교를 그대로 쓰지 않는다.
4. 결정과 근거, 기각한 대안을 기록하고 재검토 조건을 정한다.

쟁점: 표준화의 정도

• ① 소수 언어로 표준화: 인력 이동과 도구 공유가 쉽다. 영역별로 최적이 아닌 선택을 강요한다.
• ② 팀 자율: 팀의 판단을 존중한다. 언어가 늘어나 유지 보수와 채용이 어려워진다.
• ③ 계층별 표준: 실시간 코어와 안전 관련 계층은 제한하고 응용 계층은 허용한다.

견해: 기본값은 ③이다. 요구가 엄격한 계층은 선택지를 줄여 검증 비용을 낮추고, 변화가 빠른 계층은 자율을 허용하기 때문이다.

함정

유행에 따른 선정, 개인 선호의 일반화, 소수 인력에만 의존하는 희소 스택의 채택, 비교 대상의 조건이 달라 결과가 왜곡된 성능 비교, 장기 유지 비용을 고려하지 않은 선정이 있다. 가중치는 임의성이 있으므로 점수의 합계가 판단을 대체하지 않도록 한다.

1.2.21 실시간 시스템 및 결정성 요구사항에 대한 기술 리딩 방법

이 절은 CTO의 기술 리딩 개관까지를 서술하며, 실시간성과 결정성 요구사항의 기술적 상세는 11.1이 본거지이다.

개념의 구분

실시간 시스템은 계산의 정확성이 논리적 결과뿐 아니라 그 결과가 산출되는 시각에도 좌우되는 시스템이다(실시간 컴퓨팅 문헌에서 통용되는 정의이며 원전은 확인하지 못하였다, 확인 필요). 마감 시간을 넘기는 것이 치명적 결과를 초래하면 경성(hard), 품질 저하에 그치면 연성(soft)으로 구분한다. 결정성은 같은 입력과 상태에서 동작과 응답 시간이 예측 가능한 성질로 쓴다(작업 정의). 평균 성능이 높아도 최악의 응답 시간이 요구를 넘으면 실시간 요구를 충족하지 못한다.

CTO의 리딩 과제

1. 요구사항의 정량화: "빠르게"가 아니라 마감 시간, 허용 지터, 최악 응답 시간을 측정 조건과 함께 제품 요구사항으로 명시한다. 이 수치는 고객에게 하는 성능 진술의 근거가 되므로 CTO의 사실 확인서에 포함한다(1.1.2).
2. 아키텍처 반영: 시간 임계 기능과 비임계 기능을 분리하고, 운영체제·스케줄링·런타임·언어의 선택은 결정 기록으로 남긴다(1.2.8, 1.2.20). 런타임의 지연 특성은 11.2~11.4가 다룬다.
3. 검증: 평균이 아니라 상한과 분포를 최악 조건에서 측정하며, 개발 환경에서만 시험하지 않고 목표 하드웨어에서 시험한다(1.2.10).
4. 역량: 실시간 설계 경험이 있는 인력은 희소하므로 확보와 이전 계획을 둔다(1.2.11).
5. 안전과의 연결: 마감 위반이 안전 사고로 이어지는 시스템은 기능 안전 규격의 요구에 연결한다(12.4~12.8).

요구사항 명세의 형식(가정 예시)

수치 자체는 제품마다 다르므로 이 표는 명세에 반드시 있어야 할 항목만 제시한다. 요구가 정량화되지 않으면 검증 계획과 고객에 대한 약속의 근거가 모두 사라진다.

경영진과의 소통

시간 요구의 위반은 성능 저하가 아니라 안전과 인증의 문제일 수 있다. 요구가 개발 후반에 정의되거나 발견되면 아키텍처 변경으로 이어져 비용이 크게 늘어나므로, 초기 요구사항 단계에서 확정하도록 CEO에게 보고한다. 고객에 대한 성능 약속에는 측정 조건을 병기하도록 한다.

함정

평균 지연만 평가하는 경우, 성능이 좋은 개발 장비에서만 시험하는 경우, 시간 요구가 개발 후반에 처음 정의되는 경우, 비실시간 구성요소(로깅, 네트워크 통신)가 실시간 경로에 간섭하는 경우가 있다.

1.2.22 전사적 인공지능 전환(AX)에서의 최고기술책임자 역할

이 절은 AX(인공지능 전환, AI Transformation)에서 CTO의 역할 경계를 서술하며, 전사 AX 로드맵의 수립과 추진은 15.1가 본거지이다.

두 영역의 구분

AX는 업무에 인공지능을 도입하는 영역과 제품에 인공지능을 내장하는 영역으로 나누어 책임을 정한다.

역할의 선택지

• ① CTO가 AX를 총괄: 기술 기반과 도입이 일관되고 결정이 빠르다. 업무 혁신과 조직 변화 관리가 기술 부서 중심으로 편향된다.
• ② CTO는 기술 기반만 책임하고 총괄은 별도 책임자(CEO 직할 또는 COO)가 담당: 업무 혁신의 균형이 좋다. 책임 경계가 겹치고 기술 판단이 늦어질 수 있다.
• ③ 위원회형: 부서 의견을 반영한다. 결정이 느리고 책임이 분산된다.

견해: 제품 내 인공지능은 CTO가 A로 책임지고, 업무용 인공지능은 업무 부서가 사용자이면서 CTO가 기술·보안 기준의 심사자가 되는 구조(②에 가까운 형태)를 기본값으로 둔다. 총괄은 회사 구조에 따라 정하되 책임·권한 매트릭스에서 A를 한 명으로 지정한다(1.2.2). 경영진 전체의 분담은 1.3가 다룬다.

거버넌스의 참고 틀

미국 국립표준기술연구소(NIST)의 인공지능 위험관리 프레임워크(AI RMF 1.0, NIST AI 100-1, 2023년 1월)는 인공지능 시스템의 위험 관리를 위한 자발적 지침이며 Govern, Map, Measure, Manage의 네 기능(거버넌스, 맥락 파악, 측정, 관리에 해당)으로 구성된다(해설 자료로 확인하였다, 문헌에 따르면). ISO/IEC 42001:2023은 조직의 인공지능 경영시스템을 수립·운영·개선하는 요구사항을 규정하는 국제 표준으로 2023년 12월에 발행되었다(표준 기관 카탈로그의 설명으로 확인하였으며 본문은 열람하지 못하였다). 한국의 법적 틀은 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」이며 의무 대상과 내용은 35.3가 본거지이므로 이 절에서는 조문을 인용하지 않는다. 위 두 문서는 자발적 틀이고 법적 의무의 충족을 대신하지 않는다.

CTO의 책임 항목

데이터와 모델 플랫폼의 아키텍처, 제품 내 인공지능의 평가 기준(성능, 안전, 편향)과 평가 체계(35.1), 도구 도입 기준, 역량 전환과 재교육(36.4.22), 연산 비용의 관리, 공급자 종속의 관리가 있다. 생성형 인공지능 서비스에 영업비밀을 입력하면 비밀로 관리되고 있다는 요건(「부정경쟁방지 및 영업비밀보호에 관한 법률」 제2조 제2호)에 영향을 줄 수 있으므로 입력 금지 정보의 등급과 승인된 도구 목록, 로그 관리를 정책으로 정한다(14.3, 15.3). 생성 결과물의 라이선스와 지식재산 귀속도 점검한다. 기계가 주도하는 연구개발 패러다임에서 CTO의 최종 결정 권한은 45.3가 다룬다.

함정

AX를 도구 구매 프로젝트로 환원하는 경우, 데이터 준비 없이 모델부터 도입하는 경우, 제품 내 인공지능의 평가 기준 없이 출시하는 경우, 연산 비용의 증가를 통제하지 않는 경우가 있다.

1.2.23 최고기술책임자의 대외 기술 커뮤니케이션과 기술 브랜딩

목적과 채널

대외 기술 커뮤니케이션은 회사의 기술 역량, 성과, 한계를 외부 대상에게 설명하는 활동이고, 기술 브랜딩은 기술 정체성을 일관되게 구축하고 전달하는 활동이다. 대상별 목적과 채널은 다음과 같다.

증거 기준

기술 주장은 증거 기준을 갖추어야 한다. 1.1.4가 제시한 다섯 질문, 즉 성능 수치가 어떤 조건에서 측정되었는지, 독립적으로 재현되었는지, 시험 환경과 실제 운영 환경의 격차는 무엇인지, 남은 기술 위험과 해소에 필요한 시간·자원은 무엇인지, 생산 규모를 키울 때 변하는 변수는 무엇인지를 CTO가 먼저 스스로 점검한다. 투자자·고객 대상 기술 성능 진술은 CEO가 최종 결정자이고 CTO는 사실 확인서로 지원한다(1.1.2).

공개 전 검토 항목

쟁점: 발신 주체

• ① CTO 개인 중심: 신뢰도와 속도가 높다. 개인 의존과 메시지 불일치의 위험이 있고 CTO 교체 시 기술 브랜드가 약화된다.
• ② 조직 중심: 검토 절차를 거쳐 여러 엔지니어가 발신한다. 통제가 가능하나 속도가 느리고 메시지의 구체성이 떨어진다.
• ③ 혼합: 공식 메시지는 조직이, 엔지니어 개인의 발표는 가이드라인을 정하여 허용한다.

견해: 기본값은 ③이다. 공식 메시지의 일관성과 개인 발신의 신뢰성을 함께 확보하기 위해서이다. 공개 전 검토의 소요 시간을 짧게 정해 두지 않으면 우회가 늘어난다.

위험 대응

과장은 단기 이익을 주지만 오류가 드러나면 신뢰 자본(1.1.11)을 소모한다. 위기 시 기술적 사실의 설명은 위기 커뮤니케이션 체계(28.4)를 따르며, 잘못이 확인된 주장은 신속히 정정한다. 채용을 위한 기술 브랜딩은 5.2이 다룬다.

1.2.24 최고기술책임자의 윤리적 책임과 기술 거버넌스

쟁점 영역

기술 윤리의 쟁점은 제품과 기술의 성격에 따라 다르다. 다음 영역을 기준으로 자사 기술에 해당하는 항목을 식별한다.

근거 문서와 법의 구분

법적 의무와 윤리 기준은 구별한다. 과학기술정보통신부가 2020년 12월에 발표한 「국가 인공지능 윤리기준」은 법적 구속력이 있는 규범이 아니라 사회 구성원의 자율적 준수를 전제로 한 기준으로 소개된다(언론과 법무법인 자료로 확인하였으며, 이후 개정 여부와 현행 내용은 확인하지 못하였다, 확인 필요). 법적 의무는 법령이 정하므로 인공지능 관련은 35.2과 35.3가 본거지이다. 윤리 원칙은 회사가 내부 규정으로 구속력을 부여할 때에만 조직 내에서 작동한다. 국제 표준으로 ISO/IEC 42001:2023이 인공지능 경영시스템의 틀을 제공한다(1.2.22). 책임·권한 매트릭스의 A는 내부 책임 배분이며 법적 책임의 배분이 아니다(1.1.2).

거버넌스의 구조

1. 원칙: 회사 수준의 짧은 기술 윤리 원칙을 정하고 이사회에 보고한다.
2. 위험 기반 검토: 고위험 기능(인명 안전, 민감 데이터, 자동화된 의사결정)을 식별하고 검토 후 승인, 조건부 승인, 반려를 정한다.
3. 기록: 검토 결과와 근거를 결정 기록과 연결한다(1.2.8).
4. 에스컬레이션: 중대한 쟁점은 CEO와 이사회에 올린다.
5. 신고 채널: 내부 구성원이 우려를 제기할 수 있는 채널과 보호 장치를 둔다.
6. 정기 점검: 제품의 사용 환경이 바뀌면 재검토한다.

쟁점: 검토의 주체

• ① CTO 단독: 속도가 빠르고 기술을 잘 안다. 이해 상충과 독립성 부족의 문제가 있다.
• ② 내부 위원회: CTO가 의장을 맡고 법무·보안·제품이 참여한다. 관점이 다양하고 기록이 남는다. 운영 비용이 들고 결정이 느려진다.
• ③ 외부 자문: 독립성이 높다. 비용이 들고 기술 정보가 외부로 나간다.

견해: 기본값은 ②이고, 인명 안전이나 민감 데이터와 관련된 고위험 영역에는 ③을 보완한다. 외부 자문에는 비밀유지 계약을 체결한다.

함정

윤리 원칙이 선언으로만 존재하는 경우, 윤리 문제를 사후 홍보 문제로만 다루는 경우, 일정 압박으로 검토를 생략하는 경우, 법무 검토로 윤리 검토를 대체하는 경우, 검토자가 개발 조직에 종속되어 독립성이 없는 경우가 있다.

1.2.25 차세대 최고기술책임자 육성과 기술 리더십 승계

이 절은 기술 리더십의 승계를 서술한다. CEO 승계 계획은 44.2이 본거지이고, 경영진 직책별 후임 계획은 1.3.19가 다룬다.

필요성

CTO 한 사람에게 핵심 기술 지식이 집중되면 이탈 시 개발이 중단된다(1.1.2). 회사의 성장 단계가 바뀌면 CTO에게 요구되는 직무가 달라지므로(1.2.1) 후임 육성은 이탈에 대비하는 장치이면서 현직 CTO의 역할 전환을 돕는 장치이다.

후보군과 역량 모델

후보는 내부(수석 엔지니어, 아키텍트, 부사장급 기술 임원, 팀 리더)와 외부에서 찾는다. 카츠(Robert Katz, 1955)는 관리자의 능력을 기술적, 대인적, 개념적 능력으로 나누고 상위로 갈수록 개념적 능력의 비중이 커진다고 보았다(1.1.4). 이를 CTO 후보에 적용하면 기술적 깊이 위에 다음 여섯 역량의 확장이 필요하다. 기술 전략 수립(1.2.4), 포트폴리오 판단(1.2.6), 조직 설계(1.2.11), 외부 기술 관계(1.2.14~1.2.18), 위험과 윤리 판단(1.2.19, 1.2.24), 경영진·이사회와의 소통(1.2.2)이다. 이 역량 목록은 학술적 합의가 아니라 이 장의 작업 틀이다.

개발 수단

• 결정 영역의 단계적 위임: 1.1.2의 결정 영역표에 따라 후임에게 이양하는 범위와 시기를 정하고, 이양 기간의 번복 요건을 정한다.
• 전략 과제: 기술 전략 문서와 로드맵 갱신을 공동 작성하게 한다.
• 이사회와 투자자 접점 노출: 정기 기술 보고를 후임이 일부 수행한다.
• 코칭과 직무 순환: 경영진 코칭의 설계는 44.2.19, 직무 순환은 44.2.20이 다룬다.
• 결정 기록의 활용: 결정 기록(1.2.8)을 읽고 근거를 설명하게 하여 판단 방식을 학습시킨다.

인계 가능성의 확보

승계는 사람의 문제이면서 문서의 문제이다. 결정 기록, 로드맵, 위험 등록부(1.2.19), 핵심 인력 지도(1.2.9), 외부 관계의 목록, 접근 권한의 목록이 최신 상태로 있는지를 점검한다. 갑작스러운 이탈에 대비하여 대행자를 지정하고, 퇴직자의 접근 권한 회수와 비밀 유지 서약 절차(14.3.17)를 준비한다.

쟁점: 승계 방식

• ① 내부 승계: 문화와 기술 맥락을 이해하고 이탈 위험이 낮다. 전략 시야가 부족할 수 있고 후임 육성에 시간이 든다.
• ② 외부 영입: 새로운 경험을 도입하고 빠르다. 조직 적응 실패와 창업 구성원과의 기술 철학 충돌 위험이 있다(57.6).
• ③ 과도기 병행(공동 CTO 또는 전임자의 자문 유지): 지식 이전이 안정적이다. 권한 중복과 책임 불명이 생기므로 기간과 권한 경계를 명시한다.

견해: 후보가 내부에 있고 성장 단계 전환이 급하지 않으면 ①을, 회사가 새로운 영역으로 확장하여 내부에 경험이 없으면 ②에 ③을 결합하는 것을 권한다. 창업자 CEO의 역할 전환과 교체 판단은 1.3.17과 44.2이 다룬다.

함정

후임 발굴을 현직 CTO에 대한 불신으로 오해하는 문화, 창업자 CTO가 위임을 미루어 후보가 성장하지 못하는 경우, 후보를 한 명으로 한정하는 경우, 평가 기준이 없어 후보 간 비교가 불가능한 경우가 있다.