요구사항 한 줄이 배포된 서비스가 되기까지 — 사내 인증 시스템 설계의 지형

사내에 시스템이 여럿 있고 로그인이 각각 따로 있다. 캘린더에 한 번, 회의실 예약에 한 번, 근태에 또 한 번. 불편한 쪽은 사용자지만 더 큰 손실은 다른 자리에 있다 — 어느 시스템도 옆 시스템의 사용자가 누구인지 알지 못하므로, 「회의실을 예약하면 참석자 캘린더에 일정이 잡힌다」 같은 연동은 시작조차 할 수 없다. 계정이 흩어져 있다는 것은 불편의 문제가 아니라 연결할 수 있는 것이 없다는 문제다.

해법은 이름만 보면 뻔하다. 전사 통합 인증 서비스를 하나 세우고 나머지 시스템이 그것을 바라보게 한다. 어려운 대목은 무엇을 만들 것인가가 아니라 그것이 어떻게 만들어지는가다. 「하나의 계정으로 모든 시스템에 로그인한다」는 문장 한 줄에서 출발해 테이블의 열 하나, API 시그니처 하나, 파드를 몇 개 띄울지의 숫자 하나까지 내려오는 동안, 그 사이의 모든 결정은 누군가가 근거를 대야 한다.

근거가 남지 않으면 반년 뒤 새 요구가 들어왔을 때 기존 스키마를 고쳐도 되는지 판단할 수 없고, 판단할 수 없으니 아무도 손대지 않는다. 산출물 문서를 형식이 아니라 설계 근거를 보존하는 장치로 다루는 이유가 그것이다.

한 가지는 먼저 갈라 두어야 한다. 이 시리즈는 인증과 인가를 끝까지 다른 것으로 쓴다. 인증은 「당신이 정말 그 사람인가」를 확인하는 일이고, 인가는 「확인된 그 사람이 이 자원에 손댈 수 있는가」를 정하는 일이다. 저장하는 데이터도 실패했을 때 돌려줄 응답도 다르며, 뒤에서 다루는 판단의 절반이 이 구분 위에 서 있다.

이 글은 여섯 편의 지도다. 판단의 「어떻게」는 뒤의 다섯 편이 하나씩 맡으므로, 여기에는 지형만 담는다 — 요구사항 한 줄이 지나는 경로, 단계마다 남는 산출물, 편마다 다른 층을 가리키는 낱말, 그리고 어느 판단이 어느 편에 실려 있는지다.

통합 인증이 짊어지는 것은 로그인 화면 하나가 아니다

흩어진 계정을 하나로 모은다는 말은 세 가지 요구를 한꺼번에 받아 든다는 뜻이다.

세 요구가 서로 다른 산출물을 부른다는 점이 중요하다. 첫째는 저장소와 절차의 문제이고, 둘째는 데이터 모델의 문제이며, 셋째는 자격증명 형식의 문제다. 셋을 한 덩어리로 놓고 「인증 시스템을 만들자」고 하면 어느 것도 끝나지 않는다.

여기에 요구사항 문서에는 잘 적히지 않는 조건이 하나 더 붙는다. 캘린더가 죽으면 캘린더만 멈추지만, 인증이 죽으면 전부가 로그인 화면에서 멈춘다. 기능 요구는 다른 서비스와 크게 다르지 않은데 가용성 요구만 유독 높은 것이 이 도메인의 성격이고, 그 성격이 마지막에 배포 형태를 정한다.

요구사항 한 줄이 배포 구성까지 내려오는 길

전체 흐름은 특별할 것이 없는 개발 생명주기다. 다만 이 시리즈에서는 각 단계가 다음 단계의 입력을 만들어 내는 자리로 쓰인다.

마지막에서 처음으로 돌아가는 점선이 이 그림의 핵심이다. 서비스는 배포하면 끝나는 것이 아니라 운영 중에 들어온 요구가 다시 앞 단계를 흔드는 순환에 들어간다. 조직 개편으로 직무 하나가 늘었을 때 그것이 코드 수정인지 데이터 한 줄 추가인지가 갈리는 자리도 여기이고, 그 판단은 앞 단계가 남겨 둔 것을 보고 내린다.

