← All work

템플리

오프라인 마트의 모바일 전단, 상품 POP, 고객 메시지 발송을 하나의 업무 흐름으로 연결한 B2B SaaS입니다. 마트 운영자용 제작 웹을 중심으로 내부 운영 백오피스와 NestJS 서버, 일부 AWS 인프라까지 담당 범위를 확장했습니다.

Product · Frontend · Backend · Infrastructure / 2022.09 — 현재

템플리프로젝트 이미지 준비 중

반복되는 홍보물 제작을 줄이는 일은 편집 화면 하나로 끝나지 않았습니다. 상품 데이터가 전단과 POP가 되고, 완성된 결과물이 고객 메시지로 발송되며, 운영팀이 고객사와 템플릿을 관리할 수 있어야 하나의 제품 흐름이 완성됐습니다.

Overview

템플리는 오프라인 마트가 모바일 전단, 상품 POP, 행사 이미지와 고객 메시지를 한곳에서 제작하고 운영하는 B2B SaaS입니다. 행사 때마다 상품명·가격·기간·이미지를 여러 도구에 반복 입력하고, 결과물을 별도로 가공해 배포하던 업무를 상품 데이터와 템플릿 중심의 흐름으로 바꾸는 제품입니다.

2022년 프론트엔드 엔지니어로 합류해 마트 운영자용 웹의 모바일 전단과 POP 제작 기능을 개발했습니다. 이후 공통 캔버스 편집기, 내부 운영 백오피스, NestJS 서버와 일부 AWS 인프라로 범위를 넓혔고, 2026년부터 Product Engineer로 제품의 화면과 운영 정책, 서버 구현을 함께 맡고 있습니다.

담당 범위

  • 마트 운영자용 Temply 웹의 전단·POP·디자인 캔버스·메시지 발송 흐름
  • POP과 디자인 캔버스가 공유하는 편집 기반과 인쇄·이미지·PSD 출력
  • 템플릿 공급, 가입 승인, 요금제와 이용권을 관리하는 내부 운영 백오피스
  • 전단·POP·회원·마트·메시지 기능을 제공하는 NestJS 서버
  • 오류 추적, 배포와 일부 AWS CDK 기반 인프라 운영

Problem

오프라인 마트의 홍보 업무는 하나의 결과물을 만드는 과정에서도 여러 번 끊겼습니다. 행사 상품을 엑셀에 정리한 뒤 전단 제작 도구에 다시 입력하고, 상품 이미지를 따로 찾고, 가격표와 POP를 별도로 만들고, 완성된 전단을 문자나 카카오 메시지에 다시 첨부해야 했습니다. 매장 운영이 본업인 사용자가 반복 입력과 세부 디자인 조정까지 떠안는 구조였습니다.

제품이 커지면서 해결해야 할 문제도 제작 화면 밖으로 확장됐습니다.

  • 제작: 같은 상품과 행사 데이터를 전단, POP, 홍보 이미지에서 재사용해야 했습니다.
  • 출력: 웹에서 편집한 결과가 이미지, 인쇄물, PSD에서도 의도대로 보여야 했습니다.
  • 운영: 템플릿과 상품 이미지가 지속적으로 공급되고, 가입 승인·요금제·사용량을 내부에서 관리할 수 있어야 했습니다.
  • 발송: 제작한 콘텐츠가 문자와 카카오 메시지로 이어지고, 채널별 정책과 규제를 지켜야 했습니다.
  • 확장: 기능이 늘어도 화면, 서버와 운영 도구의 규칙이 서로 어긋나지 않아야 했습니다.

따라서 목표는 기능을 많이 추가하는 데 있지 않았습니다. 마트 운영자가 행사 데이터를 한 번 정리한 뒤 제작, 출력, 발송까지 이어갈 수 있고, 운영팀이 그 흐름을 뒤에서 유지할 수 있는 제품 구조를 만드는 것이 핵심이었습니다.

Process

화면이 아니라 업무의 시작과 끝을 기준으로 나눴습니다

먼저 제품을 개별 페이지의 집합이 아닌 세 개의 연결된 제품면으로 보았습니다.

  1. 마트 운영자용 웹은 상품을 등록하고 홍보물을 제작·출력·발송하는 작업 공간입니다.
  2. 내부 운영 백오피스는 고객사, 요금제, 사용량과 디자인 리소스를 공급하는 운영 도구입니다.
  3. 서버와 인프라는 두 화면이 같은 권한·상품·템플릿·발송 규칙을 사용하도록 지탱합니다.

