R&D와 현업의 괴리, 원인과 통합

1. 경영진 요약

소프트웨어 연구개발(R&D) 부서와 전통적인 현업 부서 간의 소통 단절은 단순한 커뮤니케이션의 문제가 아닙니다. 이는 근본적으로 다른 두 운영 모델 간의 시스템적 충돌이며, 기업의 가치를 파괴하는 ‘사일로 효과(Silo Effect)’로 귀결됩니다. 본 보고서는 애자일(Agile)과 전통적 업무 철학의 충돌을 분석하고, 조직 사일로의 해부학적 구조를 해체하며, 이것이 혁신과 효율성에 미치는 파괴적인 영향을 규명함으로써 이 갈등을 심층적으로 분석합니다.

핵심 분석 결과에 따르면, 이러한 괴리는 서로 다른 시간 개념(스프린트 vs. 회계연도), 성과 측정 기준(팀 목표 vs. 개인 업적), 그리고 의사결정 방식(분산형 vs. 중앙집권형)에서 비롯됩니다. 이러한 근본적인 차이는 오해와 불신을 낳고, 결국에는 중복 투자, 프로젝트 실패, 시장 기회 상실이라는 값비싼 대가로 이어집니다.

이에 본 보고서는 통합을 위한 다층적 프레임워크를 제시합니다. 여기에는 교차기능팀(Cross-functional Team)을 통한 구조적 재설계, 공유 목표 설정 및 상호 교육을 통한 문화적 개입, 데브옵스(DevOps) 및 디자인 씽킹(Design Thinking)과 같은 방법론적 도입, 그리고 프로덕트 매니저(PM)와 같은 핵심적인 ‘인적 가교(human bridge)’ 역할의 육성이 포함됩니다. 토스(Toss)와 DBS 은행과 같은 선구적인 기업들의 사례 연구는 성공적인 조직 전환을 위한 검증된 로드맵을 제공하며, 본 보고서가 제시하는 전략적 권고의 실효성을 뒷받침합니다.

2. 거대한 단절: 조직 내 소통의 심연과 사일로 효과

2.1 현상 정의: 단순한 소통 부재를 넘어

소프트웨어 R&D 부서와 현업 부서 간의 문제는 단순히 회의나 이메일이 부족해서 발생하는 피상적인 현상이 아닙니다. 이는 R&D라는 ‘엔진실’과 비즈니스라는 ‘최전선 사무실’ 사이에 존재하는 양립 불가능한 목표, 언어, 그리고 업무 리듬에서 비롯된 깊은 ‘괴리(chasm)’입니다. 표면적으로 드러나는 소통의 단절은 이 근본적인 조직적 분열의 한 증상에 불과합니다.1

이러한 괴리가 조직적으로 발현된 형태가 바로 ‘사일로 효과(Silo Effect)’입니다. 사일로 효과는 각 부서가 독립된 왕국처럼 기능하며, 조직 전체의 미션보다는 국지적인 목표 최적화를 위해 정보를 독점하고 외부와의 소통을 차단하는 상태를 의미합니다.2 일본에서 이를 문어를 잡는 항아리인 ‘다코추보(takotsubo)’에 비유하는 것은 매우 적절한 통찰을 제공합니다.5 문어가 안락함을 느끼며 들어간 항아리에서 빠져나오지 못하는 것처럼, 부서 구성원들은 자신들의 사일로 안에서 안주하며 외부와의 연결을 끊고, 이는 결국 조직 전체의 비효율을 초래하는 탈출하기 어려운 함정이 됩니다.

2.2 사일로 효과의 병리학: 조직을 잠식하는 만성 질병

사일로는 조직을 서서히 병들게 하는 만성 질환과 같습니다. 그 부정적 영향은 연쇄적으로 발생하며 조직 전체를 잠식합니다.

• 신뢰 잠식과 영역 다툼: 사일로는 ‘우리’와 ‘그들’이라는 이분법적 사고를 조장하여 부서 간 상호 불신과 내부 영역 다툼을 야기합니다.2 각 부서는 자신의 영역을 보호하는 데 급급하며, 협력보다는 경쟁을 우선시하게 됩니다.

• 운영 비효율성과 업무 중복: 정보 공유의 부재는 필연적으로 업무 중복과 자원 낭비로 이어집니다.3 예를 들어, 마케팅 부서와 영업 부서가 동일한 고객 데이터를 개별적으로 수집하고 관리하는 경우가 흔하게 발생하며, 이는 데이터 관리 비용을 증가시키고 정보의 일관성을 해치는 결과를 낳습니다.6

• 혁신 저해와 기회 상실: 획기적인 혁신은 서로 다른 아이디어가 교차하고 융합될 때 탄생합니다. 사일로 환경에서는 이러한 아이디어의 교차 수분이 원천적으로 차단되어 혁신이 억제됩니다.3 조직은 여러 기능의 교차점에서 발생하는 새로운 사업 기회를 인지하지 못하고 지나치게 됩니다.

• 고객 경험 저하: 총체적인 고객 경험을 제공하는 데 필수적인 정보들이 마케팅, 영업, 개발, 고객 지원 등 각 부서의 사일로에 파편화되어 갇히게 됩니다. 이는 고객에게 일관성 없고 단절된 경험을 제공하게 되며, 결국 고객 만족도에 막대한 악영향을 미칩니다.2

이러한 사일로는 정적인 상태가 아니라, 시간이 지남에 따라 스스로를 강화하는 역동적인 악순환의 고리를 형성합니다. 조직이 기능별로 구조화되고 3, 각 기능이 개별 KPI로 평가받는 상황에서 시작됩니다. 부서들은 이 KPI를 달성하기 위해 자원을 경쟁적으로 확보하고 정보를 권력의 원천으로 간주하여 독점하려 합니다.4 이러한 투명성 부족은 불신과 소통 실패를 낳고 2, 실패가 발생하면 리더십은 기존 구조 내에서 통제를 강화하려는 경향을 보입니다. 이는 결국 사일로의 벽을 더욱 견고하게 만들어, 다음 순환 주기를 더 강한 강도로 재시작하게 만듭니다.

