개발자와 이야기 하기위한 A to Z

1. 개발자에게 요구사항을 어떻게 전달해야 할까.

 

비개발자는 개발자에게 요구사항을 어떻게 전달해야 할까. 개발자는 요구사항을 전달받으면 어떤 게 궁금할까? 개발자에게 요구 사항을 전달할 때 어떻게 전달하면 좋은지 정리한다. 이 글은 기획자를 위한 게 아니다. 기획자들은 요청사항 전달의 전문가다. 그들은 알아서 잘 전달할 거라서 사실 걱정하지 않는다. 하지만 모두 기획자들처럼 개발자들에게 전달할 수 있는 건 아니다. 모든 조직이 기획자를 통해서 개발자에게 요구 사항을 전달하는 것도 아니다. 이 글은 기획자가 아닌 사람도 적어도 이 정도는 생각하자는 내용이다.

 

(1) Why를 전달하라.

 무엇을 만들고, 왜 만드는지 전달하라. 왜라는 주제는 중요하다. 개발자들은 '왜'라는 목적을 가지고 작업해야 더 빠르고 효율적으로 뒷부분을 설계한다. 왜라는 과정을 통해서 개발자를 설득해야 한다. 만들고자 하는 이유가 개발자를 설득하지 못한다고? 그럼 누구를 설득할 수 있나.

 

(2) 프레임에 대입해라.

 인간은 그리 꼼꼼하지 않다. 아무리 잘 챙기려 해도 구멍은 생긴다. 구멍을 메꾸고 싶다면 프레임 안에 넣어보면 된다. 스토리보드를 만들던, 유스케이스 다이어그램을 만들던 사람들이 사용하고 있는 틀 안에 자신이 생각하는 내용을 넣어보면 된다. 그러면 칸이 채워지지 않는 부분이 생기고, 그 부분을 채워 넣으면 된다. UML 같은 도구들의 도움을 받을 수도 있다.

 

(3) 시각적으로 전달하라.

 어느 한 장면을 묘사하기 위해서는 아무리 쿨한 문서도 사진 한 장만 못하다. 최종 목적이 되는 이미지를 시각적으로, 그림으로 그려서 전달해라. 당연히 프로토타입을 위한 도구들을 잘 이용하면 좋겠지만, 그것도 학습 시간이 든다. 하다못해 연습장에라도 그려라. 연습장에 그렸다면 사진이라도 찍어놔라. 최종 상이 요청을 하는 사람과 받는 사람이 일치해야 한다. 시각적 전달은 매우 중요하다.

 

(4) 예시를 함께 제공하라.

'통화 기호와 함께 금액을 표시한다.'라는 내용은 '1000원'?, '1,000원'?, '\1000'?, '\1,000'?, '\1,000원'?, '1,000 \'?, 'KRW 1,000'?, '1,000 krw'?. 예시를 뭐라도 적어라. 인간 말이 얼마나 광의적인지 알게 된다.

 

(5) 모호한 표현을 피하라.

등: 연락처 등. 등등. 등은 쓰지 않는다. 등이라는 글자의 범위는 나만 알 수 있다.

많은: 많은 게 얼마큼인가. 사람마다 많음이 다르다.

대부분, 일부분: 대부분, 일부분 같은 건 없다. 데이터의 상황은 두 가지다.

ㄴ 모든 것이 입력 가능하다. 다만 1, 2, 3, 4는 입력 불가능하다.

ㄴ 1, 2, 3, 4만 입력 가능하다. 나머진 다 안된다.

모호한 표현은 따지고 보자면 참 많다. '이렇게까지 정리해서 줘야 하나.'라는 생각이 들 정도로 정리해서 전달해야 한다.

 

(6) 경우의 수를 전달하라.

숫자 하나만 해도 경우의 수는 많다. '숫자를 입력받는다.'라는 입력창은 질문이 끝없이 나올 수 있다. 이상, 이하, 초과, 미만의 표현은 당연히 명확히 해야 한다. 마이너스는 입력할 수 있나, 최소 숫자는 몇인가(-238741298035719285719도 입력되나?), 최대 숫자는 몇인가 (193875412398571239847은 입력되나?), 입력 시 숫자만 가능하게 할 것인가, 입력은 되면서 저장 시 숫자 아닌 건 제거할 것인가, 콤마(,)는 숫자의 일부인가, 소수점도 입력받을 수 있나, 소수점은 몇 자리까지 입력받을 수 있나? 명심해야 한다. 사용자는 내가 생각지도 못하는 모든 실수를 할 것이며, 값을 필터링하고, 오류를 방지해 주는 사람이 개발자다.

 

