OG 이미지 생성은 라이브러리로도 할 수 있습니다. 왜 우리는 이걸 서비스로 만들었을까.

소셜 이미지 서비스를 오픈소스가 아닌 SaaS로 만든 이유

OpenGraph 이미지를 자동 생성하는 라이브러리는 많습니다. Next.js에는 @vercel/og가 있고, Node.js 생태계에는 Puppeteer 기반의 수많은 솔루션이 있습니다. Rust나 Go로 쓴 빠른 렌더러도 있고, 직접 Canvas API로 그리는 예제도 넘쳐납니다.

그런데 우리는 Social서비스(SaaS) 로 만들었습니다. “내 서버 안에서 돌리면 될 일을, 왜 굳이 외부 서비스에 의존하게 만드는가?”라는 질문에 대한 답변을 정리해보려 합니다.

지금 Social이 만드는 이미지들 소개 페이지에서 보여주는 것과 같은 라이브 샘플입니다. GeekNews, Weekly, 사용자 페이지, Fairy까지 실제 운영 이미지가 계속 바뀌며 표시됩니다.
Social이 생성한 실제 OpenGraph 이미지 샘플
실제 생성 결과 social.news.hada.io
social.news.hada.io/index.png
PNG 1200×630 live samples

계기: GeekNews 운영하며 겪은 불편

Social의 출발점은 단순했습니다. GeekNews에서 매일 수십 개의 글이 올라오는데, 각각에 어울리는 OG 이미지를 만들고 싶었다는 것이 전부입니다.

처음에는 직접 라이브러리를 쓰거나, 기본 이미지 하나를 계속 돌려 썼습니다. 그런데 이 방식에는 문제가 있었습니다.

  • 라이브러리를 쓰면 이미지 생성이 서버 주 스레드를 점유해 본 서비스 응답이 느려졌습니다.
  • 이미지 캐싱 전략을 직접 짜야 했습니다.
  • 폰트 로딩, 한글 렌더링, 이모지 처리 등 현실의 소소한 이슈들이 계속 발생했습니다.
  • 각 프로젝트마다 같은 문제를 또 풀고 있다는 기분이 들었습니다.

그러다 결국 “이걸 별도 서버로 빼자”는 결론에 이르렀습니다. 그리고 일단 뺀 김에, 다른 프로젝트들도 같은 서버를 쓰면 되지 않을까 하는 생각이 이어졌습니다.

이렇게 시작된 내부 도구가 Social입니다.

라이브러리 vs 서비스, 무엇이 다른가

비슷한 기능을 제공하더라도, 라이브러리서비스는 완전히 다른 물건입니다.

라이브러리

  • 내 서버 자원을 사용함 (CPU, 메모리, 디스크)
  • 의존성이 내 프로젝트에 들어옴
  • 업그레이드/호환성을 내가 관리해야 함
  • 장애 발생 시 내 서버에 영향
  • 버전 하나를 깊게 이해해야 함

서비스

  • 외부 자원을 씀. 내 서버에 부담이 없음
  • HTTP 한 줄로 끝남
  • 버전 업그레이드를 운영자가 알아서 처리함
  • 장애가 나도 대부분의 경우 페이지 자체는 정상 동작
  • 폰트, 렌더링 엔진 같은 복잡한 내부를 몰라도 됨

OG 이미지처럼 “부가적이지만 꼭 필요한 기능” 은 서비스로 분리하는 것이 오히려 더 깔끔하다는 것이 우리의 판단이었습니다.

우리 스스로를 고객으로 삼기

Social은 하다 스튜디오 내부에서 가장 혹독한 고객인 GeekNews를 위해 만들어졌고, 지금도 매일 그렇게 쓰이고 있습니다.

  • GeekNews에서 하루 수십~수백 회의 신규 OG 이미지 요청
  • 캐시 히트된 반복 요청은 그보다 훨씬 많음
  • 뉴스가 Hacker News, 해외 커뮤니티로 퍼지면서 트래픽 스파이크 발생

이 환경에서 돌아간다는 것은, 외부 서비스 사용자에게도 충분히 안정적인 서비스라는 의미입니다. 우리가 우리 스스로를 프로덕션 고객으로 삼았기 때문에, Social은 데모가 아니라 실제로 굴러가는 서비스라는 자신감이 있습니다.

왜 오픈소스로 풀지 않았나

OG 이미지 생성기를 오픈소스로 내놓는 선택지도 분명 있었습니다. 그쪽이 커뮤니티 호응은 훨씬 클 수도 있죠.

그러나 우리는 다음 이유로 서비스 형태를 택했습니다.

1. 지속적인 운영이 핵심 가치다

OG 이미지 생성기의 진짜 어려움은 코드를 짜는 것이 아니라 긴 시간 안정적으로 운영하는 것에 있습니다. 폰트 업데이트, 이모지 버전 변화, 브라우저 엔진 취약점 패치, 트래픽 스파이크 대응… 오픈소스로 코드만 풀면 사용자는 이 운영 비용을 고스란히 짊어지게 됩니다. 차라리 우리가 그 부담을 져주는 것이 사용자에게 더 나은 선택이라고 판단했습니다.

2. 서비스의 형태가 개선 속도를 높인다

서비스는 한 번 고치면 모든 사용자가 즉시 혜택을 봅니다. 오픈소스 라이브러리는 각자가 버전 업그레이드를 해야 하고, 많은 사용자가 오래된 버전에 머뭅니다.

3. 우리의 한계를 솔직히 인정

오픈소스 프로젝트를 커뮤니티와 함께 운영하는 것은 그 자체로 큰 일입니다. 풀타임 두 명이 운영하는 하다 스튜디오가 지금 감당하기는 어렵다고 판단했습니다. 차라리 안정적인 서비스 하나를 잘 운영하는 것이 더 현실적입니다.

앞으로

Social은 지금도 하다 스튜디오의 내부 사용량을 주로 처리하고 있지만, 외부 개발자와 스타트업이 쓸 수 있도록 점진적으로 공개 준비를 하고 있습니다.

프로젝트 철학은 단순합니다. “OG 이미지 때문에 더는 고민하지 않게 해드린다.” 그게 Social이 존재하는 이유입니다.

— 하다 스튜디오

← 블로그로 돌아가기