이 구분을 기준으로 새 기능을 검토할 때 사용자 화면만 완성하는 대신, 필요한 데이터와 운영 절차까지 함께 확인했습니다. 예를 들어 POP 템플릿을 추가할 때는 마트 운영자가 선택하는 화면뿐 아니라 운영자가 원본을 등록하고 미리보기를 검수하는 흐름, 저장 형식과 API까지 하나의 범위로 다뤘습니다.

상품 데이터를 여러 결과물로 이어지게 했습니다

모바일 전단은 엑셀 업로드, 상품 이미지 선택, 행사 코너와 배너 설정을 거쳐 발행됩니다. POP는 같은 상품의 가격·할인·단위 정보를 매장 인쇄물에 맞게 배치해야 합니다. 두 기능을 별개의 입력 도구로 만들면 사용자는 같은 정보를 다시 작성하게 됩니다.

그래서 전단의 상품 데이터를 POP로 불러오고, 가격·이미지·섹션 정보를 편집 가능한 문서로 변환하는 흐름을 만들었습니다. 제작한 문서는 이미지와 인쇄물로 바로 사용하거나 PSD로 내보내 후속 디자인 작업에 활용할 수 있게 했습니다. 사용자가 반복해서 만드는 레이아웃은 ‘내 템플릿’으로 저장하고 다시 적용할 수 있도록 연결했습니다.

편집기를 후속 기능이 쌓일 수 있는 기반으로 정리했습니다

POP와 디자인 캔버스는 다루는 결과물이 다르지만 선택, 이동, 크기 조절, 템플릿 적용과 출력이라는 공통 동작을 가집니다. 기능별로 편집 상태를 덧붙이던 구조에서는 저장 데이터와 일시적인 조작 상태가 섞여 변경의 영향을 예측하기 어려웠습니다.

저장되는 문서 상태, 선택·줌·클립보드 같은 작업 상태, 드래그·리사이즈 중의 상호작용 상태를 분리했습니다. 공통 편집 엔진 위에서 POP와 디자인 캔버스가 각자 필요한 도구만 노출하도록 구성하고, 가격표·템플릿·인쇄·이미지·PSD 출력을 같은 문서 모델에 연결했습니다. 편집기 자체의 세부 설계는 Canvas Editor 사례에서 별도로 다룹니다.

내부 운영을 제품의 일부로 만들었습니다

템플릿 기반 제작이 실제로 돌아가려면 디자인팀의 PSD 원본을 서비스에서 읽을 수 있는 데이터로 바꾸고, 운영자가 결과를 검수해 배포할 수 있어야 했습니다. PSD의 텍스트·이미지·폰트·레이어 정보를 캔버스 데이터로 변환하고, 이미지 업로드와 URL 치환, 미리보기 생성, 폰트·해상도 검증, 다중 업로드를 내부 백오피스에 구현했습니다.

같은 백오피스에서 신규 마트와 회원의 가입 승인, 요금제·공급가·이용권 변경, POP 레이아웃과 관리대행 전단 상태를 관리하도록 했습니다. 고객이 보는 기능과 운영팀이 수행하는 공급·검수·지원 업무를 함께 설계함으로써, 새 기능이 사람의 수작업에만 의존하지 않도록 했습니다.

제품 규칙을 서버와 운영 절차까지 연결했습니다

담당 범위가 서버로 넓어진 뒤에는 화면에서만 막던 규칙을 NestJS API의 데이터 모델과 검증 로직으로 옮겼습니다. 전단·POP 템플릿 API, 회원과 마트의 승인 상태, 메시지 발송 조건처럼 여러 화면이 공유하는 규칙을 서버에서 일관되게 판정하도록 했습니다.

대표적으로 문자 전송자격인증제 대응에서는 관련 법령과 고시를 검토해 발신번호 등록·심사, 발송 전 본인인증, 접속·인증 이력과 계정 차단을 서버·마트 운영자용 웹·어드민에 연결했습니다. 서류를 검토하는 운영 화면과 기존 고객의 계도 정책까지 함께 마련해 외부 규정을 실제 제품 정책과 운영 절차로 바꿨습니다.