(7) 데이터 간 관계를 명확히 한다.

가령 선생님과 학생의 관계를 연결할 때, 선생님에게 학생을 연결하는 구조가 간단하지만, 실제론 다를 수 있다. 학생은 소비자고, 선생님은 공급자다. 둘을 연결해주는 매개가 있어야 한다. 수업, 상담 등의 서비스가 있겠지. 선생님은 수업을 하고, 그 수업을 수강하는 학생이 있는 거다. 물론 그 수업이 하나의 주제 아래에 여러 클래스를 운영할 수도 있으니, 학생이 어디에 소속되는 건지 명확하게 구분해야 한다.

위 내용만 확인하고 진행하는 건 최소다. 당연히 요청사항이 있으면 정리가 잘 되어야 한다. 정리되지 않은 내용은 다 부채로 쌓인다고 생각하면 된다. 나중에 갚아야 된다. 작업은 가능하더라도 항상 마무리 정리를 잘하길 추천한다.

정리되지 않은 데이터는 정보라고 부르지 않는다. 정리만이 데이터를 정보로 바꾸고, 정보를 노하우로 바꾼다. 공유하고자 한다면 데이터를 정보와 노하우로 바꿔야 한다.

 

 

2. 개발자와 대화할 때 피해야 할 표현

문서나 정책 말고 대화 쪽 표현을 본다. 문서나 정책에도 쓰면 안 되는 표현이 수두룩 빽빽하다. 그건 다음에 한 번 풀어본다. 우선 구어체부터 푼다. 일을 하면서 다양한 사람들과 대화하게 된다. 기획자, 개발자, 디자이너, 마케터, 운영자, 고객님, 팀장, 사장님 등등등... 여하튼 많다. 하다 보면 당연히 욱 할 때가 있다. 기획자가 다른 기획자랑 말할 때도 문제는 생긴다. 개발자가 개발자들 사이에서 대화할 때도 의사소통에 관한 문제는 언제나 중요 화두다. 그중에서 이번에는 비개발자들이 개발자들에게 말할 때 피해야 할 표현들을 풀어본다.

 

(1) 일주일이면 되죠?

 얼마나 걸릴지는 개발자의 영역이다. 게다가 저런 질문은 보통 작업 시작 전에 던지게 되는데 개발자도 정확히 모른다. 개발자 입장에서는 정확히 확인 안 하고, 괜시리 함부로 던졌다가 야근을 해야 하는 상황이 생길 수 있다. 개발자가 확인 후에 공유해주는 게 맞다. 가령 너무 간단한 건 보자마자 알 때도 있지만, 개발자의 예측을 맹신하면 안 된다. 그러다 뒤통수 맞는다. 혹시 예상 기간을 알 거 같다고 하더라도 '작업 예상 기간이 얼마나 될까요?' 라고 묻는 게 맞다. 특별한 마감 일정이 있다면 그 일정 안에 가능하도록 요청을 하는 게 맞다.

 

(2) 그거 이렇게, 이렇게 하면 되잖아요.

 개발자 출신 요청자가 하는 실수 중에 하나다. 자신이 안다는 생각으로 함부로 개발자의 작업 영역까지 넘어가면 안 된다. 작업을 어떻게 진행할지는 개발을 직접 하는 사람도 DB담당자, 개발팀장 그 외 개발 관련 담당자들과 논의 후에 결정할 수 있다. 알고 있다 해도 알고 있는 사항을 그대로 작업하는 건 흔치 않다. 같은 기능도 인프라 구조, 코드 패턴, 프레임워크 등에 따라 작업의 분량은 전혀 다르게 책정된다. 작업 방법만큼은 개발자의 영역이다. 혹시 개발자에게 작업 방향을 함께 논의하고 싶다면. '이렇게 이렇게 하는 건 가능할까요?' 라고 묻는 게 맞다.

 

