162. 골드 플래팅 (Gold Plating) - 요구사항에 없는 기능 임의 추가 (안티패턴)

핵심 인사이트 (3줄 요약)

본질: 골드 플래팅인 Gold Plating은 합의된 요구사항 범위 밖의 기능이나 장식을 팀 내부가 자의적으로 추가하는 안티패턴이다.

가치: 겉으로는 "더 잘해 주는 것"처럼 보이지만, 실제로는 설계 범위·테스트 범위·운영 부담을 몰래 키워 일정과 품질을 동시에 흔든다.

판단 포인트: 변화 자체가 문제가 아니라 승인 없는 변화가 문제이므로, 범위 크리프 (Scope Creep)와 구분하고 CCB (Configuration Control Board)·코드 리뷰·RTM (Requirements Traceability Matrix)으로 통제해야 한다.

Ⅰ. 개요 및 필요성

골드 플래팅은 고객이나 제품 책임자가 요구하지 않은 기능을 개발팀이 "있으면 더 좋겠다"는 판단으로 임의 추가하는 행위다. 금속 제품에 필요 이상의 금도금을 입혀 비용만 늘리는 데서 나온 표현처럼, 소프트웨어에서도 본래 가치보다 과잉 장식과 과잉 구조가 문제의 핵심이다. 즉 골드 플래팅은 선의의 서비스가 아니라, 통제되지 않은 범위 확대다.

이 개념이 중요한 이유는 소프트웨어에서 추가 기능의 비용이 화면 한 줄 이상으로 번지기 때문이다. 기능이 하나 늘면 설계 문서, 테스트 케이스, 보안 점검, 장애 대응, 운영 매뉴얼, 사용자 교육까지 함께 늘어난다. 그런데 이런 변경이 공식 승인 없이 숨어 들어오면 프로젝트는 계획상 100을 수행하는 것처럼 보이면서 실제로는 120을 수행하게 된다.

골드 플래팅을 방치하면 가장 먼저 일정이 흔들리고, 이후에는 품질과 책임 경계가 흐려진다. 무엇을 왜 만들었는지 기록이 없기 때문에, 문제가 생겨도 정당한 변경인지 불필요한 잉여 기능인지 판단하기 어려워진다. 그래서 프로젝트 관리에서는 "더 많이 만드는 것"보다 "합의한 것을 정확히 만드는 것"이 더 중요하다.

📢 섹션 요약 비유: 골드 플래팅은 손님이 의자를 하나 주문했는데, 목수가 묻지도 않고 조각 장식과 숨겨진 서랍을 잔뜩 붙여 납기를 늦추는 것과 같다. 화려해 보여도 주문한 물건이 제때 오지 않으면 실패다.

Ⅱ. 아키텍처 및 핵심 원리

골드 플래팅은 보통 세 단계로 커진다. 먼저 누군가 미래 확장이나 미적 완성도를 이유로 요구사항 밖 기능을 넣고, 그다음 그 기능이 설계 분기와 의존성을 늘리며, 마지막으로 테스트와 운영 부담이 뒤늦게 따라붙는다. 즉 추가 기능의 본질은 코드 몇 줄이 아니라, 시스템 경계를 넓히는 연쇄 반응이다.

골드 플래팅을 만드는 대표 요인

요인	실제 모습	왜 위험한가
개발자 자의 판단	"나중에 필요할 것 같아서" 미리 구현	현재 요구보다 미래 추측이 우선됨
과도한 사용자 배려	화려한 UI 효과, 불필요한 옵션 추가	성능·접근성·검증 범위 확대
성급한 일반화	아직 없는 확장 시나리오를 위한 추상화	복잡도는 늘고 즉시 가치가 작음
승인 절차 생략	제품 책임자 확인 없이 병합	일정·품질 계획과 불일치 발생

아래 그림은 승인 없는 "선의의 추가"가 왜 안티패턴으로 바뀌는지 보여 준다.

