2021 조직 생산성 개선을 위한 제안

나는, 우리는, 어떻게 하면 더 생산적일 수 있을까?

현재 근무하고 있는 곳에 입사한지 만 1년 2개월이 되었습니다.
만약 내가 현재 몸 담고 있는 조직의 리더라면, 조직 차원에서의 생산성 개선을 위해
어떤 액션을 취할 수 있을지 고민해왔던 결과를 기록해보고자 합니다.

막연하게 종종 이랬으면 좋겠다 하는 생각은 있었지만,
박재성님의 이 영상을 보고 확신을 가질 수 있었습니다.

리더가 된 뒤에는 늦는다.
리더의 역량은, 주니어때부터 준비해야 한다.

 

---

1. 지식의 공유

1-1. 각 솔루션 별 사용자 행동에 따른 데이터의 흐름과 관여된 API들의 역할을 문서화해야 합니다.
1-2. 1인 1솔루션 체계를 최소 2인 1솔루션 체계로 구성하되, 1인은 다른 1인을 리드해줄 수 있어야 합니다.
1-3. 작업 결과를 코드리뷰 하며, 도메인 지식의 전파, 코드 품질의 전파가 이루어져야 합니다.

 

현재 근무하고 있는 회사는 25년여된 솔루션을 운영하고 있습니다.
급격한 변화나 완전히 새로운 기능의 추가 보다는, 기존 프로세스를 유지보수하는 것이 대부분의 업무입니다.

그러나 아주 오래된 코드이고, 관련 문서가 없어서 
작업을 담당하게 된 사람은 매번 스스로 코드를 통해 모든 프로세스를 직접 분석해야하며,
그 과정에서 효율성 저하와 도메인 지식 부족으로 인한 실수가 발생하고 있습니다.

물론 코드 분석은 스스로 해내야 하지만,
우리 솔루션에서만 존재하는 로컬 규칙들과 Flow에 대해서는
선제적으로 안내가 진행된다면, 이 분석 과정이 훨씬 원활할 것입니다.

그리고 그 인원이 휴가일 경우, 해당 건에 대한 대응이 어렵고,
만약 퇴사하게 되면 새로운 인원이 다시 처음부터 프로젝트를 분석해야만 합니다.

따라서 하나의 솔루션은 최소한 2명의 인원이 상시적으로 유지되어야 하며,
이중 1인은 다른 1인에게 도메인지식, 프로그래밍 Flow, 코드 품질 검수를 해줄 수 있어야 합니다.

 

---

2. 분업화

2-1. 프론트엔드 전문 인력을 채용해서 백/프론트를 분업, 협업할 수 있도록 구성해야 합니다.
2-2. 모든 프로젝트에는 PO 혹은 PM이 필요하고, 최소 한 명은 해당 프로젝트를 개발한 경험이 있어야 합니다.

 

아직은 우리 회사에 프론트엔드 전문 인력이 없습니다.
현재 새로 구성하는 모든 프로젝트의 프론트엔드는 리액트를 사용중입니다.
물론 사원급 중 일부와 대리급 이상의 경우 기본적인 사용법을 익혀 개발이 가능합니다.

그러나 운영 경험이 존재하고, 올바른 설계를 공유하며 프로젝트를 리딩할 수 있는
전문 프론트엔드 인력은 없는 상황입니다.

그로 인해 리액트로 제작된 일부 사내용 솔루션의 경우
상당한 버그가 고쳐지지 않고 계속 유지되고 있으며, 추가 개발건에 대해서도 효율성이 저해되고 있습니다.

그중에서도 생산성 측면에서 아쉬운 지점은,
우리 솔루션의 대부분의 프로세스를 이해하고 있고, 시스템 전체 구조 개선을 리딩할 수도 있는
사내 고급 백엔드 인력마저도 경우에 따라 프론트엔드 개발에 투입된다는 것입니다.

이는 비교우위 개념에서 경제성 측면에서 상당한 낭비입니다.

