기술 도입 검토서 작성법과 템플릿

검토서가 답해야 할 질문

검토서는 “무엇을 고를지”보다 “왜 지금, 무엇을 위해 고르는지”를 먼저 답해야 합니다. 다음 세 질문에 한두 문장으로 답할 수 없다면 아직 검토를 시작할 때가 아닙니다.

• 이 변경이 실패하면 어떤 범위까지 영향을 받는가?
• 지금 바꾸지 않으면 무엇이 얼마나 나빠지는가?
• 되돌릴 수 없는 단계는 어디인가?

실제 사례에서 이 질문들이 어떻게 답으로 바뀌는지 보겠습니다. 넷플릭스는 라이브러리 API가 호환되더라도 변경이 어디까지 퍼지는지 측정하는 도구를 만들었습니다.

메루카리는 결제 잔액 시스템을 옮기면서 무중단과 강한 일관성을 동시에 지키는 방법을 설계 문서의 중심에 두었습니다.

후보 기술과 대안 정리

대안 표에는 후보 기술 이름보다 다른 회사가 어떻게 썼는지를 적습니다. 이 사이트는 사례를 네 가지 적용 방식으로 나눕니다.

• 도입: 처음 채택해 운영에 쓴 경우
• 전환: 기존 기술에서 다른 기술로 옮긴 경우
• 제거: 쓰던 기술을 걷어낸 경우
• 언급: 비교나 소개만 하고 채택 여부는 밝히지 않은 경우

현재 수집된 글 24편 가운데 도입 8편, 전환 6편, 제거 2편, 언급 8편입니다. 제거 사례도 후보를 줄이는 근거가 됩니다. 예를 들어 스트라이프는 Envoy 프록시를 자체 데이터 플레인으로 대체한 사례를 공유합니다.

메시지 큐 비교처럼 두 기술을 나란히 놓고 보는 자료도 대안 정리에 쓸 수 있습니다. 아래 영상은 카프카와 래빗MQ의 구조 차이를 비교합니다.

선택 기준표 작성

기준표의 각 칸에는 “좋음” 같은 평가보다 수치나 조건을 적습니다. 다른 회사 사례에서 규모를 숫자로 적은 예를 보면 이렇습니다.

이 사례는 검색 트래픽이라는 구체적인 규모를 기준으로 벡터 DB 처리량을 다룹니다. 우리 트래픽을 같은 단위로 바꿔 기준표에 넣으면 사례와 바로 비교할 수 있습니다. 기준표에는 규모, 운영 부담, 팀이 이미 아는 기술인지, 되돌리기 비용을 최소한 포함합니다.

다른 회사 사례를 근거로 쓰는 법

사례는 같은 주제 안에서 어떻게 쓰였는지를 묶어 보면 근거가 됩니다. CI/CD 주제 글 4편 중 도입 사례는 4편입니다. 한 사례만 보고 결정하지 말고 주제 전체의 패턴을 확인합니다.

규모 문구가 없는 사례는 근거 강도를 낮게 적습니다. 언급만 한 글도 근거로 쓸 수는 있지만, 채택 여부를 증명하지는 못한다고 검토서에 밝힙니다.

위험과 롤백 계획

롤백 계획은 “되돌린다”가 아니라 무엇을 보고 언제 되돌릴지를 적어야 합니다. 데이터가 옮겨지는 전환에서는 쓰기를 두 곳에 남기는 기간이 필요합니다. 아래 사례는 대규모 데이터 수집 시스템을 옮긴 설계를 보여 줍니다.

모노레포 빌드 도구처럼 메이저 버전을 올리는 전환은 한 번에 바꾸기보다 영향 범위를 나눠 확인합니다. 컬리는 Nx 18에서 21로 올리면서 런타임까지 함께 바꾼 과정을 공유했습니다.

템플릿(복사용)

아래 내용을 복사해 검토 문서의 첫 파일로 씁니다. 각 섹션을 채우지 못한 채 결정을 내리지 않습니다.

## 1. 검토서가 답해야 할 질문

- 우리가 풀려는 문제는 무엇인가?
- 이 문제를 지금 풀지 않으면 무엇이 깨지는가?

## 2. 후보 기술과 대안 정리

| 후보 | 다른 회사 사례 | 적용 방식 | 우리 환경과의 차이 |
|---|---|---|---|

## 3. 선택 기준표 작성

| 기준 | 가중치 | 후보 A | 후보 B | 근거 |
|---|---|---|---|---|

## 4. 다른 회사 사례를 근거로 쓰는 법

- 사례마다 규모(트래픽, 데이터 양, 팀 수)를 함께 적는다.
- "언급"만 한 글은 근거 강도를 낮게 적는다.

## 5. 위험과 롤백 계획

- 되돌리는 조건(지표, 임계값)을 먼저 적는다.
- 데이터가 바뀌는 전환이면 쓰기 이중화 기간과 검증 방법을 적는다.