🚀 베타 테스트 회고_2년차 개발자

2025. 12. 3. 10:04·개발일지/개인 회고

0️⃣ 시작하며 — 이번 베타 테스트는 어떤 경험이었나?

베타기간 : 11월 ~ 1월!
내가 만든 서비스가 실제 사용자에게 닿는 첫 순간이었다.
  • 이전 회사에서도 서비스를 운영해본 경험은 있었지만,
    기획 → 개발 → QA → 베타 테스트까지 전 과정을 직접 주도한 것은 이번이 처음이었다.
    그래서 기대 반, 걱정 반이었다.
  • 특히 내부가 아닌 실제 사용자들의 피드백을 직접 마주하게 된다는 사실이 계속 신경 쓰였다.
    베타 테스트 시작 당일, 엄청 떨었던 것 같다.
    오픈 직후에는 로그 화면만 붙잡고 사용자 행동을 추적했던 기억뿐이다.
    “제발 큰 문제만 없기를…” 이런 마음으로 하루 종일 모니터 앞에 앉아 있었다.
  • 그리고...! 2월부터 정식오픈을 해서 운영중에 있다.

1️⃣ Before Beta — 준비 과정

가장 불안했던 건 “내 코드”가 아니라 “외부 환경”이었다.
  • 외부 API 연동 캐싱 문제
  • 인앱 환경의 불명확함
  • iOS, 브라우저, 인앱 등 환경변수에 따라 다르게 발생하는 에러
  • 그리고 무엇보다 "내부 데이터/API가 아닌 외부 환경에서 터지는 에러는 통제하기 어렵다"는 점…

그래서 할 수 있는 건 최대한 많은 대비책을 세우는 것뿐이었다.

  • 캐싱 도입 — API 부하를 줄이고 조회를 안정화
  • 서버 콜백 구조로 변경 — 인증 흐름 통일
  • 사용 환경별 가이드 제공
  • Fallback 처리 강화 — 오류가 나도 사용자가 막히지 않도록

어떻게든 “문제 발생 확률을 낮추는 것”에 집중했다. 그 다음은 솔직히 운이라고 생각했다.(제발 안터지게 해주세요)


일정 조율 — 팀 간 우선순위 충돌

영업팀은 금요일 오픈을 원했고, 나는 수요일 오픈을 요청했다.  혼자 모든 장애 대응을 해야 했기 때문이다.

다행히 영업팀이 내 상황(혼자 개발/운영하는 상황)을 많이 이해해줘서
결국 수요일 베타 오픈으로 조율할 수 있었다.
그 결정은 정말 탁월했다. 금요일에 열었으면 큰일 났을지도 모른다 ㅎ..🫠


테스트 그룹 구성형식상 “베타 테스트”이긴 하지만
실제로는 정식 출시 직전의 가오픈에 가까운 분위기였다.
그래서 더 긴장됐고, 더 책임감도 컸다.

  • 이번 베타는 내부 QA만 하는 진짜 작은 테스트가 아니라,
    서비스를 운영하는 운영팀이 실제로 관리하고 있는 사용자(테스터그룹) 그룹을 대상으로 진행됐다.
  • 일정 조율에서도 작은 논쟁이 있었다.
    영업팀은 금요일에 베타를 시작해 주말 방문자 최대치를 노리고 싶어 했고,
    나는 혼자서 모든 장애 대응을 해야 하기에 월~수 오픈을 강하게 요청했다.
  • QA와 내부 테스트를 진행하면서 분명한 기술적 리스크들을 이미 알고 있었다.

2️⃣ During Beta — 실제 운영 중

예상했던 에러, 예상치 못한 반응들가장 걱정했던 부분에서 정확하게 문제가 발생했다.50여 건의 CS 중 90% 이상이 바로 이 문제였다.
원인은 생각보다 단순했다.

 

🔧  1) 브라우저 캐시!!!


정말정말 다행스럽게도,
영업팀에서 CS 전체를 담당해주시고,

나는 원인 분석과 대응 가이드를 정리하는 역할에 집중할 수 있었다.

