써니

20장. 합의는 언제 완료되는가 - 회의에서 끝난 이야기와 문서에 남은 이야기의 차이

2026-04-02T00:00:01Z

PART 3. 이미 시작된 프로젝트를 붙잡는 시간 회의를 하다 보면 이런 순간을 자주 만난다. 각 팀의 의견이 엇갈리고, 한참을 논의한 끝에 어느 정도 정리가 된다. 누군가는 양보하고, 누군가는 조건을 붙이고, 그렇게 하나의 안으로 모인다. 회의실을 나설 때는 모두가 고개를 끄덕인다. “그럼 이렇게 가는 걸로 정리된 거죠?” 그 순간만 놓고 보면 분명 합

결제는 됐는데 주문이 없다? - 기획자 시점에서 보는 실제 서비스에서 발생한 결제 누락 장애 분석

2026-03-31T23:00:01Z

서비스를 운영하다 보면 가끔 이해하기 어려운 장애가 발생합니다. 어느 날 고객센터로부터 한 문의가 들어왔습니다. “결제를 했는데 주문이 없어요.” 처음에는 사용자의 실수라고 생각했습니다. 결제 통합 플랫폼과 PG사 관리자 콘솔을 확인해 보니 고객 결제 정보는 정상적으로 존재했습니다. 하지만 주문을 관리하는 관리자 페이지에는 해당 결제 내역이 반영되지 않았

19장. 기획 미팅은 왜 항상 길어질까 - 결정이 아닌 설명이 반복되는 회의들

2026-03-30T00:00:01Z

PART 3. 이미 시작된 프로젝트를 붙잡는 시간 프로젝트를 진행하다 보면, 매일 회의로 시작해서 회의로 끝나는 것처럼 느껴지는 순간이 있다. 아침에 시작한 미팅이 점심을 지나고, 잠깐 쉬었다가 다시 이어지고, 그렇게 하루 일정이 회의로 채워진다. 회의가 끝나면 이미 업무 시간은 지나 있고, 다음 회의를 준비하기 위해 밤을 새워서라도 회의 내용을 정리

18장. 요구사항 정리는 기획이 아니라 조율이다 - 누가 보느냐에 따라 전혀 다른 의미를 가지는 요구사항

2026-03-26T00:00:01Z

PART 3. 이미 시작된 프로젝트를 붙잡는 시간 요구사항을 문서로 정리해도, 요구사항은 쉽게 줄어들지 않는다. 오히려 실무에서는 문서를 만든 뒤에 질문이 더 많아지는 경우가 흔하다. 정리했는데 다시 묻고, 적어놨는데 다시 확인하고, 분명 합의했다고 생각했던 내용이 다른 말로 돌아온다. “이건 포함된 거죠?” “이건 그때 이야기한 거랑 같은 건가요?” “

PG사를 직접 붙이면 안 될까요? - 결제 시스템을 붙이는 방법

2026-03-24T23:00:02Z

쇼핑몰을 운영하다 보면 생각보다 다양한 요청이 들어온다. 어떤 요청은 기능 추가이고, 어떤 요청은 정책 변경이다. 그리고 가끔은 시스템 구조 자체를 바꾸는 요청도 들어온다. 내가 담당하던 쇼핑몰에서도한 번 그런 요청이 있었다. 회의 자리에서 사업팀이 말했다. “지금 결제 통합 플랫폼을 쓰고 있는데, PG사랑 직접 붙이면 안 될까요?” 이 질문은 생각보다

17장. 요구사항 정리는 어떻게 해야할까 - 요구사항 정리가 끝나지 않는 이유

2026-03-23T00:00:01Z

PART 3. 이미 시작된 프로젝트를 붙잡는 시간 프로젝트가 시작되면 기획자는 요구사항정의서를 쓰기 시작한다. 제안요청서도 있었고, 제안서도 제출했고, 계약까지 끝났지만 요구사항을 다시 정리한다. 이 작업은 이전 내용을 반복하는 일이 아니라, 요구사항을 ‘최종 결정’의 형태로 정리하는 과정에 가깝다. 어떤 요구사항을 수락할지, 어디까지를 범위로 볼지, 받

16장. 계약은 끝났는데, 왜 다시 시작하는 기분일까 - 프로젝트가 ‘공식적으로’ 시작된 순간의 착각