┌────────────────────────────────────────────────────────────────────────────┐
│                    how gold plating creates hidden cost                   │
├────────────────────────────────────────────────────────────────────────────┤
│ Approved requirement                                                      │
│      │                                                                     │
│      ├─ design / build / test / release                                   │
│      │                                                                     │
│      └─ unapproved extra feature                                           │
│             ├─ extra branches in code                                      │
│             ├─ extra dependencies                                          │
│             ├─ extra test cases                                            │
│             └─ extra operational support                                   │
│                                ▼                                           │
│                     delay / defect risk / technical debt                   │
└────────────────────────────────────────────────────────────────────────────┘

이 그림의 핵심은 "기능 하나 더"가 독립적으로 존재하지 않는다는 점이다. 추가 기능이 들어오면 제어 흐름이 늘고, RTM에 없는 코드가 생기며, 테스트와 운영이 모두 그 후행 비용을 떠안게 된다. 그래서 YAGNI (You Aren't Gonna Need It) 원칙은 미래를 대비하지 말라는 뜻이 아니라, 승인되지 않은 가정을 현재 시스템에 심지 말라는 뜻으로 읽어야 한다.

결국 골드 플래팅의 메커니즘은 기술 문제가 아니라 통제 문제다. 요구사항과 코드 사이에 추적성이 유지되면 정당한 변경이 되지만, 추적성이 끊기면 같은 기능도 안티패턴이 된다.

📢 섹션 요약 비유: 골드 플래팅은 이삿짐 목록에 없는 가구를 몰래 트럭에 싣는 일과 같다. 가구 하나는 좋아 보여도, 무게와 배치와 운반 시간이 모두 다시 꼬인다.

Ⅲ. 비교 및 연결

골드 플래팅은 범위 크리프, 정당한 변경 요청과 구분해야 한다. 범위 크리프는 주로 외부 이해관계자의 비공식 요구가 조금씩 들어오는 현상이고, 골드 플래팅은 내부 팀이 스스로 범위를 넓히는 경우가 많다. 반면 정당한 변경 요청은 영향도 분석과 승인 절차를 거쳐 일정·비용·우선순위가 함께 조정된다.

구분	골드 플래팅	범위 크리프	정당한 변경 요청
발생 주체	내부 개발팀·디자인팀	고객·이해관계자	공식 변경 프로세스
승인 여부	대개 없음	약하거나 없음	명확히 존재
문서 추적성	RTM 누락 가능성 큼	늦게 반영되기 쉬움	요구사항, 일정, 테스트에 반영
결과	과잉 구현, 유지보수 부담	일정 지연, 범위 불명확	통제된 범위 조정

이 개념은 MVP (Minimum Viable Product), YAGNI, 기술 부채 (Technical Debt), 완료 기준과도 연결된다. MVP는 지금 필요한 최소 가치에 집중하게 만들고, YAGNI는 미래 가정을 현재 코드에 심는 습관을 줄인다. 반대로 골드 플래팅은 "미래에 쓸지도 모른다"는 명분으로 현재 복잡도를 앞당겨 가져오는 행동이다.

그래서 기술사 답안에서는 골드 플래팅을 단순히 "불필요한 기능 추가"라고만 쓰기보다, 왜 범위 관리 실패와 기술 부채로 이어지는지까지 연결해야 한다. 그래야 프로젝트 관리와 소프트웨어 설계를 하나의 문맥으로 설명할 수 있다.

📢 섹션 요약 비유: 범위 크리프가 밖에서 자꾸 짐을 더 들여오는 상황이라면, 골드 플래팅은 집주인이 혼자 필요 없는 가구를 계속 사 오는 상황과 같다. 둘 다 집이 복잡해지지만 원인이 다르다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 골드 플래팅은 주로 "좋아 보이는 추가"의 형태로 등장한다. 예를 들어 단순 조회 화면에 무거운 애니메이션 라이브러리를 넣거나, 현재 요구에 없는 소셜 로그인 공급자를 미리 붙이거나, 아직 필요 없는 확장 포인트를 위해 과도한 추상화 계층을 만드는 경우가 대표적이다. 이런 코드는 데모 단계에서는 인상적일 수 있지만, 성능·보안·테스트 범위를 몰래 키워 후반부에 비용을 폭발시킨다.

따라서 프로젝트 리더와 아키텍트는 "좋은 아이디어"와 "지금 반영해도 되는 아이디어"를 구분해야 한다. 필요하다면 제품 백로그에 기록해 다음 릴리스 후보로 남기고, 현재 범위에는 넣지 않는 판단이 중요하다. 즉 좋은 개선 제안도 승인 전에는 구현이 아니라 후보 상태로 유지되어야 한다.

판단 체크리스트

이 기능이 현재 승인된 요구사항 또는 백로그 우선순위에 포함되는가?
추가 기능의 테스트·보안·운영 비용까지 함께 산정했는가?
제품 책임자나 CCB 승인을 받았는가?
지금 구현하지 않아도 되는 미래 가정을 코드에 심고 있지 않은가?

안티패턴

사용자 요구 없이 개발자가 판단한 부가 기능을 바로 병합하는 경우
미리 확장하려고 인터페이스와 추상 계층을 과도하게 늘리는 경우
코드 리뷰에서 "좋은 뜻이니까"라는 이유로 추적성 없는 변경을 통과시키는 경우
📢 섹션 요약 비유: 골드 플래팅 방지는 시험에서 정답만 정확히 쓰는 태도와 같다. 아는 것을 더 많이 쓰는 것이 아니라, 문제에서 요구한 답을 빠짐없이 맞추는 것이 점수를 만든다.

Ⅴ. 기대효과 및 결론

골드 플래팅을 막으면 프로젝트는 기능 수를 줄이는 대신, 요구사항과 산출물의 대응 관계를 더 선명하게 유지할 수 있다. 그 결과 일정 예측력이 높아지고, 테스트 범위가 명확해지며, 운영 이후에도 왜 이 기능이 존재하는지 설명하기 쉬워진다. 즉 단순함은 빈약함이 아니라, 통제 가능한 품질의 조건이다.

물론 혁신적 제안 자체를 금지하자는 뜻은 아니다. 좋은 아이디어는 백로그와 변경 관리 절차를 통해 적절한 시점에 반영하면 된다. 따라서 골드 플래팅은 "더 잘하려는 마음"을 부정하는 개념이 아니라, "승인되지 않은 잘함은 프로젝트를 흔들 수 있다"는 경계 규칙으로 기억하는 것이 맞다.

📢 섹션 요약 비유: 좋은 프로젝트 운영은 선물을 금지하는 것이 아니라, 선물도 배송 목록에 올려 정확히 보낼 때만 받는 것과 같다. 목록에 없는 선물은 오히려 배송을 망칠 수 있다.

📌 관련 개념 맵

개념	연결 포인트
범위 크리프 (Scope Creep)	외부 요구로 범위가 늘어나는 유사 현상으로, 골드 플래팅과 구분해야 한다.
CCB (Configuration Control Board)	변경의 정당성 여부를 심사해 골드 플래팅을 공식 변경과 구분한다.
RTM (Requirements Traceability Matrix)	구현 코드가 어떤 요구사항과 연결되는지 추적하게 해 준다.
YAGNI	승인되지 않은 미래 대비 코드를 줄이는 핵심 원칙이다.

📈 관련 키워드 및 발전 흐름도

요구사항 베이스라인 확정
        │
        ├── 변경 요청 + 영향도 분석 + 승인
        │          │
        │          ▼
        │     통제된 기능 확장
        │
        └── 내부의 임의 추가 구현
                   │
                   ▼
         골드 플래팅 (Gold Plating)
                   │
                   ▼
         일정 지연 · 기술 부채 · 유지보수 비용 증가

이 흐름은 같은 "기능 추가"라도 승인과 추적성이 있으면 변경 관리가 되고, 없으면 골드 플래팅으로 떨어진다는 점을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

친구가 연필 하나 빌려 달랬는데, 내가 묻지도 않고 무거운 색연필 가방까지 같이 주는 게 골드 플래팅이에요.
더 많이 주는 것처럼 보여도, 친구는 오히려 들고 가기 힘들고 늦어질 수 있어요.
그래서 필요한 것만 정확히 주고, 더 필요한 게 있으면 먼저 다시 물어봐야 해요.