서비스 기획자 개발? 을 알면 벌어지는 일들

서비스 기획자로서 10년 이상을 살아오면서 문득 이런 생각이 들 때가 있었습니다. “이걸 정말 내가 알아야 하는 걸까? 서비스 기획자 개발은 개발자들에게 맡기고 나는 기획에만 몰두하면 되는 거 아닌가?” 하지만 시간이 흐르면서 깨달았죠. 개발에 대한 이해가 기획의 한계를 넓히고, 때로는 모든 판을 바꿀 수 있는 강력한 무기가 된다는 것을요. 데이터 정의서 작성방법, 필수 구성 요소 및 템플릿 예시, 서비스 기획자는 알아야 합니다

오늘은 그동안 제가 경험한 이야기와 함께, 기획자가 개발을 이해하면 어떤 일이 벌어지는지, 나아가 요즘처럼 AI 도구가 대세인 시대에 우리가 개발자 없이도 무엇을 할 수 있는지에 대해 이야기해 보려 합니다. “그렇게 서비스 기획자가 되었다” 오픈채팅 바로가기

1. 서비스 기획자 개발? 현실적인 기획, 더 이상 꿈이 아니다

10년 전만 해도 저는 거창한 기획서를 쓰는 데 많은 시간을 쏟았습니다. 하지만 개발팀에 넘기기만 하면 “이건 불가능합니다.”라는 답변이 돌아오곤 했죠. 그럴 때마다 좌절감과 짜증이 컸습니다. 그런데 HTML, CSS, JavaScript의 기본적인 원리를 이해하고 나니, “불가능”이라는 말 대신 “이렇게 수정하면 가능할까요?”라고 질문할 수 있게 되었어요.

1.1. 기술적 한계를 알면 답이 보인다

예를 들어, API의 데이터 제한 때문에 안 된다는 말을 들었을 때, 제가 먼저 API의 구조를 살펴보고 대안을 제안했더니 개발팀이 감동하더라고요. “기획자가 이런 걸 알다니!”라는 말을 들을 때마다 그 자부심은 이루 말할 수 없었습니다. 반면에 “어디서 또 블로그 봤나 보네?” 할수 도 있죠 개발자의 성향에 따라 다른거 같습니다.

2. 개발자와 기획자의 싸움, 왜 갈등은 피할 수 없을까?

갈등 사례 1: 요구사항 변경

가장 흔한 싸움의 원인은 기획 단계에서 변경되는 요구사항입니다.

  • 기획자의 입장: 사용자의 니즈를 반영해야 하니까 요구사항을 수정할 수밖에 없습니다.
  • 개발자의 입장: 이미 설계를 끝낸 상태에서 요구사항이 바뀌면 처음부터 다시 작업해야 하니 비효율적이라고 생각합니다.

저는 한 프로젝트에서 “간단히 수정하면 될 거 같은데요?”라고 말했다가 개발팀의 분노를 산 적이 있습니다. 그때 개발자가 저를 쏘아보며 이렇게 말했죠. “기획자님, 간단히라는 말을 함부로 쓰지 말아 주세요.” 그 말을 듣고 머리를 한 대 맞은 느낌이었습니다. 그 이후로는 요구사항 변경 전에 항상 개발팀과 충분히 논의하고, 수정 이유와 예상되는 영향을 명확히 설명하려고 노력합니다.

갈등 사례 2: 일정 관리

왜 이건 이렇게 오래 걸려요?라는 질문을 던진 적이 있으신가요? 저는 한때 매 프로젝트마다 이 질문을 했습니다. 그때마다 돌아온 대답은 “기획자님, 개발은 그냥 되는 게 아닙니다.”였습니다.

기획자는 종종 ‘기획 완료 = 프로젝트 완료’로 생각하지만, 개발은 디테일과의 싸움입니다. 그 점을 이해하지 못하면 일정에 대한 갈등은 필연적입니다. 제가 일정 갈등을 해결한 방법은 간단합니다: 일정 산정을 개발자에게 맡기고, 나는 그 일정이 왜 필요한지 배우는 것. 이제는 개발팀이 잡아준 일정을 그대로 신뢰합니다. 물론, “이 일정에 대해 예상되는 리스크는 뭐예요?”라는 질문도 함께 던지며 조율하죠.

갈등 사례 3: 우선순위 문제

기획자는 사용자 경험, 개발자는 시스템 안정성을 중시합니다. 그 우선순위가 충돌할 때 갈등이 생깁니다.

