기술 제안의 보류 상태 설계

1. ‘지금은 하지 않는다’도 기술적 판단이다

기술 제안이 올라오면 팀은 흔히 두 가지 말만 준비한다. 한다, 또는 하지 않는다. 그러나 실제 현장에는 그 사이가 넓다. 의존 서비스의 정책이 아직 바뀌지 않았을 수 있고, 고객 문제는 분명하지만 해결 수단이 아직 과할 수 있다. 비용 구조가 불투명해 실험의 범위를 먼저 줄여야 할 수도 있다. 이때 “나중에 보자”는 편한 문장이지만, 의사결정으로는 거의 아무것도 남기지 않는다.

여기서 말하는 보류는 결정을 회피한다는 뜻이 아니다. 이 글의 제안은 “현재 확보한 근거와 제약으로는 구현을 시작하지 않는다”는 명시적 결론이다. 그 결론은 반려와도 다르다. 반려는 제안의 방향 또는 문제 정의가 맞지 않는다는 쪽에 가깝고, 보류는 판단을 바꿀 수 있는 조건이 아직 오지 않았다는 상태에 가깝다. 따라서 보류 문서의 목적은 찬반 논쟁을 길게 보관하는 데 있지 않다. 무엇이 달라지면 다시 판단할지를 보존하는 데 있다.

코드 리뷰의 비유가 도움이 된다. Google의 공개 코드 리뷰 가이드는 검토의 목적을 코드베이스의 장기적 건전성 개선으로 두며, 완벽하지 않더라도 전체 코드 건강을 확실히 개선하는 변경은 승인 쪽으로 기울이라고 설명한다. 또한 중요하지 않은 개선 의견은 필수 수정과 구분하라고 권한다. Google Engineering Practices의 코드 리뷰 기준을 기술 제안에 그대로 적용할 수는 없지만, ‘완벽해질 때까지 멈춤’과 ‘현재 기준에서 충분히 나아짐’을 구분하는 관점은 유용하다.

제안 단계에서는 질문을 조금 바꿔야 한다. “이 기술이 좋은가?”가 아니라 “지금의 증거로 이 변경을 시작하는 것이 더 나은가?”다. 전자는 토론을 끝없이 넓히지만, 후자는 증거·제약·되돌릴 수 있는 범위를 보게 한다. 답이 아직 아니면 보류가 된다. 그때 핵심은 보류라는 라벨이 아니라 라벨 뒤의 계약이다.

2. 보류를 운영 상태로 만드는 네 가지 필드

아키텍처 결정 기록(ADR)은 결정의 맥락과 결과를 남겨 나중의 독자가 왜 그 선택을 했는지 이해하게 하려는 방식이다. 이 형식의 출발점으로 널리 인용되는 Michael Nygard의 설명도 상태를 제안·수락·폐기·대체 등으로 구분한다. 원문: Documenting Architecture Decisions은 기록이 설계의 맥락을 잃지 않게 하는 데 초점을 둔다. 다만 보류는 어느 팀에나 같은 표준 상태가 아니다. 아래는 그 아이디어를 확장한 필자의 운영 제안이다.

보류 메모에는 최소 네 가지가 있어야 한다.

1. 현재 결론과 사유: “Kubernetes로 옮기지 않는다”보다 “현재 트래픽 변동성과 운영 인력 조건에서는 관리 복잡도가 이득을 앞선다고 판단한다”가 낫다. 사유는 찬반의 감상이 아니라 지금 판단에 쓴 관찰과 제약을 분리해 적는다.
2. 재개 조건: “분기 말에 재검토”는 일정일 뿐 조건이 아니다. 예를 들어 “현 운영 방식으로 처리할 수 없는 배포 격리 요구가 확정될 때”, “플랫폼 운영 책임자가 배정될 때”, “제한된 범위의 검증 계획이 합의될 때”처럼 판단을 바꿀 신호를 문장으로 쓴다. 어떤 조건도 특정 기술의 도입 효과를 보장하지는 않는다.
3. 재검토일과 소유자: 날짜는 캘린더 알림이 아니라 문서를 다시 열 책임의 소재를 정한다. 소유자는 제안을 한 사람일 수도, 시스템 오너일 수도 있다. 중요한 것은 그 사람이 도입을 강제하는 사람이 아니라 결과를 갱신할 사람이라는 점이다.
4. 종료 조건: 재검토일이 지나도 조건이 충족되지 않았을 때 무엇을 할지 정한다. 보류를 연장할지, 종료로 바꿀지, 더 작은 탐색 과제로 분리할지다. 종료는 실패의 낙인이 아니다. 현재 문제에 이 수단을 더 이상 연결하지 않겠다는 기록이다.

아래 양식은 그 네 항목을 한 화면에 모은 실무 문서다. 특정 조직의 검증된 표준이 아니라, 팀 상황에 맞춰 수정해 쓰는 제안서 부록이다.