덕분에 비교적 빠르게 안정화됐다.


🔧 2) DB 필드 길이 문제 … 20자는 부족했다..! 외국인 이름은 예상보다 훨씬 길다.
(진짜였다… 20자를 훌쩍 넘는 이름이 존재한다…)


🔧  3) 긴급 수정 —  다행히 대부분 커버 가능

서버를 내리지 않고도 바로 수정 반영이 가능한 구조를 잡아둬서, 잠수함 패치(?)도 여러 번 진행했다. 🛥️
(잠수함 이모티콘이 없네…)


📈 4) 예상보다 뜨거웠던 반응

  • 예상보다 많은 문의
  • 초기 목표치를 빠른속도로 달성 (회원가입 기준)

폐쇄형 베타였고, 대부분 영업팀에서 관리하던 인원이긴 했지만,
그래도 이 정도 초기 반응은 정말 큰 힘이 됐다.


3️⃣ What Went Well — 잘된 점

👍 1) 초기 온보딩 과정은 안정적으로 작동

외부 환경 영향을 받은 일부 사례를 제외하면,
대부분의 사용자들이 한 번에 문제 없이 초기 설정을 마쳤다.

‘입력 과정이 번거롭다’는 피드백도 거의 없었고,
예상보다 훨씬 부드럽게 넘어간 구간이었다.


🎨 2) UI와 전체적인 사용 흐름에 대한 긍정적 반응

몇몇 사용자들이

“색감이 편하다”, “구성이 직관적이다”
라는 반응을 주었는데,
기능 중심으로 개발했음에도 시각적 부분에서 만족감을 표현한 점이 인상적이었다.

 


🗂️ 3) 운영 도구 관점에서 필요한 기능들이 보이기 시작함

테스트가 진행될수록
운영팀이 어떤 데이터나 화면을 우선적으로 필요로 하는지 자연스럽게 명확해졌다.


🔭 4) 다음 고비가  보이기 시작

아직 사용자들이 본격적인 입력 기반 기능까지 도달한 비율은 높지 않지만,
구조적으로 다음 큰 분기점이 될 영역은 이미 파악하고 있다.

이 구간은

  • 입력 요소가 다양하고
  • 사용자 행동 패턴이 많이 갈릴 수 있고
  • 디바이스/환경 차이도 크게 영향을 줄 가능성이 있어서

베타 중 가장 많은 배움이 생긴 부분이었다.

 


베타 기간 동안 영업팀과 여러 차례 회의를 진행했다.
단순한 오류 공유나 일정 조율을 넘어, 이 서비스가 앞으로 어디로 가야 하는지를 이야기하는 시간이었다.

이 회의들을 통해
우리는 단순히 베타를 마무리한 것이 아니라,

  • 서비스의 1차 검증을 끝냈고
  • 다음 단계 로드맵의 초안을 그렸으며
  • 정식 오픈 전 반드시 정리해야 할 과제를 명확히 정의했다.

4️⃣ What Went Wrong — 아쉬웠 점

📝 1) 트러블슈팅 기록을 충분히 남기지 못한 점

이슈는 빠르게 해결했지만,
과정이 충분히 구조화되어 남지 못했다.

그 결과, 같은 이슈가 최근까지도 반복되고 있다.
이 부분은 특히 아쉬움이 남는다.

 


🤝 2) 베타 목표의 명확성 부족

무엇을 우선 검증해야 하는지,
어떤 지표를 집중적으로 봐야 하는지에 대한 정의가 충분히 명확하지 않았다.

“운영하면서 보자”에 가까웠던 부분이 있었다

 


5️⃣ Learnings — 이번 베타에서 배운 점

 

  • 완벽보다 복구 가능성이 중요하다.
  • 외부 의존 구조에는 항상 Fallback이 필요하다.
  • 로그는 정말 중요하다.
  • 일정은 기술이 아니라 현실이다.
  • 혼자일수록 더 많이 공유해야 한다.

6️⃣ Next Steps — 베타 이후 계획

