이직, 조직과 시스템

STRIX로 이직한 뒤 인프라 구축 및 아키텍트, 코더로서의 생활에서 받은 영감들
김동욱

이 강의는 아직 집필중입니다.

조직에 대한 이해

세상의 많은 부분은 평형 상태가 아니며, 일반적으로 평형에서 멀리 떨어져 있다. 세계는 끊임 없이 진화하면서 되먹임을 하고, 새로운 패턴을 만들어 오래된 것을 밀어낸다. 그리고 미래에는 이것도 결국 밀려난다. 사람들은 부를 얻었다가 잃으며, 어떤 경우에는 평생동안 여러번 그런다. 매년 회사들이 만들어졌다 사라진다. 그러나 이러한 과정 속에서, 복잡성 뒤에 어떤 질서 잡힌 과정이 작용함을 보여주는 단순한 수학 법칙들이 그 모습을 드러내기 시작한다. 인간 세상도 물질 세계 못지 않게 수학적인 정확성을 가진 법칙의 지배를 갖는 것이다.
- 사회적 원자, 마크 뷰캐넌

인력만 있는 조직

8년이 가까이의 프리랜서 경력에서도, 개인 사업을 할 때도 나는 거의 항상 혼자서 제품을 만들어 왔다. 간혹 겪었던 "협업", 프리랜서로서의 파견 근무나, 이전 직장에서의 프로젝트에서도, 학창 시절의 팀 프로젝트에서도, 나에게 "협업"이란 개인으로써 구현하기 힘든 시스템을 조직을 통해 완성하는 것이 목적이 아니었다. 단지, 인터페이스를 명확히 분리 설계하여 나의 생산성을 높이고 개인간의 책임 범위를 명확히하는 “분업” 정도에 불과했다.

나의 개인주의적인 성향이 "협업"에 대한 이러한 인식의 원인일 수 있다. 하지만 지금 생각해보면 조직이 개인보다 나은 점에 대한 이해의 부족이 그 원인이 아니었나 싶다. 나의 이기적이고 또 협소한 "조직"에 대한 인식은, 내가 결국 리더로서의 위치에 올랐을 때 팀원에게 좋지 않은 영향을 끼치게 된다.

5만명 이상이 사용한 헬스 케어 앱 (토이 프로젝트)5만명 이상이 사용한 헬스 케어 앱 (토이 프로젝트)

졸업 후 창업한 "벤젠"이란 회사는 최초에 대학 동기와 함께 2인 회사로 시작했다. 우리는 본격적인 사업을 시작하기도 전에 창업이라는 공통 관심사에 매료되어 졸업 이전부터 함께 생활했다. MVP를 기획, 개발하기 이전에 여러 토이 프로젝트를 진행했는데, 우리 모두에게 자유롭고 창의적인 생활은 나쁘지 않았다. 다만 내가 감지하지 못하던 “조직적인” 문제가 크게 불거져, 팀원이 나를 곧 떠나게 되었다.

제품을 함께 개발하는 와중에 동업자의 코드가 내 눈에 상당히 거슬렸다. 나는 당시 5년 이상의 필드 경력을 갖고 있는 반면, 그는 막 컴공과를 졸업했을 뿐, 엔드유저 어플리케이션이나 웹 서버의 구현에 대한 경험이 상대적으로 부족했다. 내가 주도적으로 뼈대 코드를 작성해나가고 그에게 부분적인 기능들을 위임했지만, 실상 그의 동의 없이 내가 코드를 뒤엎기 일쑤였다.

그가 이 문제에 대한 불만을 토로했을 때 나는 이것이 단순히 코딩 스타일의 충돌, 제품 개발에서의 작은 의사소통의 문제라고 생각하고 그쳤다. 하지만 이 문제가 불거져 결국 그는 팀을 떠나갔다. 지금에서야 생각하면 그가 나를 떠나간 이유는 단순한데, 내가 리더로서 "조직"을 구성하지 못하고 팀원에게 "신뢰와 위임"을 제공하지 않았기 때문으로 생각한다. 그는 아마 코드 쪼가리를 잘짜고 못짜고의 문제 때문이 아니라, 스스로 "조직"에 속했다는 느낌을 받지 못했기에 당연하게도 팀을 떠난 것이 분명했다. 나는 당시에는 이 잘못을 이해하지 못했고, 이러한 “조직” 운영의 비효율은 이후에도 반복되었다.

시스템이 있는 조직