2.3 Case in Point: 소니(Sony)의 몰락 - 사일로가 파괴한 기술 제국

사일로가 기업에 미치는 파괴적인 영향을 가장 극적으로 보여주는 사례는 기술 제국 소니(Sony)의 몰락 과정에서 찾을 수 있습니다. 1994년, 소니는 내부 경쟁을 통해 조직의 경쟁력을 높이려는 의도로 ‘독립채산제’를 도입했습니다.8 이 제도는 각 사업부가 독립적으로 손익을 책임지게 하는 구조였습니다.

그러나 당초의 의도와 달리, 이 제도는 각 사업부가 그룹 전체의 협력보다는 자신들의 이윤 극대화에만 몰두하게 만드는 치명적인 부작용을 낳았습니다. 기술 공유는 더 이상 혁신을 위한 협력이 아니라, 경쟁 사업부를 이롭게 하는 어리석은 행동으로 치부되었습니다. 핵심 기술과 혁신적인 아이디어들이 각 사업부의 사일로 안에 갇히면서, 시너지를 창출할 수 있는 제품 개발이 불가능해졌습니다. 예를 들어, 워크맨으로 아날로그 음악 시장을 제패했던 소니가 디지털 시대의 MP3 플레이어 시장에서 애플의 아이팟에 완패한 것은, 소니 내부에 음악, 전자, 콘텐츠 사업부 간의 협력이 완전히 단절되었기 때문입니다. 이처럼 사일로는 소니의 전반적인 기술 경쟁력 퇴보를 초래한 핵심 원인이었습니다.8

이러한 위험은 비단 기술 기업에만 국한되지 않습니다. 금융 기업 UBS는 1,000명 이상의 리스크 관리자를 보유하며 모범적인 리스크 관리 체계를 갖췄다고 평가받았지만, 부서 간 정보 단절로 인해 미국 주택 시장의 위험 신호를 종합적으로 판단하지 못했고, 결국 불량 모기지 투자로 막대한 손실을 기록했습니다.9 이는 사일로가 심각한 재무적 재앙으로 이어질 수 있음을 명확히 보여줍니다. 소니의 사례는 조직 내부의 심각한 분열이 종종 기업 전체를 아우르는 통일된 비전의 부재에서 비롯된다는 점을 시사합니다. 리더십이 조직 전체를 위한 강력한 ‘북극성’을 제시하고 이를 일관되게 추진하지 못할 때, 각 부서는 자연스럽게 자신들의 더 좁고 측정하기 쉬운 목표에 매몰됩니다. 즉, 사일로는 전략적 리더십의 공백이 만들어낸 결과물인 셈입니다.

3. 충돌의 해부학: R&D와 현업, 두 세계의 근본적 차이

3.1 운영 철학의 대립: 애자일의 유연성 vs. 전통적 프로세스의 안정성

R&D 부서와 현업 부서 간의 갈등은 그 뿌리에 서로 다른 운영 철학이 자리 잡고 있습니다. 특히 소프트웨어 R&D 조직은 변화하는 시장과 고객 요구에 신속하게 대응하기 위해 적응성, 고객과의 협업, 그리고 반복적이고 점진적인 개발을 중시하는 애자일(Agile) 원칙을 핵심으로 삼습니다.10

반면, 재무, 인사, 법무와 같은 전통적인 현업 부서들은 예측 가능성, 철저한 사전 계획, 그리고 엄격한 통제를 통한 리스크 최소화를 강조하는 선형적 프로세스, 즉 폭포수(Waterfall) 모델에 의존하는 경우가 많습니다.12 이 두 모델이 하나의 프로젝트 안에서 상호작용해야 할 때, 근본적인 충돌이 발생합니다.12

이러한 철학의 차이는 구성원을 바라보는 관점에서도 극명하게 드러납니다. 애자일은 구성원 개개인이 자율성을 부여받았을 때 잠재력을 극대화할 수 있는 열정적인 존재라고 가정합니다.10 반면, 전통적인 경영 방식은 하급 직원은 엄격한 통제와 관리가 필요하다는 관념에 기반을 두는 경우가 많습니다.10 이처럼 사람을 보는 시각부터 다르기 때문에, 두 조직의 협업은 시작부터 삐걱거릴 수밖에 없습니다.

3.2 시간과 주기의 불일치: ’스프린트’와 ’회계연도’의 충돌

두 세계의 시간은 서로 다른 속도로 흐릅니다. R&D 부서는 보통 2주에서 4주 단위의 짧고 반복적인 개발 주기인 ‘스프린트(Sprint)’를 기준으로 일합니다. 각 스프린트가 끝날 때마다 결과물을 점검하고, 피드백을 반영하여 다음 계획을 수정하는 빠른 학습 사이클을 가집니다.11

그러나 현업 부서의 운영은 연간 또는 분기 단위의 예산 수립, 사업 계획, 그리고 성과 평가 주기에 맞춰져 있습니다.11 여기서 엄청난 마찰이 발생합니다. 2주마다 계획을 수정하는 팀이 1년에 한 번 수립된 예산안에 어떻게 맞춰나갈 수 있을까요? 역동적인 애자일 팀의 기여도를 연말에 한 번 실시하는 성과 평가로 어떻게 공정하게 측정할 수 있을까요? 이처럼 서로 다른 시간적 주기의 불일치는 두 부서 간의 협력을 구조적으로 어렵게 만드는 핵심 요인입니다.

3.3 성과와 보상의 괴리: ‘팀의 성공’ vs. ‘개인의 업적’

성과를 관리하고 보상하는 방식의 차이는 협업을 가로막는 또 다른 거대한 장벽입니다. 애자일 조직은 팀의 성공과 공동 목표 달성을 무엇보다 중요하게 생각합니다.11 평가는 특정 관리자에 의해 독점되지 않고, 동료 평가를 포함한 다면적이고 지속적인 피드백 형태로 이루어집니다.11

