비용 센터에서 가치 전환기로: 기술 지원에서의 반가치 전환

전체 텍스트

1 서론

대부분의 제품 조직에서 기술 지원은 비용 센터로 계상됩니다. 예산은 눈에 보이고, 산출물은 처리 완료된 티켓 수로 집계되며, 통상적인 질문은 어떻게 하면 더 저렴하게 운영할 수 있는가입니다. 이 논문은 이러한 틀이 불완전하며, 그 틀이 빠뜨리는 부분이 바로 제품에 가장 중요한 지원의 측면이라고 주장합니다.

이 논증은 가치 관리 이론(Theory of Value Management, VMT)과 Æilus 방법론의 어휘를 사용합니다. 가치, 반가치, 가치 흐름, 가치 체계, 가치 변환기, 그리고 계획 가치, 실현 가치, 회고 가치는 이 시리즈의 첫 번째 논문에서 정의한 대로 사용합니다. 가치 통화인 Æ의 형식적 논의는 Bolshakov (2026)에 제시되어 있으며 여기서는 반복하지 않습니다.

주요 출처는 Æilus 문서 "Technical Support Service - Anti-Value Conversion" (Bolshakov, 2025)입니다. 이 문서는 지원을, 고객으로부터 반가치를 받아 가치로 변환하는 가치 변환기의 사슬로 기술하며, 이때 변환 계수는 각 라인마다 커지고, 모든 단계에서 측정해야 할 두 가지 계수를 제안합니다. 이 논문은 해당 모델을 다시 서술하고, 계수를 운용 가능하게 만들며, 그 계수가 누구의 가치를 측정하는지 명시하고, 측정 프로토콜을 제안합니다. 현장 데이터는 포함하지 않으며, 작업 예시의 모든 수치는 설명을 위한 것입니다.

이 논문은 VMT 공리 A1(맥락성), A2(다중 해석), A4(계획과 사실의 비대칭), A5(반가치의 독립성), A6(소비 시점의 실현), A7(변환), A12(가치 비보존), A13(부분적 통약 가능성)과, 정리 T2(흐름 반전), T4(저항의 누적), T5(국소 최적화), T9(숨겨진 흐름), T14(해석되지 않은 가치는 소실된다), T15(경계 의존성), T16(실현 없는 해석에 의한 확장)에 의존합니다.

2 지원이 비용 센터로 취급되는 이유와 그것이 가리는 것

2.1 비용 관점은 경계 선택이다

비용 센터 관점은 가치 체계의 경계를 회사의 재무 흐름 둘레에 그은 결과입니다. 그 경계 안에서 지원은 급여와 도구를 소비하고 수익 항목은 만들어 내지 않습니다. A1에 따르면 가치는 가치 체계 안에서만 존재하며, T15에 따르면 경계를 바꾸면 현실은 바뀌지 않은 채 결론만 바뀝니다. 비용 관점은 하나의 가치 체계에 대한 올바른 해석이지, 지원이 하는 일에 대한 서술이 아닙니다.

T2는 하나의 흐름이 서로 다른 체계에서 상반된 해석을 담을 수 있다고 말합니다. 회사가 비용으로 계상한 지원 상호작용은 고객에게는 반가치의 제거입니다. 즉 더 이상 고통을 주지 않는 장애, 더 이상 업무를 막지 않는 질문입니다. 출처는 지원이 제공하는 열 가지 고객 가치를 열거하는데, 사고 반가치의 감소와 시간 절약에서부터 위험 감소와 신뢰까지 이릅니다. 이 가운데 비용 보고서에 나타나는 것은 없습니다.

2.2 비용 관점이 가리는 것

