상반기의 업무 방식이 과감하게 도전하기(Be Bold)라면, 하반기의 일하는 방식은 “함께 리듬감있게 일하기“로 이야기하고 있다. 상반기엔 구성원 모두가 정말 과감하게 도전했고 기대 이상의 성과들을 만들었다. 말이 쉽지 개개인의 희생과 노력없이 도전은 이뤄질 수 없다. 그만큼 피로가 쌓일 수 밖에 없기에, 이 방식은 지속 가능한 업무 형태로 적합하지 않다. 이에 대한 고민을 아래와 같은 방식으로 정리해봤다.

1. 리듬감있게 일하기
2. 한번에 되는 일은 없다!
3. 되풀이하지 않기
4. 현실은 멀티플(Multiple)

 

리듬감있게 일하기

지속 가능성을 염두에 뒀을 때, 상반기 과감한 흐름이 조직의 DNA로 이어질 수 있는 방안을 생각했다. 고민을 바탕으로 하반기 일하는 핵심 키워드로 “함께”와 “리듬감”을 뽑았다.

“함께”라는 단어는 알겠지만, “리듬감”은 뭘 말하는지 모르겠다는 질문이 많았다. 보통 리듬은 일정하게 반복되는 주기성 혹은 패턴을 의미한다. 우리는 스프린트 방식(2~3주 단위의 반복적 개발 방식)으로 일한다. 팀의 역량(Capacity)에 따라 일정 양(Volume)의 일을 반복한다. 자연스럽게 리듬있게 일하고 있는거 아닌가? 하지만 음악에도 변주가 있듯이 스프린트 그 기간 안에서 벌어지는 일의 양과 성격이 매번 다를 수 밖에 없다.

그럼에도 리듬감있게 일하기 위해 가장 필요한 것은 실행의 단위를 갖는 것이다. 이미 스프린트가 있기 때문에 이 스프린트가 명시적으로 유지되어야 한다. 2주 혹은 3주 단위의 스프린트 단위로 함께하는 동료 혹은 팀들이 의식적으로 일을 진행해야 한다. “새로운 요구 사항이 계속 나오고, 2~3일마다 배포하고 있는데 스프린트가 무슨 의미가 있냐?” 라는 질문 할 수 있다. 이런식으로 라이브 배포를 하고 있으면 스프린트의 의미가 없다….

이런 이야기까지 나오는 건 계획(Planning)할 수 없기 때문이다. 예측할 수 있다면, 적어도 스프린트에 할 일을 구체화하고 실행할 수 있지 않을까? 물론 예측 못한 일들이 마구 나온다는건 분명 잘못된 시그널이다. 방향과 지도 없이 헤메고 있을 가능성이 높다. 바로 잡으려면 방향을 잡고, 우리가 알고 있는 지식과 경험으로 지도를 그려야 한다. 높은 산꼭대기가 아니더라도 언덕 위에 올라가면 하루, 이틀의 길을 예측할 수 있다. 거기부터 시작해야 한다. 예측을 시작해야 무엇에 집중할지 결정할 수 있게 된다. 그럼 스프린트에 진짜로 뭘 만들어야할지 제대로 알게 된다. 2~3일마다 배포해서 얻는 결과보다 더 큰 가치를 타켓팅할 수 있게 된다.

2023년의 시장 환경은 한 분기 단위의 예측성 조차 보장하기 힘들만큼 급변했던 것 같다. 상반기를 어렵게 넘겼지만, 하반기 역시 녹록하지 않다. 그럼에도 “리듬감있게 일하자!”라는 배경에는 리더로서 최소한 2개 혹은 그 이상 스프린트의 예측성을 각 개발팀에 보장해주기 위함이다. 당장 시작할 다음 스프린트를 예측할 수 있다면, 개발을 담당하는 각자는 플래닝을 통해 코딩에 집중할 시간을 가질 수 있지 않을까 싶다. 물론 이 정도 스프린트의 시간으로 일이 완성되지 않는다. 과정은 반복되고, 서비스는 답이 정해진 게임이 아니다.

한번에 되는 일은 없다!

완결된 목표는 한번 “으쌰!”한다고 완성되지 않는다. “무엇을 만들자!“가 선언되고, 제품/기능/서비스로 실체화 되는데 시간이 걸린다. 특히 명제가 갖는 가치와 무게가 높고 무거울수록 더 많은 시간이 필요하다. 완성되기 전까지 우리는 “무엇”의 완벽한 실체를 알 수 없다. 그래서 우리는 점진적인 완성을 향해가는 개발 방법론을 사용한다.

시간에 따른 점진적인 완성이 동작하기 위해서는 소통이 있어야 한다. 우리가 파악한 정보는 무엇이며, 이를 바탕으로 검증할 대상을 정해야 한다. 정해진 대상을 스프린트를 통해 구체화시키고 데모를 통해 확인한다. 결과물은 나아갈 방향을 검증하고, 새롭게 정보가 추가된다. 그리고 다음 스프린트에서 최종 목표를 위해 뾰족하게 할 내용을 정의한다. 이 반복을 통해 우리는 목표(Goal)를 향해 차근차근 다가간다. 그리고 충분히 고객과(End User)과 관련자(Stakeholder)를 만족시킬 수 있다는 판단이 들 때 우리는 출시(Release)를 통해 “무엇“의 가치가 실체화되는지 확인한다.

