AI 시대, 「내제화인가 외주인가」는 어떻게 변하는가 ~ SIer의 입장에서 생각하는 일본 IT 시장의 미래 ~

일본 기업의 시스템 개발은 오랜 기간 SIer(System Integrator)를 중심으로 한 다중 하청 외주 구조에 의해 지탱되어 왔다.

사용자 기업이 요구사항을 제시하면, 대형 SIer가 프로젝트를 수주한다. 대형 SIer는 개발 공정을 자회사나 협력 회사로 위탁하며, 그 너머로 업무가 분배된다. 이 구조는 사회 전체적으로 IT 인재가 부족한 가운데, 다수의 엔지니어를 필요한 기간만큼 모아 대규모 시스템을 구축하는 수법으로서 과거에는 일정 수준의 합리성을 가지고 있었다.

하지만 생성형 AI(Generative AI)나 AI 코딩 도구의 폭발적인 보급으로 인해 그 전제가 근본부터 뒤집히기 시작하고 있다.

지금까지 시스템 개발은 **「개발·운용 시에 대량의 인원을 필요로 하는 활동」**이었다. 그렇기에 기업이 자사에서 고정 인원을 보유하기보다, 필요할 때 외부로 발주하는 것이 합리적이었다. 그렇다면 AI에 의해 「소수 인원으로도 시스템을 구축·운용할 수 있는 시대」가 도래했을 때, 이 합리성은 유지될 것인가.

본 기사에서는 일본 기업이 왜 IT를 외부에 의존해 왔는지를 정리한 후, AI 시대에 내제화(In-house)와 SIer 시장이 어떻게 변화할 것인지 논하고자 한다.

일본과 미국은 IT 인재가 소속된 기업의 구조가 크게 다르다. IPA(정보처리추진기구)의 조사에 따르면, IT 인재 중 「IT 기업(SIer나 벤더 등)」에 소속된 비율은 **미국이 35.1%인 것에 반해, 일본은 73.6%**에 달한다 [1: 2020년 국세조사 기준]. 즉, 미국에서는 IT 인재의 상당수가 사업 회사에 있는 반면, 일본에서는 IT를 제공하는 측에 집중되어 있다.

이 차이를 「일본 기업은 IT를 경시해 왔기 때문」이라고 한마디로 치부하는 것은 불충분하다. 일본의 외주 의존은 다음과 같은 4가지 구조적 요인이 쌓인 결과이다.

업무의 「간접 부문」으로서의 IT 위치 설정
많은 일본 기업에서 IT는 경쟁력을 창출하는 핵심 기능이 아니라, 업무를 지원하는 간접 부문(Cost Center)으로 취급되어 왔다. 요구된 것은 「새로운 고객 가치의 창출」이 아니라 「기존 업무를 중단하지 않는 안정적인 운용」이었기 때문에, 자사에 노하우를 축적할 인센티브가 작동하기 어려웠다. -
전문직의 장기 처우가 어려운 인사 제도
연공서열이나 제너럴리스트형 배치 전환을 전제로 하는 일본형 인사 제도는, 고도의 엔지니어를 전문직으로서 적절하게 평가하고 처우하는 메커니즘과 상성이 좋지 않았다. 결과적으로 우수한 인재를 사내에 정착시키는 것이 어려웠다. -
시스템 개발 수요의 「파동(Wave)」
대규모 기간 시스템 쇄신 등의 프로젝트에서는 설계·개발·테스트의 피크 시기에 대량의 인원이 필요하지만, 출시 후의 유지보수(Maintenance) 단계에서는 그만큼의 인원을 필요로 하지 않는다. 이 수요의 파동에 대응하여, 프로젝트 단위로 외부에서 인원을 조달하는 것이 경영적으로 합리적이었다. -
리스크와 책임의 외부 이전
계약, 검수, 품질 보증, 장애 대응을 포함하여 개발·운용 전체를 외부에 위탁함으로써, 사용자 기업은 기술적인 복잡성과 그에 따른 리스크를 SIer 측으로 이전(Outsourcing)할 수 있었다.