반면, 전통적인 조직은 개인의 성과에 초점을 맞추고, 구성원들을 서로 비교하여 순위를 매기며, 개인의 업적에 따라 보상을 차등 지급하는 경향이 강합니다. 이러한 시스템은 다른 부서나 팀을 돕는 행위가 자신의 개인 KPI에 직접적인 도움이 되지 않는 한, 부서 간 협력을 적극적으로 저해하는 결과를 낳습니다.11 ‘묻어가는’ 것을 방지하고 책임 소재를 명확히 하려는 전통적 평가 방식의 의도가, 역설적으로는 조직 전체의 시너지를 막는 족쇄가 되는 것입니다.

이러한 충돌은 단순히 두 부서의 성격 차이가 아니라, 마치 서로 다른 운영체제(OS)가 충돌하는 것과 같습니다. 애자일 R&D 부서는 빠르고 유연하며 네트워크화된 OS 위에서 구동되는 반면, 나머지 조직은 안정적이지만 계층적이고 일괄 처리 방식의 레거시 OS를 사용하고 있습니다. 이 두 시스템이 데이터를 교환(협업)하려고 할 때, 프로토콜이 맞지 않아 시스템 충돌(프로젝트 실패)이 발생하는 것은 당연한 결과입니다. 기업이 R&D 부서에만 애자일 방법론을 도입할 때, 의도치 않게 조직 내부에 ‘디지털 격차(digital divide)’를 만들어내는 셈입니다. R&D 팀은 점점 더 빨라지고 데이터 기반으로 움직이는 반면, 다른 부서들은 과거의 느린 패러다임에 갇혀 있게 됩니다. 이 속도와 민첩성의 격차는 조직 내 마찰과 좌절의 주된 원천이 되며, R&D 팀은 고립감과 오해를 느끼게 될 수 있습니다.1

3.4 운영 패러다임 비교: R&D 부서 vs. 전통적 현업 부서

아래 표는 R&D 부서와 전통적 현업 부서 간의 운영 패러다임 차이를 명확하게 요약하여 보여줍니다. 이 시각적 비교는 두 세계 간의 근본적인 충돌 지점을 한눈에 파악하고, 문제 해결을 위한 공통의 언어를 마련하는 데 도움을 줄 것입니다.

4. 연결의 재설계: 구조적·문화적 통합 전략

4.1 리더십의 책무: 통합된 비전과 공동 목표 설정

사일로 문제 해결의 여정은 반드시 최고 경영진에서 시작되어야 합니다. 사일로의 근본 원인은 종종 경영진이 회사 전체를 아우르는 단일하고 통일된 비전을 수립하고, 이를 조직 전체에 일관되게 전파하는 데 실패했기 때문입니다.2 리더는 단순히 구호를 외치는 것을 넘어, 협력적인 행동을 구체적으로 장려하고 보상하는 문화를 적극적으로 조성해야 합니다.

이를 위해 모든 부서가 각자의 개별 KPI가 아닌, 조직 전체의 공유된 목표에 대해 공동으로 책임지도록 성과 측정 시스템을 재설계해야 합니다.14 리더십은 토론이 장려되는 문화를 조성하고, 일단 결정이 내려지면 모든 경영진이 한목소리로 조직 공동의 목표를 향해 나아가는 모습을 보여줌으로써 강력한 통합의 메시지를 전달해야 합니다.2

4.2 조직 구조의 혁신: 교차기능팀(Cross-functional Team)의 힘

사일로에 맞서는 가장 강력한 구조적 무기는 교차기능팀(Cross-functional Team)입니다. 교차기능팀은 엔지니어링, 마케팅, 재무, 디자인 등 다양한 기능 부서의 전문가들을 하나의 팀으로 모아 특정 프로젝트나 제품에 전념하게 하는 방식입니다.3

이러한 구조는 그 자체로 협업을 강제하는 효과가 있습니다. 팀원들은 더 이상 자신의 부서장에게만 보고하는 것이 아니라, 팀 공동의 목표 달성을 위해 서로에게 의존해야 합니다. 이는 자연스럽게 부서 간의 벽을 허물고, 의사소통을 증진시키며, 업무 전달 과정에서 발생하는 지연과 맥락의 단절을 줄여줍니다.2 또한, 팀 전체가 고객의 문제를 처음부터 끝까지 책임지는 총체적이고 고객 중심적인 관점을 갖게 합니다. 성공적인 혁신 프로젝트의 성공률이 전통적인 방식에 비해 월등히 높은 이유도 바로 이러한 구조적 힘에 있습니다.17

문화적 개선 노력도 중요하지만, 지속 가능한 문화 변화는 조직 구조의 변화를 통해 가장 효과적으로 이루어질 수 있습니다. 교차기능팀 구조는 협업을 강제하고, 이러한 강제된 상호작용이 시간이 지나면서 자연스러운 협업 문화를 구축하게 됩니다. 단순히 협업하라고 말하는 것만으로는, 여전히 사일로 구조와 개별 KPI로 평가받는 직원들의 행동을 근본적으로 바꿀 수 없습니다. 구조적 변화야말로 문화 변혁을 이끄는 가장 강력하고 지속적인 동력입니다.

4.3 문화적 장벽 허물기: 상호 이해와 공감대 형성

구조적 변화는 문화적 개입이 동반될 때 비로소 완성됩니다. 부서 간의 공감대와 상호 이해를 증진시키기 위한 구체적인 방법들은 다음과 같습니다.

• 부서 간 교육 세션: 정기적으로 각 부서가 자신의 업무 프로세스, 당면 과제, 사용하는 용어, 그리고 목표를 다른 부서원들에게 설명하는 교육 세션을 마련합니다. 이는 서로의 업무에 대한 이해를 높여 불필요한 오해를 줄이는 데 큰 도움이 됩니다.2