• 고객 측 가치. 지원은 고객의 가치 흐름을 복원합니다. 지원이 이를 멈추면 고객의 참여 조건(A8)이 위태로워지며, T7은 고객이 떠나거나 참여 형태를 바꿀 것이라고 예측합니다.
• 내부 가치. 출처는 세 가지 내부 흐름을 꼽습니다. 사고 정보, 경쟁사가 가진 기능에 대한 요청, 그리고 고객의 독창적인 제안입니다. T9에 따르면 모델이 보여 주지 않는 흐름으로 유지되는 구조는 잘못 모델링되었거나 경계가 잘못 설정된 것입니다. 지원에 대한 비용 모델이 바로 그러한 모델입니다.
• 변환. 출처는 지원이 반가치를 가치로 변환하며, 문제가 더 깊은 라인과 제품에 이르면 그 결과가 원래의 반가치를 여러 자릿수만큼 넘어설 수 있다고 주장합니다. A12는 이를 허용합니다. 하나의 근본 원인을 고치면 신고자만이 아니라 모든 고객의 반가치가 제거되기 때문입니다.

3 반가치 흐름의 진입점으로서의 지원

모든 제품은 가치와 반가치를 함께 전달합니다. A5에 따르면 반가치는 독립된 범주입니다. 고객은 제품에서 실제 가치를 받으면서 같은 주에 장애로부터 실제 반가치를 받을 수 있습니다. 지원은 그 반가치의 대부분이 관측 가능한 흐름으로서 회사에 들어오는 지점입니다. 이 논문은 이를 1선 접수에 대한 출처의 설명과 일관되게 네 종류로 묶습니다.

• 사고. 작동하던 것이 작동을 멈춘 경우입니다.
• 결함. 의도대로 작동한 적이 없는 경우입니다. 고객이 마주칠 때 반가치가 드러납니다.
• 혼란. 제품은 작동하지만 고객이 그로부터 가치를 얻지 못하는 경우입니다.
• 깨진 기대. 계획 가치와 실현 가치가 다른 경우입니다. A4는 이것이 정상이라고 말하며, 지원은 그 간극이 보고되는 곳입니다.

다섯 번째 입력은 잠재 가치, 즉 요청과 제안입니다. 출처는 이를 별도로 다루며 그 양에 제한이 없다고 설명합니다. 이는 같은 채널을 공유하므로, 두 개의 분모가 섞이지 않도록 측정에서는 이를 반가치와 분리해 두어야 합니다.

진입점이 중요한 이유는 T4, 즉 저항이 누적되기 때문입니다. 대기열에 방치된 반가치는 복리로 쌓여 신뢰의 상실로 이어지고, T6에 따라 미래 가치를 실현하는 능력의 저하로 이어집니다. 제품 개발에서의 대기열 동역학은 잘 설명되어 있습니다(Reinertsen, 2009). VMT의 해석은 여기에 더하여, 지원 대기열에서 기다리는 것이 고객의 가치 체계 안에서 누적되고 있는 반가치라고 봅니다.

4 변환 사슬

A7에 따르면 변환이란 행위자가 들어오는 가치를 실현하거나, 여기서처럼 들어오는 반가치를 흡수하여 새로운 계획 가치를 만들어 내는 것을 뜻합니다. 출처는 각 지원 라인을 그러한 변환기로 보며, 각각 고유한 가치 변환기 책임자(Value Transformer Owner, VTO)를 둡니다.

4.1 1선

출처는 1선에 다음을 맡깁니다. 반가치 흐름을 구조화된 티켓으로 접수하기, 첫 접촉에서 반가치를 신속히 완충하기, 지속적인 가치 흐름 유지하기, 라우팅, 데이터 수집, 고객 기대 관리, 반가치의 깊이 평가입니다. 1선의 역할은 필터, 충격 흡수기, 가속기입니다. 대부분 고객의 이전 상태를 복원하는 일이며, 그래서 출처는 1선에 가장 낮은 계수를 부여합니다. 기대 관리는 주목할 만합니다. 상태 안내는 아무것도 고치지 않지만 불확실성이라는 반가치를 줄이는데, 이는 A5의 직접적인 사례입니다.

4.2 2선

2선은 복잡한 반가치를 맡습니다. 어려운 버그, 통합, 성능 문제입니다. 출처의 핵심적인 전환은 문제를 억누르는 데서 근본 원인을 제거하는 데로, 그리고 한 고객에서 모든 고객으로 나아가는 것입니다. 수정과 갱신된 안내가 고객 기반 전체로 퍼지기 때문입니다. 또한 2선은 1선의 역량을 높이는 지식 베이스를 구축하고, 반복되는 사고를 백로그로 보내며, 기술 부채와 같은 숨은 반가치를 줄입니다.