2026-03-19T00:00:02Z

PART 3. 이미 시작된 프로젝트를 붙잡는 시간 프로젝트가 시작되었다. 계약도 체결되었고, 킥오프 미팅도 끝났으며, 일정대로 움직이기 시작했다. 겉으로 보면 이제 남은 일은 정해진 계획을 실행하는 것처럼 보인다. 그런데 이상하게도, 이 시점에서 기획자는 자주 이런 기분이 든다. “왜 다시 처음으로 돌아온 것 같지?” 이미 제안요청서를 검토했고, 제안

배포 후 문제 발생 시, 재배포로 해결할 수 있을까 - 재배포는 문제 해결을 위한 방법 중 하나일 뿐이다

2026-03-17T23:00:03Z

서비스를 운영하다 보면배포 이후 문제가 발생했을 때이런 이야기를 자주 듣게 된다. “다시 한번 배포를 진행하겠습니다.” 그리고 실제로 재배포 이후 문제가 해결되는 경우를 보게 된다. 그래서 나는배포 이후 문제가 발생하면재배포를 통해 해결될 수 있다고 생각했다. 실제로 재배포로 해결되는 경우도 있다. 그러나 운영을 하다 보니 배포 이후 문제가 발생했다고 해

15장. 계약 전의 말은 사라지지 않는다

2026-03-16T00:00:01Z

PART 2. 계약 전에 이미 시작된 일들 계약이 체결되면 프로젝트는 공식적으로 시작된다.하지만 실무자의 입장에서 보면 업무는 그보다 훨씬 앞에서 이미 움직이고 있는 경우가 많다. 모든 상황을 일반화할 수는 없지만, 내가 경험한 대부분의 프로젝트에서도 계약 전부터 일정이 언급되고 자료가 오가며 사실상 일이 시작된 상태로 흘러가곤 했다. 계약이 체결되는

14장. 계약 협의가 시작된 후 달라지는 요구사항

2026-03-12T00:00:03Z

PART 2. 계약 전에 이미 시작된 일들 프로젝트 진행에 대한 내부 결정이 내려지면 초반에는 계약 조건과 일정, 내부 절차 같은 현실적인 이야기들이 오간다. 그러다 어느 순간부터, 제안서에는 없던 이야기들이 조심스럽게 등장하기 시작한다. “이 기능은 있으면 좋을 것 같아요.” “운영 쪽에서는 이런 부분도 필요하다고 하더라고요.” “이건 제안서에는 없었

배포를 했는데 왜 어떤 사람만 문제가 생길까

2026-03-10T23:00:07Z

서비스를 운영하다 보면같은 서비스에 접속했는데 어떤 사용자는 정상적으로 화면이 보이고어떤 사용자는 오류가 발생하는 상황을 마주하게 된다. 처음에는 서버 문제라고 생각한다.혹은 배포가 제대로 되지 않았다고 의심하기도 한다. 하지만 운영을 하다 보면이 질문의 원인이 의외로 단순한 곳에 있는 경우가 많다. 캐시(Cache) 다. 내가 처음 겪은 캐시 문제

13장. 견적은 숫자가 아니라 판단이다

2026-03-09T00:00:02Z

PART 2. 계약 전에 이미 시작된 일들 견적은 공수 산정이 아니라, 리스크를 배분하는 일이다. 견적을 낼 때, 기획자가 받게 되는 요청 중 하나는 일정과 투입 인원에 대한 자료다. 견적 담당자는 전체 금액을 계산하지만, 그에 앞서 PM은 예상 일정의 틀을 잡고, 디자이너와 개발팀에는 각자의 작업 범위와 소요 시간을 묻는다. 기획자에게도 예외는 아니다

12장. 제안서는 ‘제안’으로 끝나지 않는다

2026-03-05T00:00:01Z

PART 2. 계약 전에 이미 시작된 일들 계약이 진행되면 고객사 내부에서는 동시에 여러 일이 움직인다. 예산을 확정하고, 구매·계약 절차를 밟고, 내부 결재 라인을 통과시키는 과정이 이어진다. 이때 기준이 되는 문서의 내용은 제안서에 적흰 내용이다. 이미 제출되어 있고, 발표까지 끝났기 때문이다. 그래서 계약서가 완성되기 전부터 제안서 속 문장은 계약의

