[회고] 창업팀에서 백엔드 개발자로서 앱을 출시하며 느낀점

요즘 나는 중앙대학교 LINC 3.0 Start-up Members 학생 창업팀인 '텔링어스'에서 개발팀장 겸 백엔드 개발자로서 일하고 있다. 프로젝트 선에서 끝내는게 아닌 실제로 출시하고 유저들이 사용하며 조금의 수익성까지 생각하고 있는 든든한 친구이자 동료들끼리 모인 팀이다. 돈을 받고 하는게 아닌, 20대 젊은 시절의 열정만으로 모인 팀이다. 이번에 완성도가 좀 떨어지긴 하지만 기간을 더 미루면 루즈해질수도 있다고 판단해 우선 2차 기능까지만 구현하고 앱스토어 출시했다. 1번의 간단한(?) 리젝 후에 릴리즈에 성공했지만 9월 15일에 코드 리팩토링 및 2.5차 기능까지 릴리즈 후 본격적으로 마케팅하기로 해 아직까지는 많은 유저들은 없다. 하지만 우리 멤버들만 있는게 아니라 외부인도 꽤 들어오긴 한 것 같다 (아마 팀원들이 릴리즈 성공했다고 인스타에 올려서 그런 것 같다). 혹여나 궁금한 사람들을 위해 링크를 남겨본다!

 

https://apps.apple.com/kr/app/%ED%85%94%EB%A7%81%EB%AF%B8-%EB%82%98%EB%A5%BC-%EA%B9%A8%EB%8B%AB%EB%8A%94-%EC%8B%9C%EA%B0%84/id6448701604

‎텔링미 : 나를 깨닫는 시간

 

<아이폰이 아닌 사람들을 위한 웹 URL>

https://tellingme.co.kr/

텔링미 | 진정한 나에 가까워지는 저널링 다이어리

 

어찌됐든 앱을 성공(?)적으로 출시하며 이런저런 느낀바가 많기에 이들을 까먹기 전에 회고록으로 정리해보고자 한다. 개발 내용뿐만 아니라 비개발적 내용이라도 내가 개인적으로 느꼈던 점들을 정리해보도록 하겠다:)

 

😢 앱 스토어 출시는 생각보다 깐깐하다

나는 이때까지 웹 서비스만 출시했기에 앱 스토어에 어플을 출시하는 것은 처음이다. 웹은 별다른 제약이 없는 반면, 앱 스토어는 성공적으로 출시하려면 꽤 많은 것들을 생각해야 한다. 우선 앱 스토어에 어플을 제출하면 바로 되는 것이 아니라 약 24시간을 기다려서 허가(?)를 받아야 출시할 수 있다. 리젝 사유를 모두 리스트업 하진 못하고 내가 가장 신경썼던 부분을 간단하게 하게 말하자면, 

 

1. 소셜로그인

요즘 사실 소셜로그인 기능이 없는 어플이 드물 정도로 보편화된 기능이다. 일반 사람들이라면 보통 카카오, 네이버, 구글 등을 많이 사용할 것이다. 하지만 앱스토어에 출시하기 위해선 '안쓰더라도' 애플 소셜로그인 기능이 필수로 존재해야 한다. 이를 위해서 Apple Developer에 의무적으로 개발자 계정을 등록해야한다. 상당히 귀찮은 과정이었지만 기능 구현을 하며 애플 소셜로그인을 몇번해보니 꽤 편한 것 같기도 하다(??)

 

2. 소셜로그인 탈퇴

일반적인 회원가입 서비스를 진행하고 회원탈퇴는 어떻게 진행할까? 나도 많은 프로젝트를 해보진 않아서 잘은 모르지만, 보통 '회원(USER, MEMBER)' DB의 특정 컬럼(status)를 바꾸거나 아니면 회원 DB를 삭제할 수도 있겠다. 우리 서버팀에서도 처음에 회원 탈퇴 요청이 오면 회원 DB의 특정 컬럼을 바꾸고 회원 탈퇴 시간을 저장했다. 하지만 애플 소셜로그인을 진행할 경우 애플 서버에 소셜로그인을 요청하게 되는데 이 과정에서 authorizationCode와 identityToken을 받는다. 회원탈퇴할 때, 이 값들을 만료시켜야 애플에서 성공적으로 회원탈퇴가 되는 것이므로 만약 이런 값들을 만료시키는 로직이 없을 경우 리젝을 받는다고 한다. 

https://kitaees.tistory.com/45

애플 소셜로그인 탈퇴 구현 (Spring, JAVA)

이 회원탈퇴 과정이 나는 너무 재밌었고 인상깊어서 블로그에 구현 과정을 정리해놨다. 궁금한 사람들은 참고해보면 좋을 듯 하다!

 

3. 회원가입 정보

