Topic 32 설정
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
애플리케이션이 출시된 이후 바뀔 수도 있는 값에 코드가 의존하고 있다면 그 값을 애플리케이션 외부에서 관리하라.
p.236
흔한 설정 값은 third-party token, DB 접속 정보 등이 있다. 대체로 이러한 값들이 있다면 .env 파일을 읽어 사용하도록 하였는데 이는 설정 값이 변경되었을 때 애플리케이션을 재시작해야 한다는 단점이 있다. 물론 무중단 배포가 가능하지만 리소스를 줄일 수 있는 것은 분명하다.
정적static 설정
보통 처음 애플리케이션을 시작할 때 읽어올 것이다.
…
우리는 그렇게 하지 않기를 추천한다. 대신 설정 정보를 (얇은) API 뒤로 숨겨라. 그러면 설정을 표현하는 세부 사항으로부터 여러분의 코드를 떼어놓을 수 있다.
p.237
최소한으로는 특정 값을 사용할 때 하나의 함수를 통해서 값을 받아오도록 코드를 작성해야하는 것은 분명하다. 그래야 버그를 줄이고 에러를 줄일 수 있다.
서비스형 설정 Configuration-As-A-Service
정적 설정이 많이 쓰이긴 하지만 요즘 우리는 다른 방식을 더 좋아한다.
…
일반 파일이나 데이터베이스가 아니라 서비스 API 뒤에서 관리하는 것을 선호한다.
p.237
사실 서비스형 설정은 처음 들어보았다.
서비스형 설정에는 몇 가지 장점이 있다.
- 여러 애플리케이션이 설정 정보를 공유할 수 있다. 인증과 접근 제어를 붙여서 애플리케이션마다 보이는 정보가 다르게 만들 수도 있다.
- 여러 인스턴스에 걸쳐서 전체 설정을 한번에 바꿀 수 있다.
- 설정 데이터를 전용 UI로 관리할 수 있다.
- 설정 데이터를 동적으로 계속 바꿀 수 있다.
p.238
여러 서비스를 만들다보면 각 인증 정보를 따로 관리해야하는 경우가 다반사이다. 시간이 지나면 권한을 부여받았던 방법부터 어떠한 서비스를 사용하고 있는지 가물가물하기도 하다. 이럴 때마다 한 곳에서 관리하면 좋을텐데 싶었는데 다음 프로젝트 때는 간단하게나마 서비스형 설정을 만들어 사용해봐야겠다.
설정값 하나를 바꾸기 위해 전체 애플리케이션을 멈추고 다시 시작해야 하는 상황은 현대인의 삶에 어울리지 않는다.
p.238
위에서 언급하였듯 무중단 배포가 있지만 서비스형 설정을 통해 인증 정보만 갱신될 수 있다면 간단하게 목표를 이룰 수 있을 것이다.
Topic 32 느낌
Topic 32 에서는 서비스형 설정을 통해 한 곳에서 인증 정보를 관리하도록하는 토이 프로젝트를 만들고 싶은 욕구를 불러일으킨다.