엔지니어링 조직의 의사결정, 어떻게 해야 잘하는 걸까?

레몬베이스 엔지니어링 그룹의 사례와 함께, 같이 고민해봐요!

들어가며

안녕하세요, 레몬베이스에서 프론트엔드 챕터 리드를 맡고 있는 James입니다.

이 글을 읽는 여러분, 혹시… 아래와 같은 상황에 놓여있지는 않으신가요?

1. 나는 회사 내 엔지니어링 조직에 소속되어 있다.
2. 엔지니어링 조직의 인원이 늘고 있다.
3. 조직 내에서 이런저런 논의를 하는데, 논의 과정에서 조직 구성원들이 서로 반대되는 의견을 제시하곤 한다.

이 길도 길이요, 저 길도 길이니라…

이럴 땐 팀으로서 하나의 결정을 내리는 게 꽤나 까다로운 일일 거예요. 각자 나름대로 주장의 근거가 있을 것이니 논리적으로만 판단을 하기도 어렵고, 어떻게든 결정을 내린다고 하더라도 누군가는 그 결정에 불만을 가질 확률이 높지요.

그럼 반대 의견이 나올 땐 항상 결정을 보류하고 계속 논의를 이어가야 할까요? 혹은 누군가 한 사람이 결정을 내려야 할까요?

이런 상황에서 레몬베이스의 엔지니어링 그룹에선 어떤 고민을 했는지, 또 어떻게 의사결정을 해나가고 있는지 이 글을 통해 공유해 봅니다.

사례보다 중요한 것은 뒤에 있으니, 꼭 끝까지 읽어보세요!

고민의 시작

고민은 엔지니어링 그룹에서 설정했던 목표에 대한 리뷰를 진행하면서 시작됐어요. 이전 분기에 우리가 설정했던 목표를 달성하기 위해 모두 열심히 노력했는데, 그 과정에서 개선할 만한 지점이 없었는지를 확인하는 것이었죠.

목표 리뷰 과정에서, 저를 포함한 레몬베이스의 소프트웨어 엔지니어분들이 훨씬 빠르면서 동시에 안전하게 개발할 수 있는 환경을 만들고 싶어한다는 사실을 알 수 있었어요.

그리고 엔지니어분들과의 1:1 미팅을 통해, 그런 환경의 기반 중 하나로 여러 가지의 기술적 의사결정을 더 빠르게 내릴 수 있는 우리만의 방식이 필요하다는 것도 알게 되었고요.

이후 기술적 의사결정을 더 빠르게 내릴 수 있는 환경을 갖추는 것을 다음 분기의 엔지니어링 그룹 목표 중 하나로 두게 되었고, 이를 위해 이런저런 다양한 시도를 해보게 되었습니다.

레몬베이스에 등록한 레몬베이스 엔지니어링 그룹의 목표 😵‍💫

의사결정 방식

레몬베이스의 엔지니어링 그룹은 *모든 엔지니어가 자유롭게, 다양한 제안을 하며 함께 논의하고 결정하는 문화*를 지향해 왔어요. 그리고 이런 문화를 만들어가기 위해 이전부터 사용하던 ‘제안과 결정’ 템플릿도 있었고요.

제안과 결정을 위해 사용하는 기본 템플릿. 더 명확한 제안과 논의를 할 수 있도록 도와요.

그래서 기존의 문화를 유지하면서 동시에 결정의 효율을 높이는 방법을 주로 탐색했고, 결과적으로 국가에서 사용하는 의사결정 시스템을 벤치마킹하여 프론트엔드, 백엔드 챕터 단위로 사용해보기로 했어요.

그렇게 현재 대표적으로 사용하게 된 방식이 바로 삼심제와 위원회입니다 :)

삼심제

프론트엔드 챕터에서는 국가의 사법 기관에서 많이 사용하는 삼심제와 유사한 형태를 만들었어요.

프론트엔드 챕터에서 정리한 삼심제 내용

삼심제를 통해선 챕터 구성원이 모두 함께 제안을 빠르게 검토하고 챕터 차원의 결정을 내릴 수 있도록 하되, 제안과 다른 의견이 있다면 이를 드러내어 더 나은 결정을 내릴 수 있기를 기대했어요.

이후 상태 관리 도구, 코드 컨벤션, 정적 검사 규칙 등의 변경 제안에 대해 이 방식을 사용했고요.

심사를 진행할 땐 레몬베이스의 서베이를 활용해 익명 투표를 진행했답니다! 🙂

위원회

