개발자의 효율성
저는 개인적으로 약간 기묘한 위치에 서있는 개발자입니다.
10년 넘은 작은 구멍가게 개발사 사장인데, 이 회사 주 개발자이기도 합니다. 제가 개발해서 저를 먹여살리는 셈이죠. 하지만 1인 회사는 아니고 멤버가 6명이나 있고 이들 전원 개발자입니다. 따라서 한 명의 부족한 개발자이면서 동시에 사장으로서의 입장도 있고, 개발 업무 외에도 영업, 기획, 재무, 인사 등의 일이 더 많은 시간을 잡아먹곤 합니다.
얼마 전 오프라인에서는 별로 못뵜지만, 개인적으로 굉장히 존경하던 네이버 개발자분과 긴 시간 이야기할 기회가 생기면서 여러 가지 의견을 주고 받았습니다. 그 분은 10명이 넘는 팀의 팀장이라 어떤 면에서는 저와 비슷한 입장일 때도 많아서 서로 공감할 수 있는 코드가 많았습니다.
같이 대화를 나누면서 개발자의 생산성이랄까 효율성에 대한 생각을 다시 한 번 해보는 계기가 되었습니다. 이 글은 그 날 떠들면서 생각난 것들을 정리한 것입니다.
제가 생각하는 개발자 효율성의 최우선적인 부분은 '외로움' 입니다.
"개발자는 독립적이고 혼자 뭘 하는걸 좋아하지" 라는게 통하는걸 저는 거의 본 적이 없습니다.
개발자도 사람이고, 사람인 이상 혼자 알아서 하는게 즐거운 경우는 거의 없습니다.
짧막하고 독립적인 작은 일이야 혼자하는게 편하죠.
하지만 실무 프로젝트에서 복잡성과 분량이 충분히 큰 일을 혼자하게 되면 처음에는 잘 진행되는 척하다가 뒤로 갈수록 크게 생산성이 떨어집니다. 단지 코드 생산 분량만 떨어지는게 아니라, 품질, 유연성 등도 전부 떨어집니다. 이 현상은 간단히 정리하면 "처음 40%가 일주일만에 완성되는데 나머지 60%가 6개월이 지나도 완성되지 않는 상태"라 할 수 있습니다.
물론 뒷 부분으로 갈수록 복잡성이 더해지고 난이도가 올라가서라는 관점도 있지만, 그렇기 때문에 더욱 더 제가 생각하는 것은 외로움입니다. 처음에 난이도가 쉬운 부분은 혼자서도 즐겁게 하다가 어려워질수록 혼자하면 짜증나고 하기 싫고, 하기 싫은 일을 혼자하다보니 느리게, 엉망으로 하기 쉬워집니다.
즉 외로움은 텐션의 저하를 불러옵니다.
저는 개발에 있어 텐션이 전부라고 생각합니다(그만큼 번아웃이 무서운거죠 ^^) 텐션이 일단 떨어지면 알고리즘을 구성하는 것은 물론, 훨씬 많은 경우의 수를 감당해야하는 아키텍쳐나 프로토콜 설계, 정교한 역할모델에 기반한 리펙토링은 물건너 가버리고, 귀찮아서 찍어내는 코드가 더욱 더 악순환을 만들어내게 됩니다.
제 경험 속 외로움이란 텐션 저하를 일으키는 큰 요인이라 반드시 제거하지 않으면 문제가 커집니다.
실무적으로 보자면 팀원이 몇 명 안될 때 3개의 동시진행 프로젝트가 있다면 절대로 하나씩 떼로 몰려가서 정복해야 한다는 것입니다. 3명에게 3개의 프로젝트를 각각 나눠주면 첫 주차에는 순조롭게 각각의 프로젝트가 진행되어 3개월 후엔 3개의 프로젝트가 동시에 완료될 것 같습니다.
하지만 실제 3개월 후엔 프로젝트 3개 다 전혀 완성되어 있지 않은 상태로 빠지는 것이 보통입니다.
반대로 3명씩 몰려가서 프로젝트를 하나씩 때려잡으면 3개 다 완성될 확률도 훨씬 높고, 실패도 부분적으로 일어나는 경우가 많았습니다.
해서 제 추천은 매니저가 외로움 기반의 인원 배치로 프로젝트를 진행하려고 하면 일정을 두 배 이상 잡던가, 아니면 뭉쳐서 일할 수 있게 배려를 고려해봐야한다는 것입니다.
두 번째는 짝프로그래밍입니다. 하지만 익스트림에서 말하는 짝 프로그래밍과는 좀 다르달까..이것도 외로움 방지의 일환입니다.
저는 특히 짝프로그래밍은 무조건 주코딩을 하는 시니어와 수준 차이가 좀 나는 주니어가 해야만 효과가 있다고 생각합니다. 현실적으로 이 조건을 충족하기 어려운 경우가 많습니다. 이미 팀이 수준이 비슷한 팀원으로 구성되어있는 경우가 많기 때문이죠. 저는 동급 개발자가 짝코딩해서 좋은 일을 경험한 적이 없습니다.
개인적으로 그럴거면 짝 코딩 대신 커다란 곰인형을 옆에 두는 편이 낫다고 생각합니다 ^^
왜 시니어 + 주니어 조합의 짝코딩인가에 대해서 차근차근 경험담을 풀어보죠. 사실 이 관점은 문제의 해결은 결국 시니어가 한다라는 것을 베이스로 두고 있습니다.
이것도 시니어의 텐션의 문제인데 어려운 부분을 코딩하면 생각하기도 싫고 코딩하기도 싫어집니다.
제 현실에서 어려운 로직이란 건 수학적으로, 알고리즘적으로 어렵다기보단 도메인이 복잡하여 경우의 수가 많고, 다양한 요구사항의 집합을 다계층으로 작성해야할 뿐만 아니라 협력계층도 많아서 퍼사드레이어를 정교하게 작성해야 하는 등의 아키텍쳐 상으로 어려운 경우가 대부분입니다.
...그냥 하기가 싫어집니다.
보통 이런 문제는 문제를 여러 차례에 걸쳐 모델링하면서 역할을 분리해내고, 다시 그 역할의 그룹지어 레이어를 구성한 뒤, 협력해야하는 큰 단위를 정의하여 프로토콜 레벨의 객체망을 구성하고 그 틀 안에서 개별 케이스를 처리할 상세 역할을 정의해서 끼워넣어 최종적인 객체망이 문제를 해결하도록 하는 과정입니다.
처음에 생각한 모델에서 최종 모델까지 여러 차례 리펙토링하면서 점진적인 인사이트를 얻게 되고 최종적으로 우아하고 유연한 해법에 이르는 노가다 많고 검증도 수 차례 해야하는 작업이죠.
혼자하면 당연히 하기가 싫습니다.
하지만 여기에 주니어가 말이죠...반짝반짝 눈을 뜨면서 옆에 앉아있는 것만으로 일을 진행하게 되는게 1차적인 효과입니다 ^^
하지만 효과는 단지 여기서 끝나지 않습니다. 주니어에게 내가 하고 있는게 무엇인지 설명하면 못알아듣습니다. 이 주니어에게 내가 해결하려는 문제를 "알아듣게" 쉽게 설명하는 과정에서 위의 리펙토링 과정이 자연스럽게 일어납니다.
자신을 향해, 코드나 문서만 갖고 인사이트를 얻는 것보다, 주니어에게 설명하고 주니어의 반응을 보면서 더욱 쉽게, 더욱 명확하게 설명을 바꿔가는 과정에서 인사이트를 얻는게 훨씬 효과적이고 주니어에게 도움도 받을 수 있습니다.
게다가 덜 외롭죠! 어렵고 복잡한 모델링을 해가는 과정이 덜 외롭고 무엇보다 혼자 하기 싫다고 배째기도 굉장히 힘들어집니다(어짜피 해야할 일입니다 ^^)
또한 모델링과 설계 과정에만 주니어가 기여하는 것이 아닙니다. 그 인사이트를 바탕으로 현재 버전의 코드를 작성해가는 과정에서도 주니어는 여전히 오타나 로직 상의 이상한 점을 계속 질문할테고 그걸 답변하는 것으로 코드의 잠재적 버그가 상당부분 걸러집니다. 코드 작성 중 뿐만 아니라 코드가 완성된 뒤 이 과정에 같이 참가한 주니어는 전후 관계를 파악하고 있으므로 즉시 자리로 돌아가 현재 버전에 대한 테스트를 작성하여 돌릴 수 있습니다.
좀 귀찮고 하기 싫은 일을 시키는 감도 있지만 원래 테스트는 남이 짜주는게 최고죠 ^^
이걸 통해 주니어도 개발물에 대한 이해도가 크게 올라갑니다. 시니어가 짠 제품을 주니어가 유지보수하거나 레포팅할 수 있게 되는 발판이 됩니다.
이렇게 어려운 부분을 작성하는데 있어서의 난관을 주니어와 함께하면 굉장히 빨리 통과할 수 있습니다.
회사에 주니어는 굉장히 소중한 자산입니다. 지난 십여년간 느낀 점이라면 주니어가 선수가 되어 시니어가 되면 다시 주니어를 회사가 뽑는 편이 더욱 돈을 많이 버는 일이었다는 것입니다.
세번째는 노하우관리의 문제가 있습니다. 여기서 말하는 노하우는 말그대로 노하우 즉 경험을 통해서 알고 있는 사실들입니다.
개발자가 3명이면 3명이 각각 맡은 코드에서 노하우를 따로 얻게 되는데 이걸 공유하는 효과적인 방법이 필요합니다. 만약 이게 없으면 같은 문제를 매번 해결해야 합니다. 헌데 대부분의 회사는 매번 검색해서 매번 디버깅해서 똑같은 문제를 해결하는데 시간을 사용합니다.
노하우가 개발자 개인에게 귀속되어있기 때문입니다. 하지만 개발자 개인도 그 노하우를 효과적으로 저장하고 사용할 방법을 찾지 못하면 다시 반복적으로 같은 문제를 해결해야하는 것은 변함없습니다.
예를 들어 저번 프로젝트에서 톰캣의 특수한 케이스를 해소하는 코드를 작성했다고 생각해보죠.
그 케이스는 프로젝트의 성격에 따라 필요할 수도 아닐 수도 있는 노하우코드입니다. 개발자 개인이 이 노하우를 효과적으로 보관할 방법이 없다면, 다음 프로젝트에서는 그 전 프로젝트 코드를 꺼내서 사용할 수도 있을 것입니다. 하지만 서너개의 프로젝트를 진행한 후엔 그 프로젝트 코드를 가져올 수 있을지 아닐지도 모를테고 그 문제를 해결했는지 아닌지도 가물가물하겠죠.
제가 생각하는 효과적인 저장소는 링크나 글이 아닙니다. 짜피 관리되는 코드가 아닌 비정형 정보는 그저 비정형 정보일 뿐이고 그걸 코드로 옮길 때의 다양한 문제는 또 해결해야 합니다.
젤 좋은 건 해결한 문제를 함수화 하여 모아두는 것입니다.
knowhow 패키지에 종류별로 모아두는 것도 좋겠죠.
이걸 팀이나 회사 차원에서 실시한다면 실제 구동되는 코드 레벨에서의 노하우 공유가 일어나고 그 코드는 즉시 사용할 수 있을 뿐만 아니라 팀이 사용할수록, 회사가 사용할수록, 더욱 안정화되고 버그가 사라지게 될 것입니다.
저는 이걸 광범위하게 도입하여 여러 플랫폼, 언어, 프레임웍에 대해 노하우를 모을 수 있는 구조의 코드 셋트를 구성해두고 직원 전원이 자신이 알게 된 노하우를 여기에 추가하도록 했습니다.
이를 통해 직원의 이직, 신입의 유입 시에 제품의 품질을 유지하고 인수인계가 최소화되면서도 작업의 연속성과 안정성을 가져갈 수 있어 많은 도움을 받았습니다.
마지막으로는 가장 중요한 것인데, 근태입니다. 개인적인 관점에서 사회에 소속된 사람은 전부 역할극을 하고 있다고 생각합니다. 아버지역할을 수행하다가 남편역할을 수행하고 직원역할을 수행하는 식입니다.
역할을 혼동하면 문제가 커집니다. 예를들어 아빠역할로 혼동하면서 상사역활을 수행하면 꼰대소리를 듣기 딱좋습니다. 그럼 회사에서 개발자라는 역할을 수행할 때 가장 중요한 것은 다른 역할을 섞지 않고 개발목표에 맞는 개발을 고품질로 적시에 하는 것이라 할 수 있습니다.
근무시간동안 높은 텐션을 유지하면서 집중력을 발휘하여 좋은 코드를 적시에 작성하는 힘은 근본적으로 어디서 오는가..
제 생각에 그것은 그 조직이 얼마나 조직원이 역할을 혼동하지 않게 배려해주는가에 달려있다고 생각합니다.
그리고 그것의 핵심은 근태가 아닐까 싶습니다.
예를 들어 "우리 회사는 무조건 10시 출근에 6시 퇴근이다. 절대로.."
라는게 성립한다고 생각해보죠. 그럼 많은 생각이 드실거에요. 일이 몰려있을 땐? 납품기간이 다가올 땐? 일이 급박하게 들어올 땐?
근데 그럼에도 불구하고 무조건 근태는 확정이라고 생각해보죠. 그럼 일이 안될 거라고 예상하겠지만 실은 정반대의 현상을 목격하게 되었습니다.
그 근태가 확정이기 때문에 어떻게든 근태 시간 내에서 문제를 해결할 창발력을 발휘하고 효율성을 제고하고 집중력을 더욱 올려서 일정에 맞추게 되거나, 굉장히 초반에 그렇게까지 해도 안되는 분량과 일정을 정확히 알게 되어 관리자나 사장인 제가 고객사와 원활하게 협상할 수 있게 해준다는 것입니다.
반대로 위에 말한 일명 "특수 사항"엔 근태를 보장하지 않는다면 일정에 그래서 잘맞춰지는가?
그렇지 않았습니다. 밤을 세게하고 야근을 밥먹듯이 시켜도, 개발자의 가장 중요한 자산인 "텐션"이 떨어져서 오히려 적기 납품에선 더 멀어지거나 고객과 협상하기엔 너무 마지막 순간에 안되는 범위를 알게 되는게 고작이었습니다.
일단 근태로 텐션이 떨어진 개발자는 회사생활에서 회사 조직원으로서의 역할을 그만두게 됩니다.
즉 회사 안에서 집에서의 역할이나 놀 때의 역할을 수행해버리는거죠. 놀거나 쉬거나 느슨하게 취미로 코딩하는 역할을 수행하거나 하는 식으로요.
제 경우 회사가 전혀 파견을 가지 않습니다. 따라서 인하우스 개발사의 생명은 신용인 셈입니다.
신용있는 개발사가 되는 데는 개발자가 회사에서 보내는 시간을 오직 회사의 제품을 적시에 잘 만드는 역할을 수행하는데 집중할 수 있게 해줘야하는게 필수적이고 아이러니하게도 그것은 근무시간을 늘리거나 들쑥날쑥 운영하는게 아니라 확정적이고 좋은 조건의 근태를 제시하는 것이었습니다.
근태만 확실하고 그게 좋은 조건의 근태시간이라면 놀랍게도 근무시간의 굉장한 집중력요구나 그 집중력 하에서만 달성할 수 있는 일정에 불만을 제기하는 경우는 거의 없고 실제 달성률도 크게 올라갔습니다.
뭐랄까 "회사왔으면 회사일열심히 해야지!"에 불만이 없게 만드는 건 그저 좋은 근태를 확정해주는 정도면 충분한게 아닐까요 ^^
(참고로 제 회사는 10시출근 7시퇴근, 점심시간 12에서 2시로 하루 일하는 시간이 7시간입니다 ^^)
저는 사장이라 보통의 개발자가 생각하는 좋은 개발의 위한 조건이 좀 다를지 모르겠습니다.
많은 개발사 사장님들이나 스타트업 사장님들, 그리고 여러 규모의 팀장님께 도움이 되실까 하여 공유해봅니다.
특히 예상과 많이 다른 부분이 연봉입니다.
공유되는 많은 글을 보면 연봉을 많이 주면 개발자는 만족한다라고 하는데 현실은 전혀 그렇지 않습니다.
근태 등의 중요한 회사의 근무환경이 들쑥날쑥하면 연봉을 많이 받아도 여전히 열심히 일하지 않고 제대로 역할을 수행하지 않는 경우가 더 많습니다. 연봉은 짜피 계약시점에 확정되는 것입니다. 한 번 확정되면 기간동안 바꿀 수 없습니다.
여기서 오너와 급여생활자의 입장은 정 반대가 됩니다.
급여생활자는 버는 돈이 확정이니 일을 안할 수록 이득입니다. 노동력 대비 급여의 비율이 올라가기 때문입니다. 그에 비해 오너는 일을 하면 할수록 이득입니다. 본인은 수익이 확정되어 있지 않고 일한만큼 많이 벌 수 있는 구조이기 때문입니다.
이 구조는 자본주의적인 보통의 회사에서 근본적으로 바뀌지 않는다고 생각합니다(그렇다고 협동조합구조의 회사들이 잘 되는 경우도 별로 없습니다) 따라서 급여생활자가 오너처럼 행동하길 바라거나 오너가 급여생활자의 마음을 알아주길 바란다는 거 자체가 제가 보기엔 웃기는 얘기입니다.
해법은 개발과 마찬가지로 역할과 책임 아닐까요. 특정 연봉으로 계약한 사람에게 계약기간 동안 일정한 텐션으로 회사 안에서 회사가 요구하는 역할을 수행해달라고 요구하고 대신 그걸 수락한 개발자에게 환경의 변화를 안일으켜주는 신뢰를 구축하는 것이라 생각합니다.
그 중 가장 큰 게 근태와 급여일 등 연봉협상시 개발자가 고려했던 중요 요소입니다.
연봉을 수락한 개발자도 그 조건에 동의해서 그 기간동안 일정한 텐션으로 개발할 것을 회사에서 보장해주고 거기에 본인이 만족한 연봉을 가져가면 이득을 못볼지라도 그 의사결정으로 사후에 뒷통수 맞지 않고 예상한대로 로의 이득을 거둘 것입니다.
결국 입장이 다른 두 사람이 서로의 합의점으로 계약하여 윈윈하자는 것이니까요 ^^
이 계약이 계속 잘 유지되려면 개발자도 일정한 텐션으로 근무시간에 역할을 수행해야하고 회사도 마찬가지로 계약 시 제시했던 조건에 변화가 없도록 신용을 지켜야합니다. 연봉은 결정된 것이니 잘 급여를 주는 책임을 지는건 당연한 거고, 최우선적으로 회사가 보장하고 신뢰를 쌓아야할 것은 일하는 시간이라고 생각합니다.
사소한 것까지 전부입니다. 워크샵은 절대로 평일에 가서 평일에 돌아와야하고, 휴무일은 법대로 쉬고, 출퇴근 시간을 칼로 보장하고 잔업을 집으로 가져가는 것도 허락하지 않으며, 원래 요구하던 텐션의 레벨을 함부로 바꿔도 안된다고 생각합니다.
오너인 입장에서 일억짜리 일을 따와서 3개월 안에 해치우면 득이 되지만 3년동안 하게 되면 망하는거 아닌가요? 사업하는 입장에서 그게 그렇게 크리티컬하다면 당연히 급여생활자도 동일하다고 생각해야겠죠.
하루 8시간 근무 조건으로 계약했는데 10시간 12시간, 휴일도 부려먹으면 급여생활자는 망하는거 아닐까요.
망하긴 싫으니까 도망가겠죠. 그건 단지 초과근무에 수당을 주는 문제가 아닙니다. 신뢰가 없어서 거래할 수 없는 지경으로 가는 문제인거죠.