이러한 경위로 인해 일본에서는 「업무를 아는 사용자 기업」과 「시스템을 만드는 SIer」의 분리가 진행되었다.

하지만 이 분리는 단순한 작업의 외부화에 그치지 않는다. **「시스템을 만들고, 운용하며, 트러블을 극복하는 과정에서 생겨나는 살아있는 지식(Knowledge)까지도 기업의 외부에 축적되는 구조」**를 만들어 버린 것이다.

이 견고한 구조를 격변시킬 가능성을 품고 있는 것이 생성형 AI를 중심으로 하는 테크놀로지의 진화다.

현대의 AI 도구는 단순한 코드 자동 생성에 머물지 않는다. **시스템 구조 조사, 설계 보조, 테스트 코드 작성, 코드 리뷰, 문서 생성, 나아가 실환경(Production)의 장애 분석 및 트러블슈팅(DevOps 영역의 자동화)**에 이르기까지, 개발·운용의 라이프사이클 전체로 적용 범위를 넓히고 있다.

중요한 것은 「소수 인원으로도 시스템을 유지할 수 있다」는 경제적 합리성의 역전이다.

AI에 의한 생산성 향상의 정도는 조건에 따라 다르지만, 「한 명의 엔지니어가 커버할 수 있는 영역이 압도적으로 넓어진다」는 트렌드는 변하지 않는다.

기존에는 신규 시스템을 구축하기 위해 수십 명 규모의 개발·운용 체제가 필요했지만, AI를 파트너로 삼는다면 최소한의 핵심 혁신가(Core Innovator)만으로도 일정 규모의 시스템을 지속적으로 개발·개선할 수 있게 된다. 대규모 피크에 맞춰 외부 인원을 끌어모을 필요성이 옅어지고, 「소수의 고도 인재를 사내에 보유하며 프로덕트를 고속으로 진화시키는」 형태가 매우 현실적인 선택지가 되었다.

AI는 단순히 개발 비용을 낮추는 도구가 아니다. 지금까지 외부 조달을 정당화해 왔던 「대량의 인원이 필요하다」는 전제 자체를 무너뜨리고, 내제화와 외주의 경계선을 다시 긋는 기술이다.

여기서 「내제화 (In-house development)」라는 말의 정의를 올바르게 정리해 두고 싶다. 많은 기업이 「자사에서 엔지니어를 채용하여 자사 직원이 코드를 작성하는 것」을 내제화라고 오해하곤 한다. 하지만 단순히 직원이 코드를 작성하고 있는 것만으로는 진정한 내제화라고 할 수 없다.

다음과 같은 상태에 빠져 있다면, 코드를 작성하는 사람이 자사 직원이라 할지라도 조직으로서 IT를 컨트롤하고 있다고 말하기 어렵다.

• 특정 엔지니어만이 시스템의 구조 (아키텍처 (Architecture))를 이해하고 있다
• 왜 그런 설계로 했는지, 의사결정 경위 (ADR 등)가 기록되어 있지 않다
• 운영 장애나 트러블로부터 얻은 교훈이 담당자의 머릿속에만 있다
• 개발 및 운용의 품질 기준이 조직의 프로세스로 정의되어 있지 않다

반대로, 구현의 일부를 외부 기업에 위탁하고 있더라도, 자사가 프로덕트의 방침을 결정하고 아키텍처를 통치하며, 운용에서 얻은 지식을 자사 조직으로 환류(Feedback)시키고 있다면, 그것은 충분히 「내제화된 상태」라고 말할 수 있다.

내제화의 본질은 고용 계약의 차이가 아니라, 다음의 능력을 자사의 「조직 능력 (Capability)」으로서 축적·컨트롤할 수 있는가에 있다.