또 회원가입 관련이다 ㅋㅋㅋㅋㅋㅋ ㅠ 하지만 또 나올 수 밖에 없는 이유는 우리 팀이 아마 가장 공들인 부분 중 하나가 회원가입이라 내 기억에도 강렬하게 남는 듯 하다. 우리 텔링미 서비스는 소셜로그인 진행 후 서비스 이용을 위해 몇가지 정보를 추가적으로 입력 받는다. 예를 들어 생년월일, 닉네임, 고민 등을 입력받는데 애플에서는 이 '개인정보'에 상당히 민감한 느낌이었다. 서비스 이용에 직접적으로 관련이 없는 정보이면 '필수 입력'을 지양시키는 편이고 이는 곧 리젝 사유로 될 수도 있다. 실제로 우리의 리젝을 보면

이렇게 나오는데 부족한 영어로 대충 해석을 해보자면, 서비스를 사용하는데 직접적으로 필요하지 않은 개인정보들은 선택적으로 받거나[Optional] 지우는 것[Remove] 하는 것을 권하고 있다. 하지만 우리 서비스는 이미 이러한 사항들을 알고 있었기에 위 사진에 나오는 생년월일과 성별은 이미 Optional로 받고 있었고 '건너뛰기' 기능이 존재했었다. 아마 심사관님이 못보고 지나치신 듯 하다. (이미 있다고 reply 드렸더니 통과했슴). 하여튼 기획자와 개발자 입장에서 내가 출시한 서비스를 사용하는 유저들이 어떤 사람인지, 목표한 타겟층과 맞는 사람인지 궁금한건 당연한거라 생각하지만 이러한 리젝을 피하기 위해선 Optional하게 받아야하는 것을 알고 있으면 좋을 듯 하다!

 

4. 생각보다 깐깐하지만 생각보다 괜찮(?)

예전에는 일주일씩 심사를 했지만 요즘에는 24시간이면 된다. 실제로 우리 서비스도 24시간만에 1번의 리젝과 1번의 통과를 받았다. 빨리되는 만큼 또 사람이 하는 만큼 요즘에는 잘 넘어가는(?) 추세인 것 같다. 실제로 우리가 봤던 타 서비스도 애플 소셜로그인이 없어도 통과했었고 우리도 몇가지 리젝 사유를 고민하다가 에라 모르겠다라고 제출했었지만 다행히 통과했다. 크리티컬한 것들만 아니면 요즘에는 잘 통과하는 것 같다.

 

😢 운영계와 개발계를 나누는 과정은 너무 힘들다

프로젝트 선에서 끝내는 것이 아니고 계속 기능을 추가적으로 개발하고 릴리즈하기로 했기에 운영계와 개발계를 나누는 것이 필수였다. 여기서 우리 팀에서 말하는 운영계란 서비스를 출시하고 실제 유저들이 사용하는 서버와 DB를 말한다. 반면 개발계는 우리 텔링어스 팀이 기능을 개발하고 또 QA하기 위해 사용하는 곳이다. 간단하게 말하면 운영계는 정말 조심스럽게 사용해야하는 곳! 개발계는 상대적으로 막(?) 써도 되는 부분이다. 기존에 있던 서버와 DB는 유저가 몰릴 것에 대비해 aws ec2의 사양을 t2.medium으로 올리고 운영계로 쓰기로 했다. 그러면 새로운 서버와 DB를 구축해야 하는데 이 일련의 과정들이 너무 귀찮았고 힘들었다. rds, ec2 생성 및 SSL 인증서부터 도메인 연결 등 해야하는 것이 너무나 많았고 또 개발계가 생김에 따라 CI/CD 파이프라인도 새로 설계해야했기에 힘들었지만 제대로 된 서비스를 운영한다는 느낌과 성장한다는 느낌을 받았기에 참고했다.

 

우리 서비스의 기존 CI/CD 파이프라인을 간단하게 보여주자면 

 

 

 

위 사진으로 설명할 수 있는데, 'main' 브랜치에 코드를 push 하면 GitHub Actions를 통해 자동적으로 build 파일을 생성하고 이를 AWS S3로 Zip 파일로 전달한다. 이 Zip 파일을 통해 AWS CodeDeploy에서 jar 파일을 배포하게 되고 EC2에서 서버가 돌아가게 되는 것이다. 이런 기존의 파이프라인에서 'develop' 브랜치가 추가되었다.

 

 

