이 화면설계 좀 이상한데요?

기획자와 개발자의 전문성

"OO씨, 잠깐 좀 볼 수 있을까요?

이번에 주신 쪽지 화면설계에서 이해가 안되는게 있어서요."

"네, 지금 자리에 있으니까 오시면 되요."

나는 카톡을 확인하고 다이어리를 챙기고 자리를 나섰다.

기획자와 의견교환을 위해 가는것이다. 말이 의견교환이지 대부분 기능 수정으로 마무리 된다.

기획이 제때 안나와서 한달 이상 계획보다 딜레이 되고 있었고 아직까지 잡아야할 논리 구멍이 많았다.

이런일이 한 두번이 아니다. 안그래도 바쁜 일정에 너무한다 생각했다.

몇년전 모 공기업 포털을 개발할때였다.

해당 공기업 관련 산업 활성화를 위한 지원정책 대상자 모집 및 커뮤니티를 위한 포털이었다.

이 프로젝트에서 기획자의 역할은 화면설계서 작성이었다.

별도의 기획서 및 시스템 기획, 데이터 시트는 존재하지 않았다.

화면설계를 보고 데이터 구조를 짜는건 개발자의 역할이었다.

일정상의 이유로 기획이 완성된 이후 개발을 시작한게 아니라 기획과 개발이 동시진행 되었다.

설계감리가 끝날때 까지도 화면설계는 완성되지 않고 완성도는 50%에 못미쳤다.

그래서 막상 화면이 있는 기능이라도 구현하려해도 기능이나 데이터에 대한 정의가 구멍이 난 경우가 많았다.

심지어 이번 일과 같이 기획자가 이상한 기획을 하는 경우도 태반이다.

"이거 기업 프로필에 쪽지 기능은 왜 넣으셨어요?"

"뭐가 문제 있나요?"

기획자가 오히려 내게 이상하는듯 물었다.

이 포털의 회원체계는 개인, 기업이 있고 회사 등 조직들의 정보를 모아서 커뮤니티를 만들고자 했다.

그래서 네이버 카페 같은 기능과 연락을 위한 쪽지 기능이 필요했다.

"하아, 개인이랑 기업이랑 관리 체계 다른건 알고 계시죠?"

"네"

"쪽지는 개인 대 개인 아니에요?

기업이 어떻게 쪽지를 확인해요?

기업 아이디는 어떻게 매핑하라고요?"

"아..."

쪽지 기능의 기획의도는 개인과 개인간의 소통을 위한 기능이었다.

그런데 기획을 점진적으로 진행하면서 기업 프로필과 커뮤니티 그룹소통 기능에 쪽지 기능을 넣어버린것이다.

그러면서 쪽지에 대한 표현과 데이터, 상태 처리를 어떻게 할것인지 명시된 내용이 없었다.

"기업을 대표하는 담당자를 둬서 쪽지를 주고받게 하면 안될까요?"

"그건 할 수 있다 쳐도 개인간에 보냈는지, 카페에서 보냈는지,

기업을 대표해서 보냈는지는 어떻게 구분하려구요?"

"아..."

기업 구성원중에 대표 담당자를 지정한다는 기획도 존재하지 않았다. 이미 구현을 진행한 기능도 문제였다.

개인 쪽지와 단체 쪽지를 구분할 장치가 마땅치 않았던것이다.

그렇지 않아도 카페 기능으로 인해서 데이터간의 관계가 복잡한데 미지수가 발생한것이다.

모든 문제를 해결하려면 많은 테이블 변경과 화면 수정 및 추가, 그리고 상황별 상태 코드 정의가 필요했다.

이 상황까지 오도록 데이터시트 하나 정리하지 않은 기획자의 잘못이지만 일정에 대한 책임은 개발자가 진다.

이 기획자는 지금 난처한 상황을 회피하려고 즉석해서 무리수를 던지고 있는것이다.

어차피 지금까지 논의한 모든게 화면설계서 등 문서로 설명이 되어야 작업을 할 수 있다.

말로만 했던 사항을 나중에 번복하는 일이 잦아서 믿을수가 없었다.

기획자가 데이터를 모르고, 신경쓰지 않으면 이런 일이 발생한다.

소프트웨어 개발 현장에서 기획자는 무슨 역할을 하는가?