적절한 수준의 정보가 있어야 스프린트를 제대로 진행할 수 있다. 음식은 너무 날 것이라도 문제를 일으키지만 너무 삭아도 안된다. 스프린트를 위한 정보 역시 마찬가지다. 참여자가 충분히 해석하고 공감할 수준이면 충분하다. 구현 단계의 생산자(Maker)들이 해석하고 분해해서 우리가 이 기간에 검증할 내용이 무엇인지 정의한다. 해석과 분해를 위해 추가적인 정보가 필요할 수 있다. 충분하지 않다면 충분하지 않다는 것 자체를 받아들이자! 상황을 받아들이고 그 상황에 맞추어 어떤 시도를 해볼지 결정하는게 좋다. 그리고 결과를 만드는 일에 스프린트 기간 동안 집중해보자. 아니 해야한다. 그리고 해석된 결과가 데모를 통해 공유하고 우리가 충분히 고객과 관련자들에게 다가가고 있는지 확인하자.

되풀이하지 않기

되풀이하지 않기 위해 각 단계에 따른 완전성(Completeness)을 추구해야 할 때도 있다. 만들 S/W 제품을 목표(Goal)로 보고 진행되는 “제품 기획 – 디자인/설계 – 개발/QA”를 단계에 따른 서비스 개발 파이프라인이라고 정의하자.

기획 단계에서 완벽한 사업 내용을 문서로 작성한다. 이 가치를 얻는데 필요한 기능들을 A~Z까지 깨알같이 정의된 산출물이 만들어진다. 디자인 단계는 화면에 어떤 요소들이 위치하는지 픽셀 단위의 오차도 허용하지 않는 피그마로 작성된다. 물론 개발을 위한 방대한 Component – Class – Sequence Diagram(State Diagram)이 깔끔하게 준비되는 경우도 있다. 방대한 정보가 역시 산출물로 만들어진다. 마지막으로 개발/QA가 코드로 Goal을 완성시킨다. 멋지다!

이점에서 제품 완성을 위해 주어진 시간은 단계로 구분된다. 각 단계의 결과물이 예상 시간 범위에 완료되면 이상적일 것이다. 하지만 세상은 완벽하지 않고, 사람의 마음은 갈대와 같다. 고객의 마음 역시 그자리에 그대로 있으라는 보장이 없다. 여기에 소위 배포일이 찍혀있는 Time-to-market 상황이라면? 어느 한 단계의 고민이 길어지면 부담은 고스란히 다음 단계로 전이된다. 개발을 위한 정보 전달이 늦어지면 늦어질수록 결국 짧은 시간에 개발과 QA를 마쳐야 한다. 줄어든 시간은 담당자들에게 심리적인 압박으로 작용하여 스트레스로 사람들을 지치게 만든다.

파이프라인에 정보가 흘러야 한다. 일을 시작할려면 필요한 정보가 있어야 한다. 앞선 이야기처럼 현재 단계를 위한 모든 정보가 있으면 좋다. 25년 개발 경험을 되돌아봤을 때 일 시작 전 모든 정보가 준비된 경우는 없었다. 심지어 SI를 했던 때도. 또한 주어진 정보라도 근거가 잘못됐거나 해석의 오류가 발생하는 경우도 빈번했다. 그래서 “못한다, 님(남)탓이다.“라고 이야기해야 할까? 만약 이런 이야기를 하고 있다면 단계라는 벽에 스스로 갇힌 것과 다름없다. 시간이 가장 귀중한 자원이다.

흐르게 할려면 막힌 부분을 열어야 한다. 정보 역시 마찬가지다.  정보가 흘러가면 모든 단계의 주체들이 뭘 할 수 있을지 고민할 수 있다. 고민하면 준비할 수 있고, 준비되면 추가된 정보를 통해 목표에 다가가는 시간을 아낄 수 있다. 때문에 각 단계의 벽을 여는 것이 가장 중요하다. 단계를 소유하는 조직들이 벽을 스스로 허물어야 한다. 파이프라인에 참여하는 모든 조직들이 단계의 벽을 낮추고 한 팀처럼 동작해야 정보가 흐르고 점진적으로 목표를 향해 나아갈 수 있다.

벽을 낮추고 여는 핵심 역할을 단계의 리드들이 해줘야 한다. 물론 파이프라인을 책임지는 리더 역시 이 부분을 독려해야 한다. 모두가 확고한 의지를 가질 수 없기 때문에 리더십과 문화가 이를 뒷받침해야 한다. 한 두사람의 의지만으로 파이프라인에 물을 흐르게 만들 수 없다.

물론 정보가 완전하지 않기 때문에 엉뚱한 일을 할 수 있다. 누구는 이를 비효율이고 낭비라고 이야기한다. 틀린 말이 아니다. 그렇기 때문에 낭비적인 요소를 최소화하기 위해 빠른 방향 전환을 할 수 있어야 한다. 추가 정보로 틀렸음을 알게되면 빠르게 인정하고 방향을 수정해서 움직여야 한다.