4.3 3선

출처는 3선을 전략 수준의 변환기라고 부르며, 아키텍처, 코드, 프로토콜, 핵심 로직에 뿌리를 둔 반가치를 다룹니다. 그 산출물은 기능과 아키텍처의 변경, 그리고 새로운 변환기입니다. 즉 반가치를 계속 변환하는 도구, 스크립트, 모니터링, 자동 점검입니다. 3선은 또한 복잡한 사례에서 가치와 반가치를 어떻게 측정할지를 포함하여 하위 라인의 규칙을 정합니다. 출처는 변경이 고객에게 도달하기 전에는 상승분을 정량화하기 어렵다고 지적하는데, 이는 운용 관점에서 본 A6입니다.

4.4 Product Owner

출처는 Product Owner 팀을 그다음 변환기이자 가치 합성자로 위치시킵니다. 이 팀은 모든 라인에서 오는 흐름의 우선순위를 정하고, 전략과 정렬하며, 비용, 시간, 위험 면에서 반가치가 가장 낮으면서 고객 가치가 가장 높은 곳이 어디인지 평가하고, 시장의 필요로부터 잠재 가치를 더합니다. 산출물은 기존 가치를 확장하고 새로운 가치를 창출하는 전달 계획입니다. 출처는 이를 PDCA와 연결합니다. 지원 데이터로 Plan, 전달 팀이 Do, 사고와 가치 지표로 Check, 전략과 제품에 대해 Act입니다. 갱신된 제품은 다시 가치를 전달하고, 지원은 다음 흐름을 포착하며, 고리가 닫힙니다.

5 출처에서 제안된 계수

5.1 라인별 명목 계수

폐쇄 루프에 대한 출처의 요약은 1선에서 포착된 반가치가 x1에서 x1.5의 계수로, 2선에서는 x10, 3선에서는 x100의 계수로 가치로 변환될 수 있다고 말합니다. 고객의 제안은 양에 제한이 없다고 설명되며 2선과 3선으로 넘어가고, Product Owner가 고객에게 돌려주는 가치는 잠재적으로 사실상 무한하다고 설명됩니다. 패턴은 이렇습니다. 문제가 클수록 더 높은 라인에 도달하고, 라인이 높을수록 계수가 높습니다. 출처는 이것을 측정값이 아니라 자릿수 규모로 제시합니다. 이 논문은 이를 가설로 다룹니다.

5.2 VAM과 ACM

출처는 각 단계에서 두 가지 매개변수를 측정해야 한다고 결론짓습니다.

• Value Amplification Multiplier (VAM), 가치 전달 계수: "고객에게 얼마만큼의 가치가 수신되고 전달되었는가".
• Anti-Value Conversion Multiplier (ACM), 반가치-가치 전환 계수: 얼마만큼의 반가치가 수신되었고 그중 얼마만큼이 고객을 위한 가치로 전환되었는가.

원문은 이를 말로만 기술하며 공식을 제시하지 않습니다. 여기서 제안하는 최소한의 비율 해석은, 검토 기간 동안의 단계 s(1선, 2선, 3선, Product Owner)에 대해 다음과 같습니다:

VAM_s = V_delivered,s / V_received,s

ACM_s = V_converted,s / AV_received,s

V_received,s는 해당 단계로 들어오는 가치(제안 또는 부분적으로 변환된 잠재 가치)이고, V_delivered,s는 해당 단계의 산출물에 기인하는 실현된 고객 가치이며, AV_received,s는 해당 단계로 들어오는 반가치이고, V_converted,s는 그로부터 생산된 실현된 고객 가치입니다. 모든 항은 Æ 단위입니다.

원문의 표현에서 두 가지 해석이 도출됩니다. 첫째, 분자는 고객을 위한 가치이므로 계획, 티켓, 백로그 항목은 고객이 실현한 이후에만 계산됩니다(A6). 둘째, 두 계수는 분모가 서로 다릅니다. 하나는 가치의 증폭을, 다른 하나는 반가치의 전환을 추적합니다. 체인 수준의 계수는 ACM_chain = sum of V_converted,s / AV_received,1이며, 접수 시점의 반가치를 분모로 하고 실현된 가치의 각 단위는 한 단계에만 귀속됩니다.