(3) 여기만 살짝 바꿔주세요.

 가끔 비개발자가 보기에 굉장히 간단해 보이는 작업들이 있다. 아무 기능도 없는 화면에 A라고 써있는 글자 대신 B라고 써야 된다든지 그런 것들. 내가 보기에 간단해 보여도 구조가 어떻게 되어 있는지는 내부 담당자들만이 알 수 있다. 글자 하나인데도, 만약 타팀에서 API로 받아온 내용을 찍어주고 있을 수도 있다. 그러면 그 타팀에 글자 바꿔달라고 요청한다. 그런데 그 문구는 회사 외부까지 공개되어 있는 API라서 함부로 변경할 수 없덴다. 내가 보기에 살짝인 게. 살짝이 아닐 수도 있다. 개발자가 구조를 파악하고 나서 살짝인지 아닌지를 함께 판단해야 한다.

 

(4) 이거 몰라요?

 개발자는 신이 아니다. 게다가 개발 분야는 엄청나게 넓다. 하나의 제품에 집중했던 개발자라 하더라도, 그 제품의 모든 코드를 외우고 있는 게 아니다. 더군다나 협업을 통해 만들어지는 프로그램은 자신이 작업한 영역 말고 다른 영역은 남이 만든 남의 프로그램 느낌이다. 오히려 모르는 게 당연하다. 당신이 알고 있는 그 내용은 모두가 알고 있는 내용은 아닐 거다. 그게 개발 지식이라면 너무 넓은 개발 분야를 탓해야 하고, 함께 작업 중인 제품의 특정 부분이라면 협업을 해야 지나 대응할 수 있는 비대해진 요청들을 탓해야 된다.

 

(5) 다른 곳은 되잖아요.

다른 곳이 된다고 우리도 돼야 한다는 말은 사실 어찌 보면 맞는 말이다. 요청자 입장에서는 말이다. 하지만 되는 그곳과 당신이 진행코자 하는 이곳은 같은 곳이 아니다. 대부분의 '다른 곳은 되잖아요'라는 멘트는 비용, 기간, 인적자원 등은 고려하지 않은 멘트다. 협업이라는 것을 하고 있는 상황이니 충분히 알고 있지 않은가. 기능 하나 나오는 게 얼마나 종합적인 활동인지.

 

 

우리는 비개발자니까 대부분 개발팀 밖에 소속되어 있을 거다. 그러니 개발팀과 소통할 때는 되도록 최대한 예를 갖추자. 물론 위와 같은 표현은 비개발팀이 개발팀에게 전달할 때의 주의사항이다. 혹시 개발자가 이 글을 읽을 때 오해할까봐 이야기하는데, 개발 팀장은 개발팀원한테 저렇게 이야기하기도 한다. 개발팀 관리자급이 이야기할 땐 다르다.

 

 

3. 개발팀 관리자가 개발팀원에게 이야기한다면...

 

(1) 일주일이면 되죠?

일주일 안에 하라는 말이다.

 

(2) 그거 이렇게, 이렇게 하면 되잖아요.

이렇게, 이렇게 작업하라는 말이다.

 

(3) 여기만 살짝 바꿔주세요.

작업 과정은 상관없고, 내 눈엔 살짝 바뀐 결과를 보여달라는 말이다.

 

(4) 그거 몰라요?

알아야 하는 사항을 당신이 모르고 있다는 말이다.

 

(5) 다른 곳은 되잖아요.

우리도 돼야 된다는 말이다.

 

 

똑같은 표현도 그 말을 하는 사람과 듣는 사람의 입장에 따라 다양한 의미로 해석되니. 우리는 협업자로서 개발 영역을 존중해야 하는 입장임을 항상 생각해야 한다.

개발이 진행되는 단계라면, 지속적인 크로스 체크는 필수다. 내가 요청한 내용이 개발팀에서 어떻게 진행되고 있는지는 알 수 없다. 지속적으로 확인할 수밖에 없다. 당연히 개발팀도 작업 단계마다 요청자에게 진행 상황을 공유해주는 게 필요하다. 내용, 일정에 관해서는 서로 끊임없는 공유 밖에는 답이 없다.