• 고객 및 업무 (도메인 (Domain))에 대한 깊은 이해
• 시스템 설계의 의도와 의사결정 경위의 파악
• 장애나 실패로부터 배우고 시스템을 회복·개선시키는 지견
• 지속적인 개선을 돌리기 위한 프로세스와 품질 기준
• 외부의 기술이나 서비스를 올바르게 평가하고 활용하는 능력

즉, 내제화란 「코드의 생산 수단」을 자사가 보유하는 것이 아니라, 「사업과 IT에 관한 의사결정 능력과 학습 능력」을 자사 내에 가두어 두는 것이다. 지향해야 할 점은 「완전한 자사 개발」이 아니라, 자사가 주도권 (Ownership)을 쥔 상태에서 외부의 전문성을 레버리지 (Leverage)하는 것이다.

내제화가 불가피해지는 또 다른 결정적인 이유는 기업 내 IT의 위치 설정 변화에 있다.

기존의 IT화 (디지타이제이션 (Digitization))는 경리, 인사, 판매 관리 등 이미 확립된 업무 프로세스를 시스템으로 대체하는 것이 중심이었다. 이 경우 「업무 부문이 요구사항을 정의하고, SIer가 구현한다」는 분업이 기능하기 쉬웠다.

하지만 AI를 사업의 핵심에 편입시키는 **AX (AI Transformation)**에 있어서는 IT와 본업을 분리하는 것이 불가능하다.

• 어떤 판단을 AI (에이전트 (Agent))에게 맡길 것인가
• 어디에 인간의 체크 (Human-in-the-Loop)를 남길 것인가
• AI의 출력 결과를 어떤 업무 프로세스나 고객 경험에 연결할 것인가

이것들은 단순한 「시스템의 기능 요구사항」이 아니라, 업무 설계, 조직 디자인, 권한 위임, 나아가 사업 전략 그 자체이기 때문이다. 외부의 SIer는 기술에 해박하더라도 고객 기업 현장에 있는 암묵지나 조직 내의 역학 관계, 예외 처리의 까다로운 운용까지는 이해할 수 없다. 반면, 사업 회사의 직원은 도메인 지식 (업무 지식)을 가지고 있어도 최신 AI 기술로 무엇을 할 수 있는지는 알지 못한다.

따라서 AX에서 필요한 것은 기존 방식의 워터폴 (Waterfall)식 분업이 아니다. 도메인 지식과 기술 지식을 동일 팀 내에서 오가며, 업무와 시스템을 동시에 실험·변혁해 나가는 애자일 (Agile)한 체제다. 이 사이클을 고속으로 돌리기 위해서는 핵심이 되는 프로덕트 책임자나 주요 엔지니어를 자사 측에 배치할 수밖에 없다.

외부의 전문성을 활용하는 것 자체는 결코 나쁜 것이 아니다. 외주의 진짜 문제는 개발 작업을 외부에 맡기는 것이 아니라, 「사업을 개선하기 위한 학습 루프 (피드백 루프 (Feedback Loop))」가 기업이나 조직의 경계에 의해 잘게 조각나 분단되어 버리는 것에 있다.

일반적인 외주 구조에서는 정보가 다음과 같이 각기 다른 장소에 고립 (사일로화 (Siloing))된다.

【고객의 요청】 ──> 사업 부문

【요구사항 정리】 ──> 정보 시스템 부문

【기본 설계】 ──> 대형 SIer

【구현·테스트】 ──> 협력사·하청 벤더

【운용·보수】 ──> 외부 보수 운용 회사 (장애·문의 대응)

각 스테이크홀더 (Stakeholder)는 자신의 담당 범위 정보만을 가지고 있다. 그 결과, 다음과 같은 치명적인 기회 손실이 발생한다.

• 현장의 장애나 고객의 실제 반응이 다음 설계에 반영되기까지 방대한 시간이 걸린다
• 현장에서 얻은 까다로운 운용 노하우가 계약 (회사)의 경계선을 넘지 못한다
• 담당자가 바뀔 때마다 시스템의 「배경」을 처음부터 다시 설명해야 하는 비용이 발생한다

