내일배움캠프 사전캠프 TIL: 개발자가 "안 된다"고 하는 진짜 이유, 드디어 이해했습니다

 

 

마케터로 일하면서 퍼블리셔 분께서 "이거 구현 가능한가요?"라고 물었을 때

부정적인 대답을 꽤 여러 번 경험했습니다.

그때마다 속으로 '왜 안 된다는 말을 먼저 하지?' 라고 생각했는데, 오늘 그 이유를 이해한 것 같습니다.

 

개발 환경 기초부터 아키텍처 패턴, 개발자와의 커뮤니케이션 방식, 디자이너-PM 협업까지

오늘 하루 꽤 많은 걸 배웠습니다.

그동안 현장에서 어렴풋이 느꼈던 것들에 "그게 그래서 그랬구나" 하는 이름이 붙는 느낌이었어요.

---

1. 개발 환경 기초: PM이 이걸 알아야 하는 이유

클라이언트-서버, 그리고 API

인터넷은 기본적으로 요청하는 쪽(클라이언트)과 응답하는 쪽(서버)의 구조로 돌아갑니다.

우리가 브라우저를 열고 뭔가를 검색할 때,

사실 내 컴퓨터가 어딘가의 서버에 정보를 요청하고 받아오는 과정이 이루어지는 거예요.

 

그리고 그 요청을 주고받기 위해 미리 약속된 형식이 바로 API입니다.

쉽게 말하면 일종의 '주문서' '이렇게 요청하면 저렇게 줄게'라는 규칙이에요.

개념	한 줄 정의	PM이 알아야 하는 이유
클라이언트	요청하는 쪽 (브라우저, 앱)	사용자 화면의 범위 이해
서버	응답하는 쪽 (데이터 제공)	데이터 처리 범위 파악
API	요청-응답의 약속된 형식	외부 연동 기획 시 범위 산정
JSON	데이터를 표현하는 형식	기획서에 데이터 단위로 명세 가능

웹 vs 앱, 같아 보여도 다릅니다

겉으로 비슷해 보여도 수정 반영 방식이 완전히 다릅니다.

• 웹: 서버에 반영되면 새로고침 시 바로 적용
• 앱: 수정 후 앱스토어 심사 필요 → 보통 1~3일 소요

버그가 터졌을 때 "오늘 중으로 수정 가능해요?"라는 말이 웹에서는 합리적이지만, 앱에서는 현실적으로 어려운 이유가 여기 있습니다. 이 차이를 모르면 개발팀이랑 불필요한 갈등이 생기기 쉬워요. 마케터 시절, 앱 프로모션 페이지 긴급 수정을 당연하듯 요청했던 기억이 새삼 떠올랐습니다.

---

2. 아키텍처 패턴: "버튼 하나 바꾸는데 왜 이렇게 오래 걸려요?"의 진짜 답

오늘 가장 인상 깊었던 부분입니다. MVC 패턴은 코드를 역할별로 나누는 설계 방식인데, 이게 개발 일정과 직결됩니다.

MVC란?

음식점으로 비유하면 이렇게 됩니다:

구성요소	역할	음식점 비유
Model (M)	데이터 저장·처리	주방 (재료 보관, 요리 담당)
View (V)	사용자에게 보이는 화면	홀, 테이블 세팅
Controller (C)	요청 받아서 M↔V 연결	웨이터 (주문 받아 주방 전달)

같은 '버튼 수정'이어도 난이도가 다릅니다

• 로그인 버튼 색상 변경 → View(CSS)만 수정 → 빠름
• 로그인 실패 3회 시 잠금 기능 → Model(실패 횟수 저장) + Controller(조건 분기) + View(팝업·페이지 이동) + 예외처리까지 → 복잡

기획서에 "로그인 화면 개선"이라고 쓰는 것과 "실패 횟수 제한 로직 추가"라고 쓰는 것의 개발 공수 차이가 여기서 나옵니다. PM이 이 구조를 알면 기획 단계에서 이미 현실적인 범위를 잡을 수 있어요.

MVC 외의 주요 패턴들

패턴	핵심 특징	PM 관점에서 의미
MVC	Model·View·Controller 역할 분리	수정 범위가 어디까지인지 파악 가능
MVVM	View와 데이터 자동 연동	앱에서 많이 씀, 실시간 반영 구현에 적합
MSA	기능별로 서비스를 독립 분리	"결제만 따로 수정해주세요"가 가능한 구조
Clean Architecture	핵심 로직을 외부 변화로부터 보호	기술 스택이 바뀌어도 핵심은 유지됨

 

복잡한 구조를 다 외울 필요는 없습니다.