고객이 필요한 소프트웨어를 만드는 이상, 누군가는 고객의 요구사항을 이해하고 정리해야한다.

단지 사람의 말을 받아적는걸 넘어서 실제 전산 시스템으로 만들 수 있도록 풀어내는 일이다.

기획자가 하는 일은 소프트웨어 개발 전반에 걸쳐서 영향을 미친다.

최종 제품의 기능과 모양이 기획서에 쓴 문구 한줄에 따라 180도 달라지기도 한다.

그래서 기획자는 고객, 디자이너, 개발자와 커뮤니케이션 하며 일을 주도하는 역할을 한다.

즉, 기획자의 일은 최종 제품의 구성과 목표를 고객의 요구사항을 충족하도록 계획하고 설계하는것이다.

이러한 역할은 문화 예술, 체육, 게임 등 다양한 분야에서 흔히 찾아볼 수 있다. 교향악단의 지휘자, 영화 감독, 게임 디렉터 등 하나의 작품이 나오기 위해 전체를 조율하는 역할의 사람들이다.

소프트웨어 개발은 개발자가 다 하는것으로 인식하기 쉽지만, 사실 제품 계획없는 코딩은 가치를 인정받기 어렵다.

'기획자도 개발을 할 줄 알아야 하나요?' 주니어 기획자들의 단골 질문이다.

위에서 내가 한 이야기들이 기획자도 개발을 할줄 알아야 한다는 이야기는 아니다.

개발자의 사고방식을 이해하기 위해서 C언어나 Java를 공부하기 시작했다는 기획자들을 보면 사실 좀 안쓰럽다.

실무에서 오죽했으면 그런 노력을 하겠는가.

결론부터 이야기 하자면 기획자가 프로그래밍을 상세하게 알 필요는 없다.

오히려 애매하게 개발자 경력이 있는 기획자가 개발자와 많이 싸운다.

물론 아예 감을 잡지 못하는것 보다는 어느정도 경험해보는것을 추천한다.

그렇다면 기획자가 알아야할것, 중요한것은 무엇인가?

최소한 '말이되는' 기획을 할 필요가 있다고 생각한다.

기획자의 일도 소프트웨어 개발의 일부다. 그래서 소프트웨어 개발의 생리에서 벗어날 수는 없다.

논리적으로, 현실적으로 말이 되지 않는 기능은 존재할 수 없다.

데이터가 어디서 만들어져서 나가는지 흐름을 만들고 모듈간의 상태를 정의하고, 상태간의 제한사항을 정리하는것도 기획자가 해야할 일이다.

쪽지 기능을 기획한다면 기능의 목적이 무엇이고, 서비스 영향 범위는 어디까지고, 대상은 누구이고 하는 논리를 다듬을 줄 알아야한다.

상담 게시판을 만든다면 질문자가 게시물을 올리면 상태가 어떻게 되고, 접근 권한은 어떻게 되며, 상담자에게는 어떻게 보이고, 답변후 상태는 어떻게 되고 하는 모든것을 일목요연하게 정리해야한다.

C++, Java와 같은 프로그래밍 언어보다 어려운 국어, 영어 등으로 논리를 만드는것이 기획이다.

사용자가 편리하게 사용하기 위한 예쁜 컴포넌트나 최신 기능을 가져다 쓰는 것은 나중의 일이다.

기획자가 일을 했다면 품질에서 무언가 한끗이라도 차이가 나야 하지 않을까?

최소한 파워포인트로 화면설계를 예쁘게 그리는것만이 기획자가 해야할 일은 아닐것이다.

물론 기획자도 여러가지 한계가 있다. 사람간의 의견과 입장을 조율하는것이 개발하는것 보다 더 힘들때도 많다.

가장 이상적인 기획의 결과는 개발이 시작되기전에 모든 목표가 정리되고 그대로 개발만 하면 되는 상태일것이다.

그러나 현실에서 그런 일은 거의 일어나지 않는다.

어느정도는 개발자가 기획서에 구멍이 난 부분을 알아서 메울줄 말아야한다.

개발자도 분석설계 단계에서 해놓은 설계를 개발을 해나가면서 논리 오류를 찾아내고 수정한다.

마찬가지로 기획자도 사람인지라 실수 할 수도 있고, 일정에 치여서 중요한것을 빼먹기도 한다.

서로간의 역할에서 수용할 수 있는 실수의 범위가 클수록 신뢰하고 같이 일을 해 나갈수 있을것이다.