• 해커톤(Hackathons): 전사적인 차원에서 다양한 부서의 직원들이 팀을 이루어 제한된 시간 내에 특정 문제를 해결하는 해커톤 이벤트를 개최합니다. 이는 공식적인 직급이나 부서의 경계를 허물고, 창의적인 문제 해결 과정에서 새로운 관계를 형성하며 사일로적 사고방식에서 벗어나는 계기를 제공합니다.2

• 직무 순환 및 섀도잉(Job Shadowing): 직원들이 일정 기간 다른 부서에서 근무하거나, 다른 부서의 업무를 가까이에서 관찰할 수 있는 기회를 제공합니다. 이는 동료의 업무에 대한 직접적인 경험과 깊은 이해를 통해 공감대를 형성하는 효과적인 방법입니다.18

4.4 Case in Point: 토스(Toss)의 급진적 투명성과 ‘사일로 파괴’ 문화

금융 플랫폼 토스(Toss)는 사일로 방지를 위한 조직 문화 설계에 있어 매우 급진적인 접근 방식을 보여줍니다. 토스 문화의 핵심 원칙은 높은 인재 밀도, 정보와 자원에 대한 평등한 접근성, 그리고 과감하고 솔직한 피드백 문화에 있습니다.19

특히 주목할 점은 역설적인 이름의 ‘인터널 사일로(Internal Silo)’ 팀의 존재입니다. 이 팀은 20명 이상의 개발자로 구성되어 있으며, 그들의 유일한 임무는 모든 직원이 사내의 어떤 정보든 단 세 번의 클릭만으로 접근할 수 있도록 보장하는 것입니다.19 이는 정보의 자유로운 흐름을 보장하기 위해 막대한 자원을 의도적으로 투자하는 것으로, 정보를 독점하려는 사일로의 속성에 정면으로 반하는 강력한 제도적 장치입니다.

토스의 접근 방식은 정보가 지식 경제 시대의 핵심 경쟁 우위이며, 마치 전기나 수도처럼 안정적으로 공급되어야 할 핵심 유틸리티라는 깊은 이해를 보여줍니다. 대부분의 기업이 정보의 흐름을 개인의 의지나 우연에 맡겨두는 반면, 토스는 정보의 ‘공급망(supply chain)’을 관리하기 위한 전담 인프라 팀을 운영함으로써 조직 내 정보의 속도와 접근성을 극대화하고 있습니다.

이 외에도 직원들이 업무 외적인 잡무에 신경 쓰지 않고 온전히 업무에만 몰입할 수 있도록 돕는 ‘두 에브리띵 사일로(Do Everything Silo)’라는 컨시어지 서비스 20나, ‘원팀 컬처(One-team Culture)’를 끊임없이 강조하는 노력 19 등은 모두 민첩성과 협업을 극대화하기 위해 정교하게 설계된 전체 시스템의 일부입니다.

5. 협업의 프레임워크: 통합을 가속하는 방법론

5.1 데브옵스(DevOps) 문화: 개발과 운영을 넘어 비즈니스까지

데브옵스(DevOps)는 단순히 자동화 도구의 집합이 아니라, 협업, 공유된 주인의식, 그리고 자동화라는 애자일 원칙을 전체 가치 흐름으로 확장하는 문화적 철학입니다.21 전통적으로 ‘변화를 추구하는’ 개발(Dev) 부서와 ‘안정을 추구하는’ 운영(Ops) 부서 사이에 존재했던 거대한 장벽을 허무는 것을 목표로 합니다.

데브옵스는 평균 복구 시간(Mean Time to Recovery, MTTR)과 같은 공유된 목표를 설정하고, 개발부터 운영까지 서비스의 전체 수명 주기에 대한 공동의 책임을 부여함으로써 두 팀의 협력을 유도합니다.21 실패가 발생했을 때 개인을 비난하기보다는 시스템과 프로세스를 개선할 기회로 삼는 ‘비난 없는 회고(Blameless Postmortem)’ 문화는 심리적 안정감을 제공하여 투명한 소통과 빠른 학습을 가능하게 합니다.22

최근에는 이러한 협업 모델이 비즈니스 이해관계자까지 포함하는 **비즈데브옵스(BizDevOps)**로 진화하고 있습니다. 이는 개발과 운영 활동이 항상 비즈니스 목표와 긴밀하게 연계되도록 보장하여, 기술적 노력이 실질적인 사업 성과로 이어지게 만듭니다.24

5.2 디자인 씽킹(Design Thinking): 고객을 중심으로 모두를 연결하다

디자인 씽킹(Design Thinking)은 다양한 배경을 가진 팀들이 공통의 언어로 소통하고 협업할 수 있도록 돕는 강력한 인간 중심의 문제 해결 방법론입니다.25

디자인 씽킹의 핵심 프로세스인 **공감(Empathize) → 정의(Define) → 아이디어화(Ideate) → 프로토타입(Prototype) → 테스트(Test)**는 기술, 비즈니스, 디자인 등 서로 다른 부서의 팀원들이 프로젝트 초기 단계부터 고객의 니즈에 대한 공유된 이해를 바탕으로 협력하도록 구조적으로 강제합니다.26 특히 ‘공감’ 단계에서 엔지니어와 마케터가 함께 고객 인터뷰를 진행하고 그들의 고충을 직접 듣는 경험은, 이후의 모든 의사결정 과정에서 ‘고객’이라는 흔들리지 않는 기준점을 제공합니다. 이는 R&D 부서가 시장의 요구와 동떨어진 제품을 만드는 흔한 실패를 예방하는 효과적인 장치입니다.

5.3 스포티파이(Spotify) 모델: 자율성과 연합의 균형

세계 최대 음원 스트리밍 서비스인 스포티파이(Spotify)의 조직 모델은 ‘느슨하게 연결되지만, 강하게 정렬된(loosely coupled, tightly aligned)’ 조직을 지향하며, 자율성과 협업의 균형을 맞추는 데 탁월한 구조를 제시합니다.

• 스쿼드(Squads): 특정 제품 영역에 대한 장기적인 미션을 가진, 작고 자율적인 교차기능팀입니다. 이들은 제품 개발의 기본 단위이며, ‘무엇을’ 만들고 ‘어떻게’ 만들지에 대한 완전한 권한을 가집니다.18