뿐만 아니라 분업화를 통한 전문성 증가, 효율성 증대 또한 놓치고 있는 것입니다.
따라서 최소 3년 이상의 운영 환경에서의 프론트엔드 경험을 가진 사람이 
프론트엔드를 가이드해줄 수 있도록 신규 채용되어야 합니다.

 

추가적으로 모든 프로젝트들이
PO, PM 없이 개발자들이 직접 업체와 소통하고 일정관리 해야 하는 상황에 대한 개선이 필요합니다.

최근 PO 역할을 담당할 팀이 신설되긴 했으나, 모두 비 개발 인력으로 구성되어 있으며,
각 프로젝트 실무와의 소통은 거의 없는 상황입니다.

개발자 출신의 PM이 최소 한 명은 존재한다면
타팀과의 협업, 외부와의 조율, 내부 개발 리딩 등에서 보다 효율적 운용이 가능할 것으로 기대됩니다.

 

---

3. 리팩토링

현재의 코드는 기존 기능을 수정하거나 새로운 기능을 추가하기에 매우 어렵고, 또한 위험합니다.
장기적인 관점에서 더 빠르고 안전정인 배포를 위해, 경제성을 위해, 리팩토링이 필요합니다.

3-1. 데이터베이스가 들고 있는 비즈니스로직을, 모두 Java로 끌어올려야 합니다.
3-2. 하나의 메소드는 하나의 역할만 수행하고, 20라인을 넘기지 않도록 구성하길 권장합니다.

 

Design Stamina Hypothesis by Martin Fowler

 

위 그림은 마틴 파울러님이 여러 세미나에 걸쳐 여러 번 발표한 디자인 체력 가설 그래프입니다.

좋은 설계 구조가 경제성에 도움이 된다, 그렇기에 더 좋은 설계를 위해 투자해야 한다.
즉, 리팩토링해야 한다는 것입니다.

개인적으로 저 그래프에 good design, no design에 이어 bad design을 추가하여,
no design 보다 더 낮은 효율을 보이는 그래프를 그리고 싶습니다.

사내 모든 인원들이 도메인 지식의 공유가 이뤄지지 않는 점과 더불어,
아주 오래된 설계에 계속해서 덧대는 식으로 대응해온 세월의 무게를 견디기 어려워하고 있습니다.
이는 산출물의 품질과 양 모두에 영향을 미칩니다.

즉, 경제성을 위해서도 리팩토링이 필요한 시점입니다.

거대한 레거시이자 모노리식 구조인 기존 시스템을 단 번에 바꿔낼 순 없습니다.
잘게 쪼개어 덜 위험한 부분부터라도 하나씩 시스템을 개선해나가야 합니다.

 

이를 위해 해야할 일이 매우 많지만,
지금 당장 우선적으로 적용되어야 하는 실전적 지침 두 가지를 제안하고 싶습니다.

 

첫째는 데이터베이스에 있는 수많은 비즈니스로직을 Java 단으로 끌어 올려야 합니다.
수많은 비즈니스로직을 데이터베이스 프로시저 호출을 통해 수행하고 있는데,
프로시저는 또 내부에서 분기처리하여 다른 프로시저를 호출하는 등,
개발 시점에 개발자에게 완전한 블랙박스적 DX를 제공하고 있습니다;

이는 우리 회사 API를 사용하는 과정에서 문제가 발생했을 때, 
원인을 파악하는데 많은 시간이 소요되게 하며,
프로젝트 신규 투입 인원이 Flow를 이해하는 데 드는 시간을 증가시킵니다.

뿐만 아니라 데이터베이스에 대한 이력관리가 되지 않아,
패키지, 펑션, 프로시저에 작성된 비즈니스로직은, 언제 누구에 의해, 어떤 목적으로 수정되었는지 알기 어렵습니다.

 

둘째는 메소드 분리입니다.

Java 쪽에도 핵심 비즈니스 로직의 경우, 매우 복잡하여 파악하기가 어렵습니다.

하나의 비즈니스로직을 찾아들어가기 위해 최소 6개에서 많게는 7, 8개 파일을 타고 들어가야 하고,
그러한 비즈니스로직이 하나의 메소드에 많게는 스무개 이상도 포함되어 있으며,
메소드 추출이나 라인수 제한도 없는 상태입니다.