한 프로젝트에서 저는 “이 버튼 디자인을 바꿔야 유저 클릭률이 올라갈 겁니다.”라고 주장했고, 개발자는 “이건 지금 당장 중요한 일이 아닙니다.”라고 반대했습니다. 그 당시에는 제가 승리했지만, 프로젝트의 다른 부분이 지연되는 결과를 낳았죠. 이 사건 이후로는 모든 우선순위를 결정할 때 데이터와 근거를 가지고 논의하려고 합니다. ‘누가 맞냐’보다 ‘어떤 것이 더 유익하냐’를 고민해야 하니까요.

3. 개발자가 좋아하는 기획자? 어떻게 될 수 있을까?

갈등을 줄이고 개발팀과 신뢰를 쌓으려면 개발자가 선호하는 기획자의 특징을 이해해야 합니다. 경험상, 개발자들이 좋아하는 기획자는 아래와 같은 특징을 가지고 있습니다.

명확한 요구사항 정의

구체적일수록 좋다.
개발자들은 애매한 기획서를 싫어합니다. 예를 들어, “사용자가 편리하게 사용할 수 있는 버튼 추가”라는 요구사항 대신 “상단 우측에 가로 100px, 세로 40px 크기의 버튼 추가. 클릭 시 페이지 이동.”이라는 구체적인 설명이 필요합니다.

이제 저는 기획서를 작성할 때 디테일을 먼저 생각합니다. 모호한 요구사항은 곧 개발자의 시간을 낭비하게 만드는 일이니까요.

현실적인 일정 제시

기획자는 때로 야심 찬 일정을 세우지만, 개발팀은 그것이 현실적이지 않다는 것을 바로 알아차립니다. 개발자는 기획자가 현실을 이해하길 원합니다.

그래서 저는 항상 일정을 세우기 전에 개발팀과 협의합니다. “이 작업은 어느 정도 걸릴까요?”라고 물으며 일정을 그들의 언어로 맞추려고 노력합니다. 이것이 신뢰를 쌓는 첫걸음이었습니다.

개발자와의 싸움? 이제는 웃으며 해결할 수 있다

개발 지식을 배우고 난 후, 소통 방식이 달라졌습니다. 예전에는 무조건적으로 요구하고 답답해했다면, 이제는 함께 해결책을 찾아가는 방식으로 협업합니다. 예를 들어, 데이터 처리 속도가 느려서 문제가 생겼을 때, 저는 개발자에게 이렇게 물었습니다.

  • “이 부분을 비동기로 처리하면 속도가 개선될까요?”
  • “캐싱을 적용하면 해결될 수 있을까요?”

이렇게 구체적인 질문을 던지니 개발팀도 적극적으로 대안을 제시했고, 갈등 대신 신뢰가 쌓였습니다. 요구사항을 명확히 정의하고, 현실적인 일정과 리소스를 제안하면서 갈등이 줄어들었죠. 개발팀에서는 저를 두고 “우리 팀에 없는 개발자”라고 부르더군요. 가장 기뻤던 순간 중 하나입니다.

개발자들은 기술 용어와 논리로 소통하지만, 기획자는 감성과 사용자의 시각으로 접근합니다. 이 간극을 줄이는 것이 중요합니다.

4. 기획자도 Git을 알아야 한다

Git은 코드 버전 관리 도구입니다. 하지만 개발자만 사용하는 것이 아니에요. 기획자도 이를 배우면 협업 효율이 대폭 증가합니다. 예를 들어, GitHub를 활용해 개발팀과 함께 작업할 때, 간단히 변경 사항을 트래킹하거나 피드백을 남길 수 있습니다.

서비스 기획자 개발

4.1. 왜 기획자가 Git을 배워야 할까?

서비스 개발은 항상 변화와 수정의 연속입니다. 기획 단계에서 확정된 내용도 개발 과정에서 수정이 필요할 때가 많죠. 이런 수정 사항을 추적하지 못하면 다음과 같은 문제가 생깁니다:

  • 기획과 개발 간의 소통 단절.
  • 어떤 부분이 변경되었는지 알기 어려움.
  • 수정 요청 및 피드백이 체계적이지 않음.

