[Career] 21앤에서 보낸 풀스택 1년 차 — 고충과 배운 점
21앤에서 보낸 풀스택 1년 차 — 고충과 배운 점
저는 21앤에서 React Native(Expo), NestJS·tRPC, Next.js, 그리고 AWS·Terraform까지 맡는 풀스택으로 일하고 있습니다.
이 글은 서비스 스펙 나열이 아니라, 1년 차에 가까워지며 겪은 고충과 그때마다 새겨 둔 배움을 정리한 회고입니다.
제품 소개·스택 개요는 이전 글에 적어 두었습니다.
1. 풀스택이라는 말의 무게
처음에는 “한 번에 다 할 수 있으니까 좋다”고 생각했습니다. 막상 일이 겹치면 앱 화면 하나, API 스키마, 어드민 테이블, 배포 파이프라인이 같은 날 터지기도 합니다. 머리는 계속 컨텍스트 스위칭을 하고, 정작 한 레이어를 깊게 파고들 시간은 부족해지기 쉽습니다.
고충으로 남은 건 이거였습니다. *“다 되는 척하다가, 막상 어디 하나 물어보면 대답이 얕다”*는 느낌. 1년 차에는 아직 시니어 한 분야가 없는 게 정상에 가깝다는 걸 머리로는 알면서도, 가슴 한켠에서는 계속 조급해졌습니다.
2. PG 연동을 하지 않기로 한 과정 — 의료·정책과의 정면 충돌
처음에는 “결제만 PG 붙이면 끝 아닌가?”라는 생각도 했습니다. 그런데 병원·시술·모델 매칭이 얽인 서비스는 일반 이커머스 결제와 결이 다릅니다.
정리해 보면 이런 검토·설득의 연속이었습니다.
-
의료 관련 규제
서비스가 단순 ‘콘텐츠 플랫폼’이 아니라, 의료·시술·계약과 맞닿아 있다는 전제에서 의료법·의료광고·중개 등과 어떻게 겹치는지, 사업·법무 쪽과 함께 키워드를 하나씩 짚었습니다. (저는 법률 전문가가 아니라, **개발 입장에서는 “어떤 결제·정산이 허용되는 그림인지”**를 질문하고 문서로 남기는 역할에 가깝게 참여했습니다.) -
PG사 정책·업종·리스크
PG는 업종·상품·정산 구조에 따라 가입 불가·제한·추가 심사가 걸리는 경우가 많습니다. 의료·미용·중개 성격이 섞이면 내부 리스크 기준에 걸려 아예 문을 닫는 케이스도 검토 과정에서 현실로 다가왔습니다. -
개발 관점에서의 결론
“PG 붙여서 카드 결제” 한 줄이 아니라, 법·사업·PG 세 축이 동시에 YES여야 하는데, 우리 도메인에서는 그게 쉽지 않았습니다. 그래서 PG 없이, 이미 제품 방향에 맞게 잡혀 있던 은행 API 기반(계좌 조회·송금) 쪽으로 설계를 고정하고, 전자계약·포인트·정산의 중심을 그리로 맞추는 쪽이 현실적이었습니다.
이 과정에서 배운 점은, 기능을 먼저 만들고 나중에 규제를 끼워 맞추면 비용이 폭발한다는 것이었습니다. 반대로 “왜 PG가 안 되는지”를 한 페이지로라도 정리해 두면, 이후에 합류하는 사람·외부 파트너에게 설명할 때도 훨씬 수월합니다.
3. 전자계약을 위해 모두싸인을 신청·등록하며
전자서명·전자계약서는 법적 효력·감사 추적까지 고려해야 해서, 자체 구현만으로 밀기엔 리스크가 컸습니다. 회사에서는 모두싸인 쪽으로 가입·기업 인증·템플릿·API·웹훅까지 포함한 연동 준비를 진행했고, 저는 그걸 앱·API·어드민에 녹이는 쪽을 맡았습니다.
풀스택으로 하면서 특히 신경 쓴 것은 다음이었습니다.
- 환경 분리: API 키·웹훅 시크릿·템플릿 ID를 dev/stage/prod로 나누고, 실수로 운영 템플릿을 건드리지 않게 구성
- 웹훅 멱등: 동일 이벤트가 여러 번 와도 상태가 한 번만 전이되도록 저장·락·중복 키 처리
- 사용자 여정: 앱에서 서명 요청까지 가는 동안 중간 상태를 어디에 둘지(우리 DB vs 모두싸인 상태만 신뢰) 합의
- 관측: 서명 실패·타임아웃·재시도 시 어디까지가 우리 버그이고 어디부터가 외부인지 로그로 구분
“신청했다”에서 끝이 아니라, 등록 이후에야 진짜 개발이 시작된다는 걸 몸으로 알게 된 구간이었습니다.
4. 비용 문제 — 풀스택이 고민해야 했던 지점
SaaS·전자서명·클라우드·은행 연동은 전부 건당·월정액·트래픽이 붙습니다. 1년 차 풀스택 입장에서 가장 부담된 건 **“기능은 구현했는데, 운영 비용 곡선이 예상과 다르다”**는 상황이었습니다.
제가 시도한 고민·해결의 순서는 대략 이랬습니다.
-
비용을 숫자로 깨기
월 고정비(좌석·구독) vs 건당 과금(서명·API 호출) vs 인프라(Fargate·RDS·스토리지)를 표로 쪼개서, “이 기능 켜면 한 달에 대략 얼마가 움직이는지”를 대시보드가 아니라 스프레드시트 한 장이라도 만들었습니다. 개발자가 이걸 하기 싫어도, PM·대표와 말이 통하려면 필요했습니다. -
단계적 켜기
처음부터 풀 옵션이 아니라, MVP 구간에서 꼭 필요한 API·템플릿만 켜고 나머지는 플래그나 환경 변수로 막아 두었습니다. “나중에 필요하면 연다”를 코드와 설정으로 명시해 두니 싸움이 줄었습니다. -
캐시·배치·비동기
PDF·알림·외부 조회처럼 돈과 시간이 동시에 나가는 작업은 동기 API로 붙이지 않고, 큐·워커·재시도 정책을 정리해 불필요한 재호출을 줄이려고 했습니다. (이건 비용이면서 동시에 안정성 문제입니다.) -
대안과의 트레이드오프 기록
“더 싼 서명 SaaS는 없나?” 같은 질문이 올 때마다, 법적 요건·감사·연동 난이도·마이그레이션 비용까지 한 줄씩 적어 두었습니다. 결정이 감이 아니라 표에 남도록요.
배운 점은 명확합니다. 풀스택은 코드만 짜는 역할이 아니라, 단가가 붙는 설계까지 질문할 수 있어야 한다는 것이었습니다. “비용은 기획이 알아서”라고 넘기면, 나중에 갑자기 끊기는 API를 설명해야 하는 사람도 결국 개발자인 경우가 많습니다.
5. 도메인이 기술보다 먼저였던 순간들
21앤은 전자계약, 포인트·쿠폰, 은행 연동, 병원·모델·관리자 권한이 한꺼번에 얽힌 B2B2C입니다. 기술 스택을 아는 것과, *“지금 이 상태값이 비즈니스에서 무슨 의미인지”*를 말하는 건 다른 문제였습니다.
- 계약이
draft에서pending으로 갈 때 누가 알림을 받아야 하는지 - 포인트 지급이 한 번만 일어나야 하는지(멱등)
- 어드민에서 보이는 숫자와 앱 사용자에게 보이는 숫자가 언제 동기화되는지
이걸 나중에 알고 나면 이미 API와 화면이 어긋난 뒤인 경우가 있었습니다. 배운 점은 기능 찍기 전에 상태 다이어그램이나 표 한 장이라도 같이 그리자는 습관이었습니다.
6. 외부 연동과 “내 잘못인지 모르겠는” 시간
전자서명·웹훅·은행 API는 내 코드가 틀린 건지, 샌드박스가 이상한 건지, 문서가 빠진 건지 구분이 안 될 때가 깁니다.
배운 점은 운영 습관이었습니다.
- 요청·응답 correlation id
- 외부 콜백 raw payload 로그(민감정보 마스킹)
- “재현 불가”라고 말하기 전에 시간대·환경·요청 바디 나열
모두싸인·은행 쪽 이슈를 겪으며 이게 습관으로 남았습니다.
7. 모노레포: 편함과 책임이 같이 온다
apps/user-app, apps/api, apps/admin이 한 저장소에 있으면 타입·상수 공유는 좋습니다. 대신 한 번의 실수가 여러 앱에 파급될 수 있습니다.
배운 점은 “공유는 최소한만”입니다. 완벽한 DRY보다 배포 리스크가 낮은 구조가 우선인 경우가 많았습니다.
8. 커뮤니케이션 — 코드로만 증명하려다 지친 날
- 15분 룰: 막히면 15분은 로그·문서·재현 시도, 그다음엔 짧게라도 동료에게 상황 공유
- 질문에 붙일 것: 기대 동작 / 실제 동작 / 재현 순서 / 이미 해본 것
- PR 설명: “왜 이렇게 했는지” 한 줄
고충은 “실력 부족을 들키는 게 싫다”는 마음이었고, 배운 점은 그게 일정을 지키는 적이 더 적다는 현실이었습니다.
9. 마케팅 회사인데, 개발자로 채용되어서
21앤은 마케팅에 강한 조직에서 출발한 면도 있고, 저는 그 안에서 개발자로 들어왔습니다. 덕분에 캠페인·브랜딩·클라이언트 커뮤니케이션에 익숙한 사람들과 같은 책상을 쓰게 되었고, 동시에 개발 조직이 얇을 때만 나오는 긴장도 같이 겪었습니다.
힘들었던 점
- 기대치의 언어가 다름: “빨리 런칭”이 마케팅 일정과 맞물릴 때, 기술 부채·보안·테스트를 설명하는 데 에너지가 많이 갔습니다.
- 개발 리소스가 한정적: 풀스택 한 명이 여러 레이어를 동시에 봐야 해서, 동료 개발자에게 물어보는 시간이 적을 때 스트레스가 컸습니다.
- 비개발 배경의 요청: “이거 간단하지?”가 데이터·권한·연동까지 포함하면 간단하지 않다는 걸 매번 풀어 설명해야 했습니다.
회사에서 배운 점
- 비즈니스 말하기: 기능을 “API 엔드포인트”가 아니라 고객 여정·전환으로 설명하는 연습이 늘었습니다.
- 마케팅 감각의 일부를 개발에 반영: 카피·랜딩·푸시 문구가 바뀔 때 앱 내 일관성이 깨지지 않게 하려면, 개발도 메시지 버전을 의식해야 한다는 것.
- 외부 파트너·법·비용이 한 테이블에 올라오는 프로젝트에서는, 문서화가 곧 속도라는 것.
이룬 점 (스스로 남기고 싶은 것)
- PG 없이도 서비스 요구를 만족시키는 결제·정산·계약 흐름을 코드와 인프라로 끝까지 이어 붙인 경험
- 모두싸인을 신청·등록·연동까지 포함해 전자계약 파이프라인에 녹여 낸 것
- 비용·과금·단계적 롤아웃을 표와 설정으로 정리해, “왜 이렇게 켰는지”를 반복 설명하지 않게 만든 것
- 마케팅 중심 조직 안에서 개발자로서 신뢰를 쌓기 위해, 릴리즈·장애 대응·문서를 보이는 산출물로 남긴 것
10. 1년 차 풀스택에게 남기고 싶은 문장
- 넓게 쓰는 사람은 초반에 필요하고, 한 축이라도 깊어지는 사람은 그다음에 필요하다. 지금 분기에서 무엇을 깊게 가져갈지는 의식적으로 고르게 되었다.
- “풀스택”은 혼자 다 하는 직함이 아니라, 비용·규제·외부 SaaS·인프라 사이를 번역하는 역할에 가깝다.
- 건강·수면이 깨지면 컨텍스트 스위칭 비용이 제일 먼저 폭발한다.
마치며
21앤은 제게 “기술 스택 나열”보다 도메인·규제·비용·외부 연동을 한 번에 보게 만든 회사입니다. 마케팅 DNA가 강한 조직에서 개발자로 버티는 일은 쉽지 않았지만, 그만큼 설득과 문서를 남기는 법을 배웠습니다. 1년 차로서 고충을 말할 수 있을 만큼 조금은 단단해진 것 같아 이 글을 남깁니다.
비슷한 역할을 하는 분들께 조금이라도 공감이 가면 좋겠습니다.
이 글은 개인 회고이며 법률·세무·PG·의료 규제에 대한 전문 자문이 아닙니다. 실제 판단은 반드시 자격을 갖춘 전문가와 회사 내부 검토를 거치시기 바랍니다. 민감한 계약·보안·내부 정책 세부는 포함하지 않았습니다.