핵심은 "기능 수정 하나가 어디까지 영향을 미치는지가 아키텍처에 따라 달라진다."는 거예요.
개발자가 "이거 생각보다 복잡해요"라고 할 때, 단순한 핑계가 아니라 구조적으로 연결된 것들이 있기 때문입니다.

---

3. 개발자가 "안 된다"고 먼저 말하는 이유

기능 하나를 수정할 때 개발자는 머릿속으로 이미 시뮬레이션을 돌립니다.

• 기존 코드와 충돌하지 않는가
• DB 연동 과정에서 문제는 없는가
• 보안·성능·운영 정책 이슈는 없는가
• 연결된 화면 흐름은 몇 개나 수정해야 하는가

이 과정을 비개발 직군에게 전부 설명하려면 오히려 그 시간에 기능을 하나 더 구현하는 게 나을 수 있어요.

그래서 결론부터 — "안 됩니다" 혹은 "이번 스프린트엔 어렵습니다" — 가 먼저 나오는 겁니다.

 

PM이 해야 할 질문의 방향:

 

1. 왜 어려운지,
2. 어떤 리스크가 있는지,
3. 어느 부분이 가장 큰 문제인지를 짚어보고

→ 그렇다면 현재 조건에서 현실적으로 가능한 대안은 무엇인가?

• 그 대안을 실현하기 위해서 내(PM)가 해야 하는 일이 뭔지?

---

4. 튜터님 피드백에서 가져온 인사이트

오늘 수요일, 금요일에 진행한 아티클 카타를 튜터님께 피드백을 받는 시간을 가졌습니다.

그 인사이트도 적어두어요.

MVP 범위는 포지션에 따라 달라진다

MVP를 어디까지 잡을지는 선발주자냐, 후발주자냐에 따라 달라집니다.

선발주자라면 시장을 먼저 검증해야 하니 작게 빠르게, 후발주자라면 이미 경쟁자가 있으니 차별화 포인트가 MVP에 포함돼야 할 수도 있어요. 같은 "최소"라도 맥락에 따라 범위가 전혀 달라진다는 것이 기억해 두어야 할 포인트입니다.

와이어프레임은 선택이 아닐 수 있다

와이어프레임 없이는 검토조차 안 하는 개발자도 있습니다. 기획자 입장에서 '말로 설명하면 되지 않나'라고 생각할 수 있지만, 개발자 입장에서는 구조가 눈에 보여야 공수 산정도, 리스크 판단도 가능합니다. 기획 산출물의 완성도가 협업 품질을 결정한다는 걸 다시 한번 체감했어요.

정량/정성 데이터 활용, 정답은 없다

데이터 활용 방식은 회사마다, 프로젝트마다, 시점마다 다릅니다. 정량 데이터에 치중할 때도 있고, 정성 데이터가 더 중요한 의사결정 순간도 있어요. 마케터 시절 광고 지표만 보다가 실제 구매 맥락을 놓친 적이 있었는데, 데이터는 수단이지 목적이 아니라는 걸 PM 공부를 하면서도 계속 되새기고 있습니다.

---

5. 디자이너와 소통하는 PM: 꿀벌 PM에서 배운 것

오늘 읽은 아티클 중 디자이너 출신 필자가 "좋은 PM"을 묘사한 글이 있었는데,

마케터 출신 PM 지망생인 저에게도 꽤 와닿는 내용이었습니다.

• 가시화 능력: 모호한 것을 구체적으로 만드는 사람. 디자이너가 말로 표현 못 하는 의도를 파악하고 개발자에게 정확히 전달함
• 방향성 피드백: "이렇게 만들어주세요"가 아니라 "이 유저스토리에서 우리가 달성해야 하는 건 이거예요"
• 데이터 투명 공유: 좋은 지표는 팀 전체의 공으로, 나쁜 지표도 인사이트와 넥스트 스텝과 함께
• 구체적 이유로 감사 전달: "수고했어요"가 아니라 왜 좋았는지를 짚어주는 피드백

PM이 솔루션까지 제시하기 시작하면 디자이너와 충돌로 이어진다는 부분이 특히 기억에 남습니다.

각자의 영역을 존중하되, 서로 다른 관점에서 비롯된 인사이트를 공유하는 것.

---

오늘의 회고

개발자의 "안 된다"는 말은 거절이 아니라, 구조적으로 연결된 복잡도를 압축한 표현이며

PM의 역할은 그 복잡도를 이해한 위에서 현실적인 대안을 함께 찾는 것이라는 점입니다.

 

앞으로는 개발 관련 내용을 공부할 때 "이걸 어떻게 외우지"보다 "이게 기획 과정 어느 지점에서 쓰이지"를 먼저 생각하는 습관을 만들어 가려 합니다.