• 챕터(Chapters): 하나의 트라이브 내에 소속된, 유사한 기술이나 역량을 가진 전문가들의 그룹입니다 (예: 백엔드 엔지니어 챕터). 챕터 리더는 소속된 엔지니어들의 기술 표준, 역량 개발, 지식 공유를 책임지며, 기술적 사일로가 발생하는 것을 방지하고 전문가로서의 성장을 지원합니다.18

• 트라이브(Tribes): 연관된 미션을 수행하는 여러 스쿼드들의 집합체입니다. 하나의 작은 스타트업처럼 기능하며, 스쿼드 간의 시너지를 창출하는 역할을 합니다.18

• 길드(Guilds): 부서나 직무에 상관없이, 특정 주제에 대한 관심사를 공유하는 사람들의 비공식적인 커뮤니티입니다 (예: ‘데이터 시각화 길드’). 길드는 조직 전체에 걸쳐 지식과 열정을 전파하는 통로가 됩니다.18

데브옵스, 디자인 씽킹, 스포티파이 모델과 같은 방법론들은 단순히 더 나은 프로세스를 제공하는 것을 넘어, 사일로 조직에 결여된 상호작용을 구조적으로 강제하는 ‘협업 엔진’ 역할을 합니다. 이들은 서로 다른 관점들이 필연적으로 ‘충돌’하고 융합될 수밖에 없는 구조화된 장을 마련해 줍니다. 특히 스포티파이 모델은 Part II에서 제기된 ‘운영체제 비호환성’ 문제에 대한 정교한 해법을 제시합니다. 스쿼드는 빠르고 민첩한 프로젝트 중심의 OS 역할을 하고, 챕터는 안정적이고 표준 중심의 기능적 OS 역할을 합니다. 직원들은 이 두 시스템에 동시에 속함으로써, 조직이 고속의 실행력과 깊이 있는 기능적 전문성을 사일로 없이 동시에 확보할 수 있도록 하는 ‘호환성 계층(compatibility layer)’ 그 자체가 됩니다.

5.4 Case in Point: DBS 은행의 대전환 - 전통에서 애자일로

거대하고 전통적이며, 엄격한 규제를 받는 조직도 성공적으로 현대적인 프레임워크를 도입할 수 있다는 사실을 싱가포르의 DBS 은행 사례가 증명합니다.31 DBS는 관료주의적이고 낡은 시스템을 가진 은행에서, 디지털 시대의 선도자로 탈바꿈하기 위해 과감한 변화를 단행했습니다.

DBS의 핵심 전환 전략은 다음과 같습니다.

• 기술을 핵심 역량으로: 구글, 아마존, 넷플릭스 등과 같은 테크 기업처럼 생각하고 행동하자는 ‘GANDALF’ 이니셔티브를 추진하며, 기술을 비용 센터가 아닌 핵심 경쟁력으로 재정의했습니다.31

• 스타트업 정신 주입: 전사적인 해커톤을 개최하고, 직원들에게 실패를 두려워하지 않고 실험할 수 있는 권한과 환경을 제공하여 스타트업과 같은 문화를 조성했습니다.31

• 고객 여정 중심의 전사적 전환: ‘Four Ds (Discover, Define, Develop, Deploy)’라는 자체적인 고객 여정 방법론을 개발하여, R&D 부서뿐만 아니라 인사, 감사, 마케팅 등 은행의 모든 부문에 적용했습니다. 이는 조직 전체가 고객 중심적으로 사고하도록 만드는 강력한 구심점이 되었습니다.31

• 기존 인력의 재교육에 대한 막대한 투자: 외부에서 새로운 인재를 채용하는 데 그치지 않고, 기존 26,000명의 직원들이 새로운 시대에 필요한 역량을 갖출 수 있도록 대규모 재교육 프로그램을 실행했습니다. 이는 변화에 대한 저항을 줄이고 조직의 DNA 자체를 바꾸는 데 결정적인 역할을 했습니다.31

6. 인간 중심의 연결고리: 소통을 중재하는 핵심 역할

6.1 프로덕트 매니저(PM): 비즈니스와 기술의 ‘미니 CEO’

구조와 방법론의 변화 속에서, 소통의 간극을 메우는 가장 중요한 역할은 바로 사람입니다. 그중에서도 프로덕트 매니저(PM)는 비즈니스, 기술, 그리고 사용자 경험(UX)의 교차점에 서 있는 핵심적인 ‘인적 가교’입니다.33

PM의 핵심 기능은 양방향 통역사 역할입니다. 한편으로는 비즈니스의 요구사항과 고객의 니즈를 R&D 팀이 이해하고 실행할 수 있는 구체적인 ‘제품 백로그(Product Backlog)’로 변환합니다.35 다른 한편으로는 개발 과정에서 발생하는 기술적 제약, 일정, 그리고 트레이드오프(trade-off)를 비즈니스 이해관계자들이 이해할 수 있는 언어로 설명하고 설득합니다.33 이처럼 PM은 제품과 관련된 모든 정보가 모이고 분배되는 커뮤니케이션의 허브로서, 서로 다른 언어를 사용하는 두 세계를 연결하는 필수적인 존재입니다.37

6.2 테크니컬 어카운트 매니저(TAM): 고객과 엔지니어링의 통역가

테크니컬 어카운트 매니저(TAM)는 주로 고객 대면 접점에서 활약하는 또 다른 중요한 연결고리 역할입니다.38 TAM은 깊이 있는 기술적 지식과 뛰어난 비즈니스 감각을 동시에 갖추고 있어, 고객이 겪는 비즈니스 문제의 기술적 근본 원인을 정확히 진단할 수 있습니다.

고객에게는 신뢰할 수 있는 기술 자문가이자 내부 대변인 역할을 수행하며, 복잡한 기술적 문제를 내부 엔지니어링 팀에 정확하게 전달하고, 그 해결 과정을 다시 고객이 이해하기 쉬운 언어로 설명합니다.39 이들은 고객과 내부 기술팀 사이의 중요한 연결 고리로서, 문제 해결을 가속화하고 고객 만족도를 극대화하는 역할을 합니다.41

