용병팀과 미션팀 - [인스파이어드] 책을 읽고

인스파이어드 - Yes24

 이직간에 약  2주간에 휴가중에 마티케이건의책 '인스파이어드' 라는 책을 읽었다.

사실 이 책은 이전회사 재직 중에 읽어보려고 했던 책 중에 하나였으나, 그 당시 '인스파이어드' 책을 약 50페이지 정도 읽을 적에 나에게 맞지 않는 책이라 판단하고- 책을 알라딘에 팔아버렸다.

 

그럼에도 불구하고 다시, 이 책을 편 이유는 최근 끊임없이 고민하고 있는 부분에 대한 해답을 알려줄거라는 믿음 때문이였다.

 

과거에는 인스파이어드 책이 맞지 않았다.

왜 이전직장에서는 이 책을 읽으려고 했을 때 맞지 않았다라고 생각했을까? 

'인스파이어드' 책에서는 프로덕트(Product) 라는 부분에 초점을 맞춘다.

'우리가 프로덕트를 만드는 건 엔지니어, 디자이너를 포함해 많은 이해관계자가 서로 협업을 통해 하나가 되어 집중해야되고 더 나은 프로덕트를 만들기 위한 노력을 멈추지 않아야 한다.'

 

 이 책에서는 위 내용을 조금 더 체계적이고 효율적인 방법을 제시해주고 있다. 나는 이부분이 맨 처음 이 책을 접했을 때 나랑 맞지 않는다라고 판단했었다. 그 이유는 명확했다. 이전직장에서 유지보수하고 있었던 프로젝트는 약 10년동안 유지된 프로젝트로서 약 76만 라인의 Java 소스코드로 이루어져 있어 프로덕트매니저라는 말이 어색할정도로 한 사람이 커버해야될 도메인이 너무 거대했었다. 그러므로, 도메인을 이해한다 라는 말은 불가능에 가까웠고, 이슈가 발생할 때 그 시점부터 이슈에 관련된 도메인을 익히는 것에 급급했었다. 또한 만약 신기능을 개발해야될 일이 있더라면, 그건 내가 속해있는 팀이 아닌 신기능만 개발해주는 팀이 따로 존재했다.

 

 결과적으로, 프로덕트 라는 말이 나의 환경과 맞지 않았기에 나는 이책을 덮었었다.

 

도메인과 프로덕트

 이전 직장을 나오기 직전까지 나는 이전 직장의 계열사에서 약 3주간 파견 근무중이였다. 파견 근무를 하게된 이유는 계열사 근무지에서 SI 업체에서 만들어 놓은 코드에 문제가 많기 때문에 이를 해결하기 위해 본사 직원이였던 나를 포함한 몇몇이 파견근무로 가게되었다.

 약 2주간 계열사 도메인을 학습하고 드디어 코드를 마주쳤을 때, 경악을 금치못했다.

 

먼저, 스프링부트 기반의 프로젝트에 도메인을 표현해주는 패키지가 존재하지 않았다. 즉, 도메인이라는 개념이 없다. 앞서 언급한 SI 말고 또다른 DBA 외주 업체가 만들어 놓은 DB 테이블을 보고 해석해가면서 데이터를 CRUD 하는 것. 이것이 바로 도메인에 해당하는 영역이였다.

실제 프로덕트 코드 중 일부

 흔히 우리는 도메인이라는 용어와 프로덕트라는 용어를 혼용해서 사용한다.

백엔드 개발자에게 도메인은 내가 해결하고자 하는 영역을 의미하지만, 또다른 의미로는 내가 일하는 분야에 배경지식이라는 생각도 있다. 그럼 프로덕트는 무엇일까? 프로덕트는 인스파이어드 책에서는 동작되어지는 서비스를 의미한다고 말하고 있다. 요즘 디자이너를 칭할 때는 프로덕트 매니저 라는 말을 많이 사용하더라.

 

파견 근무를 하면서 도메인에 대한 이해가 어느정도 확립됐을 때, SI 업체가 만들어 놓은 코드를 보면서 나는 심각한 고민에 빠졌었다. 내가 무엇을 하려고 하는가? 내가 할 수 있는 것이 어떤 부분인가? 이 코드를 바꿀수 있는 것인가? 코드를 보고 있는데, 이런저런 생각이 끊임없이 고민되니 나중에는 타이레놀을 하나 먹어야 될 정도였다. 3년 간 본사 근무할 적에는 모든 프로젝트에 도메인이 굉장히 중요하니- 항상 도메인을 코드로 표현하는 것을 강조해왔기 때문에 더 많은 고민에 빠지게 되었다. 조영호님의 과거 트랜잭션스크립트 패턴과 도메인 모델링 패턴을 비교해서 약 1시간 30분동안 강의를 했던 적이 있었는데- 이를 실제로 마주하게 되니 생각보다 더 큰 충격이였던 것 같다.

 