# 기술 제안 보류 메모

- 제안 / 문제: [무엇을 해결하려 했는가]
- 오늘의 결론: [보류 / 종료 / 작은 탐색으로 분리]
- 판단에 쓴 근거: [관찰한 사실, 링크, 제약]
- 아직 모르는 것: [결정을 막는 불확실성]

## 재개 조건

- [어떤 사건·관찰·합의가 생기면 다시 검토하는가]
- [그 조건을 누가, 어디서 확인하는가]

## 재검토 계약

- 재검토일: [YYYY-MM-DD]
- 문서 갱신 소유자: [이름 또는 역할]
- 함께 읽을 사람: [시스템 오너, 보안, 제품 등]

## 종료 조건

- [이 날짜까지 재개 조건이 충족되지 않으면 종료한다]
- [종료 뒤 남길 대안 또는 관련 문서]

3. ‘재검토일’만 있는 보류가 실패하는 이유

재검토일은 필요하지만 충분하지 않다. 날짜만 있으면 회의가 문서를 다시 여는 의식이 되기 쉽다. 그 자리에서 사람들은 또 묻게 된다. “그래서 지금 할까?” 하지만 이전에 무엇이 불확실했는지, 무엇이 바뀌어야 하는지 적혀 있지 않으면 같은 주장과 같은 추측이 되풀이된다.

보류를 열었을 때는 아래 순서로 확인하는 편이 낫다.

[보류 당시의 근거] → [재개 조건이 충족됐는가?]
                                  │
                    ┌─────────────┴─────────────┐
                    ▼                           ▼
                [아니오]                     [예]
                    │                           │
        [종료·연장·작은 탐색]        [새 제안으로 재평가]

이 흐름에서 “예”는 구현 승인을 뜻하지 않는다. 재개 조건이 충족됐다는 것은 다시 판단할 재료가 생겼다는 뜻이다. 예컨대 벤더의 기능이 출시됐다는 사실은 검증을 시작할 이유가 될 수 있지만, 팀의 보안 경계·비용·운영 소유권이 맞는다는 결론까지 대신하지 않는다. 재평가는 원래 제안으로 되돌아가는 일이 아니라, 바뀐 근거와 남은 제약을 기준으로 새 결정을 쓰는 일이다.

반대로 “아니오”도 무기력한 결론일 필요가 없다. 재개 조건이 여전히 충족되지 않았고 그 조건을 만들 비용도 정당화되지 않는다면 종료가 더 정직한 결과다. 다만 종료 메모에는 대안을 남긴다. 예를 들어 “서비스 메시 도입은 종료, 대신 현재 API 게이트웨이의 인증 정책을 분리해 관리한다”처럼 문제 자체를 방치하지 않는 선택을 기록한다.

▲ 이 이미지는 보류 메모의 운영 흐름을 설명하기 위해 만든 AI 개념 일러스트입니다. 체크 표시나 그래프는 실제 성과 측정 결과를 뜻하지 않습니다.

4. 회의에서 보류를 합의하는 대화 순서

문서 양식이 있어도 회의의 말이 달라지지 않으면 보류는 다시 애매해진다. 특히 제안자가 “아직 준비가 덜 됐습니다”라고 말하고, 검토자가 “좀 더 알아보고 오세요”라고 답하는 장면은 흔하다. 두 문장은 모두 성실해 보이지만, 누가 무엇을 확인해야 하는지는 남기지 않는다. 다음의 짧은 순서는 회의록을 길게 쓰지 않고도 그 빈칸을 줄이기 위한 필자의 진행 제안이다.

먼저 제안자는 현재의 결론을 한 문장으로 말한다. “이 제안은 보류를 요청합니다. 이유는 기능 부족이 아니라 운영 소유자가 확정되지 않았기 때문입니다.” 그 다음에는 반대 의견을 받기 전에 재개 조건을 제시한다. “운영 소유자가 정해지고, 장애 대응 경계가 합의되면 같은 문서를 다시 열겠습니다.” 이렇게 하면 회의의 초점이 제안자의 열정이나 기술의 유행성에서 판단 조건으로 옮겨간다.

검토자는 ‘언제 다시?’ 대신 ‘무엇이 확인되면 다시?’를 묻는다. 이 질문은 타임라인을 지우라는 뜻이 아니다. 재검토일도 정해야 한다. 다만 날짜가 조건을 대신하지 않게 한다. 예를 들어 다음 달 첫 주를 재검토일로 정했다면, 그때 확인할 자료와 자료를 만들 사람을 함께 적는다. 재검토일에 근거가 바뀌지 않았으면 연장·종료·작은 탐색 중 하나를 고른다. 아무 결론 없이 다음 날짜만 새로 잡는 것은 보류 계약을 갱신한 것이 아니다.