잘게 쪼개어 하나씩, 정확하게 이해하는 방향으로 접근해야만,
우리는 더 안정적으로, 효율적으로 일할 수 있습니다.

많은 개선이 필요하지만 우선 당장은 메소드 분리를 해내서,
각 코드가 어떤 비즈니스로직을 수행하는지 책 읽듯 메소드 이름만 읽어도 파악되도록 개선해야 합니다.

 

---

4. 복지 및 인프라

4-1. 로그 확인 절차가 간소화되어야 합니다.
4-2. 구성원들의 책상과 의자, 자기계발에 투자해주세요.

 

현재는 이슈 발생 시, 로그 확인을 위해
1번의 OTP입력과 2번의 아이디 입력, 세번의 비밀번호 입력이 필요합니다.

또한 즉시 원하는 실시간 로그에 편리하게 접근할 수 있는 것이 아니라, 
CLI를 통해 버킷에 파일을 업로드하고, 로컬에서 그것을 다운 받아 확인해야 합니다.

이러한 프로세스는 상당한 피로감과 더 빠른 대응을 방해하고 있습니다.

만약 허락해주신다면,
각 서버에 API를 구성하고, 각 API를 묶어주는 대표 API를 만들어서,
어느 서버의 어느 인스턴스의 어떤 파일을 요청한다 라고 요청만 보내면
바로 파일이 반환될 수 있는 식으로라도 구성을 해보고 싶습니다.

현재는 과거 데이터를 기준으로라도 사내에서 제 컴퓨터로 요청을 보내면,
과거 이력을 조회할 수 있게 개인 API라도 구성을 하여,
같은 이슈에 대응하고 있는 동료에게 공유를 해둔 상태입니다 ;ㅅ;

 

마지막으로는 복지입니다.

개발자들에게 가장 중요한 장비는 물론 컴퓨터입니다.
그 다음으로 책상과 의자라고 생각합니다.

장기적 관점에서 투자로 생각하고 사내에 높낮이 조절이 가능한 모션 데스크를 지급해주셨으면 좋겠습니다.
만약 그게 어렵다면 의자라도 교체해주셨으면 합니다.

헤드레스트 없는 의자가 기본 제공이고, 헤드레스트 있는 의자가 입사 1년만에 제공되었으나
제 동기중 두 명은 새 의자가 허리에 안 좋아서 기존 헤드레스트 없는 의자로 돌아갔습니다..

의자와 책상에는 조금 더 투자를 해주시면 개발자들의 효율이 좀 나아지지 않을까 생각합니다.

그리고 자기계발비입니다.

현재는 사내 자기계발비 지원이 전무한데,
한달에 1만원 정도라도 자기계발비로 지원해주신다면,
교보문고 sam 이나 기타 전자책 구독 서비스를 통해 개발자들이 스스로 역량을 개발할 수 있을 것 같습니다.

 

---

5. 맺는말

앞서 제가 제시한 내용들은 모든 회사에 적용 해야 한다는 의미는 아니며,
현재 제가 재직중에 있는 회사에서 제가 만약 리더라면
조직 생산성 개선을 위해 이러한 실천적 지침들을 당장 적용해볼 수 있겠다 하는 내용들임을 다시 알립니다.

 

물론 위 내용 보다 훨씬 건설적이고 더 장기적으로 중요한 내용들도 존재합니다.

그러나 조직에 변화를 만들어내는 일은 쉬운 일이 아니며,
하나씩 차근히, 그리고 확실히 해나가야 합니다.

그리고 그것을 조직 구성원들이 인지할 수 있을 정도로 장기적으로 고수될 수 있어야 합니다.
그래서 지금 당장 실천할 수 있는 일들을 위주로 작성해봤습니다.

지금 재직중인 회사가 앞으로도 계속 발전해나가는 조직이 되었으면 좋겠습니다.

감사합니다.

 

---

출처

https://martinfowler.com/bliki/DesignStaminaHypothesis.html

bliki: DesignStaminaHypothesis

https://www.youtube.com/watch?v=DngAZyWMGR0