Git은 이러한 문제를 해결할 수 있는 강력한 도구입니다. 특히, 아래와 같은 상황에서 기획자가 Git을 활용하면 큰 도움이 됩니다.

  1. 변경 사항 추적
    Git을 사용하면 문서나 코드의 모든 변경 사항이 기록됩니다. 이전 상태로 돌아가야 하거나, 특정 시점의 변경 사항을 확인해야 할 때 매우 유용합니다.
    • 예시: 새로운 API 스펙을 정의한 후, 개발팀에서 이를 수정했을 때 변경된 내용을 한눈에 확인.
  2. 명확한 피드백 전달
    GitHub의 “Pull Request” 기능을 활용하면 기획자가 개발팀의 작업 내용을 리뷰하고, 댓글로 구체적인 피드백을 남길 수 있습니다.
    • 예시: API 응답 데이터 구조에 대한 수정 요청을 구체적으로 남기기.
  3. 효율적인 협업
    기획자는 새로운 요구사항을 브랜치로 분리해 관리할 수 있습니다. 예를 들어, A라는 요구사항은 브랜치 A에서, B라는 요구사항은 브랜치 B에서 작업하며 서로 충돌 없이 작업을 진행할 수 있죠.

4.2. 기획자가 Git으로 무엇을 할 수 있을까?

Git을 활용해 API 문서를 관리하고 있습니다. 개발자들이 작성한 코드를 기반으로 한 문서를 확인하고, 필요한 수정 사항을 머지 요청으로 제출하는 방식으로 작업합니다. 처음에는 조금 낯설었지만, 지금은 Git 없이는 협업이 어려울 정도로 편리함을 느끼고 있습니다.

API 문서 관리

  • 사용 시나리오: API 문서가 개발 코드와 함께 GitHub에 관리되는 경우가 많습니다. 기획자가 Git을 활용하면 API 문서를 직접 확인하고, 수정 사항을 제안하거나 피드백을 남길 수 있습니다.
  • 구체적인 작업 흐름:
    1. GitHub에서 API 문서가 저장된 레포지토리를 클론(clone).
    2. 로컬에서 문서를 확인한 후 필요한 수정 사항을 작성.
    3. 수정된 내용을 새 브랜치로 커밋(commit) 후, Pull Request 생성.
    4. 개발팀과 리뷰 과정을 거쳐 변경 사항 확정 및 반영.

요구사항 관리

  • 사용 시나리오: 프로젝트가 진행되면서 기획 내용이 수정될 때, 변경된 요구사항을 Git으로 관리.
  • 구체적인 작업 흐름:
    1. 새로운 요구사항 추가 시, 별도의 브랜치 생성(예: feature/new-requirement).
    2. 변경된 기획 내용을 브랜치에 추가하고 커밋.
    3. 변경 사항을 Pull Request로 제출해 팀과 논의 후 반영.

피드백 및 리뷰

  • 사용 시나리오: 개발팀이 구현한 기능에 대해 피드백을 줄 때, GitHub의 코멘트 기능 활용.
  • 구체적인 작업 흐름:
    1. Pull Request 내용을 검토하며 변경된 코드나 문서를 확인.
    2. 필요한 부분에 댓글로 피드백 작성.
    3. 피드백이 반영되면 최종 승인을 통해 작업 종료.

4.3. 기획자를 위한 Git 학습 가이드

Git은 처음에 배우기 조금 복잡하게 느껴질 수 있습니다. 하지만 기본적인 기능부터 천천히 익히면 기획자로서 충분히 활용할 수 있습니다.

  1. 필수 명령어 익히기
    • clone: 원격 레포지토리를 로컬로 가져오기.
    • branch: 새로운 작업 브랜치 생성.
    • commit: 변경 사항 저장.
    • push: 로컬에서 작업한 내용을 원격 레포지토리에 업로드.
    • pull: 원격 레포지토리의 최신 내용을 가져오기.
  2. 추천 학습 리소스
    • Git 공식 문서: 기본 명령어와 사용법 학습.
    • YouTube 강의: “Git 초보자를 위한 튜토리얼”.
    • GitHub의 Git 사용 가이드: Pull Request 작성 및 리뷰 방법 학습.
  3. 실습 프로젝트
    • 간단한 문서 레포지토리를 생성해 기획 문서를 관리.
    • 개발팀과 협업하여 요구사항 변경 작업 경험 쌓기.

최근 들어 Git으로 API 문서를 관리하고 있습니다. 개발자들이 만든 코드와 연결된 문서를 바로 확인하고, 필요한 수정 사항을 머지 요청으로 제출하는 것이죠. 처음에는 익숙하지 않았지만, 지금은 이 도구가 없으면 협업이 어려울 정도로 유용하답니다.

5. 서비스 기획자 개발 학습 가이드

