728x90

개인프로젝트를 앱스토어, 플레이스토어에 둘 다 출시 했다.

 

앱 명은 인테리어를 하면서 사람들이 소위 호구를 많이 당하는데, 구를 명으로 만들고자 호빵으로 지었다.

 


기획부터 프론트엔드(웹, 앱), 백엔드, 인프라까지 혼자 맡아서 하다 보니 퇴근 후 작업이 매우 힘들었지만, 값진 경험이었다. 게다가 실제 유저들까지 유입되어 보람을 느꼈다. 현재 유저는 총 81명으로 (가족과 지인을 제외한 수치) 특별히 돈을 안 들이고 블로그 글 4개로 얻은 성과인 점을 감안하면 개인적으로 매우 의미 있는 숫자라고 생각한다.

혼자서 많은걸 하다 보니 UI/UX에 신경을 충분히 쓰지 못한 것 같다. 현업에서는 백엔드 개발을 하고 있고, 프론트엔드는 학교 과제나 개인 프로젝트를 통해 일부 경험해 본 것이 전부라 어려움이 있었다. 또한, 처음 해본 앱 개발이 가장 큰 난관이었다.

실제 유저가 유입되었으며, 전체 서비스 이용률은 약 30~40%였고, 회원가입 과정에서의 이탈률은 약 20%였다. 이를 기반으로 데이터를 분석해 보았다.

1. 유저의 UI에 대한 불신
앱이 렌더링되는 디바이스 화면에 맞게 CSS가 제대로 적용되지 않았다. (출시 후 조금씩 조정하자는 생각으로 미뤄두었다. 사실상 선택과 집중을 한 것이었다고 생각한다. 한정된 시간 속에서 익숙한 백엔드 쪽에 더 공을 들인 것이 가장 큰 이유였다.)

2. 불편하고 친절하지 않은 UX로 인한 불신
예를 들어, 최초 회원가입 후 유저의 휴대폰 인증 과정에서 인증번호 실패 시의 대처 전략이 미흡했다. 렌더링되는 디바이스에 맞게 오류 메시지가 보여야 하는데, 너비가 좁은 디바이스에서는 해당 메시지가 보이지 않아 유저가 당황하고 이탈한 것으로 판단했다.

 

 

결론

위 문제점들을 개선한 결과, 유저 이탈률이 감소하고 전체 서비스 이용률이 증가하는 긍정적인 변화를 경험했다.

'난중(개발)일기 > [프로젝트] 호빵' 카테고리의 다른 글

서비스 시작 후 1달차 회고  (1) 2025.03.23
728x90

RN 으로 배포 후 카카오로그인을 했는데 자꾸 안 됐다.

 

로그를 보니 해시키값이 문제인 것 같았다.

 

그래서 배포할 때 사용한 배포용 keystore 해시키를 추출해서 사용 했는데 안 됐다. (다음과 같이)

keytool -exportcert -alias androiddebugkey -keystore ~/.android/release.keystore -storepass 123456 -keypass 123456 | openssl sha1 -binary | openssl base64

 

이런식으로 해도 안됐다.

 

그래서 GooglePlayConsole > 앱 무결성 > Play 앱 서명 >  앱 서명 키인증서 > SHA-1 인증서 지문 값을 복사 해서 Base64로 컨버팅 한 후 등록 하니까 됐다. 

 

사용 한 컨버터는 다음과 같다. https://tomeko.net/online_tools/hex_to_base64.php?lang=en

728x90

https://ydontustudy.tistory.com/207

 

CGI (Common Gateway Interface)

CGI 란서버와 애플리케이션 간에 데이터를 주고받는 이 프로세스 또는 규칙을 공통 게이트웨이 인터페이스(CGI)라고 한다. 동적인 컨텐츠를 생성할 수 있는 프로그램을 갈망하는 사람들의 요구로

ydontustudy.tistory.com

이 글에 이어서 CGI를 Servlet 과 비교 해본다.

해당 글을 요약하자면, CGI는 웹 서버와 외부 프로그램 간의 통신을 위한 표준 인터페이스이다. 각각의 요청마다 새로운 프로세스가 fork 되는데 이는 서버 리소스가 많이 들고, 동시처리가 어려운 치명적인 단점이 있다. 그래서 이를 개선한 Fast CGI 가 나와서 프로세스 재사용이 가능해졌다. 그러나 여전히 부족한 부분이 많아서 각 플랫폼마다 각자의 웹 서버 기술을 가지게 된다.

 

CGI는 동적인 웹 서비스를 할 수 있게 하는 새로운 페러다임을 소개한다. 그러나 단점이 존재하고 이를 보완하기 위해 Fast CGI라는게 나왔지만 일부만 해결된 정도이다. 그래서 각 플랫폼에서 CGI 의 아이디어를 딴 웹서버가 탄생한다. 이 중에서 CGI와 JAVA의 Servlet을 비교 해보겠다.

 

 

프로세스 vs 쓰레드

CGI의 가장 큰 단점은 매 요청마다 새로운 프로세스를 생성하는데 반면 Servlet은 멀티스레딩을 사용한다. 하나의 프로세스 내에서 여러 스레드를 생성하여 요청을 처리한다. 이는 CGI에 비해 훨씬 적은 시스템 리소스를 사용하며, 더 빠른 응답 시간을 제공한다.

 

 

생명주기 관리 측면

CGI 프로그램은 요청이 들어올 때마다 실행되고 종료된다. Servlet은 한 번 로드되면 메모리에 상주하며, 여러 요청을 처리할 수 있다. 이는 Servlet의 초기화 시간을 줄이고 성능을 향상시킨다.

 

 

이식성

Servlet은 자바의 "Write Once, Run Anywhere" 철학을 따른다. 따라서 다양한 플랫폼에서 실행될 수 있다. 반면 CGI는 플랫폼에 종속적일 수 있다. 자바의 Servlet은 JVM 위에서 돌아가기 때문에 플랫폼에 독립적이라 클라우드 환경에서도 쉽게 적용이 가능하다. 반면 CGI는 스크립트 작성방식, 프로세스 생성방식 등 플랫폼에 종속적이다.

+ Recent posts