첫 "협업"의 실패, 또 첫 아이템의 지원 사업 탈락 즈음해서 얼마 없던 자본금이 모두 떨어졌다. 나는 경력상 마지막이라 다짐하며 외부 프로젝트를 수주했다. 나에겐 1인 개발자로서 금액, 공수 면에서 거대한 프로젝트였다. 삼성에 납품되는 머신러닝 훈련 소프트웨어와 그 엔드 유저 인터페이스였는데, 나는 모델 및 훈련 엔진 관리를 위한 유저 인터페이스와 NLP 훈련 데이터의 버전 관리 시스템을 맡았다.

gRPC, nodejs/loopback, angulargRPC, nodejs/loopback, angular

git을 이용한 훈련 데이터 버전 관리git을 이용한 훈련 데이터 버전 관리

명확하게 설계된 인터페이스와 구체적인 기획 덕에 나는 공수에 대한 부담은 느끼지 않았다. 다만 업체에서는 나에게 초기 몇주간 파견 근무를 요청했다. 당시 서울대입구역에서 판교역까지의 왕복이 부담스러웠지만 일을 따야했기에 그렇게 협의하고 몇 주간 판교역으로 출근했다. 구내식당에서 밥먹고, 마련해준 자리에서 일하고, 5시쯤 퇴근하는 와중에 50가까이된 CTO와 가끔의 의사소통이 일과의 전부였다.

그 기업의 업력은 몇년 채되지 않았는데, 인원이 약 50명가까이에 달했고 그중 대강 40명 정도가 개발 및 연구직이었다. 난 그 기업의 BM이나 조직 체계, 대표의 자본력보다는 그렇게 많은 개발자들이 어떻게 공통의 프로그램들을 만들어나가는지가 궁금했다. 나는 CTO의 책상과 모니터, 회의를 어깨너머로 구경하기 일쑤였다. 난 여전히 "조직"이라는 불투명한 정체보다, “대규모 인원이 투입될 때의 개발 프로세스” 정도에 관심을 가졌다. 나의 첫 개발팀의 불협화음의 원인은 개발 프로세스에 있다고 생각했기 때문이다.

당시에 내가 CTO에게 받은 인상은, 하드웨어, 클라우드, AI, 네트워킹 등 모르는 것이 없는 시니어 개발자, 훌륭한 인터페이스를 가이드하는 아키텍트, 팀원들의 동기 부여와 제품의 완성도를 위해 커밋을 일일이 리뷰해주는 정성있는 상사였다. 아하, 이들처럼 “칸반 보드” 같이 업무를 쉽게 명문화 할 수 있는 도구를 활용하고, 투명한 "버전 관리"와, 엄격한 "브랜치 정책", PR에 대한 엄격한 “코드 리뷰” 등. 체계화된 개발 프로세스를 가지면 협업이 잘 되나 보구나. 당시에 받은 인상은 이 정도로 갈무리되고 말았다.

무엇이 시스템을 만드는가

이후 반년 이상의 시간이 지나고, 웹 서비스 풀스택에 대한 강의를 진행하고 책을 쓰며, 홀로 온라인 서비스를 운영하고 있을 때였다. 지금의 Codeflow 서비스의 전신인 "벤젠 워크샵"이라는 이름의 영리 서비스를 운영하고 있었다. 당시에 “벤젠 워크샵” 웹 서비스는 부업으로 진행하던 오프라인 프로그래밍 교육에 사용 할 교재를 기록하던 용도였다. 완성된 교재에 대한 반응이 나쁘지 않았기에, 오프라인 강의를 동영상으로 녹화해 판매하려는 계획을 세우고 서비스를 리팩토링하기로 했다.

"웹서비스 풀스택 입문" 교재 (4만 다운로드 이상)"웹서비스 풀스택 입문" 교재 (4만 다운로드 이상)

벤젠 워크샵 4.png벤젠 워크샵 4.png
벤젠 워크샵 3.png벤젠 워크샵 3.png
벤젠 워크샵 2.png벤젠 워크샵 2.png
벤젠 워크샵 1.png벤젠 워크샵 1.png

서비스를 리팩토링 하기 전에, 나는 당시에 "조직"이 "개발 프로세스"에서 기원한다는 생각에 매료되어, 1인 기업임에도 개발 조직을 위한 인프라에 빠져들었다. 몇 달간 어플리케이션 가상화/배포 기술(docker, ansible 등), 컨테이너 오케스트레이션(kubernetes) 및 CI/CD 파이프라인 등, 개발 조직에서 사용하는 다양한 유틸리티들에 대한 공부하고, CircleCI, Gitlab, JIRA, private docker registry, Gsuite 등 각동 유료 서비스까지 결제해가며 개발 조직을 위한 인프라를 실험적으로 구축해보았다.