단계마다 무엇이 남고, 다음 단계에 무엇을 넘기는가

각 단계의 산출물을 「무엇을 만드는가」가 아니라 「다음 단계가 그것으로 무엇을 하는가」 기준으로 정리하면 이렇게 된다.

오른쪽 두 열을 나눠 적은 것에 이유가 있다. 산출물은 다음 단계가 실제로 입력으로 받을 때만 추적을 만든다. 유스케이스 다이어그램을 그려 놓고 명세서를 백지에서 다시 쓰기 시작하면 그림은 장식이 되고, 그 순간 「왜 이 기능이 있는가」의 답은 사라진다.

문장이 표가 되고, 표가 스키마가 된다

앞의 표에서 설계 근거가 실제로 이어지는 구간만 떼어 놓으면 사슬 하나가 나온다. 이 시리즈가 편2부터 편4까지 따라가는 길이 그것이다.

사슬의 각 화살표는 기계적인 변환이 아니라 판단이고, 판단마다 잃는 것이 있다. 한 줄짜리 사건을 유스케이스로 묶을 때는 사건들 사이의 시간 순서가 흐려지고, 명세서 문장을 API 표로 옮길 때는 「누가 이 요청을 보낼 수 있는가」가 표 밖으로 밀려난다.

그래서 이 사슬은 뒤로 갈수록 앞을 되짚는다. 명세서에 없던 제약이 ERD를 그리다가 발견되면 명세서로 돌아가 문장을 고치는 것이 맞고, 그 되짚음이 남지 않으면 다음 사람은 스키마만 보고 이유를 추측하게 된다. 추적성은 뒤에서 앞으로도 흘러야 성립한다.

가용성 요구가 마지막에 배포 형태를 정한다

기능 요구사항이 API와 스키마를 정한다면, 비기능 요구사항은 그 애플리케이션을 어떤 모양으로 띄울 것인가를 정한다. 인증 서비스가 공통 의존 대상이라는 성격이 여기서 값으로 바뀐다.

오른쪽 열을 쿠버네티스의 기능 이름이 아니라 요구사항 쪽 언어로 적은 데는 이유가 있다. 「쿠버네티스를 쓰기로 했으니 프로브를 붙인다」가 아니라 「빠른 복구가 필요하니 죽은 것을 자동으로 알아채는 장치가 있어야 하고, 그 장치의 이름이 프로브다」의 순서여야 설정값이 근거를 갖는다.

낱말이 갈리는 자리

첫 글이 어휘를 한 뜻으로 못 박아 두지 않으면, 같은 낱말이 편을 옮겨 다니며 다른 층을 가리키는 동안 읽는 쪽만 헷갈린다. 실제로 갈리는 다섯을 먼저 갈라 둔다.

갈리는 이유는 행마다 다르다. 「역할」은 하나의 개념이 저장 · 검사 · 정책이라는 세 층을 관통하면서 층마다 다른 모습을 갖는 경우이고, 「토큰」은 서로 다른 표준이 같은 이름을 각자 가져다 쓴 경우이며, 「세션」과 「매핑 테이블」은 설계 단계의 낱말이 운영 단계에서 다른 무게를 갖게 된 경우다.

「프로브」만 성격이 다르다. 편5 안에서만 쓰이는데도 여기 적어 두는 것은 두 종류를 뭉뚱그리면 틀린 설정이 정상으로 보이기 때문이다. 구분은 편5가 한다.

용어 정리

원본 사전의 23개를 하나도 빼지 않고 옮겼다. 다만 뜻풀이는 사전식 정의가 아니라 이 시리즈가 그 낱말을 실제로 쓰는 자리에 맞춰 다시 적었다. 한 편에서만 나오는 설정값과 클래스 이름은 그 편이 처음 쓰는 자리에서 정의한다.

인증과 인가

토큰과 위임

요구사항에서 스키마로

