써니

에필로그 - 오픈이 끝이 아니라 시작이다

2026-08-16T23:00:01Z

운영은 끝이 없다. 오픈이 끝이 아니라 시작이 되고, 그 이후의 시간은 계속 이어진다. 이 글은 운영을 잘하는 방법을 알려주려고 쓴 글이 아니다. 다만 운영을 하다 보면 왜 늘 마음이 급해지는지, 왜 같은 결정이 반복되는지, 왜 일이 사람을 소모시키는지. 그 이유를 한 번쯤은 정리해두고 싶었다. 운영은 요청으로 시작된다. 운영에서 기획자의 일은 전달된

14장. 운영이 잘 되면 아무도 알아주지 않는다 - 운영의 성과는 티가 나지 않는다

2026-08-09T23:00:03Z

운영의 성과는 티가 나지 않는다. 그래서 운영은 조용히 버티는 업무이기도 하다. '서비스가 잘 운영되고 있다'는 말. 장애가 없고, 고객 민원이 줄고, 추가 요구사항/요청사항이 줄어들면 운영 업무가 크게 중요하지 않은 것처럼 느껴질 때도 있다. 운영은 눈에 띄지 않을수록 '서비스가 잘 운영되고 있는 것'처럼 보이기 때문이다. 하지만 운영이 조용하다는 건

13장. 운영 산출물은 문서가 아니다 - 운영 산출물은 기록이 아니라 ‘다음 운영을 위한 기준’이다

2026-08-02T23:00:30Z

운영을 하면서 “산출물”을 만든다고 하면 어색하게 느껴질 수 있다. 운영에는 구축처럼 기획서나 화면설계서 같은 결과물이 잘 남지 않기 때문이다. 나 역시 운영 업무를 하면서 별도의 산출물을 만들어 낸 적은 거의 없다. 하지만 운영을 하다 보면 결국 남기게 된다. ‘어떤 일을 했는지’, ‘왜 그렇게 처리했는지’, ‘다음에는 어떻게 해야 하는지’. 그 형태는

12장. 운영은 결국 반복되는 결정이다 - 운영에서 가장 많이 반복되는 건 일이 아니라 결정이다

2026-07-26T23:00:32Z

운영을 하다 보면 일을 분명히 처리했는데도 며칠 지나면 같은 질문이 다시 올라온다. “그때 그건 어떻게 처리하기로 했었죠?” “이건 예외로 해줬던 건가요?” 이건 일이 다시 생긴 게 아니라, 결정이 확실하게 나지 않아 다시 묻게 되는 것이다. 그 날은 급해서 구두로만 정리하고 넘어갔고, 누가 승인했는지, 어떤 기준으로 예외를 줬는지, 다음부터는 어떻게 할지

11장. 운영 일정은 왜 항상 망가질까 - 운영 일정은 계획대로 흘러가지 않는다

2026-07-19T23:00:05Z

운영 일정이 망가지는 건 실무자가 게을러서도 능력이 부족해서도 아니다. 운영은 일정이 무너질 수밖에 없는 구조를 가지고 있다. 구축은 시작과 끝이 있다. 일정이 있고 범위가 있고, 완료라는 기준이 있다. 그래서 “이번 주에 이걸 끝낸다”가 가능하다. 하지만 운영은 다르다. 운영의 일정은 ‘해야 할 일’로만 구성되지 않는다. 갑자기 생기는 일이 항상 섞인

10장. CS는 고객 응대가 아니라 서비스 로그다 - CS는 불만이 아니라 증상에 대한 기록이다

2026-07-12T23:00:02Z

운영을 하다 보면 CS가 쏟아지는 시기가 있다. 불만이 늘어나면 운영자는 먼저 지치고, 기획자는 “또 수정해야 하나”라는 생각부터 든다. 하지만 CS를 감정으로 받는 순간 운영은 흔들리고, 우선순위는 흐려진다. 운영 기획자는 CS를 ‘데이터’로 바꿔야 한다 CS는 불평이 아니라 서비스가 실제로 흔들린 지점이다. 즉, CS는 고객의 감정이 아니라 제품의

9장. 운영에서 가장 먼저 정리해야 하는 것 - 기능보다 먼저 흔들리는 건 정책이다

2026-07-05T23:00:01Z

운영을 하다 보면 기능은 그대로인데, 계속 문제가 생긴다. 결함이 있는 것이 아니라 사람들이 서로 다른 기준으로 일을 하기 시작할 때다. “이건 되는 게 맞나요?” “원래 이렇게 처리하는 거 아니었나요?” “이 고객은 예외 처리가 필요해요” 운영에서 흔들리는 건 화면이 아니라 해석이다. 그리고 그 해석이 흔들리는 이유는 정책이 정리되어 있지 않기 때문이다