한참 뒤에는 AWS, Azure, GCP 등 이 동네 저 동네 클라우드를 파고들면서 k8s 인프라를 구축해보다가, 몇달이 지나고나서야 리팩토링을 시작했다. 사업은 내팽개치고 개발자로서의 공부에 빠져 너무 많은 시간을 보냈다. 개발을 한참 진행하다가 "아, 사업을 해야지"라는 생각이 떠올랐다. 본질적으로 기존 서비스와 전혀 달라진 바가 없는 결과물을 보며 고민에 빠졌다.

codeflow-beta (React, GraphQL, Nodejs)codeflow-beta (React, GraphQL, Nodejs)
codeflow-beta2codeflow-beta2
codeflow-beta3codeflow-beta3

홀로 커리큘럼을 기획하고, 동영상을 녹화, 편집하며 등록하는 부담이 너무 컸다. 이렇게 해서야, 변화가 빠른 IT 분야에서 지속 가능한 수입을 달성 할 수 있는 컨텐츠를 만드는 것은 불가능에 가까울 것 같았다. 교육 컨텐츠를 개발하는 것을 너무 쉽게 생각했다는 후회가 들었다. 또 1인 개발자에게 불필요한 수 많은 프로세스와 덜떨어진 제품 기획을 보면서 나는 근 일년이 넘게 일을 위한 일만 하고있구나라는 자책에 빠졌다.

괴로운 와중에 기존 서비스를 단순히 리팩토링하는 대신에, 강의를 작성하고 공유 할 수 있는 플랫폼으로 전환하자는 아이디어가 떠올랐다. 간신히 고독한 첫 창업의 끈을 붙잡고 있었다. 그래 어찌됐든 "누구나 강의를 등록하고, 구독료를 결제 할 수 있는 프로그래밍 학습 플랫폼으로 전환만 해놓자!"라는 일념으로 다시 기획에 치중하려고 노력했다. 그러던 어느날 한 수강생한테 이메일이 왔다.

Codeflow 서비스의 기획을 어느 정도 마치고, 한창 개발에 몰두하고 있을 때였다. 한민호라는 카이스트 석사생이 자신을 벤젠 워크샵 구독자라고 밝히면서 벤젠에서 인턴으로 일하고 싶다는 이메일을 보내왔다. 민호씨는 본인의 월급을 학교에서 지불해줄 수 있으니, 나만 원하면 일을 돕고 싶다는 의사를 밝혔다.

사업가에게 치명적인 문제지만 여전히 나는 "인력"을 "조직하는"일에 자신이 없었고, 심지어 그런 능력을 배양하는 과정 자체가 부담스러웠다. 1인 개발사에 대한 환상일까? 소프트웨어 개발 경력이 있는 고급 인력이 무급으로 일을 돕겠다는 제안에 부담스러움이 먼저 다가왔다. 나의 로드맵과 기획을 공유하는 커뮤니케이션이 필요하고, 나 또는 그가 서로 미처 생각하지 못했던 일들이 마구 뒤엉켜 오히려 일정을 늦추지 않을까?

사업은 방향성을 잃었고, 나는 운영 자금의 압박으로 제품의 완성에 급급하여 날밤을 새기가 일쑤였고, 다다음달 생계를 걱정하고 있었다. 모든 신변잡기와 사업 외적인 일들이 내 시야를 가리고 시스템을 조직하고 기름칠 여유가 없다고 소리치는 것 같았다. 나는…

조직의 설계

모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다.
- 멜빈 콘웨이

공통 언어

  • 비지니스와 개발자
    도메인 지식에 대한 공유. 의사결정권과 책임이 필요한 것. 기획자냐 QA냐. HEAD인가? 상호작용의 난점.
    정말로 도메인이 겹치지 않는 경우 몰라도 될 수 있어. 그런데 같은 용어를 서로 사용하는데 그 의미와 도메인의 공유가 안된다면 잘못된 것.
    언어가 공유되지 않는 것을 Okay한다면 거기에서 부터 상호작용은 망가지고, 서로 다른 이해로 인한 엔트로피가 증가함. 언어부터 공유해라

  • 언어와 common 지식, 도메인의 공유
    인프라부터 따라서 소프트웨어나 조직 체계에는 최소한의 백그라운드만이 존재해야한다.
    그리고 모든 백그라운드는 common language로 표현되어야하며, 신뢰할수없는 "개인"에서 파생되는 것이 아니라, 전문가 "집단"의 오랜 검증과 연구에서 나온 성과를 응용해야한다.
    조직이 만드는 시스템의 큰 틀은 조직의 언어로 기술되어야한다.
    부위별로는 전문적인 얘기가 나와도 좋다. 다만 부위간에 소통에 자신의 언어를 사용하지 말고, 처음보는 사람도 알아먹을 common한 용어를 써라.