R&D와 현업 부서 간의 관계를 전자공학의 ‘임피던스 정합(impedance matching)’ 개념으로 이해할 수 있습니다. 서로 다른 임피던스를 가진 두 회로를 직접 연결하면 신호가 반사되고 전력 손실이 발생하는 것처럼, 운영 방식이 전혀 다른 두 조직을 직접 소통시키면 오해와 갈등이라는 ‘손실’이 발생합니다. PM과 TAM은 이 두 시스템 사이에 위치하여 정보와 에너지를 효율적으로 전달하는 ‘임피던스 매칭 트랜스포머’와 같은 역할을 합니다. 이들은 서로 다른 프로토콜을 변환하고 신호 손실을 최소화하도록 특별히 설계된 전문적인 역할로서, 조직 내 필연적인 마찰을 관리하는 핵심적인 조직 설계의 결과물입니다.

6.3 Case in Point: 제일기획의 RPA 도입 - 기술이 놓는 협업의 다리

때로는 기술 자체가 협업의 다리가 되기도 합니다. 제일기획의 디지털 마케팅 부서는 고객사의 신제품이 출시될 때마다 80여 개의 글로벌 웹사이트 정보를 수작업으로 검수하는, 엄청나게 반복적이고 고된 업무에 시달리고 있었습니다.42

이에 기술 부서는 로봇 프로세스 자동화(RPA) 솔루션인 ‘로프로’를 도입하여, 60만 건에 달하는 수작업 검증 업무를 자동화했습니다. 이로써 마케팅 팀은 단순 반복 업무에서 해방되어 더 창의적이고 부가가치가 높은 업무에 집중할 수 있게 되었습니다. 이는 기술 부서의 업무가 현업 부서에 실질적인 가치를 제공한다는 것을 명확히 보여줌으로써 두 부서 간의 신뢰와 호의를 구축하는 결정적인 계기가 되었습니다. 특히, 이 RPA 솔루션을 비개발자인 현업 담당자도 쉽게 사용할 수 있도록 설계하여, 현업 부서가 기술의 수혜자를 넘어 직접적인 사용자로 거듭나게 한 것이 성공의 핵심 요인이었습니다.42

제일기획의 사례는 ‘서비스로서의 공감(Empathy-as-a-Service)’이라는 강력한 전략을 보여줍니다. 기술팀은 단순히 도구를 만든 것이 아니라, 현업팀이 겪는 가장 고통스럽고 지루한 문제를 파악하고 해결해주었습니다. 이러한 기술적 공감의 행위는 신뢰의 단단한 기반을 마련했으며, 향후 더 복잡한 프로젝트에서 협력할 의지를 높였습니다. 때로는 소통의 간극을 메우는 가장 좋은 방법이, 상대방의 가장 큰 골칫거리를 조용히 해결해주는 것일 수 있습니다.

7. 전략적 종합 및 실행을 위한 제언

7.1 조직 진단 체크리스트

리더들이 자신의 조직 내 R&D-현업 간 괴리의 심각성을 스스로 진단해볼 수 있는 실용적인 체크리스트를 제시합니다. 아래 질문들은 본 보고서에서 분석된 증상과 원인에 기반합니다.

• 전략 및 목표: R&D 부서의 핵심 성과 지표(KPI)와 마케팅/영업 부서의 KPI는 서로 연계되어 있는가? 전사적으로 공유되고 합의된 단일 제품 로드맵이 존재하는가?

• 프로세스 및 예산: 교차기능 프로젝트의 예산은 어떻게 책정되고 집행되는가? (개별 부서 예산의 합인가, 아니면 통합된 프로젝트 예산인가?) 시장의 새로운 요구사항이 R&D 부서의 백로그에 반영되기까지 평균적으로 얼마나 걸리는가?

• 구조 및 권한: 중요한 제품 관련 의사결정은 누가 내리는가? (경영진인가, 실무 교차기능팀인가?) 실패한 프로젝트의 원인 분석(post-mortem)은 비난의 장이 되는가, 학습의 기회가 되는가?

• 문화 및 소통: R&D 엔지니어가 마지막으로 고객과 직접 대화한 것은 언제인가? 현업 부서 직원들은 ‘스프린트’, ‘백로그’와 같은 R&D의 기본 용어를 이해하고 있는가?

7.2 단계별 통합 전략 로드맵

조직의 변화는 하루아침에 이루어지지 않습니다. 현실적이고 단계적인 통합 로드맵은 다음과 같이 제안할 수 있습니다.

• 1단계: 기반 구축 (1~6개월)

• 최고 경영진 주도하에 전사적인 통합 비전을 선포하고, 공유된 목표를 설정한다.

• 가장 중요하고 시급한 프로젝트를 하나 선정하여, 첫 번째 교차기능 파일럿 팀을 구성한다.

• 이 팀을 이끌 명확한 권한을 가진 프로덕트 매니저(PM)를 임명한다.

• 2단계: 확장 (7~18개월)

• 파일럿 팀의 성공 경험을 바탕으로 교차기능팀 모델을 다른 핵심 프로젝트로 점진적으로 확장한다.

• 디자인 씽킹 워크숍과 같은 협업 프레임워크를 도입하여 공통의 문제 해결 언어를 확산시킨다.

• Slack, Jira, Confluence 등 모든 부서가 함께 사용하는 통합 협업 도구에 투자한다.

• 3단계: 전환 (19개월 이상)

• 개인 중심의 성과 평가 및 보상 시스템을 팀 기반의 목표 달성을 장려하는 방식으로 전면 개편한다.

• 연간 단위의 경직된 예산 프로세스를 프로젝트와 팀의 변화 속도에 맞춰 유연하게 조정할 수 있는 애자일 예산 방식으로 전환을 검토한다.

• 실패를 용인하고 학습을 장려하는 심리적 안정감의 문화를 제도적으로 정착시킨다.