만일 뭔가 마음이 상하는 대화가 오고 간다면, 그건 의사 전달의 내용 때문이 아니라 표현법의 문제일 때가 대부분이다. 그게 거의 98% 이상이다. 우리는 어찌 됐건 일을 하자고 모인 사람들이다. 그냥 하는 게 아니라 잘 하자고 모인 거다. 개발자들도 대부분 일하고 돈 받는 사람들이고, 좋은 제품을 만들고자 하는 사람들이다. 개발자든, 비개발자든 모두 잘해보자고 모인 사람들이다.

 

 

 

4. 누락 여부 확인은 어떻게 해야 될까

(1) CRUD 확인하기

CRUD라 함은 개발자들이 주로 쓰는 표현으로 Create, Read, Update, Delete를 말한다. 데이터에 있어서 이 4가지 사항은 항상 같이 고려되어야 한다. 예를 들어 간단한 게시판을 하나 만든다고 하더라도. 글을 쓰고, 읽고, 수정하고, 삭제하는 것은 항상 세트다. 이렇게 보면 '요청사항 정리하다보면 당연히 확인되는 내용들 아닌가?' 라는 생각을 할 수도 있다. 다른 예시로는 회원정보가 있다. 회원가입, 회원정보 확인, 회원정보 수정, 회원 탈퇴 인데... 탈퇴 안만드는 서비스들 많다. 이탈률을 낮추기 위해서 탈퇴를 어렵게 만드는 것도 하나의 의도겠지만. 애초에 의도 자체가 없으면 안된다. 어떤 식으로 진행될지 사전에 당연히 고려되어야 할 부분이다.

 

(2) 중도이탈

모든 상황을 진행할 때 한 페이지 안에서 모든 내용이 끝나면 좋겠지만, 당연히 여러 절차를 진행하는 프로세스들이 있다. 1단계 > 2단계 > 3단계 이런 식으로 진행되는 처리는 일상에서 겁나 많다. 구글은 로그인도 2단계다. 이메일 주소 넣고, 다음 화면에서 비밀번호 넣고 하는 식이다. 어찌됐건 여러 절차대로 해야하는 일들은 일상이다. 그걸 어찌할 수는 없는 노릇이고, 우리는 요청할 때 중간에 끊기는 일이 분명 일어난다. 지나가던 동료가 내 컴퓨터를 발로 차고 갈 수도 있고, 스마트폰에서는 마지막 단계에서 꼭 베터리가 나간다. 그러면 그 동안 앞단계에서 진행했던걸 어떻게 처리하는게 꼭 말이 나온다. 앞단계까진 날려버리고 처음부터 하라고 할지, 아니면 다음에 다시 들어가면 임시저장된 내용이 있다면 자동으로 채워줄지 그건 제작진의 몫이다. 요청하는 사람 입장, 관리하는 입장에서는 중간에 페이지를 벗어나는 일을 꼭 한 번은 고민해야 된다. 어차피 고민 안해도 회의 들어가면 개발자가 물어볼거다. ;;;;

 

(3) 데이터 정의

'회원정보에 연락처 추가해주세요.' 라고 하면 개발자는 그 말을 듣고, 빨리 요청자가 다음 말을 해주길 바란다. 개발자는 '연락처'라는게 뭔지 너무 궁금하니까. 그런데. 대부분 요청자는 저걸로 끝나지. ;;; 연락처에는 집전화번호, 휴대폰번호, 직장전화번호, 팩스번호 등등 다양하다. 이메일은 연락처에 들어가나? 개발자는 데이터를 저장할 때 항목의 값을 명확히 넣어야 해서 데이터가 어떤 놈이 들어갈지 항상 궁금해한다. 요청이나 기획 하는 입장에서는 항상 데이터를 나누길 바란다. 더이상 쪼갤 수 없을 때까지 쪼갠 다음에 그걸 가지고 더 쪼개든 묶든 지지고 볶고 하는거다. 모호한 요청은 모호한 제품을 생산한다.

 

(4) 최소치, 최대치