이것은 단순한 커뮤니케이션의 비효율이 아니다. **「기업이 시장이나 고객으로부터 학습하는 속도(Learning Velocity)를 현저히 저하시키는 구조」**인 것이다.

AI에 의해 코드 구현 속도가 극한까지 높아질수록, 이러한 조직 간의 오버헤드(Overhead)는 더욱 극명하게 드러난다. AI를 사용하면 하루 만에 끝날 수정에 대해, 요구사항 문서화, 견적 산출, 계약 변경, 승인, 검수에 3주를 소비하고 있다면, 개발 공정을 아무리 고속화하더라도 비즈니스 가치 제공 속도는 변하지 않는다.

내제화(In-house development)를 통해 얻을 수 있는 최대의 결실은 외주비의 절감이 아니다. 「고객·업무·개발·운용·장애 대응」을 하나의 긴밀한 피드백 루프(Feedback loop)로 연결하여, 기업의 학습 속도를 최대화하는 것에 있다.

외부 위탁에는 눈에 보이지 않는 막대한 **「거래 비용(Transaction cost)」**이 발생하고 있다.

• 요구사항을 타인에게 전달하기 위한 문서화 비용
• 견적 취득, 가격 협상, 계약 체결 절차 비용
• 복수 기업 간의 진척 조정, 변경 관리, 책임 분계의 명확화 비용
• 납품물의 검수 및 품질 체크 비용

사내라면 "잠시 여기를 테스트해 보자"라며 당일에 목업(Mockup)을 만들어 검증할 수 있는 변경이라 할지라도, 외부 위탁에서는 매번 이러한 거래 비용의 벽이 가로막는다. 사양이 명확하고 변경이 적은 시스템이라면 이 방식도 기능하겠지만, 가설 검증을 반복하며 빠르게 시장에 적응하는 모던한 프로덕트 개발(Product development)에 있어서 이러한 지연은 치명상이 된다.

AI 시대의 내제화는 아이디어에서 구현, 평가, 그리고 개선(또는 장애로부터의 복구)까지의 거리를 최단으로 만들어, 기업 간 거래의 오버헤드에 의해 고사하는 것을 방지하기 위한 생존 전략이다.

이러한 변화는 IT에 대한 마인드셋의 전환(프로젝트 사고에서 프로덕트 사고로의 시프트)을 의미한다.

비교 축	프로젝트 사고 (기존의 외주형)	프로덕트 사고 (앞으로의 내제형)
골(Goal)	명확한 시작과 종료 (납기·예산·요구사항 준수)	원칙적으로 끝이 없음 (지속적인 성장·적응)
성과의 정의	정해진 시스템을 「납품」하는 것	시스템이 창출하는 「고객 가치·사업 성과」
접근 방식	처음에 사양을 엄격하게 고정함	가설 검증 (실험과 학습)을 고속으로 반복함

무엇을 만들어야 성과가 나올지 알 수 없는 불확실한 시대에, 처음에 완성형을 정의하는 것을 전제로 한 「도급 계약」은 본질적으로 어울리지 않는다. 그렇기에 프로덕트 사고를 채택하는 기업일수록 학습과 의사결정의 중심을 자사로 되돌리려 하는 것이다.

IT에 대한 마인드셋을 「프로덕트 사고」로 전환하지 못하는 기업에게 외부 위탁에 대한 의존은 치명적인 독이 된다.

중요한 IT 자산의 구조, 설계 사상, 운용 노하우(왜 이 구성이 되었으며, 장애 발생 시 어떻게 조사·복구해야 하는가)를 외부 기업에 통째로 맡겨버려, 자사에 블랙박스(Black box)만 남게 되는 상태는 현대에 있어 중대한 경영 리스크이다.

위탁사의 철수, 키맨(Key man)의 교체로 인한 시스템의 형해화, 유지보수 비용의 고등, 기술 스택(Tech stack)의 노후화. 계약서상에 「성과물의 소유권은 자사에 귀속된다」라고 적혀 있더라도, **자사에 그것을 핸들링할 지식이나 장애를 분석할 능력이 없다면, 그것은 자산이 아니라 「부채」**다.