7.3 성공적인 변화 관리를 위한 리더십 권고

성공적인 변화는 리더십의 역할에 달려 있습니다. 최고 경영진에게 다음을 권고합니다.

• 끊임없이 소통하라: 왜 이 변화가 필요한지에 대해 모든 채널을 통해 지치지 않고 반복적으로 설명해야 한다.

• 행동으로 보여주어라: 경영진이 직접 교차기능팀의 리뷰 회의에 참여하고, 부서 간 협력의 성공 사례를 공개적으로 칭찬하며 모범을 보여야 한다.

• 연결고리 역할을 강화하라: PM과 같은 ‘가교’ 역할에게 실질적인 의사결정 권한과 자원을 부여하여 그들이 효과적으로 기능할 수 있도록 지원해야 한다.

• 작은 성공을 축하하라: 교차기능 협업을 통해 얻은 초기의 작은 성공들을 널리 알리고 보상함으로써 변화의 동력을 확보하고 긍정적인 분위기를 조성해야 한다.

• 인내심을 갖고 지속하라: 문화적 변화는 오랜 시간이 걸리는 마라톤이라는 점을 인지하고, 단기적인 성과에 흔들리지 않고 꾸준하고 일관된 노력을 기울여야 한다.43

7.4 미래 전망: 지속 가능한 협업 생태계 구축

본 보고서에서 제시한 R&D와 현업의 통합은 일회성 프로젝트가 아니라, 끊임없이 변화하고 적응하는 살아있는 조직 생태계를 구축하는 과정입니다. 기술 변화의 속도가 기하급수적으로 빨라지는 현대 비즈니스 환경에서, R&D와 현업이 하나의 유기체처럼 원활하게 작동하는 능력은 더 이상 경쟁 우위의 요소가 아닙니다. 그것은 기업의 생존을 위한 필수 전제 조건입니다. 보이지 않는 장벽을 허물고 진정한 협업 생태계를 구축하는 기업만이 불확실한 미래에서 지속 가능한 성장을 이룰 수 있을 것입니다.

8. 참고 자료

