프론트엔드 개발자가 노션 하나로 개발 효율 3배 높인 후기

 

 

센디 블로그 - 2.5톤 트럭에 얼마나 실을 수 있을까요?

센디 블로그 - 2.5톤 트럭에 얼마나 실을 수 있을지, 숫자로 정리해봤어요!

 

 

 

들어가며

1년 전. Cmd+C, Cmd+V. 3일 동안 내가 한 일은 이게 전부였다. '이것도 개발인가?' 하는 생각이 들 때쯤, '언제 끝나지...' 하는 한숨이 나왔다.

 

PM이 작성한 노션 문서를 열고, 디자이너가 만든 피그마를 열고, 텍스트를 복사해서 코드에 붙여넣는다. 다음 섹션으로 넘어가서 또 복사, 붙여넣기. 가이드 페이지 하나를 완성하는 데 이런 작업만 3일이 걸렸다. QA 단계에서는 한 글자, 한 글자 수정하느라 더 힘들었다. 랜딩을 다루는 프론트엔드 개발자라면 누구나 한 번쯤 겪어봤을, 그 지루한 시간이었다.

 

그리고 1년 만에, 또다시 콘텐츠 페이지를 만들어야 하는 상황이 왔다. 이번에는 센디 블로그 페이지였다. 순간 3일간의 복붙 지옥이 떠올랐다.

 

아니, 이번에는 절대 안 된다. 같은 작업을 반복하기엔 시간이 너무 아까웠다. 이 과정 자체를 바꿀 방법을 찾아야 했다!!

 

글 작성은 너무 귀찮았다!

사실 이런 경험이 처음은 아니었다. 예전에 가이드 페이지를 만들 때도 똑같은 과정을 거쳤다. PM이 작성한 노션 문서를 보면서, 디자이너가 만들어준 컴포넌트에 텍스트를 하나하나 복사 붙여넣기 했다. 3일 내내 텍스트만 복사하고 붙여넣다가, QA 때는 한 글자씩 수정하느라 정말 지쳤다.

 

당시 우리 팀의 콘텐츠 제작 워크플로우는 아래와 같다.

1. PM이 글을 작성한다
2. 디자이너가 디자인에 맞게 콘텐츠 UI를 그린다
3. 프론트엔드 개발자가 피그마를 보면서 콘텐츠를 렌더링한다
4. QA하면서 한 글자씩 수정한다

 

문제는 3번과 4번이었다. 개발자가 피그마와 코드 사이를 오가며 텍스트를 옮기고, 오탈자나 수정 사항이 생기면 또다시 코드를 열어서 한 글자씩 고쳐야 했다. 단순하고 기계적인 작업인데, 개발자의 시간이 여기에 묶여있다는 게 비효율적이었다.

 

자동화를 생각하지 않은 건 아니었다. Cursor IDE나 Antigravity IDE에 Notion MCP를 연결하면 자동화할 수 있었다. 하지만 내가 원하는 방향은 아니었다. MCP는 개발자가 입력하는 프롬프트에 따라 결과가 달라진다. "간결하게 만들어줘"라고 하면 A 스타일로, "자세하게 만들어줘"라고 하면 B 스타일로 나온다. 다른 개발자가 작업하면 완전히 다른 코드가 나올 수 있다는 얘기다. 코드 리뷰나 유지보수 때 일관성이 깨지는 건 피하고 싶었다. 어떤 개발자가 유지보수하게 되더라도 일관되게 동작 가능한 방식을 원했다.

 

그래서 고민만 하고 있었다. 더 나은 방법이 있을 것 같은데, 뭔지 떠오르지 않았다.

 

뜻밖의 해결방법, 노션 콘텐츠 자동화!

그렇게 고민만 하던 중, 백엔드 개발자 주드가 흥미로운 아티클을 공유했다.

 

https://toss.tech/article/only-3-users-product

사용자 3명인 제품, 만들어야 할까?

 

토스 팀의 "단 3명의 유저를 위한 프로덕트 개발기"라는 글이었다. 글을 읽는 순간, "우리만의 고민이 아니었구나"라는 생각이 들었다. 알고 보니 3년 전 토스에서도 똑같은 고민을 했고, 해결 방법까지 찾아놨다. 노션에서 작성한 글을 바로 가져와서 렌더링하는 방식이었다.

 

이 아이디어를 보자마자 "이거다!"라는 확신이 들었다. 우리도 바로 적용할 수 있을 것 같았다. 한번 구현해두면, PM이 노션에서 글을 작성하기만 하면 자동으로 페이지에 반영된다. 개발자는 초기 설정만 하면 되고, 그 다음부터는 글 작성만 남는다. PM이 어떻게 렌더링되는지 실시간으로 보면서 작업할 수 있고, 오탈자도 직접 수정할 수 있다. 기존 4단계 워크플로우의 3번과 4번이 통째로 사라지는 셈이었다.

바로 작업에 착수했고, react-notion-x라는 라이브러리를 찾았다.

 

https://github.com/NotionX/react-notion-x

GitHub - NotionX/react-notion-x: Fast and accurate React renderer for Notion. TS batteries included. ⚡️

 

라이브러리 문서를 AI Agent에게 주고, 요구사항을 입력했다. 그리고 30분 만에 프로토타입이 완성됐다. 솔직히 이렇게 빨리 될 줄 몰랐다.

