2. 생각정리 - 의견충돌에 관한 단상
나는 일하면서 마주하는 의견충돌을 어떻게 해결하는 사람일까?
최근에 깊게 생각해볼 계기가 있었다. 평소에는 크게 고민하지 않았다. 왜냐하면 나는 스스로를 '충돌을 잘 만들지 않는 유순한 팀원'이라고 생각했기 때문이다.
그런데, 내가 그동안 여러 의견충돌들을 잘 넘겨온것은 정말 충돌을 잘 '중재 or 해결 or 해소'한 결과일까?
아니다, 나는 내가 충돌로부터 '회피'하였다는 것을 깨달았다.
팀 에서 일어나는 크고작은 의사결정들 속.. 거시적인 제품 코드베이스 설계부터 시작하여 미시적인 코드레벨에의 많은 충돌들이 있었다.
특히나 내가 만들고 있는 제품을 처음부터 끝까지 설계하신 동료 개발자분의 피드백을 들을 때, 당연히 감사한 마음도 있었지만 어느순간부터는 혼란스러움과 피로감을 느끼곤 했다.
어느순간부터 나는 반론하는걸 멈추고 수동적으로 의견을 수용했다. 충돌이 피곤하니까 그랬다.
그리고 그 피로감은 누적되어, 회사 생활 전체로 번졌다.
그 피로감의 원인을 도무지 몰라서 답답했고, 이렇게 피로감을 느끼는 나 스스로가 이상하다고 느껴지기도 했는데, 이러한 고민을 오늘 내가 존경하는 선배 개발자분(ㅎㅎ)께 털어놓고 그 원인을 찾았다.
문제점은 공통으로 합의된 의사결정 기준의 부재였다.
가령 내가 만들고있는 제품에 적용될 수 있는 기준이라면 아래와 같다.
- A 기준 : 우리는 일단 제품을 빠르게 만들어야해 -> 따라서 제품의 전체적인 설계보다는, 당장 우리 팀원들이 개발할 때 생산성을 지킬 수 있도록, 설계의 유연성을 인지하고 린하게 코드를 추가해야해
- B 기준 : 우리가 만드는 제품은 N개월안에 ㅇㅇ피쳐가 추가될거야. -> 따라서 그에 맞는 제품의 설계를 세우고, 그 설계에 맞춰서 코드를 추가해야해.
그런데 지금 팀의 의사결정은 A 기준 + B 기준이 매번 그 때 그 때의 케이스마다 뒤섞여서 이루어지고 있었던 것 이다.
그러다보니 팀원인 나는 어느 장단에 맞춰야할지 혼란스러웠고, 이렇게 의사결정 기준이 정해져있지 않은 채로 개인이 의사결정을 하고 피드백을 받는 상황은 당연히 피로감이 클 수 밖에 없다. 돌아올 피드백을 예측할 수 없으니 눈치를 보게 되고, '적당히' 의 늪에 들어간다.
어쨌거나, 이러한 문제점을 깨달은 것 만으로도 아주 기쁘다.
그래서 이러한 문제를 해결하기 위해서는, 뭘 해볼 수 있을까?
- 의사결정 기준을 다같이 확립해야한다.
- 만약 B 기준을 채택한다면, 설계에 대한 이해도가 팀 전체적으로 얼라인 되어야한다. 안그럼 B 기준을 가져가더라도 또 다시 개별들이 생각하는
설계의 방향성이 달라서, 똑같은 협업의 실패가 반복될 것 이다.
역시나 협업에서 가장 중요한 틀은 역시나 '공동의 목표'라는 것을 깨달았다.
그리고 그 틀이 정해졌다면, 내부에서 일어나는 여러 의사소통들은 '공감'을 기반으로 해야한다고. 생각한다. 즉, 상대방을 먼저 이해해보고, 그 입장에 공감하는 태도말이다.
우리 팀의 장점이라고 하면 제품 자체의 설계와 개발 설계의 싱크를 맞추려고 노력한다는 것이다.
그런데, 리소스 부족으로 제품의 아주 먼 미래까지 포용가능한 설계는 불가능했고, 그로부터 두 개의 자아..가 싸우게 된 격이다.
그리고 제품의 궁극적인 목표가 '아주 먼 미래'라고 느껴지는 것도 혼란을 가중한다고 생각한다.
'아주 먼 미래', '유저가 엄청 많아지면', '판매자/구매자를 넘어서서 외주 개발사가 붙으면'이라는 가정 하에 제품의 미래를 설계 하니, 마치 개발자들에게는 '지금 당장 고려하지 않아도 무방한 것'처럼 들리게 되는게 문제다..
사실 그렇게까지 먼 미래이고, 수많은 조건들이 붙어야만 이룰 수 있는 목표라면, 정말 지금 집중해야할 목표가 맞을까?
일단, 선제조건들을 충족시키는게 먼저 아닐까? 사실상 우리가 꿈꾸는 대로 유저가 아주 많아지면, 그 때가서 갑자기 우리의 목표가 바뀌게 될 수도 있지 않을까? 다른 방향이 더 중요시되는건 아닐까?
만약 그렇다면 우리가 지금까지 한 설계와 고민은 불필요해지는게 아닐까?
그럼 다시한번 우리가 지금 집중해야할 것은 뭘까?
참 어렵꾸나~~~~ 이렇게 다시한번 소프트웨어 설계와 제품 설계는 결국 한 몸이라는 것을 깨달았다.