1. 개발자와의 커뮤니케이션이 당황스러웠던 이유 | 요즘IT, https://yozm.wishket.com/magazine/detail/2369/
2. 팀 간 사일로 해소 - Dropbox - Dropbox.com, https://www.dropbox.com/ko/resources/breaking-down-silos-between-teams
3. 기능 간 협업: 정보 사일로에서 벗어나기 - FasterCapital, https://fastercapital.com/ko/content/%EA%B8%B0%EB%8A%A5-%EA%B0%84-%ED%98%91%EC%97%85–%EC%A0%95%EB%B3%B4-%EC%82%AC%EC%9D%BC%EB%A1%9C%EC%97%90%EC%84%9C-%EB%B2%97%EC%96%B4%EB%82%98%EA%B8%B0.html
4. 부서간 장벽 ‘사일로’, 디지털이 허문다 - 키플랫폼, https://www.keyplatform.or.kr/topicArticleView.html?no=2021040210411173170
5. 조직의 적폐 ’사일로’를 청산하라 | DBR, https://dbr.donga.com/article/view/1201/article_no/8175
6. 【실사례 포함】 기업 데이터 활용에서 피해야 할 “데이터 사일로(Silo)화“의 함정과 해결책들, https://global.trocco.io/ko/blogs/data-silo-challenges
7. 조직 내 단절을 유발하는 데이터 사일로(Data Silo) - BizSpring BLOG, https://blog.bizspring.co.kr/%EC%9D%B8%EC%82%AC%EC%9D%B4%ED%8A%B8/%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%82%AC%EC%9D%BC%EB%A1%9C-data-silo/
8. [곽병선의 리더십 에피소드] (43) 사일로를 벗어나야 한다 - 펫페이퍼, https://www.petpaper.co.kr/news/articleView.html?idxno=10766
9. [곽병선 칼럼] 사일로를 벗어나야 한다 - 열린뉴스통신, https://www.onews.tv/news/articleView.html?idxno=99859
10. [Biz times] 부장님 백 마디보다 고객님 한 마디가 … - Bain & Company, https://www.bain.com/ko/about-bain/media-center/bain-in-the-news/korea/2021/darrell-rigby-interview-dar/
11. 애자일 조직이라면 성과평가도 애자일하게! - 사람인, https://www.saramin.co.kr/zf_user/hr-magazine/view?hr_idx=245
12. 애자일과 워터폴 방식의 통합, https://business.adobe.com/content/dam/dx/us/en/resources/sdk/mixing-agile-and-waterfall/solve-the-pain-of-mixing-agile-and-waterfall_kr.pdf
13. 전통적 조직문화 vs. 애자일 조직문화 - 그래픽 | DBR, https://dbr.donga.com/graphic/view/gdbr_no/5634
14. 초불확실성 시대에서 생존하지 못하는 조직의 특징 - WORK REBOOT - KOOFA, https://www.koofa.kr/board_posts/177
15. 4가지 팀 간 협업 모범 사례 [2024 업데이트] | Lark, https://www.larksuite.com/ko_kr/blog/cross-team-collaboration-guide
16. 직장에서 팀 간 협업을 향상시키는 5가지 방법 - Humanyze, https://humanyze.com/ko/blog-methods-that-will-improve-cross-team-collaboration-at-work/
17. 혁신 인사이트 - 속도와 혁신의 마법 주목받는 ‘애자일(Agile) 경영’ - 기술과혁신 웹진, http://webzine.koita.or.kr/201704-innovation/%ED%98%81%EC%8B%A0-%EC%9D%B8%EC%82%AC%EC%9D%B4%ED%8A%B8-%EC%86%8D%EB%8F%84%EC%99%80-%ED%98%81%EC%8B%A0%EC%9D%98-%EB%A7%88%EB%B2%95-%EC%A3%BC%EB%AA%A9%EB%B0%9B%EB%8A%94-%E2%80%98%EC%95%A0%EC%9E%90%EC%9D%BCAgile-%EA%B2%BD%EC%98%81%E2%80%99
18. 실제 작업 공간에서의 5가지 협업 사례 - Lark, https://www.larksuite.com/ko_kr/blog/collaboration-examples
19. 토스를 유니콘으로 만든 게 조직문화라고? | 컴퍼니 타임스의 비즈니스 뉴스, https://www.jobplanet.co.kr/contents/news-3133
20. 맛집 추천, 여행 일정까지 회사가 해주는 토스, 복지일까 옭아매기일까 - 비즈한국, https://www.bizhankook.com/bk/articlePrint/26546
21. DevOps, 개발팀과 운영팀의 조화로운 협업 - MSAP.ai, https://www.msap.ai/blog-home/blog/devops-teamwork/
22. DevOps 문화란 무엇입니까? - Atlassian, https://www.atlassian.com/ko/devops/what-is-devops/devops-culture
23. DevOps란? - Microsoft Learn, https://learn.microsoft.com/ko-kr/devops/what-is-devops
24. BizDevOps란 무엇인가요? - IBM, https://www.ibm.com/kr-ko/think/topics/bizdevops
25. 디자인 씽킹 활용법(2) 조직문화 - 피플앤인사이트, https://www.pninsight.com/post/%EB%94%94%EC%9E%90%EC%9D%B8-%EC%94%BD%ED%82%B9-%ED%99%9C%EC%9A%A9%EB%B2%95-2-%EC%A1%B0%EC%A7%81%EB%AC%B8%ED%99%94
26. 디자인 씽킹이란 무엇인가요? 정의, 장점 및 모범 사례 - IdeaScale, https://ideascale.com/ko/%EB%B8%94%EB%A1%9C%EA%B7%B8/%EB%94%94%EC%9E%90%EC%9D%B8-%EC%82%AC%EA%B3%A0-%EC%A0%95%EC%9D%98/
27. 디자인 씽킹 진짜 효과가 있을까?, https://stibee.com/api/v1.0/emails/share/6Z7Az95zfF6FRgfds60eDtmQebowfA==
28. 세계 1위 음악 스트리밍 업체 스포티파이의 애자일 도입 사례 - HR 블레틴, https://www.hrbulletin.net/organizational-culture/%EC%99%9C-%EA%B8%80%EB%A1%9C%EB%B2%8C-%EA%B8%B0%EC%97%85%EB%93%A4%EC%9D%80-%EC%8A%A4%ED%8F%AC%ED%8B%B0%ED%8C%8C%EC%9D%B4spotify%EC%9D%98-%EC%A1%B0%EC%A7%81-%EB%AA%A8%EB%8D%B8%EC%9D%84-%EB%B2%A4/
29. [pxd talks] 96회 Spotify에서 User Research를 진행하는 방법, https://story.pxd.co.kr/1546
30. [조직문화] 스쿼드(Squad)는 그만!! - Medium, https://medium.com/@ghilbut/%EC%A1%B0%EC%A7%81%EB%AC%B8%ED%99%94-%EC%8A%A4%EC%BF%BC%EB%93%9C-squad-%EB%8A%94-%EA%B7%B8%EB%A7%8C-738b7ebd6998
31. 애자일 혁신: 전통적 은행의 성공적 디지털 트랜스포메이션, https://revenuefy.io/ko/persona/agile-transformation-successful-digital-transformation-of-traditional-banks
32. 애자일 경영 : 금융 산업의 변화, 디지털 혁신을 위해 기업들이 도입하고 있는 애자일 조직이란? (애자일 경영 도입 사례) : CEO Posting - CEO 노트, http://ceonote.co.kr/CEO-Posting/?q=YToxOntzOjEyOiJrZXl3b3JkX3R5cGUiO3M6MzoiYWxsIjt9&bmode=view&idx=142372871&t=board
33. 프로덕트 매니저(PM) 역할 및 꼭 알아야 되는 스킬 추천 - 러닝스푼즈, https://learningspoons.com/website/blog/detail/pmcareer/
34. 직업의 세계: PM ① 무슨 일을 하나요? - 내일배움캠프 블로그, https://nbcamp.spartacodingclub.kr/blog/%EC%A7%81%EC%97%85%EC%9D%98-%EC%84%B8%EA%B3%84-pm-%E2%91%A0-%EB%AC%B4%EC%8A%A8-%EC%9D%BC%EC%9D%84-%ED%95%98%EB%82%98%EC%9A%94-55552
35. 개발 작업 관리의 기초 : PM의 역할은? - 뤼이도 블로그, https://blog.riido.io/dev-management-basics-pm-role/
36. PM, PO 차이점ㅣ프로덕트 매니저, 프로덕트 오너 뜻, 역할, 하는 일 - 코드스테이츠 공식 블로그, https://www.codestates.com/blog/content/pm-po-%EC%B0%A8%EC%9D%B4
37. [Product Manager] PM이란? 프로덕트 매니저의 역할, 필요한 역량, 개발자와의 차이까지 정리, https://goldeast.tistory.com/72
38. 기술지원의 역할? TAM, TPM, https://pm-developer-justdoit.tistory.com/565
39. 테크 비즈니스 최전방의 숨은 능력자, 테크니컬 어카운트 매니저를 …, https://toss.im/tossfeed/article/technicalaccountmanager
40. Technical Account Manager - 사전 예방적이고 자문을 제공하는 기술 지원 관리를 통해 운영 효율성 향상 - Dell, https://www.delltechnologies.com/asset/ko-kr/services/support/technical-support/technical-account-manager-data-sheet.pdf
41. Technical Account Manager - 직원소개 - Korea Support, https://aws.amazon.com/ko/careers/support/employee4/
42. 제일기획 RPA 고객사례 | UiPath, https://www.uipath.com/ko/resources/automation-case-studies/cheil
43. 기업 DT의 핵심은 일하는 문화의 혁신, 애자일 어프로치 | 인사이트리포트 | 삼성SDS, https://www.samsungsds.com/kr/insights/agile_approach.html