사용자 경험은 예상보다 나쁘지 않았다. 하지만 내부적으로는 재정비가 필요했다.

  • 요구사항 재정의
  • 페이지 구조 재설계
  • DB 구조 개편
  • 운영 편의 기능 추가
  • 데이터 기반 개선

이제는 실제데이터를 기반으로 수정할 수 있다는 점이 가장 큰 변화다.

 


7️⃣ Reflection — 개인적인 회고

 

이번 베타는 내 개발 인생에서 분명히 큰 경험이었다.

연차가 많지 않은 개발자가 기획부터 설계, 개발, 퍼블리싱, QA, 베타 운영까지 전 과정을 혼자 맡아본다는 건 흔치 않은 기회라고 생각한다.

그래서 기대도 컸고, 부담도 컸다.

오픈 직후에는 로그를 계속 확인했고, 문제가 생기지 않기를 바라며 하루를 보냈다. 그 긴장감은 쉽게 잊히지 않을 것 같다.


프로젝트와 서비스의 차이

그동안 공부하며 여러 프로젝트를 만들어봤지만, 이번 경험은 확실히 달랐다.

실제 사용자가 존재하고, 그 사용자의 흐름 안에 내 코드가 들어간다는 것.

문제가 발생하면 단순한 오류가 아니라 사용자가 바로 서비스를 버릴수 있다는 의미가 되었다.

그 책임감이 가장 크게 다가왔다.


1인 개발자로서 느낀 한계

기획, 개발, 퍼블리싱, 운영 대응까지 모두 맡다 보니 집중이 필요한 큰 작업을 진행하는 중에도 작은 요청과 긴급 수정이 계속 끼어들었다.

컨텍스트 전환이 반복되면서 사소한 실수가 발생하기 시작했고, 그때 스스로의 한계를 체감했다.

이번 베타는 기술적인 역량뿐 아니라 집중력, 체력, 작업 관리 방식까지 돌아보게 만든 시간이었다.


그래도 얻은 것

그럼에도 불구하고, 이 경험은 분명히 의미가 있었다.

“기능을 만드는 개발자”에서 “운영을 고려하는 개발자”로
조금은 시야가 넓어진 느낌이다.

문제를 줄이는 것보다 문제가 발생했을 때 어떻게 대응할지 설계하는 것이 중요할 수 있다는 것을 배웠다.

 


8️⃣ 한 줄 요약

서비스를 ‘만드는 것’과 ‘운영하는 것’의 차이를 배운 시간.

 

'개발일지 > 개인 회고' 카테고리의 다른 글

AI 공부하기🤖— 생각보다 애매했던 첫 수업  (0) 2026.03.02
2년차 회고 — 개발에 책임을 배우다 🥲  (0) 2026.03.02
서비스 정식오픈🎉  (0) 2026.02.25
개발 신입 ~ 1년차 회고🤔  (0) 2025.11.05
'개발일지/개인 회고' 카테고리의 다른 글
  • AI 공부하기🤖— 생각보다 애매했던 첫 수업
  • 2년차 회고 — 개발에 책임을 배우다 🥲
  • 서비스 정식오픈🎉
  • 개발 신입 ~ 1년차 회고🤔
yeah구리
yeah구리
백엔드를 공부하는 초심자입니다.
  • yeah구리
    개발일지_헤맨만큼 내땅이다
    yeah구리
  • 전체
    오늘
    어제
    • 분류 전체보기 (118)
      • 스파르타 부트캠프(spring) (75)
      • 스파르타 기술면접 (10)
      • 코딩연습 (0)
      • 항해 (10)
      • 개발일지 (8)
        • 개인 회고 (5)
        • 개발로그 (실무) (2)
      • 공부노트 (0)
      • 코딩테스트 (0)
        • 프로그래머스 (0)
        • 백준 (0)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    비전공개발자 #개발로그 #커리어
    X(Twitter) API #캐싱 #트러블슈팅 #개발
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.5
yeah구리
🚀 베타 테스트 회고_2년차 개발자
상단으로

티스토리툴바