Hack the process, Hack the team

일전에 테크리드 업무의 한 축으로 테크스택 이야기를 했습니다. 테크스택의 결정도 대단히 중요한 일이기는 하나, 일상 업무 안에서는 관리/운영이 훨씬 많겠지요. 내가 관리/운영을 잘 하는 사람이었다면 어떤 팁을 줄 수도 있었을지 모르겠습니다만 — 안타깝게도 (MBTI 기준) 대문자 P 기질인지라, 일상 관리/운영에서는 겨우겨우 본성을 거스르는 척 하는 정도가 고작인 것 같습니다. 그래도 이 곳은 오답노트이니까, 고민과 경험만 풀어 봅시다.

 

“말 안 듣는 기계는 때려 줄 수라도 있지”

나를 포함한 대부분의 하드보일드 엔지니어들은 기계가 아닌 사람을 대하는데 서투릅니다. 정규표현식Regular Expression 이상 맥락이 있는 언어 처리Context-sensitive language processing이 안된다고 할까요. 배알stack이 콩알만 해서. (/웃었지?)

우리에게 익숙한 소프트웨어 시스템은 입-출력으로 연결된 기능 모듈의 상호 통신으로 구성됩니다. 기능 모듈은 다시 세부 단위 모듈로 나뉘고, 각 연결마다 프로토콜 (이를테면 함수 프로토타입Function prototype이나 API specification)이 결정되어 있어 그에 따라 한 쪽의 데이터를 받아 다른 쪽으로 데이터를 전달합니다.

이제 눈을 들어 사무실을 봅니다. 동료 한 사람 한 사람을 기능 모듈 feature sub-module이라 생각해 봅시다. 여기서 통신 채널은 이메일/메신저/전화/서면/대면 등이 있습니다.

가끔 입력 없이 출력을 뱉는 모듈도 있고, 출력이 절대 나오지 않는 모듈도 있습니다. 혹은 멀쩡히 입력해도 엉뚱한 출력이 나오는 모듈도 있고 같은 프로토콜에 매번 다른 상태를 뱉는 모듈도 있습니다. 아니 근데 전자 시스템이라고 그런 모듈 없는게 아니잖아요? return void 함수 안 만듭니까? 불평은 잠시 접어두고 일단은 각 모듈 특성이라고 합시다. 그게 마음이 편합니다. (데이터시트/스펙 문서가 없어서 모르겠다구요? 에이, 어차피 안 읽을거면서. RTFM?)

이제 커뮤니케이션 채널을 오가는 패킷을 스푸핑해 봅시다 (이를테면 CC 메일 메시지 읽어보란 뜻입니다. 동료 스마트폰에 백도어 설치하라는 말 아니고). 각 서브 모듈이 어떤 컨텍스트에서 어떤 입출력으로 반응하는지를 살펴 볼 수 있습니다.

이런 통신 과정을 미시적Micro으로 검토하면 개별 서브 모듈 특성을 볼 수 있겠지만, 더 거시적Macro인 차원으로 보면 조직 전체의 기능(사업 운영)과 조직의 역할이 보입니다. 조금 시야를 넓혀 팀/조직을 좀 더 큰 단위의 모듈, 혹은 서브 시스템sub system이라 해 봅시다. 팀/조직에 대한 입력(업무 요청)과 프로토콜, 그 유형과 출력까지 걸리는 시간, 안정성Availability 같은 측면들이 눈에 들어올 겁니다.

이해했습니까? 자, 그럼 이제 디버깅과 최적화, 리팩토링, 리스크 분산 및 장애 대응의 시간입니다. 우리에게 지겹도록 익숙한.

 

Hack the process

일은 참 해도 해도 끝이 없습니다. 우선은 팀/조직의 핵심 기능이라 할 수 있는 업무 진행 과정 로그Process log를 백트레이스Back-trace 해 봅시다. 어려울 것 아닙니다. 그리고 이런 질문들을 떠올려 봅시다.

• 최초 트리거trigger는 무엇이며, 입력 초기 핸들러handler는 누구입니까?
• 조직 내 콜백 연쇄callback chain 및 그 레벨은 적정한 수준입니까?
• 단일 프로세스 기준으로, 진행 모니터링progress monitoring이 이루어지고 있습니까? 만약 그렇다면, 어떻게 하고 있으며 그 빈도는 적절합니까? 만약 모니터링을 하지 않는다면, 왜 그렇습니까?
• 출력까지 이어지는 평균 회신 시간Average response time 및 최단/최장 시간은 적절한 수준입니까?
• 병목bottleneck은 어디입니까? 트랜잭션transaction은 원활합니까?
• 데드락deadlock 위험은 없습니까?
• 예외 처리Exception Handling은 어떻게 이루어지고 있습니까?
• 서브 모듈 실패에 대한 리스크 분담은 어떻게 되어 있습니까?
• 각 서브 모듈의 점유율 분담은 어떻게 이루어지고 있습니까?
• 캐싱Cacheing이 가능합니까? 가능하다면, 이루어지고 있습니까?
• 출력 포맷은 적합한 프로토콜로 이루어지고 있습니까?
• 에러 발생율 Error rate은 얼마나 됩니까?

다시 말하지만 팀/조직 업무 프로세스 이야기 맞습니다.

가령 팀원 한 사람이 휴가를 떠났다고 합시다. Sub module not responding의 상황입니다. 관리/운영 방침을 짜 놓았다면 primary module failure에 즉각 secondary module response가 이루어 질 것입니다.