서비스 기획자 개발? 10년 넘게 일하면서 깨달은 점이 하나 있습니다. 서비스 기획자 개발? “개발을 조금이라도 이해하면 내가 더 좋은 기획자가 될 수 있다.” 그런데, 어디서부터 시작해야 할지 몰라 헤매던 순간도 많았습니다. 아마 여러분도 비슷한 고민을 하고 계실 거예요. 그래서 제가 경험과 시행착오를 바탕으로 만든 ‘기획자를 위한 개발 학습 가이드’를 공유하려고 합니다.

5.1. 기본적인 프로그래밍 언어 학습: HTML, CSS, JavaScript

먼저, 프로그래밍 언어를 배우는 이유를 짚어보겠습니다. 기획자는 기술적으로 깊이 들어갈 필요는 없지만, 개발 과정에서 나오는 용어와 구조를 이해할 수 있어야 합니다. 그 기본이 되는 언어가 바로 HTML, CSS, JavaScript입니다. 이 언어들은 웹 서비스의 뼈대, 디자인, 그리고 동작을 만드는 기초이기 때문입니다.

HTML (HyperText Markup Language)

HTML은 웹 페이지의 구조를 정의합니다. 모든 웹 페이지는 HTML로 시작합니다. 제목, 본문, 이미지, 링크 등 모든 요소를 배치하는 역할을 하죠.

서비스 기획자 개발
  • 학습 방법:
    1. W3Schools에서 HTML 기본 태그 익히기.
    2. 자신만의 간단한 웹 페이지 만들기. 예를 들어, 자기소개 페이지를 만들어 보세요.
    3. Visual Studio Code 같은 코드 편집기로 작성 후 브라우저에서 결과 확인.

CSS (Cascading Style Sheets)

CSS는 HTML로 만든 구조에 디자인을 입히는 역할을 합니다. 색상, 글꼴, 크기 등을 지정할 수 있죠.

서비스 기획자 개발
  • 학습 방법:
    1. MDN Web Docs에서 CSS 기초 학습.
    2. HTML로 만든 자기소개 페이지에 CSS를 적용하여 보기 좋게 꾸며보기.
    3. 색상 팔레트와 글꼴 선택을 연습하며 디자인 감각을 키우기.

JavaScript

JavaScript는 웹 페이지를 동적으로 만드는 언어입니다. 버튼을 클릭하면 특정 기능이 작동하거나, 데이터를 입력하면 저장되는 등의 작업을 처리합니다.

서비스 기획자 개발
  • 학습 방법:
    1. FreeCodeCamp에서 JavaScript 기초 학습.
    2. 간단한 계산기나 클릭 이벤트를 구현해 보기.
    3. 콘솔에서 코드를 실행하며 결과를 확인하기.

5.2. 개발 관련 도서와 강의 활용

프로그램 언어를 익히는 것도 중요하지만, 개발자와 소통하기 위해서는 이론적인 이해도 필요합니다. 특히, 개발자가 중요시하는 원칙과 철학을 이해하면 협업이 훨씬 쉬워집니다.

추천 도서

  1. 클린 코드 (Clean Code)
    • 개발자가 가장 좋아하는 책 중 하나입니다. 이 책은 코드의 가독성과 유지보수성을 높이는 방법을 설명합니다. 기획자가 읽어도 충분히 흥미롭고, 개발자들이 왜 디테일에 집착하는지 이해할 수 있습니다.
  2. The Pragmatic Programmer
    • 실용적인 개발 노하우를 담은 책으로, 개발과 기획의 접점을 이해하는 데 큰 도움이 됩니다.
  3. Understanding the User Experience
    • 기술적인 개발보다 사용자 경험(UX)에 초점을 맞춘 책으로, 기획자가 특히 읽어야 할 필독서입니다.

추천 강의

  1. Udemy: “Complete Web Developer Bootcamp”
    • HTML, CSS, JavaScript의 기본부터 시작해 간단한 프로젝트를 만들 수 있습니다.
  2. 프로그래머스:
    • 한국어로 진행되는 강의로, 기초부터 실습까지 다룹니다.
  3. Coursera:
    • 세계적인 대학들이 제공하는 강의로, 체계적인 학습이 가능합니다.

6. 기획자가 개발자가 될 수 있을까?

기획자의 개발자 전향 이야기도 종종 듣습니다. 물론 쉽지는 않겠죠. 하지만 꼭 불가능한 일도 아닙니다. 저도 한때 그런 생각을 했고, 지금은 “반개발자” 정도의 수준에 도달했습니다. 특히 AI 도구를 활용하면 이 과정이 훨씬 빨라질 수 있습니다.