IT와 사업이 불가분(不可分)이 된 지금, IT의 주도권을 잃는 것은 경영의 키를 외부로 맡기는 것과 같다.

외부에 주도권을 잡히는 블랙박스화는 반드시 막아야 하지만, 그렇다고 해서 모든 시스템을 자사에서 제로(Zero)부터 개발·운용하는 것은 불합리하며 리소스의 분산을 초래한다. 중요한 것은 시스템을 기업의 경쟁력과의 관계성에 따라 분류하고, 적절한 포트폴리오를 구성하는 것이다.

영역	정의·구체적 사례	내제화·외주 스탠스
코어 영역 (Core Domain)	경쟁 우위나 독자적인 고객 가치와 직결되는 영역 (예: 독자적인 가격 결정 알고리즘, 핵심 고객 경험, AI를 통한 의사결정 모델, 물류 최적화 등)	완전한 오너십 (Ownership)을 유지. 의사결정, 아키텍처, 핵심 구현은 자사에서 수행. 일부 외부 전문가를 투입하는 경우에도 주도권은 넘기지 않음.
지원 영역 (Support Domain)	사업 운영에 필수적이지만, 직접적인 차별화 요소는 아닌 영역 (예: 사내 워크플로우, 데이터 분석 기반, 업무 지원 도구, 관리 화면 등)	하이브리드형 (협업). 자사가 프로덕트 오너십 (Product Ownership)을 가지되, 설계·구현의 대부분에 외부의 전문성이나 파트너를 유연하게 활용함.
범용 영역 (Generic Domain)	업계 공통 사항이며, 자사에서 독자적으로 만들 의미가 적은 영역 (예: 회계, 급여 계산, 메일·그룹웨어, 일반적인 CRM 등)	외부 서비스의 철저한 활용. SaaS나 표준 패키지를 그대로 이용하며, 자사의 귀중한 개발 리소스를 여기에는 할애하지 않음.

질문해야 할 것은 '내제화인가 외주인가'라는 흑백논리의 논쟁이 아니다. **"이 영역은 자사의 경쟁력이나 시장으로부터의 학습에 얼마나 영향을 미치는가"**라는 질문에 기반하여 현명한 포트폴리오를 설계하는 것이야말로, AI 시대의 올바른 IT 전략이다.

물론, 이 포트폴리오 전략을 모든 일본 기업이 일제히, 똑같이 실행할 수 있는 것은 아니다. 거기에는 기업 규모에 따른 현실적인 격차(양극화)가 존재한다.

대기업: 내제화 추진과 자사 플랫폼화

풍부한 리소스와 지속적인 IT 수요가 있기 때문에, 엔지니어를 일정 규모로 보유하며 사내의 다양한 테마(개발·데이터 활용·AI 도입·DevOps 자동화)에 유연하게 배치할 수 있다. 사내에 견고한 커리어 래더 (Career Ladder)를 마련하는 것도 가능하다. -
중소기업: 표준화된 서비스의 컴포저블 (Composable, 조합형) 이용

기업당 IT 수요나 투자 규모가 제한적이기 때문에, 고도의 엔지니어를 상시 고용하기는 어렵다. 따라서 모든 것을 내제화하는 것이 아니라, SaaS, 업종 특화형 플랫폼, 지역의 신뢰할 수 있는 IT 벤더나 외부 전문가를 스팟(Spot)으로 조합하는 수요가 강력하게 남는다.

앞으로는 일률적인 내제화가 아니라, 대기업은 '코어 기능의 내제화'를 날카롭게 다듬고, 중소기업은 '표준화된 외부 서비스의 철저한 활용'으로 시프트(Shift)하는 전략적 중요도에 따른 구분 활용이 진행될 것이다.

