SW설계 방법론에서 다루는 얘기와는 다르다. 굳이 범주를 말하자면 Architectural Concerns 에 가깝다고 할 수 있다.
실제 개발시에 마주할수 있는 여러가지 이슈들을 최소화 하기 위한 나의 경험만으로 정의되는 사항들이다. 이 점을 참고하여 읽으면 좋겠다.
배포&롤백
SW를 배포할때 어떠한 방법으로 배포할 것인지를 수립해야한다.
Blue-Green인지 canary인지 그로인한 기존 시스템 영향도는 어떻게 되는지, 배포시간이 얼마나 예상되는지,
그리고 배포하다 문제가 생겼을때 어떻게 피해를 최소화 하면서 롤백을 할 것인지 그에 따른 전략을 세워야 한다.
버전 업그레이드
이 SW가 나중에 업그레이드를 할때 어떻게 쉽고 빠르고 문제 없이 할것인가, 하위 버전과의 호환성도 고려해야 한다.
또한 데이터의 마이그레이션도 필요하다면 마이그레이션 전략을 생각해야한다(예: 중단으로 갈것인지 무중단으로 갈것인지)
멀티 환경 고려
여기서 멀티환경은 여러가지가 될수 있다. Private/Public 환경일수도 있고, 가상화 혹은 Bare-Metal일수도 있고, 회사별일수도 있다.
이러한 멀티환경을 고려하여 기능을 적절히 옵션화 하는 것이 필요하다. 옵션화 할때도 어떤 A환경으로 옵션이 있고, 이것을 선택했을때 1,2,3,4로 기능이 정해지는게 아니고, 1,2,3,4을 각각의 옵션화 하여 A라는 환경에서는 이런 기능들을 enable 하는 것으로 처리하는게 좋다.
다만, 환경별로 구현이 너무 상이할때는 너무 옵션화 하는것보다는 상위레이어에 추상화 레이어를 만들고 하위에 환경별 로직을 직접 코드로 구현해버리는게 더 나을수 있다.
측정 지표 및 획득 방법
배포된 서비스를 통해 얻어야 하는 측정 지표들을 선정하고 그에 관련된 코드를 넣어야 한다. 활용목적이 명확해야하며 그렇지 않으면 단순히 보여주기만을 위한 시간낭비일 뿐이다.
타 서비스 영향도
이 서비스가 배포할때, 부하가 있을때, 에러가 나서 종료가 될때 등에서 다른 서비스에 어떠한 영향을 끼칠 것인가를 고려해야한다. 타 서비스에 부하를 줄수도 있고, 업그레이드에 따른 호환성이 문제가 될수도 있다.
인터페이스
API, 옵션 등은 한번 정하면 바꾸기가 어렵다. 그래서 정 안되면 v2,v3 이런 API가 추가된다. 옵션도 마찬가지다. 기본값이 true였는데 false로 바꿔버리면 인터페이스가 깨지는 것이다. 초기 설계시 기능적 변화범위를 고려하여 충분히 확장가능하게 만들어야한다.
테스트
매우 중요하다. 본인을 자신하지 말아야 한다. 유닛테스트와 Integration 테스트는 기본적으로 수립해야한다.
에러 추적
에러가 발생했을때 어떻게 손쉽게 추적할지를 고민해야 한다. 충분히 레벨을 나눠 로그을 상세히 넣을수도 있고, 측정 지표를 넣어 부하를 확인할수도 있다. 다른 서비스와 연동이 될때는 span-id와 같은 추적가능한 id를 이용할수 있어야 한다.
보안
이 부분은 보안을 전문으로 하는 분들이 더 잘 알테지만, 서비스 개발 관점에서만 몇가지 얘기하자면,
SSL, Rate Limiting, Token 암호화/갱신, 우회경로 차단 등이 있을수 있겠다.
문서화
팀 동료, 사용자를 위한 문서는 필수이다. 이런 문서화까지 고려하다보면 사용성/가독성이 좋은 설계방향으로 가게 되어있다.