백엔드 챕터에서는 국가의 행정 기관에서 많이 사용하는 위원회와 유사한 형태를 만들었어요.

백엔드 챕터에서 정리한 위원회 내용

위원회를 통해선 특정 문제를 해결할 당사자들이 모여 보다 빠르게 의견을 교환하고, 빠른 결정 및 실행을 통해 학습하고 개선하여 챕터 차원의 결정을 내릴 수 있기를 기대했어요.

이후 백엔드 전반의 코드 아키텍처, 코드 컨벤션 등의 변경 제안에 대해 이 방식을 사용했고요.

결과

‘기술적 의사결정을 더 빠르게 내릴 수 있는 환경을 갖춘다’는 엔지니어링 그룹의 목표를 달성하기 위해서 위와 같이 삼심제와 위원회라는 방식을 마련했는데요, 실제로 목표를 달성했는지는 어떻게 알 수 있을까요?

다양한 방법이 있을 수 있겠지만, 저희는 결국 각 구성원들이 느끼는 상태로 판단하는 것으로 기준을 정했어요. ‘더 빠르다’거나 ‘충분히 빠르다’와 같은 기준은 판단하는 사람마다 다르게 느낄 수 있는, 상대적인 것이니까요.

그래서 구성원들의 상태를 판단하기 위한 익명 서베이를 진행했고, 레몬베이스에 등록했던 목표에 매주 체크인을 하며 당시 했던 일을 기록하고 목표 진척도를 업데이트했어요.

결과적으로, ‘우리는 충분히 빠르게 판단을 내리고 있는가’라는 질문에 약 75%가 그렇다고 말씀해주셨어요. 또 기명으로 따로 의견을 공유해주신 분들 중 ‘빠른지는 모르겠지만 더 개선된 의사결정을 하고 있다’는 의견을 주시기도 하여, 개선된 의사결정이라는 점에는 최소 85%가 동의하는 것으로 판단했고요.

핵심

결과로 보건대, 저희 엔지니어링 그룹의 의사결정 방식은 지난 분기에 비해 구성원들이 대체로 더 합리적이라 느끼는 방향으로 바뀌어가고 있다고 할 수 있을 텐데요.

하지만 어쨌든 모든 결정을 모두가 동의하는 상태로 반영하는 건 아니라는 점은 이전과 마찬가지입니다. 그렇다면 무엇이 같은 결과를 더 빠르게 만들면서도 구성원들이 합리적인 판단이라 느끼게 한 걸까요?

이에 대해 전 아래와 같은 요인들이 주요하지 않나 싶어요.

1. 공감대(동일한 문제 의식)
2. 충분한 논의
3. 미리 합의한 의사결정 과정

공감대

우선 어떤 변화가 되었든 변화가 필요하다는 점에 대해 구성원들이 인식하지 못하는 상태에서는 ‘굳이 이렇게까지 해야 해?’라는 생각이 들기 마련일 거예요. 그렇기에 구성원들이 문제에 대해 충분히 공감하는 상황에서, 즉 의사결정 방식이 충분히 중요한 문제가 되었을 때 변화를 시작하는 것이 중요하겠지요.

소프트웨어 개발 분야에서는 꽤 유명한, 저명한 컴퓨터 과학자인 Donald Knuth 교수님의 말이 생각나기도 하네요. 성급한 최적화는 만악의 근원이라고 하지요. 분야만 다를 뿐, 진리는 통한다고 할 수 있을까요? 😅

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

충분한 논의

그리고 어떤 방식이 되었든 논의 과정 자체를 없애고 결정을 하는 것은 위험한 방식일 거예요. 충분한 정보를 공유하지 못한 상태에서 내리는 결정은 빠른 결정이 될지는 몰라도, 합리적인 결정이 되기는 어려울 테니까요.

빠른 결정을 내린다는 것의 전제는 적어도 ‘이전과 비슷한 수준의 합리적인’ 결정을 내린다는 것일 텐데요, 그저 빠른 결정에만 매몰되어 절대다수가 불합리하다고 느끼는 결정을 내리면 안 되겠지요. 만약 다수에 의한 판단을 한다 할지라도, 정보가 공유되지 않은 상태에서는 다수결의 함정 또는 다수의 횡포라 불리는 문제에 빠질 확률이 높을 것이고요.

그래서 충분히 논의할 시간을 가지는 것은 여전히 필요할 거예요.

미리 합의한 의사결정 과정

마지막으로, 결정을 내리기 전에 구성원들이 합의한 의사결정 과정을 마련하고 그에 따라 결정을 내리는 것이 중요하다고 생각해요. 그 형태가 삼심제가 되었든, 위원회가 되었든, 혹은 아예 다른 무언가가 되었든 말이지요.

