이 글은 사이드 프로젝트 회고 2편입니다.
👉 1편: 런칭부터 검색 유입까지 – 유입 만들기까지의 모든 실험
서비스를 만들다 보면 멋진 기능보다도
사소한 실수 하나를 얼마나 덜어주느냐가 더 중요할 때가 많다.
인스타그램 데이터 다운로드 과정은 생각보다 단계가 많고 중간에 버튼 하나만 잘못 눌러도 결과 파일이 달라진다.
그래서 처음 배포했을 땐 사용자들이 잘못 만들어진 파일을 올리면서 에러가 나는 경우가 많았다.
지금 돌이켜보면 그건 사용자 잘못이라기보다
그 실수를 미리 막아주지 못한 내 서비스 구조의 문제였다.
그래서 나는 거의 매일 이벤트 로그와 에러 로그를 보며,
실패한 흐름을 하나씩 뜯어 고쳤다.
그 결과
3월 5일부터 5월 5일까지 총 63,479명이 방문했고
그중 31,996명이 분석을 완료했다.
첫 달 전환률은 28%였지만,
지금은 31,996 ÷ 63,479 ≈ 50.4%
두 배 가까이 개선된 셈이다.
사용자 경험 개선을 위한 디테일한 작업들
다음은 실제로 에러 로그를 분석하며 개선했던 대표 사례들이다.
1. HTML 파일도 분석 가능하게 만들기
초기엔 JSON 파일만 분석을 지원했지만,
인스타그램에서 데이터를 다운로드할 때 기본값이 HTML이라
1달 동안 생각보다 많은 사용자가 HTML 파일을 업로드하며 에러가 났다.
가이드엔 분명히 JSON을 선택하라고 작성했지만
직접 써보면 이런 디테일은 사용자 입장에서 쉽게 놓칠 수 있다.
초기엔 그냥 에러 메세지만 보여줬던 걸 HTML파일도 분석 가능하게 기능을 추가했다.
이후 실제 사용 데이터를 보니 의미가 있었다.
최근 한 달(4/5~5/5) 기준:
- JSON 파일로 분석 완료한 사용자: 27,000명
- HTML 파일로 분석 완료한 사용자: 1,800명
대부분은 가이드에 적힌 대로 JSON 형식으로 잘 선택했지만,
그중 1,800명은 HTML 파일을 업로드했다.
처음엔 "가이드를 안 읽은 사용자 탓"이라 생각했지만,
그런 실수까지 덜어주는 게 전환율을 높이는 핵심이라는 걸 느꼈다.
2. 손상된 ZIP 파일 - Android + 네이버 앱
한 달간 세 번째로 많이 발생한 에러는 Can't find end of central directory..였다.
이건 보통 ZIP 파일이 손상됐을 때 발생하는 에러라, 처음엔 JSZip 라이브러리의 버그인가 싶었다. 실제로 직접 GitHub에 이슈를 올리기도 했다.
근데 이상했다. 에러가 발생한 로그 대부분의 디바이스가
Mobile 94% / Android 96%
환경 특성에 문제가 있다고 생각해서 직접 테스트를 반복해서 원인을 찾아냈다.
Android 기기에서 ‘네이버 앱’을 기본 브라우저로 설정한 경우,
인스타 ZIP 파일을 다운로드할 때 파일이 손상되는 문제였다.
(심지어 알집에서도 풀리지 않는 진짜 손상)
그래서 이 에러가 발생하면 안내 메시지를 추가해 사용자에게 다른 환경에서 다운로드하도록 안내했다.
3. 개별 파일 업로드 지원
일부 사용자는 '기기에 다운로드'가 아니라 '전송 대상'을 선택해서 Google Drive같은 곳에 저장하는 경우도 있었다. 이 경우에는 ZIP이 아닌 풀린 JSON 파일이 개별로 저장 되며, 사이트에서는 ZIP만 업로드 가능했기 떄문에 파일을 못 올리는 상황이 발생한다.
→ 그래서 이런 사용자를 위해 개별 파일 분석 전용 페이지를 따로 만들었다.
4. Facebook 파일 업로드 방지
에러 로그 중 "facebook_"으로 시작하는 파일명이 종종 보였다.
처처음에는 어떻게 페이스북 파일을 올리는거지? 싶었는데, 나중에 본계정으로 테스트하면서 원인을 찾았다.
인스타 계정과 페북이 연동되어 있으면
인스타에서 정보 다운로드 시 '페이스북' 데이터를 선택할 수도 있다.
해당 케이스도 명확히 감지해서 가이드 + 에러 메시지에 명시적 안내를 추가했다.
5. 모든 정보 데이터 파일도 분석 가능
처음엔 생각 못 했는데, 이벤트 로그에서 용량이 큰 ZIP 파일이 보이기 시작했다.
확인해보니 ‘사용 가능한 모든 정보’를 선택해서 받은 파일이었다.
처음엔 이 파일들도 분석이 안 됐지만, 예외 처리를 확장해 이 경우도 분석 가능하게 만들었다.
실제로 다른 유명한 서비스에서는 HTML파일을 올리거나, '사용 가능한 모든 정보'를 선택해서 파일을 다운로드 했을경우 아래처럼 에러 메시지를 보여준다:
내 서비스는 사용자 실수를 탓하는 대신 서비스가 유연성을 갖추도록 개선을 했다 😎
에러를 줄이려는 노력
단순 성공 수보다 성공 대비 에러 비율을 보면
얼마나 안정성이 올라갔는지 더 명확하게 드러난다.
| 기간 | 분석 성공 | 분석 실패 | 에러 비율 (실패 ÷ 성공) |
|---|---|---|---|
| 3/5 ~ 4/4 | 3,700건 | 479건 | 12.9% |
| 3/5 ~ 5/5 | 31,996건 | 1,500건 | 4.7% |
📊 첫 달 로그 (3/5 ~ 4/4)
📊 두 달간 누적 로그 (3/5 ~ 5/5)
서비스 초기엔 분석 성공 100건 중 약 13건이 실패했지만
지금은 100건 중 4~5건만 실패할 정도로 안정성이 개선됐다.
이건 단순히 에러 메시지를 수정한 게 아니라
그 실패 흐름을 하나씩 따라가며, 구조 자체를 손 본 결과였다.
참고로, 실패한 요청 중 대부분은 인스타그램과 무관한 ZIP 파일을 업로드해서 발생한 경우였다.
검색 유입도 늘었다
전환율 개선과 함께, 검색 유입도 꾸준히 성장하고 있었다.
특히 '인스타 언팔 확인 사이트' 같은 주요 키워드 검색 시 내 서비스가 상위에 노출되기 시작했다.
📈 '인스타 언팔 확인 사이트' 검색 시 내 서비스가 1위에 노출 (BlackKiwi 기준)
📲 모바일 앱 배포까지
모바일 사용성을 높이기 위해
Flutter WebView로 감싼 Android 앱으로도 제작해 Play 스토어에 배포했다.
📱 Google Play 스토어에서 다운로드
💻 GitHub 코드 보기
마무리하며
이 프로젝트는 단순히 기능만 구현하는 게 아니라
사용자가 실수하더라도 결과를 볼 수 있도록 만드는 방법을 끝까지 고민한 과정이었다.
매일 이벤트 로그를 보면서 실패한 흐름을 하나하나 되짚었고
"왜 실패했을까?"를 계속 고민하며
내가 놓친 지점을 찾아내고 개선하는 과정을 반복했다.
그 과정에서
- Vercel Pro 요금 $20
- 이벤트 로그 과금
- 매일 로그 정리하고 확인하는 시간
꽤 많은 리소스를 들였지만, 그만큼 얻은 것도 많았다.
전환률은 28%에서 50%로,
실패율은 12.9%에서 4.7%로 줄었다.
꼭 대단한 기능이 아니어도
작은 실패 하나라도 줄여가는 과정 자체가 의미 있는 일이었다고 생각한다.
그리고 이 프로젝트를 통해
실무에선 직접 다뤄볼 기회가 없었던 SEO도 처음으로 제대로 설계하고 적용해볼 수 있었다.
검색 유입을 높이기 위해 SEO관련 책과 다양한 기술 블로그를 참고했고
검색 키워드 선정 → 메타데이터 구성 → sitemap/robots 설정 → 백링크 확보까지
SEO의 주요 요소들을 하나씩 실제 서비스에 적용해보았다.
그 결과
‘인스타 언팔 확인’, ‘언팔로워’ 같은 키워드로
구글/네이버 상위 노출에 성공했고
지금도 하루 평균 1,500명 이상이 꾸준히 유입되고 있다.
실패를 줄이고, 전환을 높이고, 유입 구조까지 만들면서
단순히 만드는 개발자에서, 사용자와 연결되는 제품을 고민하는 개발자로 한 걸음 더 나아갈 수 있었다.