하지만 그 정도가 너무 심하다면 서로의 일을 방해하는 사태가 벌어진다.

현실적으로 개발이 가능한 범위와 기획의 방향성이 어긋날 경우 많은 시간을 허비하게 된다.

학교 납품용 방송장비를 개발한적이 있다. 하드웨어에서는 전체 방송 기능과 특정 채널 방송 기능만 제공되었다.

하나의 채널이 선택되어 있는동안 다른 채널로는 동시 송출이 불가능했다.

그런데 만들어야 하는 기능은 그룹으로 관리되는 특정 채널에 동시에 방송하는 기능을 만들어야했다.

소프트웨어에서 어떻게든 해결하려해도 녹음한 음성 등을 송출하는 기능도 제공하지 않았다.

하드웨어에서 해결해야할 문제를 소프트웨어로 미룬것이 화근이었다.

결국 해당 기능은 납품 일정이 거의 다 되서야 개발 불가능한것으로 마무리 되었다.

프로젝트 사정에 따라 기획자가 없어 개발자가 비즈니스 분석 업무를 하게 되는 경우가 많다.

제안요청서(RFP) 내용을 보고 고객과 미팅을 하고 화면설계를 그리고 그대로 설계 및 개발을 한다.

이 때 제대로 기획을 해서 개발을 하는 개발자는 거의 존재하지 않는다.

개발자에게 있어 기획이란 개발을 하기 위한 기능 목표를 잡는것, 그 이상은 될 수 없기 때문이다.

때로는 아무런 계획없이 대충 잡은 기능 목표만 가지고 코딩부터 하기도 한다.

코딩을 하면서 이 기능이 될지, 안될지 정리하고 증거들을 쌓으면서 기능 목표에 다가가는것이다.

좋게 포장해서 애자일(Agile)이다.

그러나 국내의 대부분의 중대형 프로젝트는 워터폴(Waterfall)로 수행한다.

어차피 분석설계를 해야하고 소프트웨어 감리를 받기 위해 문서를 써야한다.

코딩을 해놓은 부분과 프로젝트 목표의 차이를 한참 시간이 지나서야 확인하게 된다.

결국 분석설계를 마무리하는 시점은 한참 뒤로 밀리기 일쑤다.

초벌 코딩을 하느라 시간을 빼앗긴 만큼 제품의 최종 목표를 잡는데 소홀해진것이다.

그래서 사용자 경험이나 기능의 정체성이 엉망인채로 이미 소프트웨어가 완성되어 있는 경우가 많다.

심한 경우 긴 시간 시행착오를 겪거나 힘들게 개발해놓은 기능이 폐기되기도 한다.

기능은 만들었지만 실제 프로젝트 목표나 배포 등 실제 적용에 문제가 있는걸 간과했기 때문이다.

개발자는 컴퓨터와는 친하지만 사람의 언어로 무언가를 정리하는게 약하다.

그렇다면 소프트웨어 개발 프로젝트에 있어 기획은 누가 해야하는가?

당연히 기획자가 따로 있다면 기획자가 하는게 맞다.

그러나 기획자가 파워포인트 문서를 그리는것에 전문성을 두고 있다면 없는게 낫다.

이 글에서는 개발자란 '프로그램 코드를 작성하는 사람'이라는 의미로 썼다.

하지만 '고객의 문제를 해결하고 제품을 만드는 사람'이라는 의미에서는 기획자도 개발자의 한 분류에 속한다.

기획자와 개발자가 상호보완적인 존재로서 시너지를 낼 수 있어야 프로젝트가 원활이 굴러갈것이다.

과거에 함께했던 개발자, 디자이너의 실력을 지금 프로젝트에서는 쓰지 못할지도 모른다.

그럼에도 불구하고 현재 활용 가능한 자원 내에서 최고의 제품을 고객에게 전달해야한다.

기획은 무형의 창조를 하는것이 아니라 기술, 시간 등 자원을 이용하여 현실의 결과를 만들어 내는 것이다.

기획이 창의성의 영역이라는 착각에서 많은 오해가 시작된다.

계획을 세우고, 현실가능 여부를 따져보는것이 기획이다.

머리속에 있는것을 그리는것만이 기획이 아니라, 고객에게 가치를 제공하는것이 기획임을 잊지말자.