개발 리더로서 나의 역할
개발 임원, CTO 등의 업무를 수행하면서 이에 맞는 역할에 대해 정리해 봤다.
팀장 때는 팀원들이 업무에 기여하고 성장할 수 있도록 돕는 것이 주 업무였다면, 본부장 급 이상의 직책을 수행하게 된다면 우리 본부의 여러 팀들이 서로 한 조직처럼 일하게 하는 것과 다른 본부와 원활하게 협력하여 회사의 주요 업무에 기여하는 것이 중요한 업무였다.
11번가에서 개발 그룹장, Ktown4u에서 CTO를 할 때부터는 한 회사의 거의 모든 개발 조직에 대한 책임을 갖게 되었다. 지금 정리해 보면 이때부터의 나의 주요 업무는 다음과 같은 것들이라고 생각한다.
개발 프로세스, 문화 정착시키기
개발 조직의 practice를 best practice, process화 하여 항상 기준 이상의 성과를 만들어 낼 수 있도록 하고, 이를 개발 문화로 정착시키고 지속 개선하기.
업무를 처리할 때 개개인의 개발자들이 처리하는 방식을 공유하고, 이 중에서 우리가 보기에 가장 좋은 방법을 베스트 프랙티스로 발굴하고, 이러한 베스트 프랙티스들을 구성하면 우리만의 프로세스가 만들어진다. 이를 숨 쉬듯 지킬 수 있는 문화로 정착하면 우리 중 누가 하든 결과의 차이가 크지 않게 된다. 당연히 상향 표준화해야 한다.
나는 배포를 할 때는 가역성(Reversiblity)을 중요하게 생각한다. 배포 후 문제가 발생되었을 때 롤백하면 끝난다면 가장 행복한 경우이다. 코드를 롤백하더라도 데이터가 변화가 있어서 롤백하면 제대로 동작하는 경우가 있다면 이것은 가역성이 없는 경우이다.
모든 경우가 가역성을 확보할 수 없으니 가역성이 불가한 경우는 카나리 배포를 진행한다. 1%, 2%, 5%. 이렇게 조금씩 배포하면서 이상이 있는지 보는 것이다. 대개의 경우 카나리 배포를 진행하면 많은 문제를 해결할 수 있다.
그런데 카나리 배포도 불가한 경우도 있을 수 있다. 이럴 때는 체크리스트를 작성한다. 가역성이 있거나 카나리 배포가 가능한 경우라도 매우 위험한 일이라면 체크리스트를 활용한다. 여러 팀원들이 모여서 다양한 경우를 고려해서 체크리스트를 작성하고, 실행을 할 때는 본래 체크리스트를 항공기 정/부조정사들이 하는 것처럼 실행하는 사람은 생각할 필요가 없도록 복명복창하듯이 진행한다.
이러한 것들이 프로세스라고 생각한다. 더 많은 것들이 있을 텐데, 후에 이러한 프로세스들을 모아서 정리해 보는 것도 의미가 있을 것 같다.
성장, 개발자의 역량 증대
참 중요한 주제다. 여기서 중요한 것은 이러한 역량 증대와 성장을 어떻게 얻냐는 것이다. 업무와 관련이 없더라도 자신의 이력서에 넣으면 좋을 기술을 공부를 하고, 토이 프로젝트를 하면서 배울 수도 있다. 나는 이력서에 넣기에 이런 역량 증대나 성장은 가치가 매우 낮다고 생각한다. 이력서에 넣는 것이 정말 나의 가치를 인정받기 위한 영역이라고 생각한다면 반드시 업무 수행을 통해 기여가 있을 때 배우거나 학습한 것이 성장이고 역량 증대라고 생각한다. 나는 많이 배웠고, 성장했다고 생각하지만 실제로 회사의 업무에 기여한 것이 없다면 그건 성장이 아닌 것 같다.
이력서를 보면 쿼리 튜닝을 해서 몇 %의 개선을 해서 수분 걸리던 것을 수초로 개선했다는 내용을 자주 본다. 이런 내용을 보면
- 이런 개선이 회사에는 어떤 도움이 되었는지?
- 사내의 다른 개발자들은 왜 이런 개선을 하지 않았는지? 그들은 가치가 없다고 생각해서 수행하지 않은 것은 아닌가?
궁금하다. 내가 수행한 개선이 고객의 만족도나 회사의 매출에 기여했는지가 중요하다. 이러한 기여가 있는 개선 작업에 참여했을 때 가치 있는 것을 배우고 성장한 것이라고 생각한다. 이런 배움과 성장이 채용 면접 때 이뤄지면 정말 좋을 것 같다는 생각이 든다.
개발조직을 Align과 회사의 지원 얻기
"개발 프로세스, 문화 정착시키기"는 눈에 잘 보이는 역할이다. 이외에 눈에 잘 안 보이는 역할로 "경영진/비개발조직과 개발조직 간의 연결고리" 역할이 있다.
일정 계획
먼저 일정 계획이 있다. 영업에서는 개발조직에 아주 구체적이지 않은 요구사항을 가지고 일정 계획을 요구한다. 개발자들은 대개 구체적인 일정 계획을 정확하게 제공하려는 경향이 있다. 이때 다음과 같은 것을 유념해야 한다.
- 그들은 가능한지? 2~3주가 걸리는지? 2~3개월이 걸리는지? 알고 싶을 수도 있다.
- 혹시 변경되더라도 일정 계획이 있어야 그들은 그들의 계획(제휴, 마케팅, 영업 활동 등)을 수립한다.
첫 번째 경우, 우리는 그들에게 일정 계획이 얼마나 정밀(precise) 해야 하는지 물어보는 것이 필요하다. 우리가 생각하는 만큼의 정밀도가 아니라 정확도(accuracy)가 필요할 수도 있다. 누가 나에게 "언제 죽을 것 같냐?"라고 물었을 때, "한 5~60년 안에는 죽을 것 같다"라고 하면 거의 100% 정확한 답이다. 하지만 "5~60년"이 누군가에게는 매우 낮은 정밀도일 수도 있지만 말이다.
이러한 차이를 경영진/비개발조직과 개발조직 사이에서 번역(?)하는 연결고리를 해야 하는 것이 개발 리더의 역할 중 하나이고, 매우 중요한 역할이라고 생각한다.
추정은 어렵다. 해 봐야 안다. 어차피 수정할(틀릴) 계획이라면 뭐 하러 계획을 세우나라는 생각을 할 수 있는 개발자들.
개발조직에서 일정을 제공하지 않거나, 준수하지 못해서 서비스/사업이 망했다고 하거나, 개발 일정이 없이는 영업 일정, 회사의 마일스톤을 세울 수 없다는 경영진/비개발조직.
이들 사이에서 개발 일정을 세우고, 공유하고, 실행하면서 계획을 추적하고, 필요하면 변경하고, 변경이 되었다면 빠르게 이해당사자들에게 공유하는 역할이 필요한 것이다.
복잡성(Complicated) vs 복합성(Complex)
Cynefin framework에 complicated와 complex의 차이점을 보면 complicated는 복잡하고 어려워 보이지만 실제로는 "문제의 구성 요소가 많지", 변수들이 제어 가능해서 사실은 그렇게 어렵지 않은 일이다.
반대로 complex 한 일도 복잡하고 어려워 보이는 데 변수를 제어할 수 없는 상황이라 "정말 어려운 상황"이다.
대부분의 비기술 리더들이 저지르는 치명적인 실수는 소프트웨어 개발을 “단순한(simple/clear)” 영역으로 간주하고 예측 가능한 인과관계(cause and effect)를 적용하려 한다는 점이다. 하지만 소프트웨어 개발은 본질적으로 Complex Adaptive System(복합 적응 시스템)이다. 동일한 개발자에게 동일한 문제를 두 번 주더라도 매번 다른 해결책이 나오며, 팀의 경험, 요구사항의 변화, 콘텍스트의 변화 등 수많은 변수들이 시스템 전체를 변화시키기 때문이다.
이러한 차이는 경영진/비개발조직에게 설명하기 어렵다. 아니 설명할 필요가 있는지 모르겠다. 알려주더라도 이해하려고 노력하지 않을 것 같다. 하지만 누군가는 이러한 차이를 이해하고 연결고리 역할을 해야 한다. 이게 CTO, 개발 리더의 역할이 아닌가 싶다.
우선순위와 요구사항
개발조직에 일정을 요구할 때 요구사항을 가지고 요청하는 경우가 있다. 특히 매우 많은 수의 과제들에 대해서 일정을 한 번에 요청하는 경우들이 있다. 내년 1년 동안 진행할 과제들에 대한 일정 계획을 요청하는 경우도 있다.
말도 안 되는 요청이다. 어떻게 1년 후에 수행할 과제를 2~3 줄 정도의 설명을 보고 일정 계획을 얘기하느냐 말이다. 하지만 그래도 해야 한다고 생각한다. 전사 구성원들이 숲을 보면서 일할 수 있어야 한다.
이런 계획은 정밀도를 낮춰서 세워서 공유하고, 주기적으로 변경을 공유하는 방법 밖에 없다고 생각한다. 중요한 것은 그럼에도 불구하고 일정 계획을 세우고 공유해야 한다는 것이다.
하지만 실제로 일을 할 때는
우선순위를 정하고, 한 번에 한 가지에 집중하면서 한 가지씩 빠르게 진행해야 한다고 생각한다.
권도균 님의 우선순위를 정한다는 것에 대해 오래된 오해라는 글을 보면 우선순위를 결정한다는 것은 열 가지 해야 할 일을 놓고 1번에서부터 10번까지 순서를 매기는 것이 아니라, 열 가지 중요한 일 중에 "하나"를 선택하는 것이라고 한다.
그리고 한기용 님의 인터뷰 영상에서 어려운 일정을 요청하면
"그때까지 힘들지만, 이 기능 중 정말 중요한 것이 무엇인지 알려주시면 그것은 먼저 해볼 수 있습니다."
라고 답하는 것이 중요하다고 한다.
Kent Beck은 Scope Management 101에서 무엇을 해야 할지 사전에 결정할 수 있는 일(fixed work)은 일의 범위(scope, 구현할 기능의 범위)가 결정되었으니 "좋고(quality), 빠르고(time), 싸게(cost)" 중에서 2개를 정하면 나머지 하나는 자연히 정해진다고 한다.
하지만 소프트웨어 개발은 처음에 요구사항(기능 범위)을 모두 정확히 아는 것이 거의 불가능하고, 개발을 진행하면서 실제로 필요한 기능이 새롭게 발견되거나, 기존에 중요하다고 생각했던 기능이 불필요해지는 경우가 많다고 한다. 그래서 소프트웨어 개발의 본질은 "무엇을 만들어야 하는지"를 점차적으로 발견해 가는 과정이라고 한다. 따라서 소프트웨어 개발에서는 ‘좋고, 빠르고, 싸게’ 중 두 가지를 고르는 공식이 맞지 않는다고 한다. 오히려, 소프트웨어 개발에서는 범위(무엇을 만들지)를 계속 조정하면서, 품질은 일정 수준 이상으로 유지하고, 시간과 비용은 그에 맞춰 유연하게 관리하는 것이 중요하다고 한다. Kent Beck은 그래서 소프트웨어 개발에서는 ‘범위 관리’가 가장 중요한 변수라고 강조한다(사실 납기 변경되거나, 갑자기 개발자의 수가 급격하게 변할 수 없어서 빠르고, 싸게도 고정이다).
그러니 우선순위를 매번 정하면서 실행하다가 이만하면 고객에게 전달해도 되겠다는 시점에 전달하고, 피드백을 보고 나머지 일을 할지? 새로운 일을 할지? 결정하는 방향으로 진행하는 것이 답이라고 생각한다.
이렇게 일하면서 최대한 빠르게 전달하고, 일정을 관리하고 변경을 최대한 빨리 공유하는 것. 이것도 CTO, 개발리더의 아주 중요한 역할 중 하나라고 생각한다.