이때 파이프라인의 어느 구간이 닫히는 경우가 있다. 비난이 원인이다. “잘못된 판단”을 하지 않으면 좋겠지만 완전하지 않은 정보를 바탕으로 판단할 수 밖에 없으니결과가 목표와 다른 일은 언제든 발생한다. 이를 용납 못하고 비난이 난무하는데 이를 리더십에서 제어하지 못한다면? 그럼 이 방법은 조직에 맞지 않다. 조직에 맞는 다른 방법을 찾는게 옳다.

현실은 멀티플(Multiple)

담당자가 참여하는 파이프라인이 하나라면 다행이다. 하지만 대부분 팀들이 할 일들이 참 많다. 회사의 꿈이 완성형이 아닌 진행형 상태라면 개인이 혹은 팀이 참여하는 서비스 파이프라인이 하나일 수 없다. 현실은 멀티플이다.

멀티플이라는 그림을 놓고보면 숨이 턱 막힌다. 한번에 두개 세개의 작업을 현실에서 어떻게 하지??? 불가능하다. 사람 머리가 두개가 아닌 이상 특정 순간에 하고 있는 일은 하나다.

컴공 전공이라면 비슷한 그림 한번쯤 보지 안았을까 싶다. 운영 체제(Operating system)를 공부했다면 바로 생각날 것이다. 여기에서 여러 작업을 처리하는 방법, 특히 CPU(Core)가 하나인 경우에 타임 쉐어링이라는 방식이 있다. 사실 여러 작업이 동시 처리되게 보이도록 만든것이지 실제 처리는 1개만 하는 것이다. 단, 계산(Computation)이 지속되도록 CPU에 작업을 지속적으로 부여한다. 만약 계산을 위해 데이터가 필요한 순간이면 그 작업을 잠시 보관하고, 계산할 다른 작업을 올려 진행한다. 물론 작업 전환이 공짜로 이뤄지는 건 아니다. 이전 작업을 이어 수행하기 위한 정보를 안전하게 보관시키고, 다음 작업 실행 상태 정보를 CPU가 바로 수행해야 한다. 운영 체제가 수행하는 이와 같은 일련의 작업 전환을 “컨텍스트 스위치(Context Switch)“라고 부른다. 이 작업 역시 CPU에 의해 실행되기 때문에 공짜가 아닌것이다. 그리고 작업 전환이 많을수록 정작 CPU는 해야할 일보다는 이 전환만 열심히 하고 있을 수 있다.

현실의 멀티플 역시 같은 맥락이다. 당면해서 처리할 충분한 정보가 있다면 그 일에 집중한다. 진행을 위해 정보가 더 필요하거나 선작업이 끝나는 것을 기다려야하는 상황이라면 다른 작업의 일부를 진행하면 된다. 물론 여기도 작업 전환 비용이 발생한다. 전에 내가 어디까지 했는지 기억도 추스려야하고, 문서나 코드도 다시 훑어야한다. 상황 자체가 이전과 판이하게 달라졌다면 당시자들을 만나 충분한 상황 공유를 받아야한다. 이전 작업이 너무 빡셌다면 다음 작업을 위해서 쉬는 것 역시 번아웃을 막기위해 필요하다.

지금까지의 논리로 보면 우리가 일하는 방식은 컴퓨터와 비슷해야 효과적일 수 있다는 것이 역설적이다. 다만 인간은 수만대의 기계를 합친 것에 비교할 수 없다. 똑똑함을 넘어선 인간의 지혜와 통찰이라는 요소가 이 차이를 만든다. 그리고 이 요소들이 십분 발휘될 수 있는 지점이 계획 수립, 즉 플래닝이라고 생각한다.

플래닝을 통해 확정된 것과 미확정 요소를 공유하고, 스프린트에 확인할 대상을 찾아야 한다. 여러 제품 혹은 서비스를 함께 챙겨야한다면 상관관계와 선후를 파악해야 한다. 이 부분이 종합되면 스프린트에 수행할 태스크의 우선 순위를 매길 수 있다. 물론 미확정 요소를 확정 단계로 만들어야하고, 이렇게 파악된 컨텍스트를 참여자 모두가 확인할 수 있도록 열린 커뮤니케이션이 공유의 형태로 유지되어야 한다. 강조해서 주의/당부하고 싶은 건 정보가 무기화되는 것이다. 누군가가 정보를 자신을 위해 사용한다고 참여자들이 모두 느낀다면 안하니만 못한 일이 되버린다.

-끝-

PS.

국방, 안전, 항공, 우주 관련 프로젝트의 경우는 절차적 단계에 따른 제품 개발이 꼭 필요하다고 생각한다. 부실한 정보를 토대로 원전 운영 소프트웨어를 작성했다는 사실을 알게 되면… 끔찍하다. 해본 적은 없지만, 이런 고난이도 개발을 해볼 기회가 있었으면 하는 생각도 든다.