마케팅 조직의 유일한 풀스택 — 21앤 1년의 의사결정과 운영 기록

이 글은 토리스 대표가 21앤(21n)에서 React Native(Expo), NestJS·tRPC, Next.js, AWS·Terraform을 아우르는 풀스택으로 일한 1년 차의 기록을 케이스 스터디 형식으로 재정리한 것입니다. 제품 구조와 스택 개요는 플랫폼 케이스 스터디에 있으며, 이 글은 의사결정·조율·운영에 초점을 둡니다.

1. 상황 — 어떤 조건에서 시작했나

21앤은 마케팅에 강한 배경에서 출발한 조직이고, 개발 인력은 얇았습니다. 그 안에서 풀스택 한 명이 다음을 동시에 담당하는 구조였습니다.

레이어	담당 범위
앱	React Native(Expo) 사용자 앱
API	NestJS·tRPC 기반 도메인 API
어드민	Next.js 통합·병원 관리자 웹
인프라	AWS(ECS Fargate·RDS 등), Terraform, 배포 파이프라인

이 조건이 만드는 현실은 명확합니다. 앱 화면 하나, API 스키마, 어드민 테이블, 배포 파이프라인 이슈가 같은 날 동시에 터질 수 있고, 컨텍스트 스위칭 비용이 상시 발생하며, 한 레이어를 깊게 파고들 시간은 구조적으로 부족합니다. “다 되는 척하다가 어디 하나를 깊게 물어보면 대답이 얕아진다”는 리스크를 인지한 상태에서, 무엇을 얕게 두고 무엇을 깊게 가져갈지를 의식적으로 골라야 했습니다.

아래는 그 1년 동안 실제로 부딪힌 문제들과, 각각을 어떻게 풀었는지의 기록입니다.

2. 의사결정 ① — PG를 붙이지 않기로 한 과정

처음에는 “결제만 PG 붙이면 끝 아닌가”라는 가설에서 출발했습니다. 그러나 병원·시술·모델 매칭이 얽힌 서비스는 일반 이커머스 결제와 결이 달랐고, 검토는 세 축으로 진행됐습니다.

2.1 의료 관련 규제

서비스가 단순 콘텐츠 플랫폼이 아니라 의료·시술·계약과 맞닿아 있다는 전제에서, 의료법·의료광고·중개 관련 규정과 어떻게 겹치는지를 사업·법무와 함께 키워드 단위로 짚었습니다. 개발 쪽의 역할은 법률 해석이 아니라, “어떤 결제·정산이 허용되는 그림인지”를 질문하고 그 답을 문서로 남기는 것이었습니다.

2.2 PG사 정책과 리스크

PG는 업종·상품·정산 구조에 따라 가입 불가·제한·추가 심사가 걸리는 경우가 많습니다. 의료·미용·중개 성격이 섞이면 PG사 내부 리스크 기준에 걸려 아예 문이 닫히는 케이스도 검토 과정에서 현실로 확인됐습니다.

2.3 결론과 그 이후

“PG 붙여서 카드 결제”는 법·사업·PG 세 축이 동시에 YES여야 성립하는데, 우리 도메인에서는 그것이 어려웠습니다. 그래서 PG 없이, 이미 제품 방향에 맞게 잡혀 있던 은행 API 기반(계좌 조회·송금) 설계로 고정하고, 전자계약·포인트·정산의 중심을 그쪽으로 맞췄습니다.

이 과정에서 남긴 원칙이 둘 있습니다. 첫째, 기능을 먼저 만들고 규제를 나중에 끼워 맞추면 비용이 폭발한다. 둘째, “왜 PG가 안 되는지”를 한 페이지로 정리해 두면, 이후 합류하는 사람과 외부 파트너에게 같은 설명을 반복하지 않아도 된다는 것입니다.

3. 의사결정 ② — 전자계약을 모두싸인으로 가져가며

전자서명·전자계약서는 법적 효력과 감사 추적까지 고려해야 하므로, 자체 구현으로 밀기에는 리스크가 컸습니다. 회사 차원에서 모두싸인 가입·기업 인증·템플릿·API·웹훅까지 연동 준비를 진행했고, 저는 그것을 앱·API·어드민에 녹이는 쪽을 맡았습니다.

풀스택으로서 연동에서 특히 챙긴 것은 다음 네 가지입니다.

• 환경 분리: API 키·웹훅 시크릿·템플릿 ID를 dev/stage/prod로 나누고, 실수로 운영 템플릿을 건드리지 않게 구성
• 웹훅 멱등: 동일 이벤트가 여러 번 도착해도 상태가 한 번만 전이되도록 저장·락·중복 키 처리
• 상태의 원천 합의: 앱에서 서명 요청까지 가는 동안의 중간 상태를 우리 DB에 둘지, 모두싸인 상태만 신뢰할지를 팀과 명시적으로 합의
• 관측 가능성: 서명 실패·타임아웃·재시도 시 어디까지가 우리 버그이고 어디부터가 외부 이슈인지 로그로 구분