프로토타입을 디자이너와 PM에게 보여줬다. "노션에 글만 쓰면 이렇게 바로 페이지에 나와요. 수정도 노션에서 바로 하시면 되고요." 반응은 긍정적이었다. PM은 "이제 개발자한테 수정 요청 안 해도 되는 거네요?"라며 기뻐했고, 디자이너도 "좋은데요?"라며 동의했다.

 

기존에는 PM이 글 작성 → 개발자에게 전달 → 개발자가 코드로 옮김 → PM이 확인 → 수정 요청 → 개발자가 다시 수정... 이 과정이 반복됐다면, 이제는 PM이 노션에 작성 → 바로 반영 → PM이 직접 수정. 중간 단계가 완전히 사라졌다. 이 정도면 개발 효율이 3배는 늘었다고 할 수 있었다.

 

마주친 문제들

물론 완벽하지는 않았다. 여러 문제가 있었는데, 그 중에서 2가지만 소개하겠다.

 

첫 번째는 동기화 문제였다. PM이 노션에서 글을 작성하면 얼마 만에 페이지에 반영되게 할 것인가? 페이지 요청마다 실시간으로 노션 API를 호출하면 가장 정확하지만, API 호출 시간 때문에 페이지 로드 속도가 느려진다.

 

고민 끝에 1시간마다 페이지를 재빌드하도록 결정했다. Next.js 서버 컴포넌트에서 revalidate 옵션을 설정해 캐싱을 활용했다. 블로그 콘텐츠는 실시간으로 변경될 필요가 없었다. 1시간에 한 번 업데이트되면 충분했다. 속도를 위해 즉시성을 조금 포기한 것이다.

 

여기서 unstable_cache를 사용했다. 이름이 "unstable"이라 걱정이 되긴 했지만, 이 정도 리스크는 감수할 만했다. 블로그 페이지는 서비스의 핵심 기능이 아니고, 최악의 경우 캐시를 지우면 되니까. 실용적으로 충분히 안정적이라고 판단했다.

 

두 번째는 페이지가 무거워지는 문제였다. 라이브러리를 쓰다 보니 노션 DB를 세밀하게 제어할 수 없었고, 불필요하게 많은 데이터를 로드하는 바람에 페이지가 무거워졌다. 이 부분은 클라이언트 컴포넌트를 최대한 서버 컴포넌트로 전환하고, unstable_cache를 통해 캐싱을 적극 활용해 어느 정도 개선했다.

 

완벽한 해결은 아니었지만, 실용적으로 충분히 쓸 만했다. 라이브러리의 편리함을 택하는 대신 세밀한 제어를 포기한 것이다. 이 정도 트레이드오프는 받아들일 만했다.

 

https://sendy.ai/blog/%EC%9D%BC%EB%B0%98%EC%9A%A9%EB%8B%AC-%EC%9A%A9%EB%8B%AC%EC%9D%B4%EC%82%AC-%EB%B9%84%EA%B5%90

센디 블로그 - 일반용달 vs 용달이사 뭐가 다른가요?

 

 

마치며

https://sendy.ai/blog/%EB%AC%BC%ED%92%88-%ED%8C%8C%EC%86%90-%ED%8C%81

센디 블로그 - 운송중 물품이 파손됐어요. 어떡하죠?

 

 

2025년 12월 20일, 드디어 센디 블로그(https://sendy.ai/blog)를 릴리즈했다.

 

한 달이라는 시간이 걸렸지만, 실제로 내가 작업한 건 첫 2주뿐이었다. 노션 콘텐츠 자동화를 구현하는 데 2주, 그 뒤 2주는 다른 이슈를 처리했고, 남은 2주 동안은 PM이 글 콘텐츠를 작성하는 시간이었다. 나는 더 이상 텍스트를 복사하고 붙여넣을 필요가 없었다.

 

2주라는 시간을 자동화에 투자한 것은 충분히 가치 있는 선택이었다. 이제 센디 블로그뿐만 아니라, 앞으로 만들 모든 콘텐츠 페이지에 이 방식을 적용할 수 있다. 다음번엔 2주가 아니라 몇 시간이면 충분할 것이다. 한 번의 투자로 계속해서 효율을 얻는 셈이다.

 

3일간 복사 붙여넣기만 하던 시절을 생각하면, 지금의 방식이 얼마나 나아졌는지 실감한다. 개발자는 개발자다워야 한다. 단순 반복 작업에 시간을 쓰는 게 아니라, 더 나은 시스템을 만드는 데 시간을 써야 한다.

 

센디 용달후기 페이지로 40%의 SEO 효과를 본 만큼, 이번 블로그도 기대된다. 하지만 그보다 더 큰 성과는, 이제 우리 팀이 콘텐츠를 만드는 방식 자체가 바뀌었다는 것이다. PM은 더 편하게 글을 쓰고, 개발자는 더 의미 있는 일에 집중할 수 있게 됐다.

 

만약 당신도 비슷한 반복 작업에 지쳐있다면, 한 번쯤 멈춰 서서 "이 과정을 바꿀 방법은 없을까?"라고 고민해보길 권한다. 생각보다 해결책은 가까이에 있을지도 모른다.

 

 

https://sendy.ai/blog/%EC%84%BC%EB%94%94-%EB%93%9C%EB%9D%BC%EC%9D%B4%EB%B2%84-%EA%B9%80%EA%B2%BD%ED%83%9C-%EA%B8%B0%EC%82%AC%EB%8B%98

센디 블로그 - 50살 되는 생일 날 사직서를 던졌어요, 김경태 기사님 이야기