Serendipity

더 전문적으로 돌아온 인스타그램 로그인 및 회원가입 여정- 코드스테이츠_PMB_14기 본문

PMB 아카이브/Daily

더 전문적으로 돌아온 인스타그램 로그인 및 회원가입 여정- 코드스테이츠_PMB_14기

김센잉 2022. 10. 12. 12:13

https://tpsdld.tistory.com/25

 

인스타그램의 로그인 및 회원가입 여정 - 코드스테이츠_PMB_14기

최근 트렌드는 인스타그램이지 않을까 싶다. 인플루언서들은 무조건 인스타그램을 쓰는 것은 물론이고 일반인들도 인스타그램을 즐겨 쓴다. 타 앱처럼 라이브나 콘텐츠를 통해 수익을 버는 것

tpsdld.tistory.com

지난 글에서 인스타그램의 로그인 및 회원가입 과정을 고객 입장에서 그려봤다. 각 과정을 겪으면서 고객이 볼 수 있는 UI, 클라이언트, 서버, DB가 각각 어떻게 보이는지와 작동할지 예상해봤는데 다시 한번 짚어보자.

 


인스타그램 로그인 및 회원가입 Flow Chart

고객이 인스타그램을 즐기기 위해서는 로그인 및 회원가입을 해야 한다. 이에 대한 Flow Chart를 간단하게 만들어봤다.

 

 


인스타그램 로그인 및 회원가입 UI

로그인 및 회원가입 -> 홈화면
페이스북 로그인 페이지
휴대폰 번호 또는 이메일 회원가입
개인정보 약관 동의 -> 친구 추천 화면

결국 어떤 경로를 거치든 간에 마지막은 홈화면이다. 심지어 페이스북은 비밀번호를 까먹었을 때 어떻게 해야 할지 갈피가 안 잡힌다. 이 부분은 과연 페이스북의 문제일까 인스타그램의 문제일까 생각해봤는데 아무래도 페이스북 문제인 거 같다. 실제 페이스북 앱을 켜서 해봤는데 비밀번호를 알 수 있는 방법이 없다. 그냥 앱을 삭제하거나 로그아웃 하지 말아야겠다.

 


인스타그램 로그인 및 회원가입 클라이언트, 서버, DB
클라이언트 개인 정보 기입, 회원가입, 로그인
서버 코드 전송, 사용자 인증, 페이스북 계정 확인, 이용약관/개인정보 약관 확인, 입력된 데이터를 DB로 전달
DB 회원 정보 저

로그인 및 회원가입 단계에서 DB는 서버사 호출하는 회원 정보를 가져다주거나 저장하는 것 외에 역할이 없다. 그렇기에 한 가지 역할을 하는 DB 말고 클라이언트와 서버를 중심으로 보면 된다.

 


2주라는 시간이 지났으니 이 글을 회고하며 수정해보자.

 

인스타그램의 Technical Flow Chart

우선 인스타그램의 유저가 할 수 있는 행동에 대한 Flow Chart는 직접 내가 인스타그램 웹 사이트에서 부계정을 만드는 과정을 담았기에 틀린 곳이나 빠트린 곳이 없다. PM에 대한 지식이 당시 글을 쓸 때보다 쌓였으니 배운 것을 반영하여 Technical Flow Chart를 만들 수 있다.

클릭하면 확대됩니다

 

인스타그램 회원가입을 하면서 알게 된 점은 '생일 정보'에 대해 검토를 하지 않아 현재 인스타그램에 부계정이 많다는 점이었다. 다른 이메일, 휴대폰 번호 등으로 가입을 하면 부계정을 만들 수 있는데 생일을 아무렇게 설정했지만 그냥 가입이 되었다. 이를 통해 생일 정보는 DB에서 정보 유효성 검토를 하지 않고 그냥 저장만 하고 관리한다는 것을 알았다.

 