여기서 얻은 교훈은 단순합니다. 외부 SaaS 연동은 “신청했다”에서 끝나는 것이 아니라, 등록 이후에야 진짜 개발이 시작된다는 것입니다.

4. 의사결정 ③ — 비용을 개발자의 문제로 가져오기

전자서명 SaaS·클라우드·은행 연동에는 전부 건당·월정액·트래픽 과금이 붙습니다. 가장 부담스러웠던 상황은 “기능은 구현했는데 운영 비용 곡선이 예상과 다르다”는 것이었고, 이를 다음 순서로 다뤘습니다.

1. 비용을 숫자로 깨기 — 월 고정비(좌석·구독), 건당 과금(서명·API 호출), 인프라(Fargate·RDS·스토리지)를 표로 쪼개, “이 기능을 켜면 한 달에 대략 얼마가 움직이는지”를 스프레드시트 한 장으로라도 만들었습니다. 개발자가 하고 싶은 일은 아니지만, PM·대표와 말이 통하려면 필요한 작업이었습니다.
2. 단계적으로 켜기 — 처음부터 풀 옵션이 아니라 MVP 구간에 꼭 필요한 API·템플릿만 켜고, 나머지는 플래그·환경 변수로 막았습니다. “나중에 필요하면 연다”를 코드와 설정으로 명시하자 소모적인 논쟁이 줄었습니다.
3. 캐시·배치·비동기 — PDF·알림·외부 조회처럼 돈과 시간이 동시에 나가는 작업은 동기 API로 붙이지 않고, 큐·워커·재시도 정책으로 불필요한 재호출을 줄였습니다. 이것은 비용 문제이자 동시에 안정성 문제입니다.
4. 대안과의 트레이드오프 기록 — “더 싼 서명 SaaS는 없나” 같은 질문이 올 때마다 법적 요건·감사·연동 난이도·마이그레이션 비용을 한 줄씩 적어, 결정이 감이 아니라 표에 남게 했습니다.

결론적으로 풀스택은 코드만 짜는 역할이 아니라 단가가 붙는 설계까지 질문하는 역할이었습니다. “비용은 기획이 알아서”라고 넘기면, 나중에 갑자기 끊기는 API를 설명해야 하는 사람도 결국 개발자입니다.

5. 도메인이 기술보다 먼저였던 순간들

21앤은 전자계약, 포인트·쿠폰, 은행 연동, 병원·모델·관리자 권한이 한꺼번에 얽힌 B2B2C입니다. 기술 스택을 아는 것과 “지금 이 상태값이 비즈니스에서 무슨 의미인지”를 말하는 것은 다른 문제였습니다.

• 계약이 draft에서 pending으로 갈 때 누가 알림을 받아야 하는가
• 포인트 지급은 한 번만 일어나야 하는가(멱등)
• 어드민에 보이는 숫자와 앱 사용자에게 보이는 숫자는 언제 동기화되는가

이런 질문을 뒤늦게 발견하면 이미 API와 화면이 어긋난 뒤인 경우가 있었습니다. 그래서 기능을 만들기 전에 상태 다이어그램이나 표 한 장을 먼저 그리는 것을 팀 습관으로 만들었습니다.

6. 외부 연동 운영 — “내 잘못인지 모르겠는” 시간을 줄이는 법

전자서명·웹훅·은행 API는 내 코드가 틀린 것인지, 샌드박스가 이상한 것인지, 문서가 빠진 것인지 구분이 안 되는 시간이 깁니다. 모두싸인·은행 쪽 이슈를 겪으며 다음을 운영 습관으로 고정했습니다.

• 요청·응답에 correlation id를 부여해 흐름을 추적
• 외부 콜백의 raw payload 로그 보존(민감정보는 마스킹)
• “재현 불가”라고 말하기 전에 시간대·환경·요청 바디를 먼저 나열

이 습관은 디버깅 속도뿐 아니라 외부 파트너와의 커뮤니케이션 품질을 결정했습니다. 근거가 정리되어 있으면 파트너 쪽 이슈 확인도 훨씬 빨라집니다.

7. 모노레포 — 편함과 책임이 같이 온다

apps/user-app, apps/api, apps/admin이 한 저장소에 있으면 타입·상수 공유는 편합니다. 대신 한 번의 실수가 여러 앱에 파급될 수 있습니다. 운영해 본 결론은 “공유는 최소한만”입니다. 완벽한 DRY보다 배포 리스크가 낮은 구조가 우선인 경우가 많았습니다.

8. 이해관계자 조율 — 이 1년의 실제 본론