전문화된 장기들

  • 조직 설계, 인간의 장기는 오랜시간에 걸쳐 디자인되어 세분화되었다.
    개발팀 / 기획팀 이것이 올바른 형태의 장기인가? 왜 장기를 한번 설정하면 진화하지 않는가?
    외부 요인, 환경, 또 output "제품"에 아주 밀접하게 붙어있는 연약한 형태의 장기와 산출물들.
    백엔드/프론트엔, 여러 서비스들에 붙어있는 파편화된 코드와 리소스들.
    이것이 기업이라는 생명체의 가장적합한 형태인가? 생명력을 검출하는 프로토타입으로써는 두말않겠다만, 균형을 갖는 기업으로써는?

  • 그래, 그래서 공통 언어를 이용한 대화가 필요해?
    경계에 대한 협의, 책임 소재의 명확. 이는 문제시 고장부위를 정확히 찾기 위함임 자신이 생산하는 산출물의 명확한 테두리와 짧더라도 명확한 문서와 공유 필요해. 같은일을 다시하지 않고 비슷한 일을 합치기 위해선 상호작용 해야하거든.

권한과 책임 부여

민주적? 가족적? 수평화 조직?
수평화 조직은 책임을 명확히하며 책임소재에 따라서 움직이고 인사를 평가받는 것이지 책임을 모두가 공유하고 일도 공유하는 것이 아니라.
조직.시스템은 결국에 엮이고 엮여 그래프가된다. 하이어래키가 아니여도. 단순한 celled-map이 되지 않는다.
명확한 책임을 주고 피드백 할 필요가 있다.

방어기제

모든 생명체에는 방어기제가 있다. 소프트웨어 조직에도 감사가 필요하다.
개인이라는 시스템의 유닛은 문제와 장단, 진행정도, union을 한눈에 관망 가능한 제어하기 쉬운 성향이지만.
회사라는 조직의 유닛과 결합에는 다양한 문제가 발생하고, 기본적으로 단절되어있다.
이 단절은 개개인의 성향이나 능력에 기초하는 것이 아니라, 인사정책과 체계화된 조직체계로써 풀어야한다.

조직의 확장

기업은 개인에게 임무를 할당할 것이아니라, 시스템, 조직을 구축하고 단지 책임과 권한을 부여해야한다. 또 개인은 자신의 하부시스템을 구축하고 항상성을 만들어나가야 한다.
껍데기뿐인 프로덕트를 주지 말고. 시스템화가 가능한 일감을 주어라. 전체적인 수준에서 관망해야.
막내에게도 자신만의 하위 부서를 주어라. 단순한 output이 아닌 항상성을 가질 잠재력이 있는 시스템의 장기를 구축 할 수있도록 하라.

조직의 엔트로피

비조직화를 허락하는 조직

시스템의 유지보수와 재사용, 상호작용하지 않는 조직, 비조직화를 허락하는 조직, 엔트로피의 증가
소프트웨어는 찾아갈 정답이 있다. 마찬가지로 시스템에는 정답이 있다. 아니 정답이 아니더라도 오답을 피하는 방법은 있다.
현실적인 벽, 시간, 일정. 정말? 시간이 부족해서 못한다. 시간이 부족하니 체계화하지 않고 실뭉치를 투영하겠다. 이후에는 알아서 되겠지.
하지만 이 변명은 개인에게서 초래되는것이 아니라 개개인이 안착해있는 시스템에서 초래된다.
명문화되지 않은 기업의 문화가 동일한 결과를 만들고 엔트로피를 증가시며 효율을 떨어뜨린다.
기술이든 뭐든 조직에서 예외를 허락하는 순간, 그것은 피드백 가능한 시스템이 아니다.
성공했든 실패한 시스템이든, 시스템으로써 존재해야 피드백이 가능하고 개선될 여직 ㅏ있는것.
하지만 시스템과 규칙으로써 존재하지 않고 개개인의 수많은 변수로써 회사가 존재한다면 정량적인 피드백과 개선이 힘들다.
개발 내외적으로 계속해서 엔트로피를 감소시켜야한다… if, dev/prod 이미지 이중화, 하드코딩, 날코딩 하지말고, 껍데기가 아닌 기능을 만들으라는 말
작은 수준의 라이브러리는? 공유할 필요가 있을때 공유하고, 공유하려면 그 범위를 명확히하고, 자신이 책임소재를 갖는 시스템으로 생성해라.
만들고 만들고 또만들고 노노 자산을 만들고 공유하고 시스템화하고 함께 키워나가라.
경계 없이 끝도 없이 커지는 무언가가 바로 암세포다.