모든 외부로 나가는 커뮤니케이션에 반드시 팀장 승인을 받아야 한다고 합시다. 그리고 커뮤니케이션 케이스가 빈번하게 발생해 팀장 승인을 받으려 실무진이 줄을 서서 기다린다고 합시다. transaction overloaded bottle neck 상황입니다.

별다른 고민 없이 일을 잘 해 오던 팀원/직원에게 비슷한 일을 던져주다 보면 — 혹은 업무 점유율 고려 없이 기능만 고려해서 업무를 던져주다 보면 업무 분담의 불균형이 발생합니다.

Redis 같은 인메모리 캐시는 어디 한 군데 붙일 거 없나 호시탐탐 노리는 팀장 중에서도 내부 업무 프로세스가 캐싱되고 있는지 (그리고 캐시가 공유되고 있는지Shared cache) 신경 못 쓰는 경우가 많습니다.

사람으로 구성된 조직을 서브 시스템 모듈로 두고 내부/외부 모듈 간 입출력 통신 및 처리Processing의 관점에서 보면, 업무 처리 과정의 여러 측면들이 보일 겁니다. 하나하나 예를 들어 보면 책 한 권 쓰기에도 모자랍니다. 케이스도 끝도 없고.

 

Team hacking

이번엔 개별 프로세스에서 눈을 돌려 기능을 처리하는 서브 시스템, 팀/조직의 구조를 봅시다. 기능 범위, 점유율/가동율, 오차율, 응답 성공율/실패율, 오차율… 생각해 볼 수 있는 가짓수는 수도 없이 많습니다.

프로세스 해킹이 기능 최적화와 디버깅의 영역이라면, 팀 해킹은 리팩토링에 비유할 수 있을 것 같습니다. 불필요한 처리 단계가 있으면 제거하고, 병목이 있으면 이중화 합니다. sequential transaction latency가 걸리면 비동기 병렬 처리 가능하도록 업무 단위를 나누어 봅니다. 그리고 이 과정에서 효율성 — 속도와 안정성이 트레이드 오프라는 것 또한 잊지 맙시다.

서브 기능 모듈(사람)마다 담당 기능, 특성은 서로 다릅니다. 하지만 대체로 기능상 오버래핑을 만들지 못할 것도 없습니다. 단순 효율성을 최대로 고려한다면 오버래핑을 줄여야 하겠지만, 안정성을 생각한다면 오버래핑을 늘려야 합니다. 보통 (소프트웨어 시스템과 달리) 인력이란 서브모듈은 실패율Fail rate과 오차율 Exception/Error rate이 높고, 컨텍스트 스위칭 비용 context switching cost이 매우 큰 특성이 있습니다. 때문에 일반적인 업무에서 (다시, 소프트웨어 구조와 달리) 기능 오버래핑을 통해 높은 실패율/오차율에 대비하며, 모듈당 지정 태스크의 갯수/가짓수를 가급적 줄여주는 편이 효율적이라 봅니다.

그리고 이 과정에서 간과할 수 없는 측면이 조직 내 라뽀Rapport 형성, 조직 문화와 같은 감성적인 측면입니다. 계속 기능 모듈, 서브 시스템으로 설명해서 헷갈릴지 모르겠지만 — 그 서브 모듈은 감정이 있는 동물이고, 그 감정 상태에 따라 퍼포먼스 수준이 크게 좌우됩니다. 멀리 갈 것 없습니다. 당장 우리 자신부터 — 평소 공부/책 읽기를 그리 싫어하지 않았더라도 — 시험 직전에 공부하려면 책상 청소가 재미있지 않습니까?

“일은 이러나 저러나 어차피 힘듭니다.
그러니 기왕이면 웃으며 하는 편이 낫습니다.”

개인 지론입니다. 어느 정도 일을 하면서 관심을 두고 살펴보면 그래도 조금씩은 각 한 사람(기능 모듈) 특성을 파악할 수 밖에 없습니다. 모티베이션 메커니즘은 무엇인지, 가치 판단에 대한 우선순위/결정 트리 구조가 어떤 식인지, 좋아하는 것은 무엇이고 싫어하는 것은 무엇인지. 무엇을 잘 하고 어떤 실수/잘못을 많이 하는지. 사람 마음 알 수 없다지만, 기반 기질은 어지간해선 쉽게 바뀌지 않는 것 같습니다. 나 스스로 그런 것처럼 말입니다.

 

물론 이 모든 것들과 비슷한 우선순위로, 리드 본인의 시간과 노력 (체력)도 똑같이 한정적인 자원이라는 점을 잊으면 안됩니다. 특히 의욕이 너무 앞서다 보면 리드 그 자신이 가장 먼저 소진되기 쉽습니다. 팀/조직에서 가장 비싼 단위 시간, 가장 비싼 단위 노동력은 단연 리드 본인입니다.

이쯤에서 나와/내 조직에서 일 해본 경험이 없는 분들은 정말 이런 관점에서 조직을 운영/최적화를 해 보았는가, 궁금할 수도 있겠습니다. 네 뭐 몇 가지 해 봤습니다. 가장 자랑하고 싶은 사례가 정규 보고를 완전히 없애는 실험이 있는데, 안 그래도 말이 많았으니 따로 떼어서 이야기하겠습니다.