『오늘도 개발자가 안 된다고 말했다』 @나는 왜 또 거절당했을까?

기획서 작성 시 가장 중요한 점은 작성 방법이 아니라,
전달하고자 하는 메시지를 정리하는 것이다.

특히 협업을 할 때는 내가 생각한 의도를 상대방에게 정확하게 전달할 수 있어야 한다.
그러기 위해서 무엇보다 기획 의도를 명확하게 정의할 수 있어야 한다.

- 오늘도 개발자가 안 된다고 말했다 中 -

 

김중철, 김수지 - 오늘도 개발자가 안 된다고 말했다

 

“이거 A 기능을 넣어서 업데이트할 수 있을까요?”
“안돼요.”
“…왜요?”

 

"왜 안돼요…?" 기획자와 개발자 사이, 그 어색하고 미묘한 거리

 

 이 대화, 어디서 많이 들어본 적 있지 않나? 특히 서비스 기획자나 디자이너라면 한 번쯤 개발자에게 던졌던 질문이고, 그 답변은 마치 벽처럼 느껴졌을 것이다.

 IT 업계는 협업 없이는 성립할 수 없는 산업이다. 그런데 이 업계의 협업은 생각보다 훨씬 복잡하고, 종종 삐걱댄다. 특히 기획자와 개발자, 디자이너 간의 소통은 다소 미묘하다. 표면적으로는 각자 역할을 수행하는 것 같지만, 실제로는 한 팀처럼 맞물려 돌아가야 한다. 결국 좋은 협업을 위해선 상대의 언어와 일의 맥락을 이해하는 것부터 시작해야 한다.

 

 《오늘도 개발자가 안 된다고 말했다》는 그런 간극을 좁히기 위한 책이다. 주니어 기획자, 디자이너, 그리고 개발자들이 IT 실무를 보다 현실적으로 이해하고, 협업의 핵심을 배울 수 있도록 돕는다. 이 책은 특정한 기능을 어떻게 구현하느냐를 가르치기보다, ‘왜 이 일이 이렇게 돌아가는가’에 대한 시야를 넓혀주며, ‘왜 이런 요청이 받아들여지지 않을까’, ‘어떻게 말해야 서로 이해할 수 있을까’ 같은 질문에 대해 고민하게 만든다. 그래서 막 입사한 신입, 이직을 준비하는 주니어라면 이 책을 통해 ‘협업의 감각’을 익히는 데 꽤 많은 힌트를 얻을 수 있다.

 

나 역시 비전공자로 IT 업계에 들어와 일하고 있다. 그래서인지 디자이너나 개발자 파트보다는, 이 책 속 ‘기획자’의 이야기에서 유독 공감이 많이 갔다. 같은 비전공자 혹은 주니어 기획자라면, ‘기획자에게 가장 필요한 감각이 무엇일까?’라는 질문에 대해 이 책이 하나의 실마리를 줄 수 있을 것이다.

 

---

책소개

“개발하기 싫어서 안 된다고 말하는 게 아니다”

“개발 언어를 잘 몰라도 협업을 잘할 수 있다”

많은 IT 종사자들이 안 된다고 말하는 개발자로 인해 협업에 어려움을 겪는다. 우리는 IT 비전공자로서 소통을 잘하기 위해 개발자의 입장에서 많이 생각하게 됐고, 이 과정을 통해 개발자의 안 된다는 말에 담겨 있는 여러 가지 의미를 깨달았다. 이 책에는 우리의 성장 과정에서 발견한 협업 노하우들을 담아냈다.

 

개발자와의 협업은 외국인과의 대화와 닮은 점이 많다. 영어 시험 점수는 높은데 외국인과 대화를 못 하는 친구와 시험 점수가 높지 않아도 외국인과 대화를 잘하는 친구를 모두 만나본 적이 있을 것이다. 개발 언어는 영어 단어와 비슷하게 많이 알면 유리하지만 당장 협업에 써먹기는 어렵다. 개발 언어를 배우기 전에 꼭 먼저 알고 있어야 할 정보들에 대해 알아보자.

 

[교보문고 제공]

---

 

 

기획자의 협업

프로젝트를 성공으로 이끌기 위해서는 서비스의 구조와 방향을 모든 프로젝트 참여자가 명확히 이해할 수 있어야 한다. 그리고 그 출발점은 바로 잘 정리된 기획서다. 기획서는 단순한 문서가 아니라, 프로젝트 전반의 나침반이 된다. 특히 협업의 중심에 있는 기획자는 서비스의 방향성과 목적을 명확하게 정리하고, 이를 다른 팀원이 공감하고 따라올 수 있도록 구조화된 문서로 풀어낼 수 있어야 한다.

 

기획자가 준비해야 할 핵심 문서들

1. IA (Information Architecture, 정보구조도)
서비스 전반을 체계적으로 구조화한 문서다. 비슷한 속성을 가진 정보들을 묶어 상하 관계로 정리함으로써, 서비스의 전체 구조를 한눈에 파악할 수 있게 한다.

@오늘도 개발자가 안 된다고 말했다

 

2. MECE와 Hierarchy (계층구조)
MECE는 '서로 겹치지 않으면서 전체를 빠짐없이 나누는 것'을 의미하고, Hierarchy는 부모-자식 간의 위계적 관계를 말한다. IA를 만들 때 이 두 가지 원칙을 적용하면 정보의 누락 없이 깔끔한 구조화가 가능하다. Depth 또는 Level로 구분하여 문서화하는 것이 일반적이다.