이처럼 대기업이 '코어 영역'의 내제화로 본격적으로 시프트하고, 중소기업이 SaaS 활용을 추진하는 세상에서, 지금까지 대규모 IT 투자를 주요 수익원으로 삼아온 SIer 모델은 강력한 타격을 받게 된다.

AI를 통해 엔지니어 한 명의 생산성이 향상되면, 고객은 '절반의 인원·절반의 기간'으로 동일한 성과를 얻을 수 있게 된다. 하지만, **매출을 '투입 인원 × 기간'으로 계산하는 '인월 계약 (Man-Month, Time & Material)' 비즈니스 모델에 의존하고 있는 SIer에게는, 생산성을 높이면 높일수록 자사의 매출이 줄어드는 구조적 모순 (딜레마)**에 직면하게 된다.

향후 도태되는 것은, '고객과의 정보 격차'에 안주하며 요구사항을 단순히 전달하거나, Excel을 통한 진척 관리, 문서의 재생산만으로 인월(Man-month)을 벌어왔던 SIer의 상류 공정이다. 도메인 지식 (Domain Knowledge)은 고객이 가지고, 일반적인 기술 정보의 정리나 자료 작성은 AI가 대체한다. 그 사이를 단순히 전달만 하는 존재에게 높은 단가를 지불할 이유는 어디에도 없다.

인월 비즈니스로부터의 탈피를 목표로 하는 가운데 주목받고 있는 것이, **FDE (Forward Deployed Engineer: 전방 배치형 엔지니어)**라는 역할이다.

FDE는 기존의 '영업', 'PM', '개발자'의 경계를 넘어 고객의 현장 (Frontline)에 깊숙이 파고들어, 업무 과제를 그 자리에서 발견하고 스스로 AI나 클라우드를 구사하여 초고속으로 프로토타입을 설계·구현한다.

이는 SIer가 '수탁 벤더'에서 '고객 밀착형 기술 파트너'로 변모하기 위한 훌륭한 모델이 될 수 있다. 하지만 FDE도 만능 특효약은 아니다. 단순히 고객마다 개별적인 투박한 커스텀 개발을 계속하는 것에 불과하다면, 그것은 이름만 바꾼 '고가동 파견·수탁'에 지나지 않는다.

FDE 모델을 성공시키는 열쇠는, 고객 현장에서 얻은 범용적인 지견이나 과제 패턴을 SIer 자사의 '재사용 가능한 자산 (Common Platform, 공통 AI 에이전트, 업계 템플릿)'으로 환원·제품화할 수 있는가에 있다. 현장의 지견을 자산 (Product)으로 변환할 수 있을 때 비로소 SIer는 노동 집약적인 인월 비즈니스를 넘어서는 스케일을 손에 넣는다.

향후 SIer가 취해야 할 전략적 방향 설정은 크게 다음 4가지 방향으로 집약된다.

「내제화 저지」에서 「내제화 동반 지원」으로의 전환

고객을 자사에 의존하게 만드는 락인 (Lock-in) 전략은 더 이상 통하지 않는다. 오히려 고객의 시스템 아키텍처 (System Architecture) 표준화, DevOps 환경 구축, 보안 거버넌스 (Security Governance), AI 활용 기술 육성 등을 지원하여, 「고객이 자생할 수 있는 견고한 토대」를 함께 만드는 파트너로서의 지위를 구축한다. -
노동(사람)이 아닌, 자산(Asset)의 판매

AI 시대의 단순한 구현 작업은 커모디티화 (Commoditization) 된다. SIer는 특정 산업 특화형 데이터 모델, 컴플라이언스 (Compliance) 요건을 충족한 보안 기반, 고도로 튜닝된 AI 에이전트 등 「단기간에 만들 수 없는 재사용 가능한 소프트웨어 자산」을 보유하고, 이를 베이스로 가치를 제공한다. -
커모디티화되지 않는 「초·고도 전문성」의 제공