6 누구의 가치를 측정하는가

A1과 A2에 따르면 가치 체계(value system)가 명시되지 않은 계수는 의미가 없습니다. 이 체인은 네 개의 가치 체계와 접하고 있습니다:

이 논문은 측정을 다음과 같이 확정합니다. VAM과 ACM의 분자는 고객의 가치 체계에서 측정됩니다. 실현된 가치는 수신자의 해석이기 때문입니다. 분모는 고객-지원 경계에서 측정됩니다. 즉 고객이 경험하고 보고한 대로의 반가치를 1선이 기록합니다. 지원 및 제품 체계는 이 계수를 사용하고, 회사 체계는 이를 비용과 대비하여 평가합니다. VSO는 부분적으로만 통약 가능한(A13) 이러한 해석들을 비교하기 위한 집계 정책(policy)을 소유합니다. 만약 지원 조직이 자신의 가치 체계에서 스스로를 측정한다면, 노력과 계획된 가치를 보고하게 될 것입니다. 원문의 정의는 바깥을 향하고 있으며, 프로토콜은 그것을 그대로 유지합니다.

7 측정 프로토콜

아래 프로토콜은 현장에서 검증되지 않은 제안이며, 기존의 티켓 및 백로그 도구와 함께 작동하도록 설계되었습니다.

7.1 기록할 데이터

• 접수 시: 고객과 제품 사용 현황, 입력 유형(장애, 결함, 혼란, 깨진 기대, 제안), 가능한 경우 고객과 확인한 공유 척도상의 Æ 단위 반가치 추정치, 영향을 받는 도메인.
• 각 인계 시: 수신 단계와 사유, 해결 유형(상태 복구, 해당 고객에 대해 수정, 근본 원인 제거, 새로운 변환기 생성, 백로그 항목 등록), 티켓과 백로그 항목 및 릴리스 간의 연결, 제안된 변경의 계획된 가치(실현된 가치와 별도로 유지).
• 전달 후: 고객 또는 합의된 대리 지표로 확인된 Æ 단위의 실현된 가치, 도달한 고객 수, 이후의 회고적 재평가.

7.2 실현된 가치를 검증하는 주체

공로를 주장하는 변환기는 자신이 실현한 가치를 스스로 검증하지 않습니다. 고객이 명시적 확인 또는 사전에 합의된 대리 지표(장애가 재발하지 않음, 기능이 사용됨)를 통해 이를 해석합니다. 각 라인의 VTO는 추정치를 제안하고 로그 품질을 책임집니다. 제품 VTO는 전달된 변경 중 어떤 것이 어떤 지원 입력으로 거슬러 올라가는지 확인합니다. VSO는 귀속 분쟁을 판정합니다. 계획된 가치는 기록되지만 A4와 T16에 따라 분자에 결코 들어가지 않습니다. 해석만으로 가치 주장을 확대하는 것은 구조적으로 불안정하기 때문입니다. 3선에 대한 원문의 x100은 변경이 고객에게 도달하기 전까지는 그러한 주장에 해당합니다.

7.3 검토 주기

• 티켓별, 종료 시: 접수 시 추정치, 해결 유형, 1선의 실현된 가치.
• 라인별, 짧은 정기 주기로: 완료된 항목의 ACM과 VAM, 대기열에 있는 미해결 반가치의 경과 기간(T4), 에스컬레이션 사유.
• 체계별, 더 긴 주기로: VSO와 제품 VTO가 전달된 변경, 회고적 재평가, 총 반가치 유입량, 그리고 라인별 계수가 원문이 예측하는 순서를 따르는지를 검토.

실현에는 시차가 있으므로, 계수는 코호트(cohort), 즉 반가치가 수신된 기간별로 보고해야 합니다.

7.4 함정

Goodhart (1975)는 통계적 규칙성이 통제에 사용되는 순간 무너지는 경향이 있다고 관찰했습니다. VMT 용어로는 이것이 T5, 즉 국소 최적화가 전역적 개선을 보장하지 않는다는 것입니다.