@pageflows

 

3. Flow Chart (순서도)

IA가 전체적인 구조를 보여준다면, Flow Chart는 사용자의 행동 흐름을 직관적으로 도식화한 것이다. 사용자가 어떤 경로로 화면을 이동하고 어떤 행동을 하는지를 시각적으로 보여주며, 서비스 시나리오를 구체화하는 데 큰 도움이 된다. Flow Chart에는 구체적인 정책도 함께 정리해두면 협업 효율이 높아진다.

 

 

협업을 위한 화면 설계서

화면 설계서는 단순히 ‘디자인을 위한 스케치’가 아니다. 서비스의 핵심 기획 의도를 명확히 전달하고, 팀원들과 원활하게 커뮤니케이션하기 위한 중심 도구다. 기획자가 초안을 만들고 나면, 개발팀과의 기술 검토를 거쳐 구현 가능성을 따져보고, 이후 디자인팀이 시안을 완성한다. 디자인이 확정되면 다시 개발팀으로 넘어가 실제 개발이 진행되고, QA/QC를 거쳐 운영환경에 배포된다. 이 전체 흐름에서 화면 설계서는 실질적인 ‘공통 언어’ 역할을 한다.

그래서 모든 팀원이 쉽게 이해할 수 있는 설계서를 만드는 것이 중요하다. 단순히 예쁘게 그리는 게 아니라, 누구든지 보고 서비스 구조와 목적을 파악할 수 있게 만드는 것이 핵심이다.

@오늘도 개발자가 안 된다고 말했다

 

기획서를 쓸 때 중요한 건 ‘어떻게 쓰느냐’보다 ‘무엇을 왜 쓰는지’에 대한 논리를 담는 것이다. 특히 협업 과정에서는 기획자의 의도가 명확하게 전달돼야 한다. 다음의 5단계는 논리적인 기획서 작성을 위한 기본 틀이다.

◈ 기획의 목적을 명확하게 전달하는 논리적인 문장 정리법
1) 개발 요청 기능 정의하기: 어떤 기능을 개발할 것인가?
    - 장바구니 기능 개발 [신규 기능]
2) 제공 대상: 누구를 위해서 제공하는가?
    - 2개 이상의 물건을 구매하려는 고객
3) 이유 및 목적 작성: 이 기능을 만드는 이유와 목적이 무엇인가?
    - 2개 이상의 물건 구매 시 묶음 배송이 안되는 불편함을 해소하기 위한 목적
4) 예시/사례 작성: 정성적/적량적 지표 제시
    - 최근 2개 이상 물건을 구매하는 고객 수 15% 증가
    - 묶음 배송 관련 유선 문의 건수가 전체 문의의 20% 차지
    - 상품별로 배송비를 따로 지불하고 있어 불편하다는 낮은 평점의 고객 리뷰 증가
5) 기대 효과: 무엇이 좋아지는가?
    - 고객지원팀에서 묶음 배송을 직접 처리하고 있어 빠른 개발 대응 필요
    - 해당 기능 도입 시 고객지원팀의 투입 리소스 절감 가능

 

이처럼 구체적인 데이터와 사례를 제시하면 설득력이 커진다. 데이터를 수집할 땐 CS팀의 VOC, 마케팅팀의 캠페인 반응, 또는 개발팀이 보유한 데이터 등 실무 팀의 리소스를 활용하는 것이 빠르고 정확하다.

 

기획 문서 체계적으로 관리하기

설계서를 작성하다 보면 수많은 수정이 오간다. 그래서 문서를 체계적으로 관리하는 것이 중요하다. 가장 기본적이면서도 효과적인 방법은 파일명을 통해 문서의 내용을 직관적으로 파악할 수 있게 만드는 것이다.

작성 완료 날짜 / 플랫폼 유형 / 기능 상세 명칭과 기획 방향(신규/개선/고도화) / 문서 버전
예시: 2025.01.01_A몰_상품 검색 신규 기획 설계서_v1.0

항목	설명
작성 완료 날짜	최신 문서를 빠르게 식별 가능
플랫폼 유형	서비스가 여러 개일 경우 명확하게 구분 가능
기능 명칭 & 기획 방향	신규, 개선, 고도화로 기능 목적 구분
문서 버전	같은 날짜여도 버전 관리가 가능해 혼동 방지

@geralt

 

기획자는 ‘설계자’이자 ‘소통자’다

 《오늘도 개발자가 안 된다고 말했다》와 이 글의 내용을 함께 정리해보면, 기획자는 단순히 아이디어만 던지는 사람이 아니라는 걸 알 수 있다. 기획자는 서비스의 구조를 짜고, 팀원 모두가 같은 목표를 향해 나아갈 수 있도록 이끄는 가교 역할을 한다. 특히 신입 기획자라면 화면을 예쁘게 꾸미는 것보다 더 중요한 건, "왜 이 기능이 필요한가?"를 스스로 설명할 수 있는 능력이다.

 좋은 기획서란 화려한 디자인보다 간결한 구조와 명확한 논리에 달려 있다. 그리고 그 논리는 사용자 데이터와 현장의 목소리에서 나온다. 이 글이 비전공자 출신의 주니어 기획자, 혹은 기획 입문자에게 실질적인 방향과 기준이 되어주기를 바란다.

결국 협업은 ‘신뢰’에서 시작된다. 그리고 신뢰는 잘 정리된 한 장의 설계서에서부터 시작된다.

 

@Pexels