Technical Flow Chart를 만들면서 새로 알게 된 점은 번호 코드에 대한 것이다. 유저가 번호 코드 인증을 위해 휴대폰 번호를 입력하면 서버에서 해당 번호와 랜덤 숫자 4자리를 DB에 저장한 뒤, 인증 번호가 담긴 문자를 유저에게 보낸다. 이때 문자 전송 API가 적용된다. 유저가 휴대폰으로 온 인증 번호를 입력한 후 인증 요청을 하면 DB에서 유저의 휴대폰 번호와 인증 번호를 대조한 뒤 맞다면 True를, 틀리다면 False를 리턴한다고 한다.

 

또, 알고 보니 이용 약관도 DB로 저장된다고 한다. 약관 테이블을 따로 DB에 저장하고 약관 정보를 관리한다. 단지 회원 정보와 같은 것들만 저장하고 관리하는줄 알았는데 약관 테이블이 따로 있다는 것에 놀라웠고 이전 글에서 자세하게 서칭하지 않은 것이 바보 같았다. 약관 테이블에는 기본 값인 약관코드, 약관명, 약관 내용, 필수 여부가 들어가는데 필수 여부 Y/N 중 N이 있다면 재동의 요청을 보낸다고 이해했다.

 


인스타그램의 클라이언트, 서버, DB

위 Technical Flow Chart를 통해 이전 글에서 다뤘던 클라이언트, 서버, DB를 수정할 수 있다.

클라이언트 서버에 요청하는 데이터 전송
요청하는 데이터: 신규 유저 로그인 정보, 회원가입 정보, 로그인 정보, 번호 코드, 약관 동의 내용
서버

클라이언트가 요청한 정보들을 DB에 전달 및 저장
재입력, 재동의 요청
번호 코드 전송
이용약관/개인정보 약관 확인
로그인 완료
DB 로그인 정보 저장 및 대조: 아이디, 비밀번호, 생년월일, 페이스북 연동 정보 등
정보 유효성 검토: 입력된 정보가 맞는지 검토
번호 코드 대조: 휴대폰 번호와 인증 번호 대조 후 True/False 전송
약관 필수 동의 대조: 필수 여부 대조 후 True/False 전송
회원가입 정보 저장: 휴대폰 번호, 이메일, 이름, 생년월일, 인증 번호, 약관 동의 내용, 페이스북 연동 정보 등

 


출처: BBC

지난 글을 회고하고 수정하면서 드는 생각은 이전에는 많이 부족했지만 지금은 많이 성장했구나다. 이전 글에서는 지금까지 계속 만들어왔던 유저 스토리에 관한 것만 하면 되겠거니 하고 만들고 클라이언트, 서버, DB에 대해서 정확하게 짚고 넘어갈 생각이 없었던 거 같다. 하지만 이번에 Technical Flow Chart를 제대로 만들면서 클라이언트, 서버, DB에서 어떤 일이 일어나는지 확인할 수 있었고 100% 정답은 아니겠지만 로그인 및 회원가입 과정에서의 작동을 알 수 있었다. 갈피가 안 잡혔던 서버와 DB에 대해서도 이해가 되었으니 앞으로 더 공부하고 발전할 일만 남았다.

 

2주 동안은 PM의 전문적인 업무에 대한 것이 아닌 PM과 함께 일하는 개발자의 업무를 수박 겉핥기식으로 해봤는데 쉽지 않다. 지금까지 배운 걸 토대로 과연 개발자와 커뮤니케이션할 수 있을지 문득 겁이 난다. 하지만 결국엔 공부해야 한다는 생각밖에 들지 않는다. PM이 읽어야 하는 필수 도서들을 구매했는데 지금까지 과제해야 한다는 핑계로 안 읽은 나 자신을 탓해야 된다. 공부하고 책 읽자!

 


출처 및 자료

ohwani.log (https://velog.io/@ohwani/Django-%EB%AC%B8%EC%9E%90%EC%9D%B8%EC%A6%9D)

서비스 기획자의 삽질하는 공간 (https://hyeyun133.tistory.com/entry/01-%ED%9A%8C%EC%9B%90%EA%B4%80%EB%A6%AC-%EB%8D%B0%EC%9D%B4%ED%84%B0)

BBC (https://www.bbc.com/news/technology-56414963)