8장. 운영 범위를 지키는 기획자의 말 한마디 - 추가비용 협의는 싸움이 아니라 구조로 시작해야 한다

2026-06-28T23:00:01Z

운영을 하다 보면 운영 범위를 넘어서는 요구사항을 요청 받는 순간을 만나게 된다. “이 정도는 운영범위내에서 진행 가능하죠?” “이거 간단한거니 하나만 추가해주세요.” “다른 곳은 운영범위로 해주던데요.” 요청은 늘 “작게” 들어온다. 하지만 작은 요청이 반복되면 운영 업무 범위는 금방 확장된다. 그리고 운영 범위가 확장되는 순간부터는 기획자도 개발팀도 일

7장. 운영 수정 vs 추가개발 구분은 어떻게 해야할까 - 운영이라는 이름으로 들어오는 요청 중 일부는 추가개발이다

2026-06-21T23:00:02Z

안정화 이후 요구사항이 늘어나는 건 자연스럽다. 사용자가 실제로 쓰기 시작하면 불편이 보이고, 개선점이 드러나기 때문이다. 문제는 이 요청들이 모두 “운영 수정”으로만 끝나지 않는다는 데 있다. 운영 요청처럼 보이는 말로 들어오지만 실제로는 구조를 바꾸거나 범위를 넓히는 요구가 섞여 있다. “이거 조금만 바꿔주세요.” “이 기능도 같이 넣어주시면 좋을 것

6장. 안정화 이후에 왜 요구사항이 갑자기 늘어날까 - 오류가 잡히면 끝날 줄 알았지만, 그때부터 요구사항이 열린다

2026-06-14T23:00:03Z

오픈 직후에는 대부분 오류를 잡는 시간이 이어진다. 로그인이 막히고, 결제가 누락되고, 화면이 깨지고... 운영은 그 문제들을 하나씩 수습하면서 ‘정상 상태’를 만들어간다. 그리고 어느 정도 안정화가 되면 팀은 한숨을 돌리고 말한다. “이제 좀 괜찮아졌네요.” 하지만 운영에서 진짜 특이한 순간은 그 다음이다. 오류가 줄어든 뒤부터, 요구사항이 갑자기 늘어

5장. 운영 요청은 왜 항상 우선순위 싸움이 될까 - 운영에서 우선순위는 “중요도”가 아니라 “영향도”이다

2026-06-07T23:00:02Z

운영에서 우선순위를 정할 때 단순히 “이 기능이 중요하다”는 이유만으로 우선순위를 결정하지는 않는다. 오히려 기능의 중요성 보다는 해당 문제가 서비스에 얼마나 영향을 미치고 있는지가 중요하다. 같은 오류라도 누구에게, 얼마나 자주, 어떤 흐름을 막는지에 따라 우선순위는 완전히 달라진다. 로그인이 막히면 서비스의 입구가 닫힌다. 결제가 막히면 매출이 멈춘다

4장. 운영 요청은 왜 '결론' 지어 들어올까 - 기획자는 '결론'을 다시 ‘상황’으로 되돌려야 한다.

2026-05-31T23:00:35Z

안정화가 어느 정도 되면 장애는 줄어든다. 하지만 운영이 끝나는 건 아니다. 그때부터는 ‘요청’이 쌓이기 시작한다. 운영 요청은 대부분 이렇게 들어온다. “이거 수정해주세요.” “이 기능이 불편해요.” “이거 안 되는데요?” “이 부분도 추가해주면 좋겠어요.” 운영 요청은 정의가 아니라 결론으로 들어온다. 요청을 보내는 사람 입장에서는 편한 방식이다.

3장. 서비스 안정화의 기준 - 안정화는 오류가 없는 상태가 아니라, 통제 가능한 상태다

2026-05-24T23:00:25Z

오픈 직후의 운영은 대부분 오류 대응으로 시작된다. 로그인이 막히고, 결제가 누락되고, 예상하지 못한 예외가 튀어나온다. 생각지도 못한 오류를 하나씩 대응하고 잡아나가는 시간이 이어진다. 그렇게 며칠, 혹은 몇 주가 지나면 고객사는 한숨 돌린 얼굴로 말한다. “이제 안정화 단계로 넘어가죠.” 하지만 안정화는 생각보다 애매한 말이다. 오류가 하나도 없어야 안

운영에서 마주치는 보안/인증 요구(ISMS) - 어느 순간 ‘갑자기 진행해야 했던 일'