반대로, 개발자가 기획자로 전향하는 사례도 많습니다. 개발자는 기술적 이해도가 뛰어나기 때문에, 사용자 경험을 고려한 기술 중심의 기획을 할 수 있죠. 저희 팀에서도 개발자 출신의 기획자가 있는데, 함께 일할 때마다 배우는 것이 많습니다.

7. AI 시대, 개발자는 필요 없는가?

사실, 이 글의 하이라이트는 여기입니다. 요즘은 ChatGPT 같은 AI 도구만으로도 간단한 개발이 가능합니다. 믿기 어려우신가요? 제가 직접 경험한 사례를 하나 공유하겠습니다.

7.1. ChatGPT로 직접 코딩하기

얼마 전, 작은 프로토타입 프로젝트를 혼자 진행해야 하는 상황이 생겼습니다. 개발 인력이 부족한 상태였죠. 그래서 ChatGPT에게 도움을 요청했습니다. “React로 로그인 페이지를 만들어 줘”라고 입력하니 코드가 바로 생성되었습니다. 제가 간단히 복사해서 실행해보니 완벽히 작동했죠. 그때 느꼈습니다. “개발자를 대체할 수는 없어도, 상당 부분의 일은 혼자 해결할 수 있겠구나!”

더 놀라운 점은, 코드에 문제가 있을 때 디버깅도 가능하다는 것이었습니다. 오류 메시지를 ChatGPT에 입력하면 어떤 부분을 수정해야 하는지 알려줬고, 몇 번의 수정 끝에 모든 기능이 정상 작동했습니다

7.2. No-Code 도구로 코딩 없이 아이디어을 실현 시키다

No-Code 플랫폼은 프로그래밍 지식이 없는 사람도 클릭 몇 번으로 서비스를 만들 수 있게 합니다. 예전에는 상상도 못했던 일이지만, 이제는 현실이죠.

Bubble: 복잡한 웹 애플리케이션도 OK

서비스 기획자 개발

Bubble은 데이터베이스와 사용자 인터페이스를 손쉽게 연결할 수 있는 도구입니다.

  • 사용 사례: 제가 한 번은 작은 이벤트 관리 애플리케이션을 만들어야 했던 적이 있습니다. 개발팀은 이미 바빠서 도움을 요청하기 어려운 상황이었죠. 그래서 Bubble을 이용해 이벤트 등록, 사용자 관리, 알림 발송 기능이 포함된 웹앱을 직접 제작했습니다.
  • 느낀 점: 데이터 흐름과 논리를 시각적으로 이해하면서 구현하니, 개발자가 매일 어떤 고민을 하는지도 조금씩 이해가 되더군요.

Webflow: 디자인과 개발의 경계를 허물다

서비스 기획자 개발

Webflow는 디자이너와 기획자에게 가장 사랑받는 도구 중 하나입니다. 복잡한 코딩 없이도 세련된 웹사이트를 만들 수 있죠.

  • 사용 사례: 한 프로젝트에서 서비스 소개 페이지가 필요했는데, 개발팀에게 요청하기엔 일정이 너무 촉박했습니다. 저는 Webflow로 한 주 만에 프로토타입을 만들어 팀원들에게 보여줬습니다. 반응은 뜨거웠죠. “이게 기획자가 만든 거야?”

이 두 가지 도구를 활용하면서 제가 배운 건, “기획자는 아이디어를 바로 실현할 수 있는 사람이 되어야 한다.”는 점이었습니다. 이제 아이디어를 개발팀에 전달하고 기다리는 것이 아니라, No-Code 도구로 빠르게 시각화하고 팀원들에게 공유하는 것이 가능해졌습니다.

8. 기술 이해는 선택이 아닌 필수

서비스 기획자 개발? 로서 개발 지식을 이해하는 것은 더 이상 선택이 아닙니다. 이제는 AI와 No-Code 도구 덕분에 더욱 많은 가능성이 열려 있습니다. 중요한 것은 기술을 완벽히 배우는 것이 아니라, 문제를 해결하려는 태도와 도구를 활용할 줄 아는 능력입니다.

10년 전으로 돌아간다면, 저는 더 빨리 개발을 배우고 AI 도구를 익혔을 겁니다. 개발자랑 더이상 싸우지 마시고 먼저 질문을 던지는 서비스 기획자가 되는건 어떠신가요?

그거 아시나요? 서비스 기획자가 개발까지 할줄 안다면 정말 무섭다는걸 오늘도 긴글 읽어 주셔서 감사합니다

Read More