무엇을 만들지보다, 무엇을 안 만들지

안녕하세요. 성구의 인디웨이, 성구입니다.

이번 주에는 프로덕트를 만들면서 했던 고민을 나누려고 합니다.

2026년이 되면서 프로덕트로그(인디해커를 위한 프로덕트 관리 SaaS)를 다시 집중해서 만들기 시작했어요.

프로덕트로그를 다시 만들면서 제가 가장 많이 한 고민은 “무엇을 더 만들까?”가 아니라 “무엇을 만들지 말아야 할까?”였습니다.

보통 무언가를 만들기 시작하면 아이디어는 생각보다 훨씬 빠르게 늘어납니다. 특히 혼자 만드는 상황에서는 누군가 말려주지 않기 때문에 “이것도 있으면 좋겠다”는 생각이 그대로 기능이 되기 쉽죠.

저 역시 그 과정을 그대로 겪고 있었습니다.

만들수록 좋아지는 게 아니라, 헷갈리기 시작했습니다

처음에는 아주 사소한 기능들이었습니다.

“이 정도는 기본 아닌가?”
“다른 서비스에는 다 있는 기능인데?”
“지금 안 만들어두면 나중에 다시 손대야 하지 않을까?”

이런 질문들은 모두 합리적으로 들렸고, 그때마다 저는 고개를 끄덕이며 기능을 하나씩 추가해 나갔습니다.

문제는 기능이 늘어날수록 판단해야 할 것도 함께 늘어났다는 점이었습니다.

이 기능은 MVP에 포함해야 하는지, 이건 언제 완성해야 하는지, 지금 쓰지 않는 기능은 남겨두는 게 맞는지, 아니면 과감히 지워야 하는지.

결정해야 할 질문이 쌓이면서 어느 순간부터는 프로덕트 자체보다 ‘결정’에 더 많은 에너지를 쓰고 있더라고요.

매일 코드는 치고 있었지만, 이 작업이 정말 중요한지에 대해서는 스스로 확신하지 못하는 상태였습니다.

다시 만들기로 결심하다

그래서 최근 프로덕트로그를 리팩토링하면서 그동안 쌓아둔 구조와 기능들을 처음부터 다시 들여다보기 시작했습니다.

모노레포 구조도 걷어냈고, “언젠가는 필요할 것 같아서” 남겨두었던 기능들도 하나씩 정리했습니다.

솔직히 쉽지 않은 선택이었습니다. 이미 만든 것을 되돌리는 일은 항상 마음이 조금 아프거든요.

기술적으로 보면 더 정교하고, 더 확장성 있어 보이는 선택을 스스로 포기한 셈일지도 모릅니다.

하지만 지금의 저와 프로덕트로그에는 “잘 만든 구조”보다 “지금 감당할 수 있는 구조”가 훨씬 중요하다고 판단했습니다.

혼자 만들고, 혼자 운영하고, 혼자 실험해야 하는 상황에서 복잡함은 곧 부담이 되고, 부담은 결국 속도를 늦춥니다.

그래서 모든 판단을 하나의 질문으로 줄였습니다

정리 과정에서 저는 모든 기능과 결정을 이 질문 하나로 통과시키기 시작했습니다.

“이게 지금 사용자에게 정말 필요한가?”

이 질문에 조금이라도 망설여지는 기능들은 백로그에만 남겨두고, 지금은 만들지 않기로 결정했습니다.

언젠가는 필요해질 수도 있습니다. 하지만 “언젠가”를 기준으로 만들기 시작하면 지금 집중해야 할 것이 흐려진다는 걸 이번에 분명히 느꼈습니다.

‘안 만드는 선택’은 포기가 아니라 집중을 위한 선택이라는 걸 조금 늦게 깨달은 셈이죠.

프로덕트로그는 왜 ‘피드백’에 집중하게 되었을까?

이 과정을 거치면서 프로덕트로그가 잘해야 할 일도 자연스럽게 드러나기 시작했습니다.

프로덕트로그의 핵심은 '프로덕트 운영을 더 편리하게 만들고, 지속적인 개선을 돕는 것'입니다.

그래서 여러 기능을 잘 묶는 관리 도구가 아니라, 빠르고, 쉽게 피드백을 받고 관리할 수 있는 경험이 가장 중요하다는 결론에 도달했습니다.

피드백은 생각보다 아주 예민합니다.

조금만 입력 과정이 번거로워도 사용자는 그냥 닫아버리고, 확인하기 불편하면 만든 사람도 점점 보지 않게 됩니다.

그리고 피드백에 대한 반응이 없으면 사용자는 곧 이렇게 생각하게 됩니다.

“말해봐야 소용없구나.”

이 경험이 한 번 쌓이면 그다음 피드백은 거의 오지 않습니다.

피드백 흐름이 끊기는 순간, 프로덕트 개선의 루프도 함께 멈춥니다.

그래서 지금 프로덕트로그가 가장 잘해야 할 일은 문서 관리도, 체인지로그 관리도, 복잡한 관리 기능도 아닌 “피드백을 쉽고 빠르게 남기고, 확인하고, 다음 행동으로 이어지는 경험을 최대한 단순하게 만드는 것”이라고 생각했습니다.

왜 피드백에 집중하게 되었는지, 그리고 어떤 방식으로 풀어가고 있는지는 다른 글에서 더 자세히 이야기해보려고 합니다.

안 만들기로 하니, 오히려 할 일이 또렷해졌습니다

기능을 줄이자 아이러니하게도 할 일은 더 분명해졌습니다.

어떤 가설을 세워야 하는지,
어떤 기능을 만들어야 하는지,
언제까지 만들어야 하는지,
어떤 사용자를 타겟으로 해야 하는지,
어디에서 피드백을 남기지 못하고 돌아서는지.

해야 할 일이 줄어든 게 아니라, 우선순위가 눈에 보이기 시작한 느낌이었습니다.

이 상태라면 작은 개선 하나도 훨씬 빠르게 실험해볼 수 있겠다는 확신이 들었습니다.

지금 저에게 더 중요해진 기준

무언가를 직접 만들고 운영해보니 속도보다 더 중요하게 느껴지는 게 있었습니다.

무엇을 더 할지보다, 무엇을 하지 않기로 결정하는 것.

이 기준 하나가 시간과 에너지, 그리고 프로덕트의 방향까지 크게 좌우하더라고요.

앞으로의 방향

당분간은 무언가를 더 얹기보다는 핵심을 더 선명하게 만드는 데 집중하려고 합니다.

프로덕트로그를 시작으로 인디로그, 북로그로 확장하고, 다른 Micro SaaS와 App도 만들어갈 계획이지만, 그만큼 ‘안 만들 것’을 더 분명히 정해가려 합니다.

무엇을 만들지보다, 무엇을 안 만들지.

오늘도 긴 글 읽어주셔서 감사합니다.

성구 드림

P.S. 지금 만들고 있는 프로덕트의 ‘단 하나’의 핵심 기능은 무엇인가요?