조직을 다시 설계하는 방법 Ch.3 | EP.03
애자일과 OKR은 결코 ‘좋은 말’이 아니다.
그것은 ‘일의 구조’를 설계하는 구체적인 방식이다.
다시 말해, 실행 가능한 운영 시스템이다.
Chapter 1. 구조로 몰입을 설계하다(4회)
Chapter 2. 채용이 조직을 말해준다(4회)
“목표는 있는데, 왜 우리는 늘 계획만 세우다 끝나는 걸까?”
중견 IT기업의 5년차 기획자 이 팀장은 매주 회의 때마다 비슷한 좌절을 겪는다.
월요일 아침마다 작성하는 주간 계획표, 월말마다 보고하는 실적 정리, 분기마다 바뀌는 KPI.
일정표는 가득하지만, 일의 속도는 늘 뒤처진다.
회의에서는 “더 빠르게 실행하자”, “현장 중심으로 움직이자”는 말이 반복되지만,
그 말조차 익숙한 의례가 되어버렸다.
이 팀장이 처음 ‘애자일’이라는 말을 들었을 때는 꽤 설렜다.
‘스프린트’, ‘스크럼’, ‘빠른 피드백’, ‘자율적인 팀’이라는 키워드는 왠지 일의 활기를 되찾아 줄 것 같았다.
실제로 부서에 애자일 코치가 도입되고, OKR도 시범적으로 적용됐다.
구성원들은 일주일 단위로 목표를 세우고, 데일리 스탠드업 회의를 통해 진행 상황을 공유했다.
하지만 몇 달이 지나자 기대는 다시 피로로 바뀌었다.
“왜 또 목표를 새로 써야 하죠?”,
“이건 그냥 회의만 늘어난 거 아니에요?”,
“스프린트는 있는데 왜 일은 계속 늦어지죠?”라는 질문이 잇따랐다.
‘애자일’을 시작했지만, 오히려 더 복잡해졌다는 불만이 조직에 퍼져나갔다.
문제는 방식이 아니라 구조였다.
이 팀장 조직의 애자일 시도는 절반만 설계된 채로 시작됐다.
스프린트는 도입됐지만, 권한은 여전히 팀장이 쥐고 있었다.
피드백을 주고받는 회의는 생겼지만, 실질적인 피드백 문화는 자리잡지 못했다.
무엇보다,
구성원 각자가 스스로 목표를 설정하고 실패를 실험할 수 있는
‘심리적 안전감’이나 ‘경계 없는 협업 구조’는 설계되지 않았다.
결국 ‘애자일’이라는 이름만 빌려온,
이전 구조에 포장만 바뀐 시스템이 된 것이다.
한편, 반대의 사례도 있다.
스타트업 G사는 정해진 조직도나 명확한 직무 분장이 없다.
주간 단위로 모이는 스프린트 회의에서 팀원들은
“이번 주에 꼭 이루고 싶은 일(What I’ll own)”을 직접 정의하고,
동료들에게 공유한다.
팀장은 이를 확인만 하고, 필요한 자원만 연결한다.
모든 구성원은 Notion 페이지에 자신의 OKR과 업무 루틴을 공유하고,
동료 피드백을 자동으로 주고받는다.
누가 어떤 일을 하겠다고 정하면,
그걸 ‘누가 시켰는지’는 중요하지 않다.
중요한 건,
일이 흐르고, 그 흐름이 스스로를 진화시키는 구조였다.
이 두 사례의 차이는 어디서 비롯된 걸까?
애자일을 도입한다고 해서 조직이 민첩해지는 것은 아니다.
OKR을 작성한다고 성과가 발생하는 것도 아니다.
중요한 건 그 구조가 어떻게 설계되었는가다.
일하는 방식이 선언에 그치는지, 구조로 연결되는지가
몰입과 지속 가능성의 차이를 만든다.
오늘날 많은 조직이 애자일과 OKR을 도입하려고 한다.
그러나 단지 도구와 용어만 차용해서는 안 된다.
중요한 것은 그 언어가 실질적인 구조로 작동할 수 있도록 설계하는 것이다.
그리고 그 구조는 자율과 책임, 실험과 피드백, 흐름 중심의 일 방식이
조화를 이뤄야 비로소 성과로 이어질 수 있다.
이 글에서는 왜 애자일과 OKR이 이름값을 못하는 조직이 생기는지를 짚고,
실제로 그것이 잘 작동하는 조직에서는 어떤 구조적 설계가 존재하는지,
그리고 그것을 어떻게 우리 조직에 맞게 적용할 수 있을지를 탐색할 것이다.
애자일과 OKR은 ‘운영 방식’이기 전에 ‘일의 철학’이다.
그리고 그 철학은 구조로 구현될 때 비로소 힘을 발휘한다.
“애자일은 했는데, 왜 일은 그대로일까?”
많은 조직이 이 질문에 봉착한다.
구성원들은 ‘애자일 전환 교육’을 이수했고, OKR 템플릿도 만들었다.
‘데일리 스크럼’, ‘위클리 리트로스펙티브’, ‘분기별 OKR 리뷰’ 등의 단어도 익숙해졌다.
그런데도 팀의 성과는 오르지 않고,
구성원들은 여전히 주어진 업무만 처리하느라 허덕인다.
도입은 했지만, 작동은 안 된다.
왜일까?
핵심은 구조와 문화의 부조화다.
대부분의 조직은 ‘애자일’과 ‘OKR’을
기존의 수직 구조 위에 덧씌우는 방식으로 접근한다.
예를 들어 ‘스프린트 회의’를 도입하면서도
의사결정권은 여전히 팀장에게 있고,
목표는 구성원이 아닌 상위 관리자가 설정한다.
OKR을 작성하지만,
그것이 진짜 자율적인 목표가 아닌 ‘상부에서 내려온 업무지시의 다른 표현’에 불과하다.
결국 구성원들은 이렇게 말한다.
“그냥 보고서 양식이 하나 늘어난 거죠.”
“목표는 내가 세운 게 아닌데 왜 나더러 책임지라 하죠?”
“OKR 쓴다고 연봉 오르는 것도 아니잖아요?”
이처럼 애자일과 OKR이 새로운 언어는 제공하지만,
구조적 권한과 심리적 안전은 보장하지 못할 때,
그것은 구성원에게 또 다른 ‘형식적 업무’로만 받아들여진다.
두 번째 문제는 ‘속도’에 대한 착각이다.
애자일이 민첩함을 추구한다는 이유로
많은 조직이 그것을 속도 경쟁의 구호로 오해한다.
“빠르게 해!”, “일단 MVP 만들어서 시장에 던져!” 같은 말은
애자일의 철학과는 거리가 멀다.
진짜 애자일은 빠르게 움직이기 위해
무엇을 빼야 하는가,
어디서 피드백을 받을 것인가,
어떻게 실험할 것인가를 묻는
구조적 질문이다.
그러나 대부분의 조직은
이러한 구조적 고민 없이 ‘빨리 하라’는 슬로건만을 반복한다.
이런 상황에서 애자일은
‘빠르게 무너지는 실패’를 반복하게 되는 시스템일 뿐이다.
세 번째로는 성과와 책임의 연결 방식이다.
OKR은 목표(Objectives)와 핵심 결과(Key Results)를 연결해
구성원이 스스로 방향을 세우고 실행을 조정하도록 설계된 도구다.
그런데 실제 기업에서는 여전히 OKR이 성과 평가 지표로 활용된다.
구성원들은 말한다.
“실패하면 감점되니까, 낮은 목표부터 세워야죠.”
“실적 중심 KPI랑 다를 게 없잖아요?”
이렇게 되면 OKR은 몰입과 혁신을 촉진하는 도구가 아니라,
성과 관리의 또 다른 이름이 된다.
본래의 철학인 ‘도전적 목표 설정’과 ‘실패를 통한 학습’은 사라지고,
생존 전략으로서의 보수적 목표 설정이 남는다.
네 번째는 조직 문화와 연결되지 않은 구조 도입이다.
OKR과 애자일은 단순한 업무 방식이 아니라,
조직이 구성원을 신뢰하고,
자율성과 협업을 촉진하는 문화를 전제로 한다.
그런데 상사의 지시가 모든 것의 기준이 되고,
실패가 곧 평가 손실로 연결되는 조직에서는
애자일이 ‘이질적 기제’가 될 수밖에 없다.
도입은 됐지만, 문화와 충돌해 버리는 것이다.
결국, 문제는 ‘도입하지 않아서’가 아니라,
도입은 했으되 설계되지 않았기 때문이다.
목표를 세울 권한은 누구에게 있는가?
실패해도 되는가?
회의에서 진짜 의견을 말할 수 있는가?
서로의 목표와 성장을 공유할 수 있는 구조인가?
이 질문에 “그렇다”고 대답할 수 없다면,
그 조직의 애자일과 OKR은 선언에 불과하다.
문장은 있었지만, 구조는 없었다.
우리는 이제 ‘왜 실패했는가’를 성찰해야 한다.
‘우리는 애자일을 도입했다’는 말이 아니라,
‘우리는 애자일이 작동하도록 구조를 설계했다’고 말할 수 있어야 한다.
애자일(Agile)과 OKR(Objectives and Key Results)은
단순한 운영 방식이나 기법이 아니다.
그것은 일을 바라보는 관점의 전환이며,
조직이 구성원에게 부여하는 권한과 책임의 구조 설계 방식이다.
겉으로는 유사하게 보이지만,
기존의 KPI(성과지표) 시스템과는 철학의 출발선부터 다르다.
애자일은 2001년 미국 유타주 스노우버드에서
17명의 소프트웨어 전문가들이 모여 작성한
‘애자일 선언문(Manifesto)’에서 시작됐다.
그들은 기존의 워터폴(계획-설계-구현-테스트-배포) 방식이
현실의 불확실성과 너무 동떨어져 있다고 느꼈다.
그래서 선언문은 이렇게 시작한다.
“우리는 프로세스나 도구보다 개인과 상호작용을,
작동하는 소프트웨어보다 방대한 문서를,
계획을 따르기보다 변화에 대응하는 것을 더 가치 있게 여긴다.”
이 말의 핵심은 정답을 미리 정해놓고 따르라는 것이 아니라,
지금 마주한 문제에 빠르게 대응할 수 있는 역동성을 만들라는 것이다.
즉, 애자일은 ‘빠르게 하라’가 아니라,
‘빠르게 배워서 다음 선택을 바꿀 수 있도록 설계하라’는 철학이다.
실행보다는 학습, 결과보다는 과정, 통제보다는 신뢰.
이 세 가지 원칙이 애자일의 근간이다.
OKR은 Intel의 앤디 그로브(Andy Grove)가 고안하고,
이후 Google의 존 도어(John Doerr)에 의해 널리 확산됐다.
OKR은 다음 두 가지 질문에 답하게 한다.
지금 우리가 가장 집중해야 할 목표(Objective)는 무엇인가?
그 목표에 도달했음을 어떻게 측정(Key Results)할 수 있는가?
OKR의 진정한 가치는 구성원이 자기 일의 의미를 발견하고,
스스로 몰입 가능한 목표를 설계하게 만든다는 점에 있다.
OKR의 구조는 KPI보다 훨씬 도전적이며 유연하다.
KPI는 주어진 업무를 얼마나 잘 수행했는지를 묻지만,
OKR은 조직의 방향성과 구성원의 성장을 동시에 고려한다.
예를 들어 KPI가 “고객 1,000명을 유치하라”는 정량 지표라면,
OKR은 “고객에게 더 깊은 신뢰를 주는 콘텐츠 채널을 만들자”처럼
정성적이고 도전적인 목표를 설정하고,
그에 따른 핵심결과를 숫자화해 추적한다.
OKR은 무엇보다도 ‘실패를 허용’한다.
70%만 달성돼도 충분히 도전한 것이라 판단한다.
여기에는 “도전은 배움이다”라는 철학이 깔려 있다.
애자일과 OKR은 다음의 네 가지 키워드를 공유한다.
1. 자율성 – 상사가 정한 것이 아니라, 구성원이 참여해 만든 목표여야 한다.
2. 투명성 – 목표와 실행이 조직 안에서 공개되고 공유되어야 한다.
3. 정렬 – 팀과 개인의 목표가 조직의 전략과 연결되어야 한다.
4. 학습 중심 – 실패가 벌점이 아니라, 다음 실험을 위한 피드백이 되어야 한다.
결국 두 방식 모두,
“몰입은 설계되는 것이다”라는 전제를 바탕으로 한다.
즉, 단지 방법론을 도입하는 것이 아니라,
그 방법이 작동할 수 있도록 권한과 책임, 협업과 피드백의 흐름을
구조적으로 설계하는 것이 핵심이다.
요소 전통적 방식 애자일 / OKR
권한 상위 관리자 중심 팀과 구성원에게 분산
목표 설정 연간 계획 수립 후 고정 주기적 조정, 짧은 사이클
평가 기준 실적 중심 정량 평가 학습 중심 정성 평가 포함
실패 인식 책임 추궁 실험과 피드백 기회
애자일과 OKR을 단순히 ‘도구’로 보면 실패한다.
그것은 문화이자, 구조다.
그리고 그 구조는 신뢰를 전제로 설계되어야만 작동한다.
애자일과 OKR은 표면적으로 ‘일하는 방식’처럼 보인다.
하지만 실제로는 조직 구조와 문화 전반에 영향을 주는 운영 철학이자 경영 전략이다.
성공적으로 이를 구현한 기업들은 몇 가지 공통된 구조를 갖추고 있었다.
그들은 단지 선언에 머무르지 않고, 실행 가능한 구조를 설계해냈다.
구글은 OKR을 전사적으로 가장 잘 구현한 조직으로 손꼽힌다.
이들은 단지 OKR을 ‘목표 관리 도구’로 사용한 것이 아니라,
구성원 모두가 목표를 중심으로 협업할 수 있는 환경을 만든 것이 특징이다.
모든 조직과 팀의 OKR은 내부 시스템에서 전사적으로 공개된다.
구성원은 상향식(Bottom-up)으로 OKR을 제안하고 상사와 정렬한다.
OKR 달성률은 평가에 직접 반영되지 않으며, 도전적 목표 설정을 유도한다.
구글에서 가장 유명한 OKR 사례 중 하나는 ‘Chrome 브라우저 1억 사용자 확보’다.
이 목표는 당시로선 무모해 보였지만,
분기별로 집중 목표를 정하고, 각 부서가 연동하며 달성해냈다.
핵심은 ‘숫자’보다 집중과 정렬의 힘이었다.
이러한 구조 덕분에 구글은 혁신을 조직 내부로 끌어들이고,
반복 가능한 성공 방식을 구축했다.
OKR은 단지 도구가 아니라, 협업의 뼈대가 되는 구조였다.
네덜란드 ING은행은 전통적인 금융기업임에도 불구하고
전사적으로 애자일을 도입한 대표 사례다.
2015년, 그들은 조직을 ‘스쿼드(Squad)’라는 소규모 자율 팀으로 개편했다.
이는 Spotify의 애자일 모델에서 영향을 받았다.
각 스쿼드는 특정 고객 문제를 해결하는 ‘작은 스타트업’처럼 운영되었다.
관리자는 ‘프로덕트 오너’ 혹은 ‘애자일 코치’로 전환되었다.
기능 중심 조직이 아닌, 문제 해결 중심의 크로스펑셔널 팀이 구성되었다.
가장 큰 변화는 ‘보고 체계’였다.
기존에는 상하 구조였지만,
애자일 전환 후 수평적인 커뮤니케이션이 가능해졌다.
“계획을 따르라”는 말 대신,
“문제를 정의하고 실험하라”는 원칙이 조직 전반을 관통했다.
결과적으로 ING는 빠르게 디지털 서비스 전환에 성공했고,
유럽 금융업계의 디지털 트랜스포메이션 리더로 자리잡았다.
국내에서도 OKR을 도입한 성공 사례가 있다.
특히 쿠팡은 빠른 실행과 고객 중심을 강점으로 삼아
OKR 시스템을 각 팀 단위까지 확대 적용했다.
팀마다 분기별 OKR을 설정하며, 전사적으로 정렬된 전략과 연결되도록 한다.
문제 해결형 목표(예: ‘반품 고객 CS 접점 감소’)를 중심으로 설정한다.
OKR 달성률보다는 문제 해결을 위한 시도와 데이터 기반 실험을 중시한다.
이러한 구조는 ‘빠르게 실패하고, 빠르게 개선하는 조직’을 만들었다.
구성원들은 실패에 대한 두려움보다, 실험에 대한 책임감을 가지게 되었다.
실패의 원인을 정리하고 공유하는 문화는,
다시 다음 분기의 OKR 수립에 반영된다.
결국 OKR은 ‘책임’이 아닌 ‘성장’을 위한 구조로 작동하게 된 것이다.
성공적으로 애자일과 OKR을 작동시킨 조직들은 공통적으로 다음의 4가지 구조를 갖추고 있었다.
설계 원칙 설명
1. 정보의 투명성 누구나 목표를 공유하고, 진행 상황을 확인할 수 있는 시스템
2. 자율성 기반 팀 구조 상사가 명령하지 않아도 스스로 일의 흐름을 설정할 수 있는 구조
3. 학습 피드백 루프 실행 결과에 대한 리뷰와 개선이 반복되는 순환 시스템
4. 전략 정렬 OKR과 애자일 팀이 조직 전략과 긴밀히 연결되어 있는 구조
이 네 가지는 선언만으로는 절대 만들어지지 않는다.
시스템과 리더십, 문화, 운영 방식이 함께 맞물려야 작동한다.
결국 애자일과 OKR은 단편적인 변화가 아니라, 설계의 전환이다.
‘어떻게 목표를 세울 것인가’에서 끝나지 않고,
‘그 목표가 구성원에게 어떻게 의미가 되는가’를 함께 설계하는 것이다.
많은 조직이 애자일과 OKR을 도입하며 회의를 열고,
내부 보고서에 문장을 남기고,
임직원 교육을 진행한다.
하지만 그것만으로는 작동하지 않는다.
작동은 선언이 아닌 ‘운영 구조’의 설계에서 시작된다.
성공한 조직들은 이를 단지 방법론이 아닌 시스템으로 받아들였고,
그 시스템은 아래와 같은 전략적 설계에 기반한다.
OKR의 핵심은 Output이 아닌 Outcome이다.
'우리는 무엇을 했는가?'가 아니라
'그 일이 어떤 결과를 만들었는가?'에 초점을 둬야 한다.
그러나 대부분의 조직에서는
여전히 “보고 가능한 결과물”만을 목표로 삼는다.
예를 들어 "보고서 10건 작성", "캠페인 3건 집행" 같은 것이다.
반면 Outcome 중심 OKR은 다음과 같은 질문으로부터 시작된다.
고객이나 사용자에게 어떤 변화를 일으키고 싶은가?
이 변화는 조직의 전략적 방향성과 어떻게 연결되는가?
이를 위해 핵심적으로 집중할 수 있는 가시적인 행동은 무엇인가?
이를 위해 기업은 OKR 수립 단계부터 다음 3단계의 구조를 설계해야 한다.
1. 문제 정의
: OKR은 문제 정의에서 출발해야 한다. 현재 조직이 해결해야 할 핵심 문제는 무엇인가?
2. 성과 지표 도출
: 단순 수치 목표가 아니라, 고객 경험·업무 효율·팀 몰입도 등 질적 지표를 포함한다.
3. 연동 구조 설계
: 전사 OKR → 조직별 OKR → 개인 OKR의 흐름이 ‘기계적인 수직 계열’이 아니라 ‘전략의 수평 정렬’로 구성되어야 한다.
Outcome 중심 OKR은 구성원에게 목표에 대한 ‘의미 있는 몰입’을 가능하게 하며,
일을 위한 일이 아니라 ‘가치 창출의 흐름’ 속에 자신을 위치시키게 만든다.
애자일과 OKR이 선언으로 끝나는 가장 큰 이유는 ‘실행의 리듬’이 없기 때문이다.
아무리 좋은 OKR을 세워도, 분기 말까지 손도 대지 않으면 의미가 없다.
반면 성공적인 조직은 분기·월·주 단위로 ‘점검 리듬(cadence)’을 구조화한다.
예를 들어 다음과 같은 흐름이 있다:
분기 시작: OKR 수립 및 공개 (팀 및 개인 OKR 확정)
주간 단위: 15분 ‘위클리 체크인 미팅’으로 진행률 확인, 장애 요소 점검
월간 단위: 월간 리뷰 미팅을 통해 방향 수정 및 성과 교차 검토
분기 말: 리플렉션(회고) + 다음 분기 OKR 설계
특히 리더의 참여는 필수다.
위클리 미팅이 형식이 되지 않기 위해선,
팀 리더가 OKR을 '성과 요구서'가 아니라 ‘지원의 기준’으로 다뤄야 한다.
즉, “왜 안 했냐”가 아니라
“이걸 하기 어려운 조건은 무엇이었나?”를 묻는 리더십이 필요하다.
애자일을 조직 전반에 정착시키려면,
애자일 방식이 하나의 프로젝트 수행법이 아닌, 일하는 기본 단위가 되어야 한다.
그 핵심은 ‘스쿼드(Squad)’ 기반의 팀 구조다.
이는 전통적인 부서 중심이 아니라, 문제 중심의 소규모 자율 팀으로 구성된다.
각 스쿼드는 명확한 고객 대상 혹은 문제를 설정하고,
크로스펑셔널(Cross-functional)하게 구성원들이 배치된다.
책임과 권한을 가지고 의사결정과 실험을 반복하며 개선한다.
이러한 구조는 업무의 흐름에 맞게 팀을 설계하는 방식이며,
기존처럼 ‘정해진 틀 안에 사람을 넣는’ 방식과는 다르다.
특히 한국 조직에서는 애자일을 도입해도
기존 보고 체계와 의사결정 방식이 바뀌지 않아 실패하는 경우가 많다.
“애자일하게 일하되, 결재는 사장님이”라는 구조로는 애자일은 작동하지 않는다.
애자일의 핵심은 ‘회고(Retrospective)’다.
회고 없는 애자일은 단지 조금 빠른 속도의 일 분배 방식일 뿐이다.
따라서 OKR을 포함한 모든 활동의 마지막에는 다음 질문이 필수다.
이번 목표에서 우리가 잘한 점은 무엇인가?
가장 큰 장애물은 무엇이었고, 이를 다음에는 어떻게 개선할 수 있을까?
개인의 몰입이나 학습은 어떻게 이뤄졌는가?
이 회고는 단지 ‘미팅’이 아니라 조직이 학습하는 존재가 되기 위한 구조다.
회고가 반복되면 구성원들은 OKR을 더 정교하게 설계하고,
더 실현 가능하게 계획하며,
몰입도를 스스로 높여간다.
리더는 회고의 분위기를 조율하는 ‘퍼실리테이터’ 역할을 해야 하며,
실패가 비난이 아닌 학습의 자산으로 전환되는 문화를 만들어야 한다.
많은 조직이 애자일과 OKR을 ‘좋은 철학’ 혹은 ‘일 잘하는 문화’로 인식한다.
그리고 그 철학이 자율성과 혁신, 몰입을 가져올 것이라 믿는다.
그러나 현장에서 우리가 목격하는 대부분의 실패는,
철학이 없어서가 아니라 철학을 작동시킬 ‘구조’가 없기 때문에 발생한다.
애자일과 OKR은 결코 ‘좋은 말’이 아니다.
그것은 ‘일의 구조’를 설계하는 구체적인 방식이다.
다시 말해, 실행 가능한 운영 시스템이다.
그리고 이 시스템은 다음과 같은 원리를 기반으로 작동한다:
의미 있는 목표의 분해 구조 (Outcome 중심 OKR)
반복적 실행과 점검의 리듬 (Weekly/Midterm Cadence)
작은 단위의 자율성과 책임 (Squad 중심 애자일 팀)
실패로부터 학습하는 구조 (Retrospective 문화)
즉, 애자일과 OKR은 철학 이전에 일하는 방식을 다시 짜는 설계 도구이며,
이 도구는 선언으로는 작동하지 않는다.
OKR 수립을 워크숍 하루로 끝내고,
애자일을 조직 슬로건으로만 두는 순간 그것은 실패로 이어진다.
우리가 강조해야 할 것은 ‘일 잘하자’가 아니다.
우리가 설계해야 할 것은 ‘일이 잘 되게 만드는 구조’다.
우리 조직은 OKR을 수립했는가, 아니면 복붙했는가?
주간·월간·분기 단위의 실행 리듬은 작동하고 있는가?
애자일 팀에 진짜 자율과 책임이 주어져 있는가?
실패와 회고는 학습 자산으로 축적되고 있는가?
이 질문에 ‘예’라고 대답할 수 없다면,
애자일도, OKR도,
모두 이름만 존재하는 시스템이다.
OKR과 애자일이 주는 메시지는 명확하다.
‘일을 잘하려면 사람을 탓하지 말고, 구조를 설계하라’는 것.
탁월한 사람을 영입해도, 일의 구조가 설계되지 않으면 그들은 곧 지쳐 떠난다.
반대로 아직 성숙하지 않은 구성원이라도,
구조가 뒷받침되면 빠르게 성장하고, 몰입하며, 성과를 만들어낸다.
결국, 애자일과 OKR이 우리 조직에 주는 진짜 교훈은 이것이다.
“탁월함은 철학이 아니라 시스템으로 만들어진다.”
선언을 멈추고 구조를 설계할 때,
조직은 비로소 ‘몰입의 리듬’을 갖게 된다.
그리고 그 리듬 위에서,
사람은 성장하고, 팀은 성과를 내며, 조직은 변화한다.