선제적으로 할 고민
- 사용자가 누구인가?
- 어느 플랫폼을 지원할 것인가?
- 트래픽의 규모는 어떻게 되는가?
개발을 하면서 사고 과정
사람을 믿지말고, 시스템을 믿어라.
- 대충 이렇게 만들어도 절대 그렇게 쓰는 사람은 없겠지? 라고 생각하지마라. 무조건 그렇게 쓸 것이다. 코드와 시스템으로 무조건 제한하고, 만들어둬라
정말 개발해야하는 걸까 고민해라.
- 어떤 기능을 개발하지 않고도 처리할 수 있을지 고민해라. 개발 리소스는 공짜가 아니다.
모델링 / 데이터
User 모델을 만들 때
- 1인 1 계정 이상으로 만들지 못하게 만들 것인가?
- 부계정을 인정할 것인가?
- 인정하지 않는다면, 어떤 방법(ex. 본인 인증)을 써서 막을 것인가
- 해당 유저의 정보는 누가 볼 수 있는 것인가?
- 관리자라고 하더라도 개인 정보를 어디까지 노출할 것인가?
- 해당 유저가 접근 할 수 있는 메뉴, 액션에 대해 어떻게 제어할 것인가?
- 본인 인증을 할 수 있는 방법이 다양한데, 어떻게 저장할 것인가?
- Oauth 등을 통해 가입 경로가 있다면, 정보를 어떻게 저장할 것인가? 별도 테이블에 구성할 것인가? users 테이블에 같이 저장할 것인가?
전화번호 데이터
- 국제 전화는 고려해야 할까?
- 특정 국가만을 위한 서비스일까?
- 국가 번호는 따로 저장해야할까?
- 전화번호의 형식을 어떻게 저장해야할까? - 등의 문자는 생략하고 저장해야할까?
- 전화번호를 진짜 사용하고 있는 사용자인지는 어떻게 확인해야할까?
돈(금액) 데이터
- 환율에 따라서 환전을 해야하는 경우가 있는가?
- 특정 화폐에 따라 소수점 단위가 있는데, 정수형 / 실수형 환율 계산을 어떻게 매끄럽게 할 수 있을것인가?
- 소수점이 있는 화폐와 없는 화폐를 어떻게 상호 전환할 것인가?
deleted_at, destroyed_at 등의 컬럼
- 해당 컬럼을 사용해야할 만큼의 남겨놔야할 데이터인가?
- unique index를 만들 때, 해당 컬럼을 제외하는 partial index를 만들었는가?
- 해당 컬럼에 삭제 정보를 남겨놓으면서 실제로 삭제하지 않는 경우, 법적 이슈가 될만한 정보(ex. 개인 정보)가 있는가?
- 있다면, 특정 기간이 지나면 삭제되는 로직을 같이 구성했는가?
시간 데이터
- 시간 값들은 가능하면 시간대를 맞추어 저장하자.
- KST 등으로 저장할 거라면 무조건 모든 데이터를 통일하라. 서로 달라지는 순간 개발자의 실수가 발생한다.
이메일 데이터
- 이메일 / 알림은 보내고 끝이 아니다.
- 이메일 / 알림이 제대로 전송되었는지 확인해라.
- 확인했는지 등을 더 추적할 수 있는가를 고민해라.
알림 데이터
- 사용자가 해당 알림을 정말 받고 싶을까?
- 카테고리별로 알림을 받아야 하는지 저장하고 있는가?
- 알림 빈도는 어느정도 되는가?
- 알람을 정말 보내기로 했다면 알람 데이터는 소실되면 안된다.
- 알람이 지연되거나 순서가 틀려도 괜찮을 수 있다.
- 알람을 보내는데 실패했다면 재시도해야 하는가?
- 알림을 종류는 어떻게 되는가?
- 알림을 받는 사용자는 어떤 플랫폼으로 받는가? 이에 따라 어떤 API, 서비스를 써야하는가?
비밀번호
- 비밀번호를 절대절대 평문으로 저장하지 마라.
- 암호화 방식이 어떤 것인지 확인하고, 해킹의 위험이 있는지 확인해라.
이미지 저장
- 사용자가 올리는 이미지를 정말 그대로 업로드받아서 저장할 것인가?
- 용량을 제한해야 할 것인가?
- 사용자가 올린 이미지를 과연 reponse에 그대로 넣는게 최적화에 맞는 행위인지 다시 고민해라.
- 용량을 제한하지 않았다면, 이미지의 용량을 최소화시킬 수 있는 방법을 찾아라
주소 저장
- 주소 형식은 나라마다 조금씩 상이하다. 하지만 일관된 국제 주소는 있다.
- 이걸 활용할 것인지 고민해라. 국내 주소는 굳이 이렇게 하지 않아도 되기 때문에.
- 국제 서비스가 될 것인가? 미래를 고민해라
- 정말 문자열로 “단순하게” 저장할 것인지 다시 고민해라.
컬럼에 대해
- 숫자형 컬럼을 만들때, 정말 해당 컬럼은 그 타입의 범위를 가져도 되는건지 생각해라. (개인적인 생각)더 먼 미래를 보고, 생각하는 것도 괜찮다. 조금은 여유롭게 설정해도 좋은 것 같다.
- 정말 그 테이블이 맞는가 고민해라. 테이블에 너무 많은 컬럼이 생기는 것은 개발자에게도, DBMS에게도 안 좋다.
- RDB내의 컬럼에서 Json 형식의 데이터(postgresql jsonb)가 저장되는 것은 (개인적으로) 최악이다. 차라리 jsonb로 저장할 바엔 테이블을 추가하는게 맞다. jsonb 컬럼을 이용해 DB 쿼리를 날려야 하는 순간 최악이다.
인프라
데이터 백업
- 백업 정책은 어떻게 되는가?
- 데이터가 날라갔을 때, 최대 몇분 안에 복구할 수 있는가?
- 복구했을 때, 날라가는 정보의 범위는 어느정도인가?
에러 로그
- 에러는 무조건 모니터링이 되어야 한다.
- 에러를 받을 수 있는 채널이 있는지 확인해라. 단순히 슬랙으로 메세지를 발송시키더라도, 확인해라
- 에러를 모니터링하느라 실제 서비스의 리소스가 부족해지는지 확인해라.
SPOF
- SPOF를 찾아라. 단순히 인프라에서만 일 수도 있지만, 코드에서도 적용된다.
- 하나가 고장났는데, 모두가 고장나는 경우를 발생시키지 마라. 절대. 대안을 찾아놔라.
- 심한 경우, AWS가 고장났을 때 GCP로 바로 옮길 수 있는가까지 고민해야한다.
Mono Repo
- Repository를 무조건 분리해야하는 상황이 있는가? 없다면 Mono Repo를 일단 유지하는 것이 좋을 수 있다.
- 서비스가 점차 커지면서 자연스럽게 서비스가 분리될 수 있는 “여지”를 잘 남겨놓고 개발하자.
코드를 작성하면서
레코드 복사 기능
- 만약 파일이 업로드 되어있다면, 해당 파일은 복사해야할지, 그냥 링크로만 가져와서 연결할지 정해라
- 어떤 레코드가 삭제되었을때 해당 파일을 지워야하는가도 같이 고민해라
- 해당 레코드에서 복사가 정말 되어야하는 값인 건지 다시 확인해라
- 같이 복사가되어야 하는 relation이 있는지 고민해라
마크다운 에디터
- 마크다운 에디터를 적용할 때, 가능한 모든 문자열에 대해 테스트를 다 해봐라.
- 해당 마크다운 문자열이 만약 로그에 담겼을 때, 로그가 이상하게 나오는지 검증해봐라.
- 마크다운 문자열로 인해, 로그가 제대로 작성되지 않는다면 오류 모니터링시 귀찮은 상황이 생긴다.
데이터베이스 쿼리 / ORM 작성
- JOIN 또는 Eager Loading을 하든 N + 1을 피해라.
- 두 방법 중에 어떤게 나은지는 쿼리를 조사해라. 단, 데이터의 수를 고려해라.
Job / Worker
- 사용자가가 호출한 API가 꼭 바로 응답이 정확하게 가도 되지 않는다면, 비동기로 처리하는 것을 고민해봐라. 일단 응답을 보내주고 Job을 돌리는 것도 대안이 된다.
테스트 코드
- 외부 API를 통해 불러오는 부분이 있다면, 모킹을 꼭 제대로 해라.
- 별도로 해당 API가 정상적으로 동작하고 있는지도 확인하는 장치를 만들어라.
- 테스트 코드를 항상 짜라.
- 테스트 커버리지를 무조건 믿지는 마라.
- 테스트 커버리지가 100%라도 커버되지 않는 TC가 있을 수 있다. 의심하고 또 의심해서 코드를 작성해라.
서비스 설계
뉴스 피드 시스템
- 유해컨텐츠를 어떻게 방지할 것인가?
- 한 사용자가 올릴 수 있는 포스팅 수에 제한을 둔다든지?
- 컨텐츠가 정말 유해한 컨텐츠인지 판단을 어떻게 할 것인가?
- 팬아웃을 언제 할 것인가? (팬아웃: 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정)
- 쓰기 시점에 한다.
- 뉴스피드가 실시간으로 계속 갱신된다.
- 핫키 문제가 발생할 수 있다.
- 읽기 시점에 한다.
- 뉴스 피드를 읽어오는데 시간이 오래 걸린다.
- 비활성화 사용자에게 까지 데이터를 발행하는 경우가 적어진다.
채팅 시스템
- 채팅에서의 종단간 암호화를 지원해야 하는가?
- 채팅으로 주고 받을 수 있는 컨텐츠의 종류는 어떻게 되는가?
- 채팅방의 인원제한은 어떻게 되는가?
- 채팅 이력은 언제까지 보관되어야 하는가?
- 어떤 플랫폼을 지원해야 하는가?
- 접속 상태를 표시해야 하는가?
- 웹소켓 vs 폴링 방식
Hot Key 문제
캐시 구조
Tradeoff에 대한 고민
수직적 규모 확장 vs 수평적 규모 확장
SQL vs NoSQL
Sharding을 어떤 기준으로 할 것인가?
연관 페이지
참고 문헌 / 사이트