2026-05-20T23:00:10Z

“보안 점검이 필요합니다.” “인증 절차를 바꿔야 합니다.” “접근 권한 정리가 필요합니다.” “ISMS 대응해야 합니다.” 어느 날 갑자기 운영을 담당하는 내게 요구사항이 접수된다. 보안/인증 요구는 기획자가 깊이 있게 설계하지 않아도 된다. 하지만 무슨 의미인지, 어떤 영향을 만드는지는 알고 있어야 한다. 내용을 모르면 범위가 커지고, 일정이 흔들리고

2장. 테스트를 했는데도 왜 오픈하면 오류가 날까 - 환경이 달라지면 문제가 달라지고, 운영은 그 차이에서 시작된다.

2026-05-17T23:00:37Z

테스트를 충분히 했는데도, 오픈하면 오류가 난다. 그리고 그 오류는 이상하게도 테스트에서 보던 오류와는 다르게 나타난다. 재현이 안 되고, 원인이 단번에 잡히지 않고, 때로는 특정 환경 혹은 특정 사용자에게만 발생한다. 이건 테스트가 부족해서만은 아니다. 서비스의 문제가 갑자기 생겼다기보다, 환경이 달라졌기 때문이다. 환경이 달라지면 문제가 달라진다 개

1장. 운영 업무는 언제부터 시작될까 - 구축을 완료했다고 생각한 순간, 운영은 시작된다

2026-05-10T23:00:01Z

서비스가 오픈하는 순간, 프로젝트는 끝난 것처럼 보인다. 기획서도 정리됐고, 화면도 나왔고, 개발도 배포됐다. 오픈 일정에 맞춰 할 일을 모두 마쳤고, 이제는 운영 단계로 넘어간 듯한 분위기가 된다. 하지만 오픈은 결코 ‘완료’가 아니다. 운영은 서비스 오픈과 동시에 시작된다. 그리고 그 시작은 조용히 구축 담당자에게도 이어진다. “이거 수정해 주세요.”

머리말 - 이미 만들어진 세계를 버텨낸다는 것

2026-05-03T23:00:02Z

구축 프로젝트는 오픈을 목표로 달린다.일정이 있고, 범위가 있고, 완료라는 기준이 있다.그래서 구축 프로젝트는 오픈이라는 마침표가 있다. 반면 운영에는 마침표가 없다. 서비스 오픈이란 끝이 아니라 시작이고,운영은 그 이후의 모든 시간을 책임지게 된다. 운영은 오픈과 동시에 시작된다.정확히는, 누가 시작을 선언하지 않아도어느 날 갑자기 “이거 수정해 주세

기획자는 개발을 어디까지 알아야 할까? - 서비스 기획자가 개발 지식을 알아야 하는 이유

2026-04-29T00:00:27Z

서비스 기획 일을 처음 시작했을 때는 이런 생각을 했다. “기획자가 굳이 개발을 알아야 하나?” 기획자는 서비스 정책을 만들고개발자는 그것을 구현하는 사람이라고 생각했다. 그래서 처음에는 기술적인 지식이 없어도기획을 하는 데 큰 문제가 없을 거라고 생각했다. 하지만 막상 일을 해보니 생각과 현실은 꽤 달랐다. 기획서를 작성하다 보면 자연스럽게 기술을 고려

에필로그 - 기획자의 일은 언제나 중간에서 끝난다

2026-04-27T00:00:01Z

기획자의 일은 언제나 중간에서 끝난다. 끝났다고 말하는 순간에도, 그 프로젝트는 누군가의 질문으로 다시 시작되기 때문이다. 완전히 시작되지 않은 상태에서 일을 넘겨받고, 완전히 끝났다고 말하기 어려운 지점에서 손을 놓는다. 이번 연재에서 이야기한 많은 순간들도 그렇다. 계약 전이지만 이미 시작된 일들, 확정되지 않았지만 기준처럼 작동하는 말들, 오

26장. 오픈은 끝이 아니라, 책임의 시작이다 - 오픈이 되면 책임이 따르는 질문들 받게 된다

2026-04-23T00:00:02Z

PART 4. 오픈이라는 목표 앞에서 오픈을 하고 나면 프로젝트는 끝난 것처럼 보인다. 일정은 지켜졌고, 서비스는 열렸고, 내부 보고도 마무리된다. 캘린더에 적혀 있던 가장 큰 날짜가 지나가면, 마치 하나의 일을 완주한 것 같은 기분이 든다. 하지만 실무에서 오픈은 끝이 아니다. 오히려 이 시점부터, 그동안의 판단들이 실제 결과로 드러나기 시작한다