아무리 충분한 논의를 거쳐 결정을 내린다 하더라도, 알 수 없는 과정을 통해 내 생각과 다른 결정이 내려진다면 불만이 안 생기긴 어려울 거예요.

하지만 적어도 내가 미리 동의한 과정을 통해 결정이 내려진다면, 결과에 대해 만족하지 않을 순 있어도 ‘내 설득이 부족했구나’ 혹은 ‘ 아직 때가 무르익지 않았구나’ 정도의 생각을 할 수 있겠지요. 가끔은 ‘내가 보지 못한 면이 있구나’ 깨달음을 얻을 수도 있을 거고요.

전제

은총알은 없다(No Silver Bullet).

소프트웨어 엔지니어링의 진리로 받아들여지는 격언인데요, 모든 문제를 해결해주는 단 하나의 만병통치약 같은 건 없다는 뜻으로 쓰이곤 하는 말입니다.

이건 은총알이 아닙니다. 😂

그리고 소프트웨어 엔지니어링에서와 마찬가지로, 의사결정 방식에도 은총알은 없다고 할 수 있겠습니다.

우선 레몬베이스의 엔지니어링 그룹은 전문성이 비슷한, 다시 말해 회사에서의 역할과 책임이 비슷한 구성원들이 제품의 기술적 문제 해결을 위해 서로 협력하는 조직입니다. 다양한 전문성을 가진 구성원들이 협력하는 cross-functional 팀은 아니지요(여기서 말하는 전문성, 역할과 책임이 무엇인지에 대해서는… 다음 글로 다뤄볼 예정이에요 🙂).

또 위에 언급한 방식들이 모든 결정에 적용할 수 있는 방식도 아닐 거예요. 예를 들어, 프론트엔드 챕터에서는 삼심제를 아래와 같은 요건을 만족하는 제안에 대해서만 적용하고 있어요.

1. 챕터 단위의 변화 필요
2. 예상되는 보안 위협 없음
3. 점진적인 도입 가능
4. 되돌릴 수 있음

완전히 구조가 동일한 조직이라 해도, 현재 조직의 상황과 구성원의 특성에 맞춰 적절히 변주가 필요하겠지요?

맺으며

이 글을 통해 레몬베이스의 엔지니어링 그룹에서는 지금까지 효과적인 조직 단위 의사결정을 위해 어떤 고민들을 해왔는지, 또 고민의 결과로 어떤 문화를 가지게 되었는지 공유 드려보았습니다. 그러나 앞으로도 동일한 방식으로 결정을 내려갈지는 알 수 없어요. 조직이 성장하면서 상황은 바뀔 것이고, 그럼 그에 따라 변화해 나가야 할 테니까요.

하지만 기본적으로 앞으로도 다양한 의견을 수렴하고 학습하여, 조직과 구성원이 모두 발전하는 상태를 만들어가려 해요. 다양한 의견은 결국 다양한 입력이고, 다양한 입력을 잘 학습하면 어떻게 되는지는… 요즘 AI가 잘 보여주고 있지 않나 싶네요. 😅

이 세상에는 매우 다양한 조직과 구성원이 존재하는 만큼, 조직의 의사결정 방식도 수백, 수천 가지가 존재할 거예요. 또 어떤 방법이 이 조직에는 잘 맞고, 저 조직에는 잘 맞지 않는 상황도 있을 거고요.

다만 이 글이 여러분의 고민을 해소하는 데에 조금이나마 도움이 된다면 좋겠습니다. 그리고, 이 글을 읽으며 무언가 생각이 나거나 주실 의견이 있으시다면, 주저 없이 입력해 주세요!

함께 얘기하다 보면 분명 지금보다 더 좋은 방법을 찾고, 우리 모두 성장해 나갈 수 있을 거예요. 🙂

모두 함께, 즐겁게 일하는 엔지니어링 조직을 위하여!

레몬베이스 엔지니어링 그룹에서는 크루들이 모두 힘을 합해 계속해서 더 나은 개발 문화를 만들어 나가고 있습니다.

레몬베이스 팀은 더 좋은 제품을 만들기 위해 더 많은 뛰어난 동료들이 필요한 상황입니다. 내 손으로 직접 만들어나가는 문화에서 압축적으로 성장하고 싶은 엔지니어분들의 많은 관심 부탁드립니다! :)

레몬베이스 채용 페이지 : lemonbase.team james@lemonbase.com