돌아보면 기술 문제보다 조율 문제에 더 많은 에너지를 썼고, 그만큼 배운 것도 여기에 몰려 있습니다.

8.1 마케팅 중심 조직과 개발자 사이

캠페인·브랜딩·클라이언트 커뮤니케이션에 익숙한 구성원들과 같은 책상을 쓰면서, 개발 조직이 얇을 때만 나오는 긴장을 함께 겪었습니다.

• 기대치의 언어가 다름: “빨리 런칭”이 마케팅 일정과 맞물릴 때, 기술 부채·보안·테스트의 필요성을 설명하는 데 에너지가 많이 들었습니다.
• 비개발 배경의 요청: “이거 간단하지?”라는 요청이 데이터·권한·외부 연동까지 포함하면 간단하지 않다는 것을 매번 풀어 설명해야 했습니다.
• 동료 개발자 부재: 풀스택 한 명이 여러 레이어를 동시에 보면서 기술적으로 물어볼 상대가 적다는 것이 가장 큰 스트레스 요인이었습니다.

이 간극을 좁힌 방법은 두 가지였습니다. 기능을 “API 엔드포인트”가 아니라 고객 여정·전환의 언어로 설명하는 연습, 그리고 판단 근거를 표·문서·설정으로 남겨 반복 설명 자체를 없애는 것입니다. 외부 파트너·법·비용이 한 테이블에 올라오는 프로젝트에서는 문서화가 곧 속도였습니다.

8.2 커뮤니케이션 원칙

“실력 부족을 들키는 게 싫다”는 마음이 커뮤니케이션의 가장 큰 적이었고, 그것을 다음 원칙으로 대체했습니다.

• 15분 룰: 막히면 15분은 로그·문서·재현을 시도하고, 그다음엔 짧게라도 동료에게 상황을 공유
• 질문의 형식: 기대 동작 / 실제 동작 / 재현 순서 / 이미 해본 것
• PR 설명: “왜 이렇게 했는지” 한 줄

혼자 끙끙대는 것보다 이렇게 공유하는 쪽이 일정을 지키는 데 압도적으로 유리했습니다.

8.3 마케팅 감각을 개발에 반영

역으로 배운 것도 있습니다. 카피·랜딩·푸시 문구가 바뀔 때 앱 내 일관성이 깨지지 않으려면 개발도 메시지 버전을 의식해야 한다는 점입니다. 마케팅 조직 안에서 일했기 때문에 얻은 감각입니다.

9. 결과 — 1년이 남긴 것

• PG 없이도 서비스 요구를 만족시키는 결제·정산·계약 흐름을 코드와 인프라로 끝까지 이어 붙였습니다.
• 모두싸인을 신청·등록·연동까지 포함해 전자계약 파이프라인에 녹였습니다.
• 비용·과금·단계적 롤아웃을 표와 설정으로 정리해, “왜 이렇게 켰는지”를 반복 설명하지 않는 상태를 만들었습니다.
• 마케팅 중심 조직 안에서 릴리즈·장애 대응·문서를 보이는 산출물로 남겨 개발자로서의 신뢰를 쌓았습니다.

10. 재사용 가능한 교훈

1. 넓게 쓰이는 사람은 초반에, 한 축이라도 깊은 사람은 그다음에 필요하다. 지금 분기에 무엇을 깊게 가져갈지는 의식적으로 골라야 합니다.
2. 풀스택은 혼자 다 하는 직함이 아니다. 비용·규제·외부 SaaS·인프라 사이를 번역하는 역할에 가깝습니다.
3. 규제·비용·외부 연동은 기능보다 먼저 검토한다. 나중에 끼워 맞추는 비용이 항상 더 큽니다.
4. 판단은 감이 아니라 표에 남긴다. 한 페이지 문서가 반복 설명과 소모적 논쟁을 대체합니다.
5. 건강·수면이 무너지면 컨텍스트 스위칭 비용이 제일 먼저 폭발한다. 여러 레이어를 오가는 역할일수록 지속 가능성이 곧 생산성입니다.

마치며

21앤은 기술 스택 나열보다 도메인·규제·비용·외부 연동을 한 번에 보게 만든 회사였습니다. 마케팅 DNA가 강한 조직에서 개발자로 일하는 것은 쉽지 않았지만, 그만큼 설득과 문서를 남기는 법을 배웠습니다. 이 기록이 비슷한 조건 — 얇은 개발 조직, 규제가 있는 도메인, 외부 연동 중심 제품 — 에서 일하는 분들께 참고가 되기를 바랍니다.

---

이 글은 재직 경험에 기반한 케이스 스터디이며 법률·세무·PG·의료 규제에 대한 전문 자문이 아닙니다. 실제 판단은 반드시 자격을 갖춘 전문가와 회사 내부 검토를 거치시기 바랍니다. 민감한 계약·보안·내부 정책 세부는 포함하지 않았습니다.