• 티켓 수 조작. 하나의 문제를 여러 티켓으로 쪼개면 처리량이 부풀려집니다. VAM과 ACM은 건수가 아니라 Æ 단위의 비율이지만, 티켓 수를 이들과 나란히 목표로 설정해서는 안 됩니다.
• 접수량 축소. 반가치를 과소평가하면 ACM이 높아집니다. 접수 시 추정치에는 공유된 척도와 표본 추출 방식의 고객 확인이 필요합니다.
• 과도한 에스컬레이션. 상위 라인이 더 높은 계수를 보이면 에스컬레이션이 유혹적이 됩니다. 이는 3선이 정한 에스컬레이션 규칙에 비추어 판단되어야 합니다.
• 이중 계산. 동일한 실현된 가치를 여러 단계가 주장할 수 있습니다. 각 단위는 한 번만 배정됩니다.
• 유입 은폐. 최선의 결과는 지원 조직에 도달하는 반가치가 줄어드는 것인데, ACM은 이를 볼 수 없습니다. 총 유입량을 계수와 함께 보고해야 하며, 그 감소는 하나의 성과로 해석되어야 합니다.
• 신호 누락. T14에 따르면 해석되지 않은 가치는 사라집니다. 로그는 얼마나 많은 제안과 패턴이 제품 의사결정에 도달했는지 보여주어야 합니다.

8 서비스 도메인과의 관계

Æilus 방법론은 도메인(domain)을 허용 가능한 실천법(practices)과 결과에 요구 사항을 부과하는 가치 해석 맥락으로 정의합니다. 도메인은 가치를 창출하지 않으며, 허용되지 않는 반가치를 방지합니다. 지원은 여러 전형적인 도메인과 접합니다:

• Availability and Continuity. 장애는 고객에게 이 맥락의 위반입니다. 연속적인 가치 흐름을 유지해야 하는 1선의 책무는 그 운영적 측면이며, 라우팅은 중요도에 대한 도메인 정책(policy)을 따라야 합니다.
• Security. 방법론은 안전한 참여에 필요한 맥락을 위반하기 때문에 가치가 거부될 수 있다고 지적합니다. 보안을 약화시키는 임시 우회책은 전환이 아니라 새로운 반가치로 기록됩니다.
• Architecture. 원문은 3선의 결정이 아키텍처 무결성, 확장성, 성능, 보안 측면에서 검토될 것을 요구합니다.
• Knowledge Management 및 Continuous Improvement. 2선의 지식 베이스와 PDCA 루프는 이들 도메인의 실천법입니다.

두 가지 귀결이 따릅니다. ACM에 계산되는 실현된 가치는 관련된 모든 도메인에서 허용 가능해야 합니다. 그리고 ACM은 부분적으로 통약 가능한(A13) 도메인들에 걸쳐 가치를 집계하므로, 방법론이 VSO에게 부여한 명시적 집계 정책이 필요하며, 도메인 정책은 도메인 소유자(Domain Owner)가 보유합니다. 방법론은 이것이 없으면 최적화가 국소적 선호나 지표 조작으로 퇴화한다고 경고합니다.

9 예시를 통한 설명

이 예시는 가상의 것입니다. 제품, 고객, 수치는 지어낸 것이며 의도적으로 딱 떨어지는 값입니다. 이는 연구 결과가 아니며 원문의 계수를 검증하지 않습니다.

한 제품에 데이터 가져오기 통합에서 반복적인 장애가 발생합니다. 한 기간 동안 열 곳의 고객이 이를 보고합니다.

