기획자가 개발자와 소통하려면
외국인과 일을 하려면 외국어부터 배워야 한다
개발자가 다른 직업군보다 나은 점이 하나 있다면 그것은 프로그래밍과 소통하듯 어떤 절차를 빈틈없이 설명할 수 있다는 점이다. 대부분의 사람들은 개발을 해본 적이 없기 때문에 명령을 추상적으로 하는데 익숙하다. 왜냐면 사람은 기계가 아니기 때문에 추상적 표현도 어느 정도 각자가 구체화해서 알아듣는 셈이다.
가령 샌드위치 만들기를 시킨다고 해보자. 샌드위치를 만들기 위해선 어떤 과정이 필요할까? 먼저 식빵을 준비해서 그 안에 잼이나 양상추, 햄, 치즈 등을 넣으면 된다고 간단하게 말하는 게 익숙할 것이다. 하지만 프로그래밍의 관점에서는 아주 엉망인 지시에 해당한다. 식빵은 어디에 위치하는 식빵인지, 식빵은 얼마의 양을 사용할 것인지, 식빵을 얻기 위해 봉투를 열어야 하는지, 열기 위해서는 어떤 도구가 필요한 것인지, 봉투를 열었으면 마지막엔 닫아야 하는지, 식빵을 합치기 전에 어디에 배치할 것인지, 배치하고 나면 내부에 들어갈 재료들은 어떤 도구로 배치할 것인지.
이상해 보이도록 많은 단계를 인간은 알아서 접근할 수 있으나 실제 개발을 하다 보면 이 모든 작업을 하나하나 지시해 주어야만 제대로 된 결과에 다가갈 수 있다. 만약 식빵이 존재하지 않는 경우엔 어떻게 해야 할까? 기계는 알 방법이 없다. 식빵을 구매해와야 하는데 그러면 어떤 식빵을 구매해야 하지? 구매하기 위해서는 지갑과 충분한 돈이 있어야 하는데 그것은 어떻게 확인하지? 모든 것을 다 알려주어야만 한다. 프로그래밍은 아주 촘촘하게 설계된 그물처럼 코드가 나와야 빈틈없이 모든 경우에 대응할 수 있게 된다.
애초에 정확한 입력이 없는 추상적 명령에 대응하는 것은 개발자에겐 무척이나 괴로운 일이다. 반면 다른 대부분의 직업군은 추상적 명령에 매우 익숙해서 그것이 추상적이라는 사실조차도 인지하지 못한다. 추상적 명령이라는 것은 대부분 이러하다. 정확한 가이드라인이 존재하지 않고, 정확한 기일이 존재하지 않고, 정확한 요구사항이 전달되지 않는다. 이것이 제대로 전달될 수 없는 근본적 이유는 지식이 없기 때문이다. 개발에 대한 지식이 없기 때문에 정확한 요구사항이 전달될 수 없고, 그러다 보니 개발자는 자신의 판단에 따라 시스템의 허용 스펙을 설정해 그것에 대응되는 시스템을 만들게 된다.
개발자의 주관에 따른 스펙 설정, 요구사항 정의가 이뤄지게 되면 여러 시나리오에서 예상치 못한 결과가 발생할 수 있다. 대표적으로 시스템 확장 시나리오다. 개발자가 판단하기에 이것은 데모 버전이라 가벼운 로직과 고도화를 고려하지 않은 구조를 만들어두었는데, 어떤 이유에선지 급박하게 서비스 지원 범위를 늘리거나 더 많은 사용자를 지원하도록 개선해야 하는 상황이 발생할 수 있다. 이렇게 되면 그때부터는 제대로 된 설계 단계가 아닌 미봉책으로 문제를 해결하게 되는 셈이다.
비유하자면 이런 셈이다. 프로토타입 차량을 만들었고, 이 차량은 최대 속력이 150km다. 만약 그 이상 밟게 되면 조향 기능에 심각한 문제가 생길 수 있다. 그러나 갑자기 200km까지 뽑아야 되는 상태가 됐고, 큰 프레임은 변경이 불가능하다. 그렇다면 조향만을 잡기 위해 수정 가능한 하드웨어 영역과 소프트웨어 영역을 억지로 맞춰 스펙을 맞추게 된다. 그렇게 억지로 맞춰진 200km의 속력에서의 조향 가능성은 불안하지만 작동되긴 했다. 그러나 그로 인해 차체 중량이 늘어나고, 다른 예상치 못한 문제점들이 발생했다. 엔진의 RPM이 불안정하게 날뛰거나 조향 과정에서 가끔씩 핸들이 자기 마음대로 움직이는 문제가 생기곤 한다. 그러면 또 그것을 해결하기 위해 문제를 덮기 위한 일을 할 뿐이다.
이런 식으로 일을 하게 되면 결국 제품은 누더기가 되고, 코드는 스파게티 코드가 되며, 기술 부채는 쌓이게 된다. 애초부터 요구사항과 표준 스펙에 대한 정의가 선명해도 그것은 버그 없이 구현하는 게 쉽지 않은데, 요구 사항 정의도 엉망이고, 시나리오 고려도 제대로 하지 않고, 중구난방으로 일관성 없는 변화를 요구하게 되면 결과적으로 시스템은 위기가 생기게 된다.
개발자와 소통을 잘하는 방법은 모든 단계를 절차적이고, 명확한 요구사항 설계부터 하는 방법을 알아야 한다. 대응되어야 하는 사용자의 숫자, 그 사람들이 하는 핵심 활동, 허용 가능한 딜레이 시간, 지원되어야 하는 기기 종류와 버전 등부터 배워야 한다. iOS 버전, 안드로이드 버전, 지원되어야 하는 브라우저 목록 등 숫자와 더불어 측정 가능한 값으로 소통하는 법을 알아야 한다. 만약 제품 설계를 하는데 숫자가 아닌 정성적 지표들만 떠들고 있는 사람이 있다면? 그 사람은 프로가 아니다. 외국인과 일을 하려면 외국어를 알아야 하는 법. 개발자와 일을 하려면 개발자에게 정확한 요구를 하는 방법부터 알아야 하고, 그것을 모른다면 결과물에 대해 불평할 자격이 충분할까 의문이 든다.
