젠슨 황, 직렬(CPU)에서 병렬(GPU)의 시대로
GAME 3-1에서 우리는 갈릴레오의 망원경을 훔쳤습니다.
우주의 중심을 '나'에서 '데이터'로 옮겼고, 정확한 좌표를 찾았습니다.
방향은 맞습니다.
그런데 문제가 생겼습니다.
"너무 느립니다."
일은 쏟아지는데, 조직의 속도는 한 사람의 입만 쳐다보며 정체되어 있습니다.
왜 우리는 늘 시간이 부족할까요?
세상에서 가장 비싼 반도체 기업을 만든 사나이가 답을 알고 있습니다.
그는 천재 한 명을 갈아 넣는 대신, 평범한 수천 명을 동시에 달리게 했습니다.
컴퓨터의 두뇌인 CPU는 엄청나게 똑똑한 '천재'입니다.
복잡한 수학 공식을 순식간에 풉니다.
하지만 치명적인 약점이 있습니다.
일을 '직렬(Serial)'로,
즉 한 번에 하나씩만 순서대로 처리한다는 것입니다.
1993년, 젠슨 황은 엔비디아를 창업하며 전혀 다른 베팅을 합니다.
GPU(그래픽 처리 장치)라는 새로운 아키텍처입니다.
GPU 안에는 복잡한 수식을 푸는 천재는 없습니다.
대신 단순한 계산만 할 줄 아는 '평범한 일꾼' 수천 명이 들어 있습니다.
핵심은 이들이 '병렬(Parallel)'로,
즉 수천 개의 계산을 '동시에' 처리한다는 것입니다.
과거에는 복잡한 논리가 중요했지만,
지금의 AI 시대는 방대한 데이터를 한꺼번에 집어삼키는 능력이 중요합니다.
결국 아인슈타인 1명(CPU)은,
동시에 계산을 하는 초등학생 1,000명(GPU)을 이기지 못했습니다.
이것이 엔비디아가 세상을 지배하게 된 관점의 시프트입니다.
"순서대로 완벽하게"에서 "동시에 무식하게"로의 전환.
2025년, 이 원리가 사무실에도 들어왔습니다.
에이전트 AI입니다.
당신이 "신제품 런칭 보고서 만들어줘"라고 하면, AI가 혼자 끙끙대지 않습니다.
시장 조사 에이전트, 경쟁사 분석 에이전트, 카피 작성 에이전트가 동시에 달립니다.
각자 결과를 가져오면, 총괄 에이전트가 조립합니다.
구조를 보십시오. CPU가 아닙니다. GPU입니다.
AI가 일하는 방식이 이미 병렬인데, 당신의 조직은 아직도 직렬입니다.
"당신의 조직은 CPU입니까, GPU입니까?"
2026년 기업 현장.
우리는 여전히 구시대의 CPU 방식으로 일합니다.
TYPE A. 직렬형 조직
기획서 작성 → (대기) → 팀장 리뷰 → (대기) → 디자인 → (대기) → 개발
일이 파이프라인을 타고 순서대로 흐릅니다.
앞 단계가 안 끝나면 뒷사람은 놉니다.
특히 모든 결정이 팀장을 거쳐야 한다면?
팀장이 회의에 들어간 2시간 동안 팀 전체의 업무가 정지됩니다.
→ 결과: 아무리 똑똑한 사람들이 모여도, 조직의 속도는 가장 좁은 병목(팀장)의 속도를 넘지 못합니다.
TYPE B. 병렬형 조직
기획, 디자인, 개발이 동시에 출발합니다.
완벽한 기획서가 나오길 기다리지 않습니다.
'목표'와 '인터페이스(연결부)'만 합의하고, 각자의 영역에서 뼈대를 동시에 만듭니다.
→ 결과: 누군가를 기다리지 않습니다. 속도가 폭발합니다.
단, 연결 규칙 없이 달리면 5일 차에 세 팀이 세 방향으로 흩어집니다.
속도만큼 동기화가 중요합니다.
당신의 목(Neck)이 조직의 병목(Bottleneck)입니까?
그렇다면 당신은 헌신적인 리더가 아닙니다.
조직의 처리량을 갉아먹는 가장 큰 버그입니다.
왜 우리는 직렬로 일할까요?
불안하기 때문입니다.
"내가 확인하지 않고 넘어갔다가 사고가 나면 어떡하지?"
이 문장의 핵심은 "사고"가 아니라 "내가"입니다.
사고의 책임이 한 사람에게 집중되어 있기 때문에,
확인도 한 사람에게 집중됩니다.
책임이 직렬이면, 업무도 직렬이 됩니다.
이 완벽주의가 '순차적 결재'를 만듭니다.
과거의 산업 시대에는 이 방식이 맞았습니다.
자동차 조립 라인에서는 바퀴를 달기 전에 엔진을 얹어야 하니까요.
하지만 지식 노동의 시대, AI의 시대에는 다릅니다.
완벽한 기획서를 1달 동안 끙끙대며 쓰는 것보다,
엉성한 프로토타입 3개를 동시에 던져놓고 고객 반응을 보는 것이 훨씬 정확합니다.
병렬화의 전제 조건은 속도가 아닙니다.
책임의 분산입니다.
맥락이 공유되면 판단이 분산되고,
판단이 분산되면 책임도 분산되고,
책임이 분산되면 병목이 사라집니다.
업무 구조를 바라보는 관점에 따라 인간은 세 부류로 나뉩니다.
① 대기하는 쓰레드 (플레이어)
"기획서 아직 안 나왔나요? 그럼 전 대기할게요."
앞 공정이 끝나기만을 수동적으로 기다립니다.
→ 유휴 상태. 자신의 시간이 낭비되어도 문제의식을 느끼지 못합니다.
② 과열된 중앙처리장치 (기술자)
"내가 다 확인해야 해. 나 없으면 일이 안 돌아가."
스스로 조직의 병목이 됩니다. 매일 야근하며 자신의 중요성을 증명합니다.
→ 통제 강박. 본인은 갈려 나가고 조직은 느려집니다.
③ 병렬 아키텍트 (설계자)
"기다리지 마. 우리가 맞춰야 할 '규격'만 정하고 동시에 달린다."
일의 순서를 해체하고, 여러 명이 동시에 작업할 수 있는 판(구조)을 짭니다.
→ 분산과 동기화. 권한을 나누고 속도를 해킹합니다.
리더인 당신에게 묻습니다.
"당신이 오늘 휴가를 가면, 팀원들은 본인의 일을 진행할 수 있습니까?
아니면 당신의 결재를 기다리며 올스톱입니까?"
멈춘다면, 당신의 조직 구조는 실패한 것입니다.
엔비디아의 GPU가 수천 개의 코어를 동시에 돌릴 수 있는 이유는,
그들을 묶어주는 CUDA라는 소프트웨어 플랫폼이 있기 때문입니다.
사람들을 동시에 움직이게 하려면 두 가지 메커니즘이 필요합니다.
Mechanism 1. 인터페이스 합의
개발자들은 일을 시작할 때 'API(서로 데이터를 주고받는 규칙)'부터 정합니다.
"나는 너에게 A를 줄 테니, 너는 나에게 B를 줘."
규칙만 정해지면, 기획이 다 끝나지 않아도
디자인과 개발이 동시에 각자의 뼈대를 만들 수 있습니다.
Action: 회의의 목적을 '지시'가 아니라 '결과물의 규격합의'로 바꾸십시오.
합의가 끝나면 각자 흩어져서 동시에 작업합니다.
Mechanism 2. 맥락의 동기화
직렬 조직에서는 리더만 '왜(Why)'를 알고
실무자는 '무엇(What)'만 합니다.
병렬 조직이 되려면, 1,000명의 코어(실무자)가
리더와 똑같은 '왜(Why)'를 공유해야 합니다.
그래야 기다리지 않고 스스로 판단할 수 있습니다.
Action: 과정 통제을 멈추고, 맥락 공유을 하십시오.
정보 독점을 풀고 전사에 투명하게 공개하는 것이 병렬화의 시작입니다.
여기서 잠깐. GAME 2-3의 교훈을 잊지 마십시오.
견제와 균형을 설계하라고 했습니다.
그런데 지금은 "직렬의 목을 자르라"고 합니다.
하지만 병렬화는 '실행'에 적용하는 것이지,
'검증'에 적용하는 것이 아닙니다.
기획, 디자인, 개발은 동시에 달리십시오.
하지만 최종 의사결정 전의 크로스 체크 — 법무, 재무, 품질 — 는 반드시 거치십시오.
액셀은 병렬로, 브레이크는 직렬로.
이것이 "안전하게 빠른 조직"입니다.
상황: 사장이 1주일 안에 신제품 런칭 캠페인 기안을 가져오라고 지시했습니다.
선택 A. 직렬의 길 (CPU 모드)
1~3일 차: 당신이 완벽한 기획 뼈대를 짠다.
4~5일 차: 디자이너에게 넘겨 시안을 뽑는다.
6일 차: 마케터에게 카피를 쓰게 한다.
7일 차: 보고한다.
→ 결과: 5일 차에 디자인이 방향과 다르게 나오면, 시간이 없어 그대로 가거나 밤을 새워야 합니다.
선택 B. 병렬의 길 (GPU 모드)
1일 차 오전: 팀 전원이 모여 목표와 타겟을 공유한다.
1일 차 오후 ~ 5일 차: 기획은 뼈대를 잡고, 디자이너는 무드보드를 10개 뽑고, 마케터는 카피 30개를 동시에 던진다. 매일 15분씩 모여 맞춰본다.
6일 차: 레고 블록처럼 가장 좋은 것들을 조립한다.
7일 차: 크로스 체크(품질/법무)를 거쳐 보고한다.
→ 결과: 누군가의 작업이 막혀도 다른 작업은 굴러갑니다.
6일 차까지 병렬로 달리고, 7일 차에 브레이크를 밟습니다.
3초간 생각해 보십시오 …
[ 결과 분석 ]
* A를 택했다면
: 당신이 3일을 쓰는 동안, 디자이너와 마케터는 놀고 있었습니다.
그리고 5일 차에 터진 문제를 수습할 시간이 없습니다.
* B를 택했다면
: 1일 차부터 세 팀이 동시에 달립니다.
매일 15분 밎춰보기가 궤도 이탈을 막습니다.
그리고 마지막에 브레이크(크로스 체크)가 품질을 잡습니다.
갑자기 "다 각자 알아서 해!"라고 하면 조직은 혼돈에 빠집니다.
병렬화는 방임이 아닙니다.
연결점을 더 촘촘히 하는 것입니다.
Bad: "알아서들 진행하고 금요일에 봅시다." (방임)
Good: "각자 파트를 동시에 진행합시다. 대신, 매일 아침 10분, '어디까지 했는지'와 '무엇이 막히는지'만 공유합시다." (동기화)
팀원들이 일주일 동안
"누군가의 피드백이나 결과물을 기다리느라 아무것도 못 한 시간"을 측정해 보십시오.
그 빈 공간이 당신 조직의 잃어버린 전투력입니다.
다음 프로젝트가 시작되면, 착수 전에 물으십시오.
"이 일에서 서로 기다리지 않고 동시에 진행할 수 있는 부분은 어디인가?"
한 덩어리의 과업을 독립 모듈로 분해하는 연습.
이것이 병렬화의 핵심 스킬입니다.
분해가 안 되면, 동시에 달릴 수 없습니다.
연습이 어려우면, AI에게 먼저 시켜보십시오.
"이 프로젝트를 동시에 진행 가능한 독립 모듈 5개로 쪼개줘."
AI의 분해 결과를 보면, 당신의 업무 중 어디가 직렬이고 어디가 병렬 가능한지가 보입니다.
AI는 당신의 일을 대신하는 것이 아닙니다. 당신의 구조를 보여주는 거울입니다.
리더는 실무자의 A부터 Z까지 확인하는 사람이 아닙니다.
지켜야 할 규칙만 결재해 주십시오.
실무자가 그 가드레일 안에서 움직인다면, 중간 과정은 보지 않아도 됩니다.
1990년대 후반, 엔비디아는 죽어가고 있었습니다.
NV1, NV2 아키텍처가 연달아 실패했습니다.
자금은 바닥났습니다.
유일한 생명줄은 세가(SEGA)와의 계약이었습니다.
젠슨 황은 세가에 전화를 걸었습니다.
"우리가 만들고 있는 것이 틀렸습니다. 계약을 취소해주십시오."
자기 회사의 유일한 수입원에게,
스스로 "우리가 틀렸다"고 말한 것입니다.
그리고 남은 자원을 전혀 다른 아키텍처에 올인했습니다.
기존 경로(직렬)를 스스로 끊고,
새로운 경로(병렬)로 도약한 것입니다.
그것이 오늘의 엔비디아를 만들었습니다.
직렬의 목을 자르는 것은 용감한 일이 아닙니다.
"내가 틀렸다"를 인정하는 것이 용감한 일입니다.
그리고 남은 자원을 새로운 판에 거는 것.
당신의 목을 자르십시오.
그리고 판을 까십시오.
좌표를 옮기고(갈릴레오),
병렬로 속도까지 높였습니다(젠슨 황).
그런데 속도가 빨라지면 반드시 발생하는 문제가 있습니다.
바로 '실수(Error)'입니다.
"틀리면 어떡하지?"
우리는 정해진 악보대로 연주하도록 교육받았습니다.
하지만 비즈니스 현장에는 악보가 없습니다.
다음 주.
재즈의 거장에게 배우는 불확실성과 즉흥(Improvisation)의 알고리즘.
당신의 실수를 마스터피스로 바꾸는 관점의 해킹이 시작됩니다.