- 개발 조직의 탁월함은 “주어진 목표를 얼마나 빠르고 정확하게 수행할 수 있는가”로 정의된다.
- 이를 달성하기 위해 개발 조직은 세 가지 지점에서 조직의 성과를 끝없이 재평가해야 한다.
- 개발부터 배포까지의 과정에서 병목 지점이 어디인지, 이를 어떻게 탁월하게 해결할 수 있을지 끝없이 고민해야 한다.
- 한 제품의 배포는 이와 상관없는 다른 제품과 완전히 독립적이어야 한다.
- 배포된 제품 전반에 걸친 모니터링이 되어야 한다.
소프트웨어 공학이 모든 것인 시대가 시작되었다. 기존에 인류가 하고 있던 일은 소프트웨어 공학을 통해 수 만~수 억 배의 효율화를 이루어낼 수 있게 되었고, 기존에 인류가 풀 수 없었던 문제들 또한 소프트웨어 공학을 통해 해결할 수 있게 되었다.
그러나 우리는 소비자로서 종종 이와 전혀 상반되는 경험을 하거나, 생산자로서 진정 소프트웨어 공학이 우리의 문제를 해결해주고 있는 것이 맞는지 의문을 가지곤 한다. 이를 테면 “이 결과물이 과연 최선인가?” 라던가, “기술이 발전하는 속도에 비해 생산/소비되는 결과물은 너무 뒤쳐져 있지 않은가?”와 같은 의문점들이 그것이다. 미국의 빅테크 기업들은 수십억명의 전 지구적 트래픽을 받아내면서 모든 사용자에게 맞춤형 컨텐츠를 중단 없이 서비스하고 있는 한편, 많은 한국의 은행들은 지금도 자정부터 30분씩 정기 점검을 가지면서도 트래픽 증가와 장애 대응에는 아마추어적인 모습을 보이며, 새로운 기능 추가에도 매우 보수적으로 접근하고 있다.
이는 본질적으로 사회, 혹은 경영인들이 조직을 운영할 때 정의해야 할 “핵심 목표” 및 이를 달성하기 위한 “조직의 탁월함”의 기준이 바뀐 사용자들의 요구사항에 제대로 부응하지 못함에서 시작된다. 소프트웨어 공학을 통해 문제를 해결하기로 결정한 조직은 기존의 사람이 해내던 일들을 소프트웨어를 통해 더욱 효율적으로 해내기 위해 이 “탁월함의 기준”을 잘 재정의할 필요가 있다. 이것의 중요성은 조직의 크기와는 독립적으로, 아무리 작고 기민한 스타트업 조직이라도 이에 대한 기준을 잘못 가지고 있다면 절대 소프트웨어 공학을 응용한 시장에서의 우위를 점할 수 없다.
Objective: 개발 조직의 탁월함 정의하기
개발 조직의 탁월함은 매우 단순하고 직관적이다. “주어진 목표를 빠르고 정확하게 수행할 수 있는 조직”이 탁월한 개발 조직이다. 나머지 모든 요소들은 이 탁월함을 달성하기 위한 요소들에 불과하다.
왜 빠름이 중요한가? 그것이 소프트웨어 공학으로 점유할 수 있는 경쟁 우위의 본질이기 때문이다. 소프트웨어 제품은 1. Fast - 소비자의 요구사항에서 실제 사용 가능한 제품으로 옮겨지기까지의 시간이 빨라야 하며, 2. Agile - 요구사항이 변했을 때 이에 기민하게 반응할 수 있어야 한다. 소프트웨어 제품은 이 속도의 차별점을 통해 사용자의 요구사항에 빠르게 대응해나가는 것으로 시장에서 우위를 점해야 한다.
왜 정확성이 중요한가? 이는 빠름을 추구하는 과정에서 필연적으로 정확성의 결손이 발생하기 때문이다. 최소 배포 가능한 제품(MVP)를 작성한 창업자, 혹은 개발자는 배포 즉시 지구의 전 인류가 나의 제품을 써줄 수 있을 것으로 기대하지만, 실제로는 각 사용자에 맞는 수많은 요구사항들을 확인하고 이를 맞추어 나가는 과정을 시작으로 계속해서 제품을 개선해 나가야 한다. 이 과정에서 제품은 마치 논리 회로처럼 각 상황에 처한 고객들과 객체들의 상황에 정확히 들어맞는 기능을 선보여야 한다. 이를 더 정교하게 깎는 것이 경쟁자와의 차별점을 형성한다.
탁월함을 잘 정의했다면, 이제 이를 달성하기 위해 조직이 정해야 할 구체적인 핵심 성과(key result)와 action item을 세워야 한다. 이는 조직이 풀고 있는 문제의 특성과 수익 모델에 따라 크게 달라질 수 있다. 이 글에서는 B2C agile 조직이 추구해야 할 핵심 가치 세 가지를 우선적으로 소개하고자 한다. 다음 문단을 시작하기 전에 누차 강조해도 아깝지 않은 점은 목적이 수단보다 항상 우선해야 한다는 것이다. 수단의 실행으로 목적 달성에 실패했다면 그 선택을 과감히 철회하고 실패한 이유를 회고해야 하며, 그렇지 못하는 조직은 절대 탁월함에 다다를 수 없다.
Key Results: 탁월함을 달성하기 위한 결과들과 Action Item들
1. 기획에서부터 배포까지의 병목 지점이 어디인지 끊임없이 찾아내야 한다
제품의 요구사항이 정의되고 이에 수반되는 구체적인 구현 명세가 확정되고 나면, 그 뒤로부터는 개발 조직의 탁월함에 따라 배포까지의 데드라인이 정해진다. 단순히 버튼에 들어갈 텍스트 변경부터 세상에 없던 새로운 증권 앱을 만드는 과정까지 모든 소프트웨어 제품은 같은 규칙에 종속된다. 개발 조직의 일부 혹은 전체는 계속 달라지는 요구사항에도 항상 높은 탁월함을 유지해야 하는데, 이 과정을 어렵게 만드는 가장 큰 장애물을 추상화하여 “병목 지점”이라고 명명할 수 있겠다.
흔히 개발자는 어림(estimation)을 정말 못하는 직업으로 평가받곤 한다. 소프트웨어 기업에서의 작업 흐름뿐만 아니라 일반적인 공학 업무(건설, 제련, 정유, 조선, …)에서도 가장 estimation을 지키지 못하는 직종을 꼽자면 바로 소프트웨어 공학자일 것이다. 이는 소프트웨어 공학이 다른 공학에 비해 압도적으로 잦은 명세 및 수단 변경에 직면해 있음을 간과할 수 없다. 30층짜리 건물의 최대 수용 인원을 정하고 나면 그 수치는 몇십년간 쉽게 바뀌지 않지만, 오늘 1천명이 방문하던 사이트가 다음 날 1백만명의 트래픽을 받는 것은 드문 일이 아니다.
때문에 개발자는 자신의 어림을 박살내는 병목 지점을 만날 때마다 1. 왜 이 지점이 병목이 되었고, 2. 이를 반복하지 않기 위해 어떤 노력을 해야 할지 끊임없이 고민해야 한다. 어떤 날에는 데이터베이스의 처리 용량이 병목 지점일 수도, 인프라 내 여러 노드로의 점진적 배포 과정이 병목 지점일 수도, 코드 빌드 시간이 병목 지점일 수도, 심지어 어떤 날은 코드 리뷰가 늦어지는 동료가 병목 지점일 수도 있다. 한 번 겪은 병목 지점을 다시 겪지 않도록 인지하고 노력하는 과정을 멈추지 않는 것으로 개발자의 어림은 점점 정확해지고 탁월함에 가까워질 수 있다.
일반적인 Action Item들
- 제품의 배포가 끝나고 나서 estimation과 달라진 점을 회고하고 이를 반복하지 않을 방법을 고민하는데 충분한 시간을 사용한다.
- 하루를 마무리하거나 시작할 때 “어제/오늘은 어떤 작업에 시간을 가장 많이 썼는지” 회고한다.
- 나 뿐만 아니라 전세계의 탁월한 엔지니어들이 같은 병목 지점을 해결하기 위해 치열하게 고민하고 있다. 그들의 아이디어를 잘 빌려올 방법을 고민한다.
- 예시: 어떤 빌드 툴은 기존 구조를 그대로 유지하면서도 빌드 시간을 1/10으로 단축할 수 있다.
- 예시: 개발 도중 혹은 배포 이후에 예상치 못한 문제를 만날 확률을 줄이기 위해 강한 타입 시스템과 주요 지점들에 대해 효과적이고 빠른 테스트를 작성할 수 있다.
- 예시: 내가 만났던 문제를 동료 개발자가 반복적으로 만나지 않도록 문제의 해결책을 쉽게 공유하는 모노레포 혹은 라이브러리 구조를 사용한다.
2. 한 기능의 배포는 다른 기능의 배포와 완전히 독립적이어야 한다
조직의 제품이 품는 작은 단위의 제품(product) 혹은 기능(feature)들이 많아질수록 문제의 복잡도는 이에 비례하지 않고 제곱, 혹은 그 이상의 속도로 증가하는데, 복잡성이 가파르게 증가하는 가장 핵심적인 원인은 특정 기능의 변경이 다른 기능의 동작에 영향을 미치기 때문이다. 이 영향 또한 다양한 현상으로 나타날 수 있는데, 어느 날에는 A기능 개발로 인해 B기능의 코드 빌드가 깨질 수도 있고, 어느 날에는 A기능 배포로 인해 증가한 트래픽으로 인해 B기능의 서비스가 장애(failure)를 겪을 수도 있다.
이 문제를 잘 해결하는 핵심 아이디어가 “각 기능간의 독립성”임을 인류는 십수년간의 개발 조직 운영 경험을 통해 깨우쳤다. 컴퓨터과학을 간단하게나마 공부한 사람이라면 문제의 크기 에 대해 복잡도가 에서 으로 개선되는 것이 얼마나 극단적인 성능 향상으로 이어지는지 이해할 것이다. 종속적인 서비스 그물(mesh)에서 독립적인 서비스 그물로의 전환은 마치 복잡도의 문제를 으로 끌어내리는 것과 같은 효과를 낸다.
서비스 독립성의 효과 중 또 한 가지 짚고 넘어갈 것이 있다면 바로 “배포에 대한 두려움 감소”일 것이다. 서로가 종속적인 서비스 그물 구조에서는 내 배포가 다른 서비스, 이어서 제품 전체에 끼칠 영향에 대해 정확히 파악이 어렵기 때문에 개발자는 배포를 두려워하게 된다. 반면 독립적인 서비스 그물에서는 내 배포가 잘못되어 일으킬 수 있는 문제는 내가 담당하는 서비스의 장애 이상으로 커지지 않는다.
많은 기업들이 이 독립성을 달성하기 위해 엄청난 리소스를 쏟아붓고 있으며, 어떤 기업들은 개발 조직 그 자체보다도 더 많은 리소스를 여기에 투입하기도 한다. 그만큼 중요하고 많은 연구가 이루어진 분야이기 때문에 제시된 방법론, 솔루션 등도 무지하게 많다. 탁월한 개발자라면 목적과 수단을 명확히 구별하여 현재 조직이 풀고 있는 문제의 크기에 맞는 솔루션을 도입하여 지금 단계의 복잡도에 맞는 해결책을 적용하여 서비스 독립성을 달성할 수 있어야 한다.
일반적인 Action Item들
3. 제품이 배포에 이르는 전후 과정이 모두 모니터링이 되어야 한다
위의 두 가지 목표와 다르게 모니터링은 배포 후에 일어나는 과정임에도 불구하고 탁월함의 주 목적인 속도와 정확성에 큰 영향을 끼친다. 소프트웨어 공학뿐만 아니라 다양한 위기 대응 이론(소방, 치안, …)에서 “장애는 전체 파이프라인에서 발견되는 시점이 늦어질수록 기하급수적으로 높은 피해를 일으킨다”고 기술하고 있다. Agile 제품 개발적인 관점에서 기획이 완료된 제품이 배포에 이르기까지 거치는 과정은 크게 기술 명세 작성 - 구현 - 테스트 - QA - 배포로 추상화할 수 있다. 위 이론에 따르면 기술 명세 작성에서 발생한 문제는 구현 단계에서 잡을 수 있을 때 가장 저렴한 것이고, 배포에 이르러서 잡게 된다면 전자의 경우에 비해 훨씬 큰 조직적 비용을 치르게 되는 것이다.
탁월함을 추구하기 위해 모니터링이 달성해야 할 주 목적은 크게 두 가지로 나눌 수 있다. 첫 번째는 마지막 단계인 배포를 여러 구간으로 쪼개어 배포의 초기 단계에서 문제를 감지할 수 있게 하는 것이다. 점진적 배포를 사용하는 조직이 매우 뛰어난 모니터링 체계를 구축하고 있다면, 약 1%의 사용자가 장애를 일으키는 배포 버전을 만나는 상황에서도 문제를 감지하고 장애가 전파되는 것을 막을 수 있다. 모니터링이 제대로 되지 않는 조직이라면 전체 사용자가 새 배포 버전을 만나고 한참이 지나서야 장애를 감지하고 대응할텐데, 이는 같은 배포 단계임에도 불구하고 매우 큰 조직적 비용을 치르게 만든다.
두 번째는 훌륭한 모니터링을 통해 조직의 탁월함을 측정하는 좋은 척도를 만들고, 이를 통해 탁월함을 개선할 action item들을 세우는 것이다. 모니터링을 통해 크고 작은 장애 지점들을 발견하기 시작하고 이러한 문제점들을 조직의 큰 비용을 치르게 하는 큰 문제로 번지기 전에 해결하는 경험을 하고 나면, 이제 개발 조직은 발견된 문제들을 계속해서 완화하고, 영향 범위를 축소하고, 같은 대응을 하면서도 개발자의 개입을 최소화할 수 있는 방법에 대해 고민하기 시작하고, 또 이를 계속 반복해야 한다. 모니터링으로 발견되는 문제들은 조직의 크기, 혹은 해결하는 문제의 크기가 배로 커지면 자명히 배로 많아지는데, 이를 대응하는데 들어가는 시간이 배로 증가하는 조직은 절대 확장과 탁월함을 동시에 달성할 수 없다.
일반적인 Action Item들
- 개발자 개개인의 책임감 강화
- 알림(alert) - 자동으로(programmatically) 감지할 수 있는 모든 문제에 대한 적절한 알림과 알림 단계 설정, 조직 구조에 맞는 alert escalation protocol
- 여러 기술적 지표(metric)에 대한 장기 보관 파이프라인 구축
- 보관된 데이터를 기반으로 한 장애 빈도와 주 문제 지점 파악, 회고
- 이를 완화하기 위한 활발한 기술적 토의가 이루어지는 개발 조직 문화
맺으며
탁월한 개발 조직을 추구하는 조직에서 설정해야 할 핵심 목표와 이를 달성하기 위한 성과 지표 세 가지, 그리고 일반적으로 실행할 수 있는 action item들을 정리해보았다. 글의 마지막에서도 다시 한 번 강조하자면 목적이 정확하게 설정된 후 수단을 결정하는 것이 매우 중요하기 때문에, 제시된 action item들은 예시에 불과하고 조직의 구조와 요구사항에 맞는 적절한 action item들을 설정하는 것이 중요하다.
글을 맺으며, 독자가 탁월한 개발 조직을 향한 추구는 생각보다 개발자 스스로에게 큰 효능감을 준다는 점을 믿어줬으면 한다. 스스로 설정한 목표를 action item으로 쪼개어 달성해나가는 것은 누구에게나 즐거운 일이다. 조직의 핵심 가치가 속도인데, 이 속도를 나의 기여를 통해서 올리는 경험은 자신에게 주는 만족도 엄청날 뿐더러, 실제로 조직에 끼치는 영향도 막대하다. 탁월함에 대한 끝없는 추구, 개발자로서의 역할을 다하면서도 조직 전체의 생산성을 끌어올리는 패턴이 체화되기 시작했을 때, 시장에서 흔히 찾아볼 수 없는 탁월한 조직을 만들 수 있는 개발자로서의 성장이 시작될 것이고, 그 과정은 당신에게 큰 즐거움을 안겨줄 수 있을 것이라고 필자는 확신한다.
감사의 말
글을 흔쾌히 읽고 감수해주신 많은 분들에게 모두 감사드립니다.
글의 모든 이미지는 작성자가 제작한 것을 GPT 5로 재가공함.