1인 1회 이벤트가 10번 참여된 이유 - 기획자가 운영에서 처음 이해한 레이스 컨디션

2026-03-04T05:17:07Z

서비스를 운영하다 보면 가끔 이해하기 어려운 순간을 만난다.논리적으로는 문제가 없어 보이는데 실제 서비스에서는 전혀 다른 결과가 나타나는 순간이다. 이벤트 기능을 운영하던 중이었다. 룰렛 이벤트로 참여 조건은 단순했다. 1인 1회 참여. 사용자가 버튼을 누르면 중복참여여부를 체크하고, 참여 정보가 없으면 룰렛이 돌아가고, 룰렛 참여 기록은 데이터베이스에

계약 전 산출물 제출 시 고려해야 할 것

2026-03-02T00:00:02Z

계약 전 산출물 제출 시 고려해야 할 것 계약 전 단계에서 작성하는 산출물은 협의를 위한 참고 자료처럼 보이지만, 계약이 체결되는 순간 기준 문서로 작동할 가능성을 안고 있다. 그래서 문서를 제출하기 전, 기획자는 다음을 한 번 점검해 볼 필요가 있다. 1. 이 문서가 확정본처럼 보이지 않는가 - 파일명이나 제목에 초안, Draft, 검토용 등의 상태가

11장. 계약도 안 했는데 왜 이미 일을 하고 있을까?

2026-03-02T00:00:01Z

PART 2. 계약 전에 이미 시작된 일들 기획자는 계약서에 도장을 찍기 전인데도 이미 일을 하고 있다. 제안요청서를 검토하고, 질문을 정리하고, 제안서를 쓰고, 회의에 참석하고, PT 자료를 준비한다. 아직 계약은 체결되지 않았고 법적으로는 아무것도 약속되지 않은 상태지만, 실무에서는 이 모든 과정이 이미 프로젝트의 일부처럼 흘러간다. 제안요청서를 받

10장. 제안 PT 이후 시작되는 문제

2026-02-26T00:00:02Z

PART1. 시작할 것인가, 말 것인가 제안서를 제출하고 제안 PT를 마치면 프로젝트는 이제 막 첫 관문을 넘은 상태가 된다. 제안 PT는 세부 요구사항을 조율하는 자리가 아니다. 고객사에서 전달받은 제안요청서를 기준으로 작성한 제안서의 내용을 발표하는 자리다. 즉, 고객사의 시선에서 우리가 제안서에서 이야기한 방향이 같은 문제를 같은 관점에서 이해하고

9장. 제안서는 제안요청서의 내용과 같을 수 없다

2026-02-23T00:00:01Z

PART1. 시작할 것인가, 말 것인가 제안요청서를 검토한 다음 제안서를 쓴다. 이 순서는 너무 자연스러워서 별다른 설명이 필요 없어 보인다. 하지만 이 두 문서의 성격은 처음부터 다르다. 제안요청서는 고객사가 정리한 요구의 목록이고, 제안서는 그 요구에 대해 프로젝트를 담당하게되는 우리가 어떤 방식과 조건으로 응답할 것인지를 밝히는 문서다. 작성

8장. 제안 작업을 하지 않기로 한 프로젝트

2026-02-19T00:00:02Z

PART1. 시작할 것인가, 말 것인가 제안요청서를 받았다고 해서, 모든 경우가 제안서 제출로 이어지는 것은 아니다. 제안요청서를 검토하고, 질문을 정리하고, 내부 논의를 거친 끝에 아무것도 제출하지 않기로 결정하는 경우도 있다. 이 선택은 대개 조용하게 이루어진다. 하지만 그만큼 가볍지 않은, 꽤 신중한 판단의 결과다. 겉으로 보면 제안하지 않겠다

7장. 전원 상주라는 조건이 위험 신호인 이유

2026-02-16T00:00:04Z

PART1. 시작할 것인가, 말 것인가 제안요청서나 미팅 자리에서 “전원 상주를 기본으로 생각하고 있습니다.”라는 말을 들으면, 처음에는 프로젝트에 집중하겠다는 의지나 소통을 원활하게 하겠다는 의지로 보인다. 특히 규모가 큰 프로젝트일수록 이 조건은 책임감의 표현처럼 받아들여지기도 한다. 실제로 국가 프로젝트나 금융권, 대기업의 주요 시스템 구축 프로젝