인증 & 인가 서비스를 위한 Swagger 기반의 ERD 그리기 2

---

Server

 

이전 글에서는 Path를 설계해봤었다.

• Path는 어디로부터 왔는 지 알기 위해 서버 출처가 필요하다.

를 만족시키기 위해 서버를 관계시켜뒀는데, 이번 글에서는 해당 테이블을 설계해볼 것이다.

 

가장 먼저 떠오른 핵심적인 건, 서버 이름이다.

사용자가 API를 등록할 때 서버 이름을 보고 해야되기 때문이다. 따라서 겹치지 않도록 고유하게 만들어둬야 한다.

이제 뭐가 더 필요할까... 를 고민할 때 점점 그림이 복잡해지므로

좋은 설계는 실제 현상을 기반으로 만든다. 원칙을 떠올려서 사용자 시나리오를 만들어보자.

에서 서버가 필요한 부분은 여기다

아래처럼 구분해두면 조회 성능에서 큰 차이가 있을 것이기 때문이다.

그리고 관리자 입장에서 서버로 구분해두면 편리하다.

특히 서버 도큐먼트 주소를 입력하는 부분을 어느정도 자동화하면 휴먼 에러를 피할 수 있을 것 같다.

 

이제 더 필요한 게 무엇일까보다, 어떤 게 필요할까를 생각할 수 있다.

• 이름
• 주소

 

이제 테이블을 설계해보자.

 

 

 

 

 

 

---

Trivials

 

 

참으로 적절한 번역이다.

지금까지 설계한 내용을 토대로 만들면 필자가 원하는 서비스를 구현할 수 있을 것 같다.

그렇다면 처음으로 돌아와, Swagger 결과 데이터 구조를 보자.

 

내 설계도에 Parameter, Request, Schema, Field, ... 는 필요할까?

아니다, 하찮은(trivial) 정보이다.

 

내가 실무에 있으면서 했던 착각 중 하나는 '더 있으면 좋지'였다.

있는데 안 쓰는 건 문제가 없지만, 없지만 써야되는 건 문제가 크기 때문이다.

더 솔직하게 말하면 '더 있어서 덕본 경험'도 있었다.

 

하지만 지금와서 느끼는 거지만, 없어도 되는 건 없어야 맞다.

성능에 영향을 준다는 뻔한 이야기 말고도, 명확한 설계를 할 수가 없다는 문제가 있다.

'미래에는 이것도 있어야 될 것 같은데'로 고민을 시작하면서 하나 둘 그리기 시작하면,

시간이 오래 걸릴 뿐더러, 설계도를 보고 이게 도대체 뭘 하는 건지 알 수가 없기 때문이다.

 

 

그렇다면 필요에 의한 확장은 어떻게 할까?

예를 들어 특정 파라미터는 암호화가 필요하기 때문에 파라미터 정보가 필요해졌다고 해보자.

path를 수정할 필요도 없다. 그냥 테이블 하나 더 만들어 관계시키면 된다.

다만 모든 path에 대해 파라미터를 추가해야하는 일이 늘었지만,

어차피 Swagger를 파싱하는 건 이미 있지 않은가. 이 정도 사건은 감내할 수 있다.

 

이를 상쇄하고도 남을 장점은 바로 집중이라고 생각한다.

사실 이때 되서야 파라미터를 업데이트하는 로직을 어떻게 할 지,

또 어떤 암호화 방식을 써야 될 지 등 제대로 고민할 기회가 있기 때문이다.

처음부터 파라미터를 넣어놔도 먼저 path에 대한 인증 & 인가를 어떻게 해야할 지 고민하는 게 우선인데,

멀티태스킹으로 파라미터를 어떻게 설계할 지 제대로 생각할 수 있다고 하는가?

이게 바로 이상한 고민으로 만든 설계도를 보면 이게 도대체 뭘 하는 건지 알 수가 없다고 하는 이유다.

 

 

이제 컬럼을 추가하는 걸 생각해보자.

Swagger의 operationId는 함수명과 일치하는 건 확인했다. 이게 필요하다고 가정해보자.

이럴 땐 대부분 별도 테이블로 빼두거나 새로운 테이블을 생성해서 마이그레이션 하면 된다.

 

하지만 고작 하나 컬럼 때문에 이 모든 걸 해줘야 된다는 게 난감할 때도 있다.

실무에 있으면 이런 일은 아주 가끔 등장한다.

이럴 땐 기본값이 정의된 컬럼 하나 만들면 된다.

 

선두에 말했듯 이럴 일은 거의 없다.

그걸 잡자고 초가삼간 태우는 게 더 이상하다.

좋은 설계는 근본을 찾는 것부터 시작한다. 원칙을 다시 떠올려보자.