모든 고도 기술을 사업 회사가 자체적으로 모두 떠안을 수는 없다. 차세대 클라우드 인프라 (Cloud Infrastructure) 최적화, 최첨先端 사이버 보안 대응, 대규모 시스템 마이그레이션 (Migration) 아키텍처, AI 거버넌스 수립 등 변화가 격심하고 극히 전문성이 높은 영역을 「결과·성과 커밋형 (Commit-type)」으로 제공한다. -
중소기업을 위한 「매니지드 셰어드 서비스 (Managed Shared Service)」

내제화를 수행할 체력이 없는 중소기업군을 대상으로, 개별 개발이 아닌 업종 특화형 SaaS나 공통 업무 플랫폼, AI를 활용한 운영 대행 등을 저비용·고품질 패키지로 제공한다.

기업뿐만 아니라 그곳에서 일하는 「개인」의 커리어 관점에서도 유사한 구조적 변화가 일어나고 있다. 지금까지는 「SIer에서 기술을 연마하여 사업 회사의 내제화 요원으로 이직한다」는 일방향적인 커리어가 주류였다. 하지만 앞으로는 양자 사이를 긍정적으로 오가는 「인재의 왕복 (순환)」 이 활발해질 것이다.

SIer와 사업 회사에서는 각각 얻을 수 있는 경험의 질이 본질적으로 다르기 때문이다.

SIer에서 얻을 수 있는 경험: 다양한 업계의 시스템을 접할 기회, 대규모 프로젝트 매니지먼트 (Management), 최첨단 인프라·보안 기술의 횡단적인 지식 (Knowledge). -
사업 회사에서 얻을 수 있는 경험: 특정 도메인 (Domain, 사업·고객)에 대한 깊은 몰입, 시스템이 사업 수치에 미치는 인과관계 트래킹 (Tracking), 릴리스 (Release) 후의 지속적인 개선이나 트러블슈팅 (Troubleshooting)을 통한 프로덕트의 지속 가능성 (Sustainability) 이해.

앞으로의 시대에 시장 가치가 가장 높아지는 것은, 「기술」과 「도메인」 양쪽의 언어를 구사하며 서로 다른 조직의 경계를 넘나드는 「경계 초월 인재 (Cross-border Talent)」 이다. SIer에서 광범위한 기술을 배운 자가 사업 회사에서 도메인 지식을 심화하고, 그곳에서 얻은 변혁의 노하우를 지닌 채 다시 FDE나 컨설턴트로서 SIer(또는 스타트업)로 돌아와 여러 기업을 지원한다. 이러한 순환이 일본 IT 산업 전체의 저변을 확대하는 데 기여한다.

이 순환을 가속화하기 위해서는 기업 측의 인사·평가 제도 업데이트가 필수적이다. 사업 회사는 이들을 단순한 「사내 프로그래머」가 아닌 「사업 변혁의 아키텍트 (Architect)」로 대우해야 하며, SIer 측도 사업 회사 출신 인재의 도메인 지식을 프로덕트 개발에 활용할 수 있는 커리어 패스 (Career Path)를 마련해야 한다.

향후 논의에 있어, 「모두를 내제화할 것인가, 모두를 외주화할 것인가」라는 이지선다는 본질이 아니다.

정말로 묻고 있는 것은, 「자사의 경쟁력 원천이 되는 지식과 신속한 의사결정 능력을 누가 보유하고 있는가」 라는 단 한 점이다.

AI에 의해 변하는 것은 코드를 쓰는 속도만이 아니다. IT 인재를 어디에 배치하고, 누가 주도권을 쥐며, 현장의 트러블이나 고객의 목소리에서 얻은 배움을 「어디에 축적할 것인가」 하는, 산업 전체의 분업 구조 그 자체의 재정의인 것이다.

이 변화의 격류 속에서 자사가 유지해야 할 「코어 영역 (Core Area)」을 명확히 정하고, 그 능력을 개인의 경험으로 끝내지 않고 「조직의 자산」으로 축적하는 프로세스를 확립한 기업만이, 내제·외주의 형태를 불문하고 IT를 진정한 무기로 삼을 수 있는 것이다.