• 접수. 각 클라이언트의 반가치는 10 Æ로 추정되므로 AV_received,1 = 100 Æ입니다.
• 1선. 알려진 우회 방법과 상태 업데이트로 업무가 복구되며, 클라이언트는 120 Æ의 실현된 가치를 확인합니다. ACM_1 = 120 / 100 = 1.2이며, 원문의 공칭 범위 안에 있습니다.
• 2선. 구성 관련 근본 원인이 발견되고, 수정된 기본값과 지식 베이스 문서가 신고한 클라이언트와 다른 클라이언트에게 전달됩니다. 확인된 실현 가치는 400 Æ입니다. ACM_2 = 400 / 100 = 4로, 공칭 x10보다 낮습니다. 프로토콜에서 이는 바로잡아야 할 오류가 아니라 검토해야 할 결과입니다.
• 3선과 제품. 가져오기 프로토콜이 취약한 것으로 확인되어, 재설계와 자동 검사가 5,000 Æ의 계획 가치와 함께 로드맵에 올라갑니다. 아직 출시된 것이 없으므로 이 코호트에서 ACM_3 = 0입니다. 5,000 Æ는 기록되지만 산입에서는 제외됩니다.
• 제안. 두 클라이언트가 예약된 가져오기를 요청합니다. 이는 VAM 트랙의 잠재 가치이며 ACM에는 포함되지 않습니다.

이번 검토에서 ACM_chain = (120 + 400 + 0) / 100 = 5.2입니다. 이후 재설계가 출시되고 클라이언트가 가치를 확인하면 3선 코호트는 소급하여 갱신되며, 재설계가 회귀를 일으키면 해당 반가치는 3선에 대해 기록됩니다. 이 예시는 파일럿이 관찰해야 할 것을 보여 줍니다. 가장 깊은 단계에서의 계획과 실제 간의 격차(A4, A6), 실현 지연, 그리고 공칭 계수와의 가능한 괴리입니다.

10 한계

이 논문에도 원문에도 현장 데이터는 없습니다. 계수 x1에서 x1.5, x10, x100은 제안된 규모 수준(order of magnitude)이며, 서술된 메커니즘(하나의 수정이 다수의 클라이언트로 확장되고 새로운 변환기가 만들어지는 것)에서는 그럴듯하지만 측정된 바는 없습니다. 공식은 말로 된 정의에 대한 이 논문의 해석이며, 다른 해석도 가능합니다. Æ 추정치는 해석에 의존하는데, 이는 A2에 따르면 가치의 속성이지만, 팀 간 비교에는 여전히 보정된 공통 척도가 필요하며 이 논문은 이를 제공하지 않습니다. 단계 간 귀속은 규칙 없이 VSO에 할당됩니다.

모델을 뒷받침하거나 약화시킬 수 있는 파일럿은 다음을 보여 주어야 합니다.

• 서로 다른 사람들이 동일한 티켓에 대해 일관된 Æ 추정치를 내놓는다는 것,
• 여러 검토 주기에 걸친 코호트 ACM이 절대값과 관계없이 선(line)별로 예측된 순서를 따른다는 것,
• 실현된 가치가 이를 주장하는 선이 아니라 클라이언트 또는 합의된 대리 지표에 의해 확인되었다는 것,
• 계수를 사용한 후 7.4절에 열거된 조작 없이 반가치 총유입이 감소했다는 것,
• 계수가 서비스 복구 시간과 같은 기존 척도(Forsgren, Humble and Kim, 2018)를 넘어서는 정보를 더해 준다는 것.

11 결론

지원을 비용 센터로만 취급하는 것은 경계의 선택입니다. 회사의 재무 체계에서 지원은 비용이고, 클라이언트의 체계에서는 반가치의 제거이며, 제품의 체계에서는 제품이 어디에서 실패하는지에 대한 가장 직접적인 정보입니다. 원문 모델은 1선에서 3선, 그리고 Product Owner 팀으로 갈수록 레버리지가 커지고, 클라이언트로 되돌아가는 PDCA 순환을 완성하는 변환기의 사슬을 서술하며, 이를 측정하기 위해 VAM과 ACM을 제안합니다. 이 논문은 계수에 최소한의 공식을 부여하고, 분자를 클라이언트의 가치 체계에 고정하며, 실현되고 도메인에서 허용되는 가치만 산입하고, 기록, 검증, 검토 및 조작 방지를 위한 프로토콜을 제안했습니다. 원문의 규모 수준이 성립하는지는 파일럿만이 답할 수 있는 문제입니다.

참고문헌

• Bolshakov, V. Technical Support Service - Anti-Value Conversion. aeilus.tech, 2025.
• Bolshakov, V. Domains and Policies. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Roles. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Forsgren, N., Humble, J. and Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. A. E. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. G. The Principles of Product Development Flow. 2009.