Solution

마트 운영자용 제작 웹

Next.js와 TypeScript를 기반으로 모바일 전단, POP, 디자인 캔버스와 메시지 발송을 연결했습니다. TanStack Query로 서버 데이터를 관리하고 Jotai와 편집기 전용 상태 구조를 사용해 복잡한 제작 상태를 분리했습니다. 마트 운영자는 엑셀과 기존 전단에서 상품을 불러오고, 템플릿을 적용해 결과물을 만든 뒤 이미지·인쇄·PSD로 출력하거나 고객 메시지 발송으로 이어갈 수 있습니다.

내부 운영 백오피스

React와 TypeScript 기반 어드민에서 고객사 온보딩, 요금제와 이용권, 템플릿과 이미지 리소스, 관리대행 상태를 관리합니다. 특히 디자인 원본을 제품 데이터로 변환하는 파이프라인을 구축해 운영팀이 개발자의 개입 없이 템플릿을 등록하고 변환 결과를 검수할 수 있는 기반을 만들었습니다.

서버와 인프라

NestJS 서버에서 전단·POP·회원·마트·메시지 도메인의 API와 정책을 구현했습니다. MySQL·TypeORM, Redis와 AWS S3를 사용해 문서와 템플릿, 인증과 발송 상태를 다뤘고, Sentry와 AWS 환경에서 오류와 운영 상태를 추적했습니다. 화면의 기능을 API 호출에 연결하는 수준을 넘어, 사용자 권한과 운영 정책이 서버에서도 같은 기준으로 적용되도록 범위를 확장했습니다.

Results

  • 모바일 전단, POP, 홍보 이미지 제작과 문자·카카오 메시지 발송이 하나의 Temply 제품 안에서 이어지는 흐름을 구축했습니다.
  • 농협 하나로마트 10개 점포의 업무 효율화 프로젝트에 사용된 POP 에디터를 개발해 웹 편집 결과를 실제 매장 인쇄물로 연결했습니다.
  • POP와 디자인 캔버스가 공통 편집 기반을 사용하면서 가격표, 사용자 템플릿, 인쇄, 이미지와 PSD 출력 같은 후속 기능을 같은 문서 모델 위에 확장했습니다.
  • 디자인 원본의 변환·검수·배포와 고객사 가입·요금제·이용권 관리를 내부 백오피스에 연결해 제품 운영에 필요한 도구를 함께 구축했습니다.
  • 약 4년에 걸쳐 프론트엔드 중심의 역할을 서버, 운영 정책과 일부 인프라까지 넓히며 한 기능의 사용자 경험과 운영 조건을 함께 다루는 Product Engineer 역할로 전환했습니다.

Learnings

운영 도구도 사용자 기능만큼 중요했습니다

템플릿이나 자동 매칭처럼 겉으로 보이는 기능의 품질은 운영팀이 원본을 공급하고 오류를 바로잡는 과정에 달려 있었습니다. 사용자 화면과 백오피스를 함께 보면 기능 출시 이후의 유지 비용과 예외 상황을 더 일찍 발견할 수 있었습니다.

편집 제품에서는 저장 모델이 기능의 한계를 결정했습니다

캔버스 UI를 빠르게 추가하는 것보다 어떤 상태를 문서에 저장하고 어떤 상태를 작업 중에만 유지할지 정하는 일이 더 중요했습니다. 이 경계를 먼저 정리한 뒤 템플릿 재사용과 여러 출력 방식을 같은 모델 위에 추가할 수 있었습니다.

정책은 화면 문구가 아니라 시스템의 판정 규칙이어야 했습니다

요금제, 가입 승인과 메시지 규제는 프론트엔드에서 버튼을 숨기는 것으로 끝나지 않았습니다. 서버 검증, 데이터 이력과 운영자의 예외 처리까지 함께 설계해야 실제 서비스 정책으로 작동했습니다.

다음 단계에서는 제작 시작부터 출력과 발송까지의 소요 시간, 템플릿 재사용률, 출력 실패율 같은 제품 지표를 기능과 함께 정의하려 합니다. 구현 범위뿐 아니라 사용자의 반복 업무가 얼마나 줄었는지를 지속적으로 설명할 수 있기 때문입니다.