성장이 없는 배려에 대하여
서버에서 구현할 기능을 앱에서 구현하는 것이 동료에 대한 배려일까?
클라이언트 개발자와 백엔드 개발자로 나뉘어 일을 하다보면 이런 일이 있다. 백엔드에서 처리해야할 일인데 클라이언트에서 처리하거나, 사실은 클라이언트에서 처리해야하는 일인데 백엔드 개발자가 처리하는 식이다. 지금 당장 겉보기에는 같은 동작을 하는 프로그램이지만 차이는 시간이 흐르면서 나타나는다. 둘 중 하나의 방식은 변경하려면 꽤 큰 대가(시간과 노동력)을 들여야 하는 것이다. 이런 문제를 해결하기 위해서는 설계(Design)를 해야한다.
그런데 이렇게 중요한 설계라는 활동이 당장의 서로의 배려에 의해 일어나는 경우가 왕왕 있는것 같다. 지금 백엔드쪽 개발자가 힘들어하니 이번에는 클라이언트에서 처리하지 뭐. 클라이언트팀이 A업무로 바쁘고 힘드니 이번에는 백엔드에서 처리하자. 이렇게 그 순간만 보면 서로에 대한 배려이고 상부상조라고 보여지는 그 활동들이 과연 진짜 서로에 대한 배려일까?
불과 한달 뒤, 당연히 클라이언트에서 구현해야했을 그 기능은 백엔드에서 구현된 덕분에 변경하기가 아주 어럽게 되었다. 최소 2배 ~ 3배의 노력이 추가로 드는 것이다. "배려"라는 이름 하에 백엔드 개발자와 클라이언트 개발자가 합의해서 진행한 설계니 당연히 서로를 탓할수는 없다. 이런 식이면 제품 개발도 제대로 진행될 리가 없다. 회사와 부서가 위험에 처한다. 당연히 사내 인간관계에 문제가 생긴 것도 아니고, 지금 받는 연봉이 부족한 것도 아닌데 이직 생각이 생긴다. 이렇게 수습하기 어려운 설계 하에서 계속 일해봤자 성장할것 같은 느낌이 들지 않는다. 그렇게 다른 회사로 옮기지만 그 회사도 크게 다르지 않다. 성장하지 못한 상태로 이직했기 때문이다.
설계가 필요한 상황이 언제인지 알아야 한다.
설계는 시간과 노력이 많이드는 활동이다. 모든 일상적인 업무에 설계를 적용할 수는 없다. 그러나 이 기능이 이전에 만들었던 기능과 특성이 많이 다른 일이고 제품 내에서 중요한 위치를 차지하는 기능이라면 반드시 설계에 대해 고민해보는 노력이 필요하다.
설계에는 기준이 있어야 한다.
그래서 우리는 설계에 대한 기준을 세워야 한다. 고객에게 최선의 경험을 제공할 수 있는 설계를 만들겠다라던지, 단기적인 관점보다 장기적인 관점으로 설계를 진행하겠다던지, 가용성 99.9999%를 만족하는 설계를 하겠다던지와 같은 기준이 있어야 설계가 가능하다. 그런 기준이 없다면 그때그때 임의로 작업자의 편의에 따라 설계하는 일이 반복되게 된다.
시스템 2를 활용한다.
인지심리학에 따르면 사람의 사고는 두 가지로 이루어져 있다. 시스템 1으로 불리는 자동(직관)시스템과, 시스템 2로 보이는 숙고 시스템이 그것이다. 설계는 분명히 그 복잡성으로 인해 시스템 2가 필요한 작업이다. 그런데 중요한 설계 결정을 시스템 1으로 하는 경우가 있다. 대부분은 일정 압박이나 커뮤니케이션 상의 미숙함 때문이다.
예를 들면 회의실에서 상사의 질문에 어떤 답이든 해야겠다는 압박감을 느낀 직원 B가 ~~이렇게 하면 될것 같습니다. 라고 대답을 해놓고, 회의에서 많은 사람에게 ~~하겠다는 약속을 했으니 반드시 지켜야 할 것 같은 느낌이 들어 실제로 그렇게 진행하는 것이다. 이럴때는 "A안, B안을 놓고 ~~같은 고민을 하고 있으며 아직 결정된 상태는 아니다"라고 대답하는게 맞다. 혹은 그마저도 모르겠으면 "조금 더 알아보고 답변을 드리겠습니다"라고 말하면 되는 것이다.
일정이 문제가 되는 경우에는 우선순위를 재조정해야 한다. 일반적인 상황에서는 설계가 우선순위가 높다. 우선순위가 낮은 작업을 당장의 작업목록에서 제외를 한후 설계에 들어가야 한다.
스타트업에서 서로에 대한 최고의 배려는 서로의 성장과 회사의 성장이다. 이런 공감대가 없으면 설계는 점점 악화되고 회사의 상황은 점점 나빠져 결국 모두에게 좋지 못한 결과로 되돌아오게 된다. 설계를 할 수 있는 여유가 없다면 가장 먼저 설계를 할 수 있는 시간부터 확보하자.