위 연락처 예시를 들었으니, 이어서 해보자. 연락처, 휴대폰번호든 뭐든 추가할 수 있게 하면.... 몇 개까지 되게 할건가? 일반 사람들 기준에서는 한 사람의 연락처라고 해봤자. 상식으로는 10개를 넘어가긴 힘들거다. 그렇다고 전달 안하면 안된다. 최대는 꼭 전달하고... 하나 더 최소도 전달해야 한다. 연락처가 없는 사람은 존재할 수 있는가, 없는가. 적어도 1개인건지. 아니면 0개도 허락하는지. 그것에 따라 회원등록부터 사용자 경험이 많이 변하게 된다.

 

(5) 디스플레이별 레이아웃

세밀하게 따지면 끝이 없지만, 크게 두 가지만 보자. 컴퓨터와 스마트폰. 크기가 전혀 다르다. 혹시 하나의 프로그램이 양쪽에 같이 들어가야 하나? 네이버는 어떤가. 네이버는 컴퓨터용, 스마트폰용 따로따로 만들었다. 하나를 두 개에 같이 보이게 할지, 아니면 별도의 화면을 만들지도 고민. 모든 컴퓨터가 해상도가 같은 것도 아니다. 해상도마다 어떻게 보일지도 고민. [로그인] 이라는 버튼이 있다면 이 버튼은 모니터가 커지면 같이 따라서 커질까, 아니면 크기는 그대로일까. 혹시 따라서 커진다면 3미터짜리 모니터에서도 그렇게 보일 것인가. 커지다가 일정 크기 이상은 안커질 것인가. 하나하나 모든게 고민이다. 물론. 대부분의 기획자들은 공통되는 레이아웃이나 컨셉을 정한다. ㅋㅋ

 

(6) 예외사항

대부분의 사람들은 자신이 원하는 것에만 집중하는 경향이 있다. 그러다보니 하나의 기능을 요청하면서 그 기능이 어떻게 돌아가야 쿨한건지 설명한다. 하지만 기억해라. 디테일은 당신이 집중하는 기능에는 없다. 가령 '전화번호 넣고 문자메시지 보내는 기능 만들어요~' 라고 하면 사용자가 자신의 휴대폰번호를 누르고 버튼을 누르면 수신자가 행복하게 문자메시지를 받는 모습만 생각한다. 그런데 예외는 어찌하나. 전화번호를 제대로 입력 안하면 어떤 메시지가 뜨나? 핸드폰번호인지 검사한다고? 요즘은 070번호에서도 문자수신이 되는데. 그런 번호도 막을건가? 아님 열어주나? 닫든, 열든 정답이 있는게 아니다. 진행하기 전에 다양한 변수를 놓고 함께 고민이 필요하다는거다. '로그인 되면 대시보드 화면 보여주세요~' ... 개발자는 저 말을 듣자마자 생각한다. if 로그인하면... else... '그럼 로그인 안되면 어떻게 하나요?' ;;;

 

(7) 기존기능 충돌

최근의 제품은 복잡하다. 당연하다. 사람들이 복잡한걸 원하니까 그렇게 된거다. 문제는 원칙 없이 복잡함을 만들 때다.

'VIP만 진행하는 프로모션을 진행하고 싶어요~', '진상고객들한테는 프로모션 제외 해주세요~'... ;;; VIP면서 진상이면 어떻게 하나요? 프로모션 넣어여? 빼여?... 잡설이지만 VIP면서 진상. 분명히 있다. 살 때마다 불만도 많고 엄청 욕하는데, 한 번 사면 3천만원씩 산다. VIP면서 진상이다. 프로모션이 보이든, 안보이든 그게 어떻게 결정되든 지금 그건 중요하지 않다. 중요한건 이런 기능 간의 충돌이 생길 가능성을 미리 검토하고, 함께 논의하라는거다.

 

 

한 번 쯤 위 내용을 문서 전체에서 확인한다면 개발사항에서 꽤 많은 부분 구멍이 메꿔질 것이다.

 이 글은 비전공자들을 대상으로 쓰여진다. IT분야에서 일하는 서비스 기획자라면 당연히 챙기는 부분들이겠지만, 그 외 분야의 사람들은 요청을 전달할 때 자신이 원하는 기능에만 집중하는 경향이 있다. 보통의 경우 한 가지 체크만 하면 그나마 좀 낫다. 그 필살 원칙은 '당연한 것은 없다.' 이다. '그런건 말 안해도 당연히 이렇게 되는거 아니예요?' 같은건 이 쪽 필드엔 없다.