개인에게 의존하는 조직

시스템에 매몰되는 인력, 인력에 의지하는 시스템
시스템도 좋지만 그 말단의 인원이 시스템을 운전하는 사람들이되어야지 시스템의 부분이되면 안됨.
모두가 시스템을 만들어나가고 확장해나가야하지 구 시스템에 매몰되어버리는 형태가 되면 안됨.
책임은 누가 지는가? 인사고과가 존재하기는 하는가?
법인은 개인에게 의존해서는 안된다. 자기 시스템을 구축하는 자기보존의 성향이 법인 자체에 녹아있어야한다.
개인은 모두 배제되고, 기계식 시계처럼 완전한 하나의 시스템이 되어야한다.
그곳에서 개인의 노동의 의미는 또 다른 맥락에서 해석되어야 할 것이다.
나의 이러한 주장은 개인의 삶이나 노동의 가치를 떠나, 기업으로써, 하나의 집단 시스템으로써 추구해야할 가치를 다루고있다
집단에서의 개발 문화나 방향성은 개인의 능력이나 성취가 아니라 전체적인 수준에서 관망되어야한다.

시스템의 항상성

시스템이 비조직화되는 경우 그 항상성은 전체를 최악으로 이끌어간다. 소프트웨어나 조직의 결함의 무서운 점은 부채로 누적되어 기하급수적으로 성장하여, 어떤 점이 문제인지 조차 판단할 수 없는 지경에 이르는 점이다.
그대한 소프트웨어일수록 더욱 그렇다

시스템이 조직화되는 단계에 있는 경우 그 항상성은 계속해서 엔트로피를 감소시키며 균형상태를 찾고 내부 생태가 안정화된 경우, 새로운 환경에 적응해 나가고, 몸집을 불릴 여유 자원을 얻는다. 자기 복제, 항상성, positive 피드백. 존재한다는 것은 생존했다는 것. 소프트웨어가 존재하지 못하고 삭제된다는 것은 실패한 코드다. 재사용되고 계속 찾계되는 코드, 모듈, 서비스는 현재로써는 자기복제에 성공한 코드다.

진화하는 시스템

인간의 DNA마냥, 지속가능하고 확장성있는 좋은 라이프사이클을 가진 소프트웨어가 존재한다. 성공에 가까운 시스템이 되는것.
그럴수도 있다만, 진화되지 않는 시스템은 패망한다. 왜 진화하지 못하는가? 왜 성장하지 못하는가? 성장하지 못하는것은 망해가고 있다는 것.
자기 복제를 이루는것으로도 훌륭하지만 돌연변이가 있어야한다. 돌연변이는 체계에서 발생한다. 체계가 존재하지 않는 곳에서의 돌연변이는 단순한 엔트로피일 뿐
임원이든 말단이든 그 책임과 관계 없이 개인은 조직에서 부품이 될 수 밖에 없다. 그 체계를 설정하고 관찰, 재설정하는 임원급 또는 고위 사원의 역할이 막중하다.
잘돌아가는 회사, 잘돌아가는 시스템, 재활용가능한 회사의 자원은, 거대 조직이나 작은 조직이나, 자연의 섭리를 벗어날 수 없다
시스템은 흥망성쇠 안에서 자기보존을 위해 계속하여 조직화하고 진화해야한다. 헤드쿼터는 이러한 조직의 체계화와 엔트로피 감소에 중요 자원을 투입해야한다.

목차
2. 20대 후반
저자

김동욱

개발 경력 약 10년, 전문 분야는 웹 및 각종 응용 소프트웨어 플랫폼입니다. Codeflow를 운영하고 있습니다.

09월 30일 업데이트

지원되지 않는 웹 브라우저거나 예기치 않은 오류가 발생했습니다.