이번 시간은 이 시리즈의 마지막 시간으로 1인 개발 시작시에 미리 알았으면 좋았을 것들을 정리하였습니다.
(모든 코드는 Github에 있습니다.)
회사나 팀 단위의 서비스가 아닌, 1인 개발로 서비스 구축시 Tip을 나열하였습니다.
회사나 팀 단위의 서비스라면 전혀 다를수 있습니다.
Tip)
회사 혹은 팀 단위 서비스라면 권남님의 신규 Web 서비스시 고려해 볼 사항을 참고해보시길 추천드립니다.
실전 초고수 손권남님의 경험을 토대로 작성된 노하우라서 정말 많은 도움이 됩니다.
백엔드 개발자라면 비법서와 같은 팁들이 넘치기 때문에 꼭꼭 보시길 추천드립니다.
내용이 계속 추가되고 있기 때문에 정기적으로 방문해서 보시는것도 좋습니다.
1인 개발이라 하더라도 개인마다 느낀 점이 전혀 다를수 있기 때문에 저 개인의 경험을 토대로 했다는점을 먼저 말씀드립니다.
Tip
회원 서비스
- 회원 서비스는 웬만하면 OAuth로 구축하는 것을 추천
- 직접 구현할 경우 배보다 배꼽이 커지는 경우가 자주 발생
- 직접 구현시 다음을 전부 구현해야함 (OAuth에도 구현해야하는 것 제외)
- 로그인 보안
- 회원가입시 이메일, 전화번호 인증
- 비밀번호 찾기
- 비밀번호 변경
- 개인정보 수정
- 개인정보 보안
- 회원 관련 CS 대응
- OAuth 로그인 구현시 위 부분을 모두 구글/네이버/페이스북 등에 맡기면 되서 심플해짐
- 서비스 개발에 집중할수 있음
- 서비스 초기에는 세션 저장소로 꼭 Nosql(Memcache, Redis) 등을 쓰지 않아도 됨
- 초기에는 RDS도 세션 저장소로 괜찮음 (이전 포스트 참고)
- Spring Session 모듈로 인해 저장소 솔루션 변경이 용이하기 때문에 RDS를 썼다고 Redis 변경이 어렵지 않음
- 기본 세션(톰캣 세션)을 쓰게 되면 톰캣이 재시작하는 순간 (배포나 스위치) 모든 로그인이 풀려버리니 기본 세션보다는 JDBC Session 추천
캐시
- API 결과 데이터 혹은 HTML 렌더링 결과는 클라이언트에서도 캐시할 수 있음
- 웹 서비스라면 브라우저 변수를 적극 활용하여 서버 자원을 아낄수 있음
- 예를 들어 화면의 탭을 누를때마다 화면이 변경된다면, 탭의 결과와 탭 클릭시간을 브라우저 변수로 저장
- 이전에 동일 탭 클릭시간에서 5초 이내(서비스 특징에 따라 변경)로 다시 탭을 클릭하면 변수에 저장된 랜더링 결과를 그대로 다시 반환하고, 5초 이상 지났다면 다시 Ajax로 데이터를 반환해서 저장하고 랜더링하면 됨
- 잦은 API 요청에 대한 서버 자원을 아낄수 있음
- kingbbode님의 Cache 참고
관리자 페이지
- 관리자 페이지와 사용자에게 제공되는 서비스는 분리해서 구현할것
- 같은 프로젝트로 있으면 다음과 같은 문제가 발생
- 외부에서 접근할 수 있기 때문에 그에 따라 인증/권한 관련 기능이 추가로 필요하게 됨
- 관리자 페이지와 서비스 페이지의 코드가 중구난방으로 교차 사용될 확률이 높음
- 중복 코드가 생기면 (Entity 클래스 등) Copy & Paste 하더라도 둘은 분리하는걸 추천
- 분리만 되있으면 이후 Gradle 멀티 모듈 전략과 같은 방법으로 개선 가능
- 초기에는 8-1-2. YAML(.yml) 수정처럼 로컬PC에서 관리자 페이지 운영환경을 실행시키는 것도 좋은 방법
- 외부에서 접근할 수가 없음
- EC2를 한대 더 사용할 필요가 없음
- 배포환경을 추가로 구축할 필요가 없음
- 메인 서비스가 안정화 된 후 관리자 페이지 개선해도 늦지 않음
써드파티
- 메인이 되는 기능 외에 나머지는 전부 써드파티 라이브러리에 의존하는걸 추천
- 1인 개발은 무엇보다 개발 시간이 부족하기 때문에 최대한 외부 서비스를 이용할 것
- 댓글: DISQUS
- 외부 API 연동: Zapier
- 페북 API와 Slack & 본인 API 연동 등을 클릭만으로 해결
- 월 100회 요청까지 무료
- 웹로그: Google Analytics
- 실시간 모니터링: Pinpoint
- CDN: Cloud Flare
- Editor: tui.editor
어플리케이션 & DB
- JPA 사용시 OSIV 옵션은 끌것
- 트랜잭션 범위가 커져 실제 설정한 시간 보다 훨씬 오래 DB 커넥션을 붙잡고 있어 성능 이슈의 주 원인이 됨
- 안그래도 낮은 사양의 장비를 사용하니 최대한 이런 요소는 미리 제거하고 시작하는것 추천
- 데이터 변경 로직은 모두 어플리케이션에서 처리할 것
- DBMS에서 데이터 생성 금지
- ex)
now(),password(), 스토어드 프로시져 등 - View 템플릿 엔진에서 데이터 로직 금지
- ex) FreeMarker, Velocity 등에서 데이터 변경하는 등 금지
- 차후 기능 변경/확장, 시스템 변경 등에서 고려해야할 요소가 너무 많아짐
- 주요 기능은 무조건 테스트 코드를 작성할 것
- QA팀이 없기 때문에 본인이 직접 테스트 해야함
- 직접 테스트하는 시간을 줄여줄수 있는 것이 테스트 코드
개발
- 욕심부리지 말것
- 수많은 고려사항들과 기능들이 생각남
- 다 무시하고, 출시를 목표로 할것
- 이런 저런 사항을 모두 고려하면 머릿속에서 구상만 되다가 좌초됨
- 가장 자신 있고, 자주 사용하는 언어와 환경을 사용할 것
- 리액트 & 웹팩도 공부할겸 서비스 출시해보겠다고 하면 출시 하는 경우를 거의 못봄
- 오히려 jQuery로 서비스 출시 -> 리액트 & 웹팩 별도 공부 -> 출시된 서비스에 적용이 성공 확률이 더 높음
- 말 그대로 혼자 개발하는게 출시 확률이 더 높음
- 사업이 아니고, 개인 서비스 출시이기 때문에 이것 저것 논의하다보면 판만 커지고 구현 완료를 못하게 됨
- 인프런 사례 참고
중요
가장 중요한 팁은, 웹 서비스를 하는 회사에서 몇년간 일해보는 것입니다.
SI, SM이 아니라 자사 서비스를 하는 곳에 가서 "제대로된 웹 서비스를 개발/운영하는 곳에선 어떻게 문제를 해결하고 어디까지 고려하는지" 경험해보는게 가장 좋습니다.
즉, 자신만의 서비스 출시를 목표로 하신다면 흔히 말하는 대기업 SI 보다는 네이버/라인/카카오/쿠팡/우아한형제들/푸드테크/야놀자/토스 등으로 취업 & 이직하시는게 좋습니다.
연봉이 대기업 SI보다 낮을수도 있지만, 웹 서비스 개발/운영 경험을 얻게 됩니다.
로그 관리, Exception 처리, 성능개선, 모니터링, 대규모 트래픽 처리 등은 이런 회사가 아니면 제대로 익히기 어렵습니다.
아직 취업 준비생이시라면 창업으로 개발자 커리어를 시작하시기 보다는 이런 회사로 취업하는걸 먼저 목표로 하는게 개발자로서 더 멀리 갈 수 있지 않을까 생각합니다.
후기
후아!
드디어 스프링부트로 시작하는 웹 서비스 시리즈가 끝났습니다!
12월부터 시작했는데 어느새 2월이 끝나가고 있습니다.
2016년에 이번처럼 시리즈로 IE 7,8에서 모던하게 JS 개발하기를 연재했습니다.
당시에 생각보다 너무 호응이 없어서 이번 시리즈도 그렇게 되지 않을까 걱정이 많았습니다.
특히 끝까지 마무리 할 수 없을까봐, 너무 잘못 알고 있을까봐 등의 부담도 있어서 시작하기 앞서 고민이 많았습니다.
초보개발자모임을 구현하면서 삽질을 너무 많이해서 "누가 전반적으로 짚어주는 자료를 만들어주지 않나" 라고 한숨쉬던 기억이 납니다.
저와 같이 고민하시는 분들이 있지 않을까 하는 마음을 계기삼아 시작할 수 있었습니다.
다행히 여기저기 많이 공유되기도 하고, 많은 분들이 댓글도 달아주시고, 좋은이야기도 해주셔서 하길 잘했다고 생각합니다.
작년 회고를 통해 다짐했던 1분기 목표를 하나씩 달성하고 있어 개인적으로는 굉장히 뿌듯한 마음으로 후기를 작성하고 있습니다.
이번주 주말에 있는 행사만 잘 마무리 되면 1분기 목표는 모두 달성하는거라 두근두근 합니다.
시리즈물을 하다보면 전체적인 큰 구조를 익히는데 도움이 되지만 회사 업무를 통해 얻은 내용들, 좀 더 깊숙한 내용들을 정리하는 시간이 없어 3월에는 좀 더 작은 범위로 한정해서 공부하고 정리할것 같습니다.
(미뤄둔 포스팅 주제들이 너무 많네요 ㅠㅠㅠ)
끝까지 봐주신 분들 정말 고맙습니다!
덕분에 마무리 할수 있었습니다.
앞으로도 좋은 주제, 도움이 되는 주제로 계속 기록하겠습니다.
감사합니다!
(마무리하면 가장 먼저 생각나는 꼭두각시 서커스의 마지막 표지로 마치겠습니다.)
