0. 기록을 남기기로 한 이유

"3개월 안에 앱 출시 가능할까요? 샵백 앱 참고해서 비슷하게 만들어주세요. 세부사항은 알아서 결정하시면 됩니다."

 

회사에서 처음 맡은 앱 개발 프로젝트의 시작이었습니다. 웹 개발 경험은 있었지만 앱 개발은 처음이었고, 인프라 경험도 전무했으며, 무엇보다 사수 없이 단독으로 진행해야 하는 프로젝트였습니다.

지금 돌아보면 무모했던 것 같기도 하지만, 그 과정에서 크고 작은 여러 문제들을 해결하며 많은 것을 배웠습니다. 그리고 이제 개발이 거의 마무리된 시점에서, 그동안 달려오느라 정리하지 못했던 기록들을 꺼내보려 합니다.

 

 

 

 

 

1. 왜 지금에서야 기술 블로그를 쓰기 시작했을까

 

사실 개발 과정에서 트러블슈팅을 만날 때마다 자료는 꾸준히 모아뒀습니다. 에러 로그, 해결 방법, 참고한 링크들, 머릿속 고민들까지. 하지만 그것들은 말 그대로 자료였을 뿐, 정리된 글은 아니었습니다.

일정에 쫓겨 해결에만 집중하다보니, 그것을 글로 정리할 여유는 없었습니다. 문제가 생기면 급하게 해결하고, 다음 기능으로 넘어가는 과정을 반복하다 보니, 꼬리 질문이나 더 깊게 파고들 만한 고민들은 메모로만 남아 있었습니다.

 

지금에서야 숨을 고를 수 있는 시점이 되었고, 그때의 판단과 선택들을 그냥 흘려보내기보다는 정리된 형태로 남기고 싶다는 생각이 들었습니다. 당시엔 너무 생생했던 문제 상황들이 시간이 지나면서 희미해지고 있었고, "그때 왜 이렇게 했더라?"라는 질문에 명확히 답하기 어려워지기 전에 기록으로 남기고 싶었습니다.

 

또 하나의 이유는 현실적인 목적입니다. 회사 코드나 실제 서비스를 그대로 공개할 수는 없지만, 문제를 어떻게 정의했고, 어떤 선택지들 사이에서 고민했으며, 왜 그 결론에 도달했는지는 충분히 일반화해서 공유할 수 있다고 생각했습니다.

이 기록들은 스스로에게 회고가 되고, 언젠가 이직을 준비하게 된다면 나를 설명할 수 있는 자료가 될 수도 있을 것입니다. 코드는 보여줄 수 없지만, 문제를 어떻게 바라보고 풀어왔는지는 전달할 수 있으니까요.

 

그리고 "주니어 개발자가 사수 없이 처음 해보는 앱을 혼자 개발한다"는 상황이 흔하지는 않겠지만, 제가 겪은 문제들 중 일부는 다른 개발자들도 충분히 마주칠 수 있는 것들입니다. 특히 React Native로 캐시백이나 커머스 앱을 만드는 분들에게는 직접적인 도움이 될 수도 있겠죠. 비슷한 상황에 놓인 누군가에게 도움이 되길 바라며, 기록을 남겨봅니다.

 

 

 

 

 

2. 프로젝트 개요

 

<뷰티 브랜드 캐시백 앱>

 

[주요 기능]

• 앱 내 인앱 브라우저에서 뷰티 브랜드몰 접속 및 구매
• 구매 추적: 주문번호 기반 브랜드 주문 내역 매칭
• 구매 확정/환불 등 상태 변화에 따른 캐시백 적립
• 적립된 캐시백의 현금 환급

 

[주어진 조건]

• 기간: 3개월(최소 기능 앱 출시)
• 인력: 나 혼자 (유일한 개발자, 디자인 팀은 존재)
• 요구사항 명세서: 거의 없음
• 가이드: 샵백 앱 참고해서 만들되, 최대한 확장성 고려(카테고리, 캐시백 정책, 해외 서비스 등)

좋게 말하면 자유도가 높았고, 솔직히 말하면 개발자 이상의 역할을 모두 맡아야 했습니다.

 

 

[내 백그라운드]

• 경험: 웹 개발 1년 (React, NestJS, PostgreSQL)
• 팀 프로젝트: 3개 (2주씩 오픈 후 종료)
• 앱 개발: 처음
• AWS/인프라: 처음

 

 

 

 