구현

배포와 운영

이 시리즈의 구성

뒤의 다섯 편은 앞에서 그린 사슬을 왼쪽 끝에서 출발해 오른쪽으로 따라간다 — 무엇을 만들지, 그것을 어떤 데이터로 굳힐지, 어떻게 구현할지, 어떻게 띄울지의 순이다.

편2 — 무엇을 만들 것인가. 인증과 인가의 구분에서 시작해 통합 인증이 실제로 어떤 방식들로 구현되어 왔는지를 훑는다. 하나의 로그인을 여럿이 인정하게 만드는 방식, 비밀번호를 넘기지 않고 권한만 위임하는 방식, 시스템끼리 서로를 신뢰하는 방식이 각각 무엇을 전제하는지가 여기서 갈린다. 후반은 그 요구를 문서로 굳히는 네 가지 산출물이다.

편3 — 문장을 데이터 구조로 바꾸기. 명세서의 기능 요구 문장 옆에 API 한 줄을 붙이는 작업에서 출발한다. 그 표들을 모아 놓고 반복해서 나오는 명사를 엔티티 후보로 뽑고, 후보들 사이의 관계와 수량 제약을 정해 최종 스키마에 이른다. 역할과 API를 잇는 표가 왜 따로 있어야 하는지가 이 편의 결론이다.

편4 — 세션이냐 토큰이냐. 스키마 위에 계층을 얹는 이야기로 시작해 가장 값비싼 선택 하나에 도달한다. 로그인 상태를 서버가 들고 있을 것인가, 아니면 서명된 문자열에 실어 보낼 것인가다. 한쪽은 즉시 무효화할 수 있고 다른 쪽은 서버를 늘리기 쉬운데, 둘 다 갖는 방법은 없다. 짧은 수명과 갱신을 조합하는 절충안이 이어진다.

편5 — 띄운 뒤에 달라지는 것. 애플리케이션을 이미지로 굳혀 클러스터에 올리는 경로를 따라간 다음이 본론이다 — 배포 중에 요청이 끊기지 않게 하는 방법, 죽은 것과 아직 준비되지 않은 것을 다르게 다루는 점검, 그리고 조직이 바뀌었을 때 코드를 고치지 않고 데이터만 고쳐 대응하는 자리다.

편6 — 되돌아오는 질문. 실제로 받는 질문은 편의 경계를 지키지 않는다. 「왜 그 방식을 골랐나」는 편2와 편4에 함께 걸리고, 「로그인이 안 된다」의 원인은 편4의 검사 순서에도 편5의 프로브 설정에도 있을 수 있다. 그래서 마지막 편은 앞의 다섯 편을 선택지 · 실패 모드 · 문답이라는 세 벌로 다시 엮는다.

정리

이 프로젝트를 어렵게 만드는 것은 인증 기술 자체가 아니라 인증 서비스가 놓이는 자리다. 기능만 보면 계정을 저장하고 비밀번호를 확인하는 평범한 애플리케이션인데, 사내 모든 시스템이 그것에 기대는 순간 요구사항의 무게 중심이 기능에서 가용성으로 옮겨 간다. 편5가 쿠버네티스를 다루는 것은 그것이 요즘 쓰는 도구여서가 아니라 이 무게 중심이 그리로 끌고 갔기 때문이다.

또 하나는 문서다. 범위 기술서 · 유스케이스 · 명세서 · API 표 · ERD는 다음 단계가 그것을 입력으로 받아야 비로소 일을 한다. 사슬 어딘가에서 입력이 끊기면 그 뒤의 모든 결정은 근거를 잃고, 근거가 없는 설계는 고칠 수 없어서 그대로 굳는다.

다음 편은 사슬의 가장 앞을 다룬다. 인증과 인가는 무엇이 어떻게 다른지, 통합 인증이라는 요구를 실현해 온 방식들이 각각 무엇을 전제하는지, 그리고 그 요구가 어떤 문서를 거쳐 다음 단계가 받아 쓸 수 있는 형태로 굳는지다.