대부분의 조직은 R&R로 나눠져있다. 그리고 업계에 만연하는 것중 프로그래머는 비즈니스 문제 해결에 관여해서는 안된다는 얘기가 있다. 비즈니스 니즈에 집중하는 것이 프로그래밍의 순수한 기술적 본질을 훼손한다는 이야기이다.
나는 이런 관점에 반대한다.
일반적으로 개발자는 크게 3개의 레벨(주니어, 미들, 시니어)로 구분한다. 각 레벨에 대한 정의를 해보자.
- 주니어: 논란의 여지가 없는 레벨이다. 이론을 배웠고, 이제 업무를 시작하려는 레벨이다.
- 미들: 기술 스택에 대해 이해하는 숙련된 레벨이다.
- 시니어: 다양한 경험을 갖추고 있고, 기술 스택에 대한 경험도 많으며, 업계 전반의 폭넓은 이해를 갖추고 있어야 한다.
원하던 원치 않든, 프로그래머는 비즈니스 문제를 해결한다. 사업은 수익을 창출해야 하고, 여기에는 급여 지급도 포함된다. 수익을 창출하려면 문제(비즈니스 과제)를 해결해야 한다. 간접적이던 직접적이던 비즈니스에 "가치"를 부여하여 문제를 해결해야 한다.
몇 가지 예를 들어보자. 새로운 웹사이트를 만들어야 한다고 가정해보자. 업무 흐름은 아래와 같을 것이다.
현업 요구사항 -> 프로젝트 관리자 -> IT 실무자로 이어지는 업무 흐름에서 두 가지 접근 방식이 존재한다.
- 사례 #1: 요구사항 대로 그냥 코딩 - 모든 사람이 책임 범위내에서 일한다. 프로젝트 관리자는 현업과 논의하고 티겟을 만들고, 시니어는 아키텍처를 설계하고, 주니어는 미들과 개발을 한다.
- 사례 #2: 업무 시작 전에 프로젝트 관리자, 시니어, 현업등이 비즈니스 문제를 심도 있게 논의하는 회의를 여러 차례 진행한다. 단순히 문제 해결 방법 뿐만 아니라, 비즈니스, 개발자, 디자이너 등 모든 사람이 참여해서 효과적으로 문제를 해결하는 방법을 논의한다. 모두에게 효과적인 방안을 찾은 후에야 개발이 시작된다.
사례#1 에서는 모두가 "그냥 코딩"만 한다. 비즈니스 문제는 비효율적으로 해결된다. 마감일이 정해져 있으면, 허술한 해결책을 찾고, 책임을 전가하고, 장황하게 수정 작업을 하고, "새로운 요구사항"을 추가하는 상황이 발생한다. 이는 사람들이 요구대로만 했기 때문이다. 모두가 자신의 범위내에서 "톱니바퀴"처럼 일했고, 비즈니스 문제 해결에는 참여하지 않았다.
사례#2에서는 항상 발생하는 대부분의 잠재적 문제가 상호작용을 통해 해결된다. 필요한 것을 오해할 수 있기 때문에 개발자가 프로젝트 구현 방식을 근본적으로 변경할 수도 있다는 점은 당연한 것이다. 물론 역량에 따라 크게 달라지겠지만, 문제는 훨씬 줄어들 것이다. 이 시나리오에서 비즈니스 문제는 효과적으로 해결된다.
사례#1과 사례#2의 주요 차이점은 무엇일까?
구현 방식이 아니라 팀워크이다. 여기서 팀이란 단순히 프로젝트내에서 무언가를 구현하는 코더 몇 명이 아니라 참여하는 구성원 전체를 의미한다. 사례#2에서는 모두가 좋은 결과를 얻기 위해 함께 노력한다는 점이 존재한다. 물론 세상은 완벽하지 않지만., 가정적으로 그렇다.
이유는 모르겠지만, 사람들은 종종 문제 해결을 영업과 연관 짓는다. 프로그래머는 "어떻게" 판매될지 생각하는 것이 아니라, "무엇"이 판매될지를 생각해야 한다. 최종 제품의 품질은 아키텍처, 속도, 로직, 디자인 등에 따라 달라진다. 여러가지 것들이 제품의 품질에 담긴다.
본 글의 서두에서 프로그래머는 원하든 원치 않든 비즈니스 문제를 해결한다고 언급했다. 다시 한번 생각해본다. 프로그래머가 비즈니스 문제를 해결해야 할까?
그래야 한다고 생각한다. 역량, 직책 그리고 경험 측면에서 해결해야 한다.
프로그래머가 영업을 해야 할까? 물론 아니다. 그러나 영업이 안고 있는 비즈니스 문제를 해결해주어야 한다.