정확히 이러한 문화를 뭐라 불러야 할지 모르겠다. 기민한 개발조직으로 만들려고 혹은 시장에서 도태되지 않기 위한 간절한 변화의 노력으로 지난 2년간 만들어낸 우리 조직[1]의 개발 문화에 대한 이야기다. 뭉뚱그려 말하면 애자일이라 할 수 있겠으나 애자일이라는 말의 쓰임이 너무나 다양하게 쓰여지고 있어 의미를 얼마나 전달할까 싶다. 아무튼 일을 해나가는 과정속에서 무리하게 정의하려고 들기 보다는 사례를 공유하고, 글을 쓰는 과정에서 조금이나마 개념 정리를 시도해보고자 글을 쓴다.
개취 인정이 자발성에 불을 지피다?
최근 몇 주간에 벌어진 일화다. 인터넷 망 절대 강국 한국에 비해 다양한 네트워크 제약이 펼쳐지는 북경 사무실에서 UI 기획 도구로 굳이 외산 서비스를 쓰는 동료가 있었다. 잠깐 의문이 들었다.
“굳이 꼭 이런 툴을 써야 할까? 내용을 참조하려면 멍하니 기다리는 다른 사람의 시간을 요구해가면서까지…”
솔직히 고백하면 한국에서 일할 때만 해도 이런 시도를 허용하기 보다는 질서나 공동 작업자에 대한 배려를 우선시 했던 것 같다. 그런데, 지난 2년간의 과정에서 필자의 접근은 꽤나 바뀌었다. 생각이 대강 아래와 같이 흘러 왔다.
“유로 서비스 비용을 내가면서까지 쓰겠다는 개취(개인 취향)를 인정해주자”
그랬더니, 프론트 개발자 출신이 노하우를 갖기 쉬운 UI 이면에 숨겨진 절차와 복잡한 비즈니스 규칙까지 그가 주도성을 발휘하기 시작했다. 대강 아래와 같은 느낌이다. 필자 개인적으로는 여기저기 스크롤을 해야 하는 별로 정이 가지 않는 복잡한 화면이다. 하지만, 중요한 사실은 내 취향이 아니다. 실제 이걸 주도해나가는 주인(Owner)이라 할 수 있는 필자의 동료 취향이다. 여기서 말하는 주인은 일을 실제로 하는 일의 주인을 말한다.
moqups 서비스 사용 사례
역할이 아니라 행동이 우선한다
아무도 그를 UI 기획자라 부르지 않는다. 그는 프론트 개발자이고 다른 개발자들이 레이아웃 맞추는 일로 어려워할 때 안내를 해주거나 직접 CSS 작업을 해주는 일을 주로 해왔다. 그러나, 자신이 썩 마음에 들어하는 도구에 자신의 창작물이 담기자 그는 그것을 키워나갔다. 자식같은 혹은 보석같은 내 작품(새끼)인 것이다. 자신이 만든 내용물(Contents)이 중요하지 자기 역할을 뭐라 부르느냐는 이미 중요하지 않는 상황이 되어 버렸다.
필자는 이 상황을 관찰하며 한 수 배웠다. 그걸 제목으로 뽑은 것이다. 역할을 뭐라 부르느냐가 중요한 것이 아니라 그가 어떤 행동을 하느냐가 중요하다. 축구에서 메시가 공격수인지 미드필더인지 포지션을 정의하는 일은 극히 일부 사람들 예를 들어, 통계를 만들어 먹고 살거나 순위를 매겨야 하는 몇몇에게만 중요하다. 그가 어떻게 움직이며 팀의 승리 혹은 팬들에게 훌륭한 경기를 보여주는 일이 축구의 진짜 내용이고 본질이다. 축구만 그럴까? 개발은 다를까? 필자는 그렇지 않다고 본다.
어느새 적응하는 나 그리고 다른 동료들
이번에는 일의 주인인 그가 아닌, 함께 협업하는 필자 일상에서 다시 바라본다. 그가 저 툴에서 뭔가 작업을 하면 메일로 깨알 같은 통지가 온다.
거의 매일 받아보는 깨알같은 통지들
메일함이 저런 소소한 변경으로 가득 차는 것이 번거롭다는 느낌을 받지만, 그의 노력에 상응하기 위해 클릭을 하고 잠시 느린 로딩 시간을 기다린다. 그리고, 눈에 띄는 부분에 대해 의견을 기록한다.
5분짜리 댓글 달기
순식간에 의견을 기록한다. 그도 역시 나처럼 메일을 보거나 아니면 이 서비스의 변경 알림 기능을 이용해서 내용을 확인하고 다시 댓글을 달거나 필자를 찾아온다. 대개 글로는 한계가 있는 소통을 할 때거나 3자 이상의 다자간 소통이 필요할 때 필자를 찾아왔다. 역시 그런 경우도 10분 내외의 짧은 미팅 정도로 다음 단계로 나아갈 수 있었다. 필자외에도 해당 화면 개발자와 UI 기획자가 함께 그의 화면을 보고 글을 쓰고, 모니터상에 화면을 띄워놓고 논의를 한다. 이렇게 차츰차츰 그의 방식에 익숙해져서 관련자들이 협업을 한다. 축구에 비유하면 2대 1 패스나 월패스같은 부분 전술이 만들어지는 것이다.
흡사 전염과도 같이 번져나가는 행동을 보며 이전 글에서 인용했던 HBR 내용이 떠올랐다. 학습이 아닌 듯 하지만 배워가는 모습이다. 요란스럽지 않게 구현한 학습 조직이다.[2]
경계를 넘나드는 협업
질서나 규칙보다는 자발성과 취향을 우선시 하면 어떤 일이 벌어질까? 필자 경험으로 일반화 할 우려를 조심해서 글을 쓴다. 여기서 필자가 배운 바는 자발성과 개취 존중에 따라 자연스럽게 얻는 한 가지 부가 효과다. 아래 그림이 그 예시이다.
UI 기획 내용이 촉발한 작업 절차와 모듈 구분에 대한 논의
이해를 위해서 조금 자세하게 우리 사례를 설명한다. 사례는 할인 규칙을 조회하는 화면 정의 내용이다. 여기서 true/false 값으로 활성화를 시키는 토글 버튼에 의견을 단 내용이 4번 파란 원의 풍선 편집창으로 버튼이 가려진 그림이다. 필자 의견은 할인 규칙(Discount Rule Set)은 상품 공급자가 제공하는 상품에 대해서 할인 조건을 부여해서 할인 가격을 부여한 상품의 집합을 정의한 내용이다. 하지만, 실제 그 집합에 속하는 상품 중에서 실제로 특정 행사(혹은 기간)에 어떤 것은 추가하고 어떤 것은 뺄 수 있다. 이를 위해 할인 규칙은 일종의 템플릿(Template) 형태로 규정해서 실제 상품을 갖고 있는 것이 아닌 집합의 정의만을 나타내자고 한 것이다. 그리고, 판매 행사(중문으로 销售活动으로 표기)라는 레코드 집합에 할인 규칙을 통해 추출한 상품 집합과 그 후 추가 혹은 빼낸 결과를 담자고 제안한 것이다. 그리고, 온라인 컨텐츠로 보여질 이미지(상품 설명 포함해서 편의상 이미지라고 부름)는 상품 집합으로 저장한 레코드와 연결하자고 제안했다. 이 부분에 대해 개발자를 포함하여 3자 논의를 하다 보니 작업 절차와 마이크로 서비스의 경계 구분이 드러났다.
작업 절차와 마이크로 서비스의 경계 구분을 간단히 표현한 그림
작업 절차는 먼저 할인 규칙을 정의하고 이를 선택하면 상품 집합이 결과로 반환되는데, 이 중에서 뺄 상품이 있다면 빼고 집합에 없는 개별 상품을 뽑은 후 별도 할인을 부여해서 최종 상품 목록(대상 상품)을 정한다. 그 후에 이미지(혹은 상품 설명)가 이번 행사(혹은 기간)에 맞게 적절하게 올라가 있는지 확인하는 3가지 작업 단계 정의를 말한다. 그리고, 마이크로 서비스 경계 구분이란 많은 상품에 대해 몇 가지 속성을 통해 빠르게 집합을 반환하기 위해 검색 엔진을 적용한 모듈[3]과 결과물로 판매 대상 상품(할인 가격 포함)을 저장하는 모듈과 구분하는 일이다. 그리고, 이미지는 재사용 여부와 방식을 아직 적용하지 않았기 때문에 당장은 활동 상품 모듈안에 저장해도 무방하다. 하지만, 필자가 개발할 것이 아니기 때문에 관련 개발자들 선택에 따라 구현한다.[4]
사례를 설명한 내용 협의가 위 그림과 같이 UI 기획안에 대한 필자의 의견 개진(Product Owner 혹은 Program Manager 입장)을 보고 관계자(대표 개발자와 위 기획 작성자)가 찾아와 묻고 답하는 과정에서 정리한 사항이다. 일은 작업자의 역할단위로 칼같이 구분되어 진행되지도 않지만, 마찬가지로 반드시 도구의 경계를 타고 흘러가지도 않는다.
도구를 넘나드는 또 다른 사례
이렇게 경계를 자연스럽게 허물며 시너지를 내는 일은 도구를 넘어서도 일어난다. 앞서 소개한 외산 서비스는 moqups라는 서비스를 도구로 사용한 예인데, 필자가 몇 차례 소개한 바 있는 국산 서비스인 두레이를 통해서도 같은 협업 일상이 벌어진다.
두레이를 활용한 소통 사례
동료가 필자 요청에 대해 기록한 내용이 메일 통지로 날라온다. 비동기 소통이 시작되는 것이다. 앞서와 마찬가지로 그의 질문(그가 던진 메시지)에 대해 팔자의 답(나의 메시지)을 제시한다.
두레이를 활용한 소통 사례
그렇다면 반드시 좋은 도구가 필요하냐? 그렇지도 않다. 전통적인 업무 방식인 메일을 통해서도 가능하다. 내용이 중요한 것이니 동료가 필자에게 공유하고 싶어하는 바를 찬찬히 읽어본다. 중국 동료면 번역기를 이용해가면서 그의 고민을 따라가본다.
자기 업무 현황을 공유하는 전통적 기업의 소통 방식
그리고 나서 아래와 같이 일부를 분해하여 필자식으로 할 일을 또 만들어낼 수 있다. 자연스러운 일의 체인이 만들어지는 것, 그것이 바로 시너지 구현이다. ?
시너지 구현 사례 (두레이 활용)
결론
요즘 필자의 멘토이기도 하고, 파트너이기도 한 북경잠자리님이 이런 말을 했다.
“(우리) 소프트웨어 설계에는 호르몬이 없지?”
생물학 전공자로서 기업 경영에 자신의 전공을 응용하는 생활융합인[5]의 자세가 엿보이는 질문이다. 그 질문에 대해 당시는 떠오르는 것이 없었다. 그러나, 지금 답을 할 수 있다.
바로 소프트웨어를 만들어가는 사람들이 시스템과 도구의 경계를 허물고 바람직한 내용을 퍼뜨려나가는 행위를 할 때 그 모습은 흡사 호르몬과 같다. 그래서, 경계를 허물어 경직성을 혁파하고 기존의 유산(Legacy)을 풍요로운 방향으로 키워가는 선순환을 만드는 일이 바로 소프트웨어 세상에 어울리는 변화 관리(혹은 생태계 적응) 실천법이다. 지금 바로 시작하시라.
[주석]
- [1] 우리 조직은 필자의 소속사인 베터코드 주식회사를 포함하지만 정확하게는 북경에서 리테일 클라우드 서비스를 운영중인 파트너회사와 우리 회사의 협업체 자체를 지칭한다.
- [2] 이미 1년 전에도 함께 그리고 가볍게 하는 소프트웨어 설계의 즐거움이라는 글을 통해 과거 이런 조직 문화를 만들어왔던 흔적을 찾을 수 있었다.
- [3] 말단의 마이크로 서비스를 모듈이라고 칭하겠다.
- [4] 물론, 이후에 구조 변경이 필요하면 이를 작업해야 하지만, 여기서 중요한 사실은 개발자가 작업 자체의 주인이기 때문에 명확한 사유가 발생하기 전까지는 개발자들의 결정대로 진행한다는 점이다.
- [5] 융합이 별거인 양, ‘융합’이란 개념 자체에 큰 의미를 부여하는 사람 말고 생활속에서 응용과 메타포 구현을 흔히 하는 사람들을 지칭한다.
글 : 안영회 / 베터코드 주식회사 대표이사. SW 전문지식을 기반으로 유통회사의 디지털 적응을 함께 하고 있으며, 최근에는 중국 커머스 환경에서 자사의 생존역량도 함께 키우고 있다. tony@bettercode.kr
관련 기사
