개발자라는 용어

지극히 프로그램 코더적인 접근일지 모르겠지만 개발자(Developer)에는 단순히 프로그램의 직접 구현에 관련된 사람 뿐만이 아니라 아이디어 메이커나 기획자, 심지어 그 조직의 장 내지 대장(CEO?)도 포함되지 않나 한다. 단순히 이해관계자(Stakeholder)로 분류되던 조직의 수장이나 마켓팅 부서도 다분히 개발조직에 포함되는 것이 맞지 않나 한다.

소프트웨어 품질에 대한 책임은 누구에게 있는가 from IBM Developerworks

테스팅 혹은 품질 관리에 관련된 이야기일수 있지만 테스팅이라는 것이 기존처럼 각 함수들이 잘 동작하는지나 최종 프로그램이 원래 계획서와 일치하는지 확인하는 수준이 아님을 지적하고 있다. 품질보증의 과정으로 처음 기획서 조차도 대장(?)의 요구사항을 제대로 수용하는지 확인하는 테스팅 과정이 필요하고 그것이 QA 즉 품질보증 내지 확인의 과정에 포함되어야 하는 것이다.

작성되는 어플리케이션이나 웹 서비스의 규모는 커져가고 단일 제품이 수용해야 할 기능성은 나날이 증가하고 있다. 수십년 전에는 한 회사가 하던 일이 이제는 컴퓨터공학과 한 과목의 텀 프로젝트 수준인지도 모른다. 복잡한 시스템을 만들어 내기 위해서 언어나 개발툴, 개발 환경도 변해왔고 프로세스적인 측면이나 학문적인 분야 모두 발전해 왔다. 개발 조직이라는 범위도 이제는 C문법이 어떤지 안다고 해서 제품이 나오는 것도 아니고 비지니스적인 측면, 마켓팅 적인 측면, 회계적인 측면 모두가 하나의 개발 과정에 모두 필요한 상황으로 보인다.

더불어서 생기는 개발 조직원들에 대한 요구사항으로 기존보다 훨씬 더 넓은 지식이 있을 것이다. 지식의 깊이에 따라 개발조직의 서브 조직이 구분되긴 하겠지만 개발자에게 기획자의 지식이 얇지만 입문 수준으로 필요하고 기획자도 개발적인 지식들을 다분히 요구한다. 이 거대한 개발조직하에서 다른 파트에 대한 기초적인 지식이 있어야만 좀더 효율적인 개발 과정이 일어나지 않은가 한다. 단순한 인간적인 이해가 아니라 실제적인 지식을 의미한다.

Artifact - 산출물 - 란 단어를 듣고는 사실 많은 관념들이 변하였는데 어떤 시스템 하나를 만들어 감에 있어 코드만이 그 시스템을 구성하는 요소는 아니라는 것이 대표적이다. 유형적인 메뉴얼 같은 것도 있겠지만 기획문서, 설계문서, 검증문서등도 시스템을 구성하는 요소일 것이다. 서비스가 런칭되기 전부터 일어나는 마켓팅 행위 그 자체도 시스템을 구성하는 요소이자, 그것을 계획하는 행위는 개발행위라고 볼 수 있다. 최상위 기획서에서는 다뤄야 하는 범위기도 하다. 코딩일정(흔히들 개발일정이라 부르는)에는 마켓팅 일정이 고려되어야 하고 마켓팅 일정에는 코딩일정을 포함되어야 할 것이며, 진정한 전체 개발일정에는 (과장해서) 사장이 가족대리고 하와이 휴가가는 일정까지 반영되어 있어야 할것이다.

개발이라는 것이 기존처럼 코더의 단독 타이핑 놀이가 아니라 이제는 다양한 지식의 사람들이 하는 다양한 활동 모두를 포함할 테고, 각 구성원들은 따라서 자신의 전공분야가 아닌 다른 분야에 대해 다분히 알고 있어야 하며, 모든 개발의 흐름은 이를 모두 아우를 수 있어야 하지 않나 싶다.

PS.
생각해 보니, 개발조직이 사용하는 스페이스를 청소하시는 분들도 개발인력이다. 주위를 깨끗하게 하는 역할만 하는 것이 전부가 아니라 코더가 쌓아둔 피자박스를 몇개까지 치워야 그렇게 더러운 상황도 아니면서도 코더가 자신의 공간이 남에게 침범당하고 있지 않다고 느끼는지 세심한 고려가 필요하기 때문일 것이다. 몇시부터 몇시까지 치워야지 일하는 사람들의 집중을 방해하지 않는지도 말이다.