develop 브랜치가 추가되면서 2개의 브랜치를 사용하게 되었는데 말 그대로 main이 운영, develop이 개발이다. 위 파이프라인 방식은 그대로 가져가되, develop 브랜치에서 구현한 기능 혹은 발생했던 에러에 대해 충분히 개발하고 QA를 진행한다. 충분한 QA가 없이 main에 올라가게 되어서 에러가 발생하면 DB에 값이 꼬일텐데 이는 최악의 상황이라고 생각한다. 왜냐하면 코드는 개발자가 고치면 되지만, 이미 꼬여서 들어간 DB를 잡는 건 거의 불가능에 가깝기 때문이다. 어떤 테이블의 어떤 컬럼에 어떤 값이 들어갔는지를 파악하기는 할 수도 없을 것 같고 하기도 싫다. 그래서 충분한 QA를 돌리고 난 뒤에 문제가 없다고 판단되면 이를 main 브랜치에 merge 한다. 그러면 자동적으로 Github Actions를 통해서 ec2에 배포를 해준다. 여기서 전이랑 달라진 점은, 기존에는 배포를 하고 나면 자동으로 서버단에서 deploy.sh 파일을 돌려 이전 버젼의 스프링부트를 종료하고 새로운 스프링부트를 돌려준다. 하지만 우리는 안정성을 위해서 조금 귀찮더라도 수동으로 이를 하기로 했고 deploy-dev.sh, deploy-prod.sh 파일을 따로 두고 코드 푸시를 할 때마다 ec2 서버에 들어가서 스크립트 파일을 실행시켜준다. 이렇게 운영계와 개발계 파일을 나누는데 성공했고 지금까진 성공적으로 서비스를 운영(?)하고 있다. 

 

👊🏻 창업이라는 경험 생각 이상으로 값지다

사실 나는 처음에 이 팀을 합류할 때 '창업'이라는 생각으로 들어오지는 않았다. 당시 나는 취업 준비를 위한 프로젝트 포폴용으로 들어왔다. 하지만 약 4~5개월 동안 창업팀으로 일하며 너무나 많은 것을 배웠고 지금의 난 단순한 프로젝트 포폴용이 아니라 진심으로 텔링미 서비스에 몰입하고 있다. 

 

 

우리 팀은 총 13명으로 서비스기획, 컨텐츠기획, 마케팅, CX, 디자인, 프론트엔드, 백엔드, iOS 등 각자의 역할에 충실한 팀원들로 구성되어 있다. 뼛속까지 개발자인 나한테는 다양한 기획자들과 가깝게 일할 수 있는 너무나 좋은 경험이었다. 실제로 기획팀과 함께 일하며 좋은 인사이트를 많이 얻기도 했고 학생 창업유망팀 투자 같은 색다른 활동을 할 수 있었다. 또 논외로 서버 개발자 입장에서 aws 비용을 걱정하지 않고 마음껏 개발하는 것도 소확행이라고 생각한다 ㅎ

http://festival.u300.kr/cms/process/invest/view.asp?c_show_no=71&c_check_no=64&c_relation=809&c_relation2=903&c_team_no=5423 

2023 학생 창업유망팀 300 네트워킹 데이

 

마음이 맞는 친구들과 매일 출근해서 같은 사무실에서 일하고 때로는 출시를 위해 밤을 새는 이 열정 넘치는 활동들이 너무 마음에 들었다.

물론 이대로 취업활동을 안하고 창업으로 빠지는 것은 아니지만 20대 젊은 시절 한번쯤은 이렇게 열정적으로 마음이 맞는 사람들과 모여 하나의 서비스를 출시해보는 것이 좋다고 생각이 들었다.

이렇게 장난아닌 장난도 치며(실제로는 다들 반말씀), 공동의 목표를 향해 나아가다 보면 동기부여도 얻고 결국에는 다같이 성장해있을거라 생각하기에 '창업'이라는 워딩에 집중하기보다 하나의 서비스를 출시해보는 도전을 하기를 강력하게 추천해본다!

 

🤙 앞으로의 방향성이 확실해짐

서비스를 출시하고 마지막으로 느낀 점은 방향성이 확실해졌다. 개발자로서 또 창업팀으로 목표한 유저 수에 도달하고 싶어졌다. 우리팀에서 장난식으로도 말하는게 유저 수 '10000명'이다. 서비스를 출시하고 아직 유저 수 가 많이 적지만 아래 사진처럼 꾸준히 KPI 지표를 기록해오고 있다.

 

 

10000명을 목표로 달려가며 나오는 개발적인 이슈를 해결하며 성장하고 텔링어스 팀의 목표인 '모두가 주체적인 삶을 살아가는 세상'을 만들어보고자 한다. 팀에 도움이 되기 위해 서버개발자로서 어떻게 해야할까를 요즘 고민 중이고 많은 트래픽을 감당하기 위한 모니터링 툴(그라파나 같은)을 도입해볼까 생각중이다. 또 사실 개발 팀장이라는 역할 아닌 역할을 맡으며 프론트엔드 개발자, iOS 개발자들에게 어떻게 API를 짜줘야 편할지 고민하며 코드를 구현하려고 노력하고 있다. 

 

 

🤔 마무리

이렇게 회고록을 쓰는게 이제 어느정도는 습관이 되면서 편해졌다. 처음에는 마냥 어렵고 귀찮았지만 회고록을 쓰며 그간의 과정을 되돌아볼 수 있고 또다른 동기부여를 주는 것 같다. 이렇게 4-5개월 간의 느낀점들을 글로 정리하니 뿌듯하고 좋은 것 같다.! 끝!

 

 

 

참고 사진 (감사합니다:)

- https://velog.io/@bluewind8791/Github-Actions

Github Actions CI + CodeDeploy로 CI/CD 구현하기