3. 기술스택 선택과정

 

이런 조건 속에서 어떤 기술을 선택해야 할지 고민하는 것이, 이 프로젝트의 첫 번째 관문이었습니다.

샵백 앱을 분석하고, 요구사항 명세서를 작성하고, ERD를 설계하고, 개발 일정을 나눴습니다. 그리고 기술 스택을 선택했습니다.

 

<기술스택>

• Frontend: React Native 0.81, Expo SDK 54
• Backend:  NestJS
• Web: Next.js (백오피스)
• DB: PostgreSQL 18
• Infra: AWS EC2, S3, RDS

 

[React Native + Expo SDK]

• 앱 개발은 처음이었지만, 지난 1년 동안 가장 익숙했던 UI 기술은 React였습니다. 3개월 안에 iOS와 Android를 동시에 출시해야 했기 때문에, 새로운 언어와 프레임워크를 학습하는 것보다 React 생태계를 확장하는 쪽이 더 현실적이라고 판단했습니다. 
• React Native 0.81은 2025년 7월에 릴리즈된 버전으로, 당시 안정성이 검증된 상태였습니다. 최신 버전도 있었지만, 프로덕션 앱을 만드는 입장에서 너무 최신 버전은 부담스러웠습니다. 커뮤니티 레퍼런스도 충분했고, Expo SDK 54와의 호환성도 좋았습니다.
• Expo는 빌드와 배포 과정의 부담을 줄이기 위함이었는데, 실제 기기 테스트 시 Xcode/Android Studio는 불가피했지만 전체 프로세스는 훨씬 수월했습니다.
• 이 선택은 이후 여러 제약과 트러블을 낳기도 했지만, 적어도 초반 개발 속도와 진입 장벽 측면에서는 합리적인 선택이었다고 생각합니다.

 

[NestJS + PostgreSQL + Next.js]

• 백엔드는 고민할 여지가 없었습니다. 1년간 써온 NestJS와 PostgreSQL을 그대로 가져왔습니다. 타입 안정성과 모듈 구조가 익숙했고, 캐시백처럼 단계별로 복잡하게 엮인 로직을 정리하는 데 적합하다고 판단했습니다.
• PostgreSQL 18은 당시 새로 나온 버전이었습니다. 약간의 위험 부담은 있었지만, 개발 기간을 고려하면 어느 정도 안정화될 거라 판단했고, 장기적으로 유지될 서비스라면 최신 버전의 성능 개선을 가져가는 편이 낫다고 생각했습니다.
• Next.js는 나중에 관리자 페이지(백오피스)나 랜딩 페이지가 필요할 때를 대비한 선택이었습니다. 실제로 나중에 백오피스를 만들 때 사용했는데, SSR/렌더링만 맡기고, 실제 비즈니스 로직은 NestJS에 그대로 두는 식으로 역할을 나눴습니다.

 

[AWS 인프라]

• 인프라는 처음이었기 때문에 운영 리스크를 줄이는 것을 우선했습니다. EC2, RDS, S3의 기본 구성으로 시작했습니다.
  • EC2: 애플리케이션 서버 호스팅
  • RDS: PostgreSQL 관리형 서비스
  • S3: 정적 파일 저장
• 복잡한 아키텍처는 일단 제쳐두고, "돌아가게 만드는 것"에 집중했습니다. CI/CD 파이프라인이나 모니터링 시스템도 초반엔 없었습니다. 하지만 개발이 어느 정도 진행되고 여유가 생기면서 이런 것들도 하나씩 추가했습니다. GitHub Actions로 자동 배포를 구성하고, CloudWatch와 Sentry로 모니터링을 시작했습니다. 이 과정도 주제로 다룰 예정입니다.

 

 

 

4. 마치며

 

완벽한 코드를 작성하진 못했습니다. 누군가 보기엔 "이런 것까지 고민했어?"라고 할 만한 사소한 부분들도 있을 겁니다.

하지만 그 순간순간 최선을 다해 고민했고, 가능한 한 많은 것들을 고려하며 만들려 노력했습니다. 그 과정 자체가 성장이었다고 생각합니다.

 

사수 없이, 처음 해보는 기술로, 짧은 시간에 혼자 만든 첫 앱. 그 과정의 솔직한 기록이 누군가에게 도움이 되길, 그리고 미래의 나에게도 좋은 자료가 되길 바랍니다.