한편으로 감사했던 부분은 이런 코드를 내가 마주칠수 있게 되었다는 점, 리팩토링을 언제, 어떻게 하면 좋은지에 대한 고민 등- 여러 생각을 할 수 있게 해준 부분에 대해서는 감사하다. 실제로 이 코드를 보고나서 리펙토링에 대한 정의도 다시금 정의할 수 있었다.

 

도메인의 중요성

 이 책을 읽으면서 가장 많이 고민 했던 부분은 도메인에 대한 나의 생각을 확립하는 부분이였다. 우리 누구나 도메인에 대한 중요성은 알고 있다.

 그러나, 그 중요성에 대해서 깊이있는 고찰을 하지 않는 것 같다. 아마도 나만의 생각이지만, 내가 '개발자'라는 모자를 쓰고 있어서 그런게 아닐까? 라는 생각을 한다. 더 나은 도구(라이브러리)를 익히고- 언젠가는 사용할 수도 있다는 생각에 도구 하나하나를 익혀오다보니, 우리는 생각만큼 도메인에 대한 중요성을 언급하지 않았던게 아니였을까 싶다. 적어도 나는 그랬던것 같다.

 이전 직장에서 76만 라인의 엔터프라이즈급 프로젝트와 파견근무를 하며 SI업체가 작성한 프로젝트 등 2개의 거대한 프로젝트를 마주하면서 느꼈던 부분은 여전히 나는 내가 다뤘던 도메인을 깊이있게 살펴보지 못했다 라는 부분이였다.

 

 로버트 마틴의 클린코드 책에서 좋은 코드에 대한 이야기가 나온다. 그 책에서 말하는 좋은 코드는 다음과 같은 원칙을 말한다.

 

- 코드를 처음 보는 사람도 쉽게 따라가며 읽을 수 있을 것

- 내 의식의 흐름을 기억하지 않아도 언제든 원하는 기능을 다시 찾아갈 수 있을 것

- 5년 뒤에 내가 다시 보더라도 금세 이해할 수 있을 것

- 새로운 기능을 추가하더라도 크게 구조변경이 없을 것

 

클린코드가 말하는 좋은 코드에는 사실 어떤 최신 기술이나, 도구가 사용되지 않음을 알 수 있다. 

 

용병팀과 미션팀

이 책에서 여러번 언급되는 부분으로 용병팀과 미션팀에 대한 내용이 나온다. 이 부분에서도 나는 공감되는 부분이 더러있었고, 앞으로 내가 일하게 될 회사에서 어떤 마인드셋을 정비하면 좋을지에 대해서 많은 힌트를 얻을 수 있었다.

우리가 원하는 것은 용병팀(Team of Mercenary)이 아닌 미션팀(Team of Missionary)이다.

용병팀은 쉽게 SI 업체라고 보면 된다. 회사에 대한 오너쉽이나 애사심은 존재하지 않고 오직 누군가 시키는데로 움직이는 팀을 말한다. 그러기 때문에 이들은 어떤 비전또한 존재하지 않는다.

미션팀은 목적단위의 조직을 의미한다. 그리고 용병팀과 가장큰 특징이라면, 프로덕트에 대한 믿음을 가지고 해결해야될 미션에 모든 이해관계자가 집중한다. 

이 두가지는 분명한 차이를 가지고 있다. 이 글을 읽고 있는 사람은 자신이 어디에 속해있다고 생각드는가? 나에게는 지난 나의 3년동안 생각만큼 미션팀에 속해있다는 생각이 없었던것 같다. 용병팀과 미션팀 그 어중간한 중간쯤...?

이런 부분을 고민하다보니- 내가 앞으로 헤쳐나가야할, 고민해봐야할 부분도 명확해졌다. 이번에 좋은 기회로 이직을 하게되면서 미션팀이라는 큰 책임과 자유를 얻게 되면서 주도적으로 나의 길을 만들어볼까 한다.

분명... 이전 회사에서 주도적으로 움직였던 면모가 있었는데, 환경이 무섭다고- 약 3년이 지나니까, 열심히 회사 문화를 바꾸려던 나의 모습에서 점점 움츠려드는 내 모습을 발견하게 되더라.