마지막으로 회의록에는 ‘결정하지 않은 것’을 한 줄 남긴다. “이번 결정은 데이터 보관 기간을 확정하지 않는다”, “이번 보류는 기존 시스템의 즉시 교체를 요구하지 않는다”처럼 범위를 제한한다. 이 문장은 보류가 다른 의사결정을 몰래 포함하는 일을 막아 준다. 서로 다른 문제를 한 제안서에 묶어 두면, 한 조건이 충족되어도 어느 부분을 다시 평가해야 하는지 알기 어렵다.

5. 작은 탐색 과제로 분리할 때의 경계

보류가 늘 최종 정지는 아니다. 그러나 ‘조사해 보자’도 조건 없이 쓰면 구현의 다른 이름이 된다. 이때는 원래 제안을 살려 둔 채, 검증 질문 하나만 가진 작은 탐색 과제로 분리하는 편이 낫다. 가령 “새 데이터베이스로 이관한다”는 제안이 보류됐다면, 탐색 과제는 “현재 데이터 모델에서 특정 일관성 요구를 충족할 수 있는가”처럼 더 좁아야 한다. 탐색 과제가 아키텍처 전체를 만드는 단계로 커지면 보류의 안전장치는 사라진다.

탐색 과제에는 산출물과 중단 지점을 함께 둔다. 산출물은 코드가 아니어도 된다. 의존성 목록, 제한된 트래픽의 관찰 계획, 운영 책임 초안, 벤더 문서 비교처럼 다음 결정을 바꿀 수 있는 자료면 된다. 중단 지점은 “이 질문에 답하지 못하면 더 구현하지 않고 보류 메모를 갱신한다”라고 쓴다. 이 방식은 탐색이 성과를 보장한다고 말하지 않는다. 대신 탐색이 어떤 불확실성을 줄이려는지, 줄이지 못하면 어떤 결론을 낼지를 투명하게 만든다.

팀에 이미 RFC나 ADR 관행이 있다면 새 도구를 도입할 필요도 없다. 문서의 상태값에 보류를 추가하고, 위 네 필드를 섹션으로 넣는 것만으로 시작할 수 있다. 반대로 문서 관행이 없다면 스프레드시트나 이슈 트래커의 상태를 먼저 바꾸기보다, 한 건의 중요한 제안에 이 양식을 시험해 보는 편이 좋다. 문서가 읽히는 위치와 소유자가 정해지지 않은 상태에서 상태값만 늘리면, ‘보류’는 또 하나의 오래된 라벨이 된다.

6. 보류 메모를 어디까지 적용할 것인가

모든 작은 선택에 이 문서를 붙이면 결정 비용이 새로 생긴다. 라이브러리의 마이너 버전 업데이트, 되돌리기 쉬운 UI 문구, 한 팀 안에서 바로 검증할 수 있는 작은 실험까지 장문의 보류 메모로 관리할 이유는 적다. 이 글의 방식은 여러 팀의 소유권, 장기 비용, 보안 경계, 되돌리기 어려운 데이터 변경처럼 결정을 미루는 것 자체가 다른 팀의 계획을 바꾸는 경우에 어울린다.

적용 전에는 세 가지를 묻으면 충분하다. 첫째, 이 제안을 미루는 동안 누가 무엇을 기다리는가. 둘째, 재개 조건을 외부 사건과 내부 준비로 나눠 적을 수 있는가. 셋째, 종료하더라도 해결해야 할 사용자 문제는 무엇인가. 세 질문에 답하기 어렵다면, 기술을 더 조사하기 전에 문제 정의나 소유권부터 정리해야 할 가능성이 크다.

보류 문서는 기술을 도입하지 않는 이유를 방어하는 문서가 아니다. 미래의 팀이 같은 논쟁을 처음부터 반복하지 않게 하는 문서다. 승인된 설계가 중요한 것처럼, 지금 하지 않기로 한 설계도 맥락을 남길 가치가 있다. 좋은 기술 리더십은 모든 제안을 앞으로 밀어붙이는 능력이 아니라, 어떤 제안을 언제 다시 열고 언제 조용히 끝낼지를 팀이 함께 알 수 있게 만드는 능력에 더 가깝다.

다음 제안 회의에서 바로 적용해 볼 수 있는 가장 작은 변화는 간단하다. 결론란에 ‘보류’를 썼다면 바로 아래에 재개 조건 한 줄, 재검토일 한 줄, 문서를 갱신할 역할 한 줄을 덧붙인다. 세 줄이 아직 나오지 않는다면 보류가 필요한 이유가 불충분한 것이 아니라, 팀이 무엇을 더 알아야 하는지 아직 말로 만들지 못한 것이다. 그 빈칸을 드러내는 것부터가 이미 더 나은 결정의 시작이다.

참고 자료 (References)

• ADR Organization - Architectural Decision Records Standards & Guidelines
• Martin Fowler - Architecture Decision Records in Practice