가치 체계 스키마로 소프트웨어 제공에서 가치 흐름 측정하기

전체 텍스트

1 서론

소프트웨어 팀은 면밀하게 측정됩니다. 속도(velocity), 처리량, 리드 타임, 배포 빈도, 변경 실패율은 자동으로 수집됩니다. 그러나 이러한 수치는 한 가지 질문을 남겨 둡니다. 팀은 어떤 가치를, 누구에게, 손실이라는 어떤 비용을 치르고 전달했는가?

이 논문은 그 질문에 답하는 방법을 제안하며, 그 방법은 Æilus 방법론의 모델링 표기법인 가치 체계 스키마(Value System Schema, VSS)를 사용하고, aeilus.tech에 공개된 VSS Editor로 구현됩니다. 이 논문은 "Æilus for Business" 시리즈의 다섯 번째 논문입니다. 시리즈의 첫 번째 논문인 "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Bolshakov, ÆVRI, 2026)에서 정의한 어휘를 사용하며, 그 정의를 반복하지 않습니다. 측정 가능한 통화(Æ)로서의 가치에 대한 형식적 논의는 "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026)에 제시되어 있습니다.

이 논문은 전달 조직이 자신의 가치 체계 스키마를 구축하고, 릴리스에 계획된 가치와 실현된 가치를 부여하며, 흐름 저항과 누출을 찾아내고, 공유 기술 노드를 평가하며, 명확한 역할과 주기로 이 사이클을 운영하는 방법을 설명합니다. 이 논문은 VMT 공리 A1, A2, A4, A5, A6, A7, A11, A13과 정리 T3, T4, T5, T6, T8, T9, T15, T16, T17에 의존합니다. 측정 데이터는 포함하지 않습니다. 9절의 사례는 합성된 것입니다.

2 전달 지표가 측정하는 것과 측정하지 않는 것

전달 지표는 작업의 움직임을 기술합니다. 속도는 완료된 추정 작업량을 세고, 처리량은 완료된 항목을 셉니다. Forsgren, Humble과 Kim(Accelerate, 2018)이 널리 알린 네 가지 핵심 지표, 즉 배포 빈도, 변경 리드 타임, 서비스 복구 시간, 변경 실패율은 전달 파이프라인의 속도와 안정성을 기술합니다. 이 연구는 이러한 역량을 조직 성과와 연결하며, 이 논문은 그 연구에 이의를 제기하지 않습니다. 이 논문의 주장은 더 좁습니다. 이러한 지표는 파이프라인을 기술할 뿐, 그 파이프라인을 통과하는 가치를 기술하지 않는다는 것입니다.

이로부터 세 가지 간극이 생깁니다.

• 노력은 가치가 아닙니다. 속도가 높은 스프린트도 아무도 사용하지 않는 기능을 전달할 수 있습니다. Product Value System deck의 표현으로 "features are not value"이고 "metrics are not value"입니다. 기능은 가치에 대한 가정이고, 지표는 그 가정에 대한 해석입니다.
• 속도는 방향이 아닙니다. 짧은 리드 타임은 잘못된 가설을 더 빨리 전달합니다.
• 안정성은 반가치(anti-value)의 부재가 아닙니다. 낮은 변경 실패율은 지연, 혼란, 사용자 측의 재작업, 또는 설계된 그대로 작동한 변경이 초래한 신뢰 상실에 대해 아무것도 말해 주지 않습니다.

가치 관리 이론(Value Management Theory, VMT)의 관점에서 이 간극은 구조적입니다. 가치는 정의된 가치 체계 안에서만 존재하며 그 행위자들이 해석합니다(A1, A2). 가치는 소비 시점에 실현되고(A6), 계획된 가치와 실현된 가치는 대체로 다릅니다(A4, T3). 파이프라인 지표는 소비 이전, 송신자 측에서 수집되므로 기껏해야 계획된 가치의 전달만을 기술합니다. 이러한 지표가 목표가 되면 Goodhart(1975)가 기술한 효과가 나타납니다. 팀이 계수기를 최적화하는 것입니다. VMT는 같은 위험을 체계의 용어로 이렇게 말합니다. 국소적 최적화는 전역적 개선을 보장하지 않습니다(T5).

3 가치 체계 스키마 표기법

3.1 표기법의 요소

Æilus 방법론에서 가치 체계 스키마는 첫 번째 핵심 산출물입니다. 이는 가치 체계, 그 행위자, 흐름, 변환기, 핵심 교환에 대한 형식적 기술이며, 체계의 경계를 설정하고 보이지 않는 외부 의존성을 방지하는 데 사용됩니다. VSS는 변환기 수준 또는 체계 수준에서 그릴 수 있습니다.

2025년 12월 aeilus.tech에 공개된 VSS Editor는 이러한 스키마를 위한 브라우저 기반 시각 편집기입니다. 이 표기법에는 소수의 요소가 있습니다.

• 컨버터. 컨버터(converter)는 스키마에서 변환기 역할을 가리키는 Æilus의 명칭입니다. 팀, 서비스, 하위 체계와 같은 기능 블록으로서 가치 요소를 받아 변환하고 새로운 가치 요소를 생산합니다. 컨버터는 가치가 생성, 증폭 또는 파괴되는 지점입니다.
• 흐름. 흐름(flow)은 컨버터 사이, 또는 컨버터와 외부 세계 사이의 방향성 있는 연결입니다. 흐름은 Æ 단위의 가치 또는 반가치의 양을 운반합니다. 흐름은 외부 유입(체계로 들어오는 가치), 외부 유출(체계를 떠나는 가치), 또는 내부(컨버터 사이의 가치)입니다.
• 입력과 출력. 외부 유입과 유출은 가치가 들어오고 나가는 지점을 표시합니다. 이들이 함께 체계의 경계를 정의합니다.
• 가치 요소. 요소 유형은 흐름을 통해 정확히 무엇이 이동하는지를 기술합니다. 고객 가치, 수익, 비용, 위험, 기술 부채 등이 그것입니다. 저장된 스키마에서 각 요소는 종류(가치 또는 반가치), 부호, 수량, 단위(Æ)를 가집니다.
• 반가치. 반가치는 손실과 부정적 효과를 나타냅니다. 지연, 재작업, 결함, 관료주의, 위험, 번아웃, 낭비된 노력 등이 그것입니다. 스키마에서 반가치는 가치의 부재가 아니라 음의 부호를 가진 명시적 요소입니다(A5).

3.2 기계 판독 가능한 모델로서의 스키마

편집기는 스키마를 노드(컨버터), 흐름, 요소로 구성된 구조화된 JSON으로 저장합니다. 따라서 스키마는 제품과 함께 버전 관리될 수 있으며, 이후 흐름별로 계획된 수량과 실현된 수량을 비교하는 분석에서 읽을 수 있습니다. 이러한 분석은 향후 과제로 예고되어 있으며 여기서는 전제하지 않습니다.

3.3 스키마가 아닌 것

VSS Editor는 명시적으로 KPI 대시보드, BI 도구, 시뮬레이션 엔진, 또는 재무 회계의 대체물이 아닙니다. 이 도구는 계산보다 명확성을 우선합니다. 권장되는 모델링 순서는 다음과 같습니다. 경계를 정의하고, 주요 컨버터만 추가하고, 이름 있는 흐름으로 연결하며(숫자보다 이름, 정밀도보다 방향), 그다음 반가치를 표시합니다. 이 단계에서 가장 많은 통찰이 나오는 경우가 많습니다.

4 누구의 가치인가: 체계와 그 경계

가치의 측정은 누구의 가치를 측정하는지 밝히기 전에는 의미가 없습니다(A1, T1). 선택한 경계는 현실이 전혀 바뀌지 않아도 결론을 바꿉니다(T15). 따라서 이 논문은 어떤 측정보다 먼저 가치 체계를 확정합니다.

여기서 모델링하는 가치 체계는 제품 조직 안에 있는 단일 소프트웨어 제품의 제품 가치 체계입니다. Product Value System deck에 따르면 그 행위자는 제품 기능, 개발 팀, 운영, 운영 환경의 제품, 사용자, 그리고 사용자가 돌려주는 가치의 수령자인 회사입니다. 재무는 외부의 지원 유입(급여)입니다.

두 가지 실현된 해석을 측정합니다. 하나는 사용자 또는 그들의 관찰 가능한 행동이 해석하는 사용자 가치이고, 다른 하나는 환원 흐름(수익, 유지, 비용 또는 위험 감소)의 수령자인 회사가 해석하는 회사 가치입니다. 계획된 가치는 릴리스 이전 송신자의 해석입니다. 같은 릴리스가 파트너나 규제 기관에 갖는 가치는 명시적으로 확장하지 않는 한 경계 밖에 있습니다.

5 제품 가설에서 실현된 가치로: 가치 루프

Product Value System deck은 제품 작업을 가치 가설이 생성, 구현, 검증, 유지되는 루프로 틀(frames)을 짭니다. 스키마 용어로 이 루프에는 다음과 같은 컨버터와 흐름이 있습니다.

1. 제품 기능에 대한 투자. 제품 기능은 자원과 사용자 신호를 계획된 가치를 지닌 가설로 변환합니다.
2. 제품 기능에서 개발로. 가설은 계획된 가치를 가진 백로그 항목이 됩니다. deck은 두 가지 기대를 제시합니다. 가설의 계획된 가치는 구축되는 동안 감소해서는 안 되며, 전달된 가치는 계획된 가치와 크게 다르지 않아야 합니다.
3. 개발에서 운영으로. 개발은 노력을 소비하여 작동하는 변경을 생산하며, 반가치(기술 부채, 결함, 지연)도 함께 생산합니다.
4. 운영에서 운영 환경으로. 변경은 실행 중인 소프트웨어가 되며, 릴리스 오류와 다운타임은 반가치로 나타납니다.
5. 운영 환경에서 사용자로. 가치는 사용 중에만 실현되므로(A6), 이것은 실현된 가치를 관찰할 수 있는 첫 번째 지점입니다.
6. 사용자에서 회사로. 사용자는 수익, 유지, 신뢰를 돌려줍니다. 2022년 1월 저자의 채널 게시물은 이를 닫힌 흐름이라고 부릅니다. 고객에게 전달된 가치는 되돌아오는 가치와 균형을 이루며, 그것은 흔히 돈이지만 돈만은 아닙니다.

이 루프는 변환 공리(A7)를 구체화합니다. 각 컨버터는 받은 것을 실현하고 다음 컨버터를 위한 새로운 계획된 가치를 생산합니다. 또한 파이프라인 지표가 3단계와 4단계만을 다루는 이유도 보여 줍니다. 가치가 계획되고, 실현되고, 되돌아오는 1, 2, 5, 6단계는 파이프라인 밖에 있습니다.

이 자료는 내부 및 외부 제품에 대해 관찰 가능한 요소 유형도 나열합니다. 가치 요소에는 절약된 시간, 줄어든 운영 오류, 현금 흐름, 위험 감소, 낮아진 인지 부하, 예측 가능성, 새로운 역량, 신뢰가 포함됩니다. 이에 대응하는 반가치 요소에는 손실된 시간, 재작업, 증가하는 운영 비용, 기술 부채, 예측 불가능성, 수작업 우회, 신뢰 상실, 저하된 고객 서비스가 포함됩니다. 이 유형 체계는 전달(delivery)을 위한 가치 요소 등록부의 출발점입니다.

6 릴리스별 계획 가치와 실현 가치, 저항과 누출

6.1 비교 단위로서의 릴리스

비교 단위는 릴리스이며, 릴리스가 작을 때는 백로그 항목입니다. 각각에 대해 이 방법은 Æ에 다음을 기록합니다.

• 계획 가치: 발신자의 추정치로, 개발이 시작되기 전에 기록되며 명시적으로 기록된 결정을 통해서만 갱신됩니다.
• 실현 가치와 실현 반가치: 릴리스가 합의된 관찰 기간 동안 사용된 후의 수신자의 해석입니다.
• 회고 가치: 2차 효과(지원 부담, 이탈, 기술 부채)가 드러난 뒤의 후속 재평가입니다.

이 자료는 단계적 도입을 제안합니다. 먼저 모든 백로그 항목에 계획 가치를 부여하고, 다음으로 릴리스된 모든 항목에 실현 가치와 반가치를 부여하며, 마지막으로 회고 가치를 부여합니다. 계획 가치가 없으면 측정할 격차가 없고, 실현 가치가 없으면 계획은 가설로 남습니다.

6.2 전달에서의 흐름 저항

흐름 저항(flow resistance)은 계획 가치와 실현 가치 사이의 격차에 흐름 안에서 나타나는 반가치를 더한 것입니다. VMT는 0이 아닌 격차를 정상으로 보지만(T3), 저항이 역사적으로 누적되며(T4) 미래 가치를 실현하는 능력을 감소시킨다(T6)고 봅니다. 전달에서 가치는 구현 단계(범위 축소, 가설의 오해), 릴리스 단계(결함, 롤백), 도입 단계(사용자가 변경 사항을 찾거나 사용하지 못함), 그리고 지연으로 인해 손실됩니다. 지연 비용 개념(Reinertsen, 2009)에 따라 지연은 별도의 지표가 아니라 늦어진 흐름의 반가치로 모델링됩니다.

각 흐름이 자신의 계획량과 관찰량을 가지면, 스키마는 어느 변환기에서 손실이 발생했는지 보여 줍니다. 이것이 Æilus 산출물 집합의 흐름 저항 레지스터와 계획 대비 실현 가치 격차 보고서의 목적입니다.

6.3 누출

누출(leakage)은 체계로 들어오는 가치보다 체계를 떠나는 실현 가치가 지속적으로 초과하는 상태입니다(A11). 제품 가치 체계에서는 두 가지 형태가 흔합니다. 첫 번째는 사용자는 혜택을 받지만 환류 흐름이 가능하게 하는 유입을 충당하지 못하는 경우입니다. 두 번째는 가설이 만들어지는 동안 팀은 투자를 소비하지만 그 가설이 결코 실현되지 않는 경우입니다. 두 경우 모두 처리량은 건강해 보일 수 있지만, 유입과 유출이 하나의 경계 위에 있기 때문에 스키마는 둘 다 보여 줍니다.

7 공유 노드: 모든 흐름에 걸친 평가

소프트웨어 체계의 일부 변환기는 사용자가 이름 붙일 만한 가치를 전혀 만들지 않지만, 모든 가치 흐름이 그것을 통과합니다. 2025년 9월의 저자의 채널 게시물과 관련된 aeilus.tech 문서는 권한 부여(authorisation)를 예로 듭니다. 권한 부여는 그 자체로는 가치를 만들지 않지만, 그것이 없으면 모든 시나리오가 멈춥니다. API 게이트웨이나 CI 파이프라인도 같은 종류입니다.

이러한 노드를 따로 평가하면 비용만 보이고 산출은 보이지 않아 비용 절감을 부추기게 됩니다. 스키마에서는 이 노드가 여러 흐름에 동시에 나타나며, 그 효율은 노드가 지원하는 모든 흐름의 총가치를 통해서만 분명해집니다. 따라서 이 방법은 공유 노드에 다음을 할당합니다.

• 스키마에서 읽어 낸, 그 노드를 통과하는 흐름의 집합
• 그 노드가 각 흐름에 더하는 반가치(지연 시간, 장애, 로그인 실패, 통합 결함)
• 그 노드의 소비 가치(팀의 노력, 인프라)

그 효율은 같은 문서의 프로세스 효율 정의에 따라, 노드가 속한 모든 흐름에 걸친 전달 가치에서 반가치를 뺀 값을 소비 가치와 대비한 것입니다. 공유 노드의 저하는 결코 국소적인 사고가 아니며, 그 노드가 서비스하는 모든 흐름에 더해지는 저항입니다. 정리 T8은 지속 가능성에 관한 논거를 추가합니다. 변환 역할을 수행할 수 없게 되면 안정성이 상실되고, 역할의 중복성은 안정성을 높입니다.

8 팀 리더가 얻는 것

2022년 2월의 저자의 채널 게시물은 이 접근법이 팀과 그 리더에게 무엇을 주는지 나열합니다. 이 논문의 용어로 다시 정리하면 다음과 같습니다.

• 피드백으로서의 전달 가치. 어느 기간에 대해서든 팀은 속도(velocity)라는 간접적 신호 대신, 수신자가 확인한 자신이 전달한 가치를 Æ로 확인합니다.
• 프로세스 방법론과 무관한 효과성 척도. 실천법이 무엇이든 척도는 소비 가치당 실현 가치이며, 실천법은 이 척도에 미치는 효과에 따라 선택되거나 폐기됩니다(P7).
• 비즈니스에 대한 투명성. 기술 작업은 그것이 지원하는 흐름을 통해 설명 가능해집니다.
• 가치에 기반한 백로그 우선순위. 우선순위는 목소리가 가장 큰 이해관계자가 아니라, 계획 가치, 그 신뢰도, 지연 비용으로부터 도출할 수 있습니다.
• 반가치로서의 지연 비용과 운영 환경 오류. 비즈니스는 변경이 늦거나 결함이 있을 때 가치가 어떻게 떨어지는지 보여 줄 수 있고, 팀은 자신의 작업의 유용성이 시기와 운영 품질에 어떻게 좌우되는지 알 수 있습니다.
• 공유 자원에 대한 논거. 관리자와 DevOps 엔지니어가 공유되는 곳에서는, 가치 기반 우선순위가 한 팀의 작업이 다른 팀의 작업을 위해 연기된 이유를 양방향 모두에서 설명해 줍니다.

이러한 이득은 실현 가치가 수신자에 의해 검증될 때만 유효합니다. 팀이 자신의 가치를 스스로 추정하고 확인하면, 그 척도는 또 하나의 자기 보고식 카운터가 되며 T17이 적용됩니다. 영향력 있는 출처의 해석이 실현으로 확인되지 않으면 반가치가 누적됩니다.

9 가상 제품의 작동 스키마 예시

이 절은 가상의 예시용 제품을 설명합니다. 이것은 사례 연구가 아니며, 어떤 실제 조직도 설명하지 않고, 측정된 수치도 포함하지 않습니다.

이 가상 제품은 소규모 서비스 업체가 고객 예약을 받는 구독형 웹 애플리케이션입니다. 이 제품의 가치 체계는 4절에서 정의한 경계를 따릅니다. 권한 부여 서비스와 API 게이트웨이라는 두 공유 노드가 사용자 대면 흐름 전체를 서비스합니다. 재무는 가능하게 하는 유입을 제공합니다. 회사는 구독 수익과 유지율을 환류 흐름으로 받습니다.

이 스키마는 VSS Editor에서 네 단계로 구축됩니다. 하나의 외부 유입(투자와 급여)과 사용자에게 향하는 외부 유출이 있는 경계, 일곱 개의 변환기, 흐름이 담는 가치 요소의 이름을 붙인 흐름, 그리고 반가치 요소입니다. 수량은 첫 번째 추정 세션까지 비워 둡니다.

하나의 가상 릴리스를 생각해 보자. 예약 불이행을 줄이기 위한 알림 기능이다. 개발에 앞서 제품 책임자는 요소별 계획 가치(시간 절감, 예약 누락 감소, 리텐션에 대한 기대 효과)를 기록한다. 합의된 관찰 기간이 지나면 제품 분석과 비즈니스 사용자 표본이 실현 가치를 제공하고, 팀은 실현된 반가치(anti-value)를 기록한다. 늦은 릴리스, 중복 알림을 발송한 결함, API 게이트웨이의 추가 부하가 그것이다. 그 차이가 이 릴리스의 저항이다. 결함과 게이트웨이 부하는 다른 시나리오에 기여하는 흐름 위에도 놓여 있으므로, 공유 노드에도 함께 할당된다. 한 분기 뒤에 회고 가치는 리텐션이 과연 변했는지를 기록한다. 실제 적용에서는 수치가 다음에 설명하는 세션에서 나오게 된다.

10 운영 방법

10.1 누가 추정하고 누가 검증하는가

2025년 게시글에 나온 Æilus의 규칙은 짧다. 프로세스의 산출 가치는 그것을 소비하는 사람이 평가해야 하고, 그 평가는 다른 누군가가 확인해야 한다. 이를 전달(delivery)에 적용하면 역할 분담이 분명해진다.

• 계획 가치는 송신자가 추정한다. 가설의 경우 제품 가치 변환기의 가치 변환기 책임자(Value Transformer Owner, VTO)로서 행동하는 제품 책임자가 이에 해당한다. 개발 변환기의 경우에는 VTO인 팀 리더가 해당한다.
• 실현 가치는 수신자가 해석한다. 제품 분석 또는 웹 분석을 통해 관찰되는 사용자와, 환류 흐름에서는 회사가 수신자이다. 발표 자료는 직접 검증이 마련될 때까지 임시 조치로 제품 분석이 사용자 측을 대표할 것을 제안한다.
• 해석의 검증은 제2의 당사자가 수행한다. 시스템 수준의 지속 가능성을 책임지는 가치 체계 책임자(Value System Owner, VSO)이거나, 핵심 흐름의 경우 흐름 책임자이다.
• 방법론적 무결성은 Æilus 마스터가 뒷받침한다(발표 자료에서는 프로젝트 관리자가 맡는 Æilus 챔피언이다). 이 담당자는 가치 전달, 계획 대 실적, 흐름 저항 보고서를 준비한다.

10.2 주기

Æilus는 일정을 규정하지 않는다. 방법론이 권장하는 이벤트에 부합하는, 전달 팀을 위한 최소한의 주기는 다음과 같다.

• 백로그 정제마다: 요소 등록부를 사용하여 새 항목에 계획 가치를 할당한다.
• 관찰 기간 이후 릴리스마다: 실현 가치와 반가치를 기록하고 검증한다. 짧은 가치 회고(Value Retrospective)에서 그 격차를 논의한다.
• 매월 또는 분기마다: 공유 노드를 포함한 스키마 전반에 대한 흐름 저항 리뷰(Flow Resistance Review)를 수행하고, 이전에 릴리스된 항목의 회고 가치를 검토한다.
• 분기마다 또는 구조 변경 시: 경계, 변환기, 의존 관계에 대한 가치 체계 리뷰(Value System Review)를 수행하고, 스키마 파일을 갱신하여 버전을 관리한다.

10.3 규율

모든 산출물에는 책임자, 갱신 주기, 의사결정 목적이 필요하다. 그렇지 않으면 유지 비용과 잘못된 확신을 통해 반가치를 만들어 낸다. 이 방법에서 의사결정 목적은 백로그 우선순위, 공유 자원의 배분, 릴리스 시점, 공유 노드에 대한 투자이다. 계획 가치의 증가는 팀이 그것을 실현할 능력이 확인된 경우에만 허용된다(P9). 계획 가치를 실현 가치보다 빠르게 확대하는 것은 T16이 설명하는 실패 모드이다.

11 한계와 실증 연구에 필요한 것

이 논문은 개념적이며 측정된 데이터로 검증되지 않았다. 따라서 몇 가지 한계가 있다.

• 추정의 질. Æ에서의 값은 해석이며, 그 신뢰성은 추정자와 그들의 보정에 달려 있다.
• 부분적 통약 가능성. 시간 절감, 수익, 신뢰는 부분적으로만 통약 가능하다(A13). 이를 하나의 통화로 표현하려면 가치 집계 정책(Value Aggregation Policy)이 필요하며, 이 논문은 이를 전제하지만 정의하지는 않는다.
• 귀속. 실현 가치는 흔히 여러 릴리스와 외부 요인의 결과이다. 스키마는 구조를 보여 주지만 하나의 릴리스가 기여한 몫을 분리해 낼 수는 없다.
• 숨은 흐름. 스키마로 시스템의 관찰된 안정 또는 쇠퇴를 설명할 수 없다면, 잠재 흐름이 있거나 경계가 잘못된 것이다(T9). 스키마는 구조에 대한 가설이며 수정되어야 한다.
• 방법의 비용. 의사결정을 낳지 못하는 세션은 방법 자체를 반가치로 만든다.

실증 연구에는 최소한 다음이 필요하다. 회고 가치를 기록할 만큼 충분히 긴 기간 동안 이 방법을 적용하는 여러 전달 팀, 데이터 수집 전에 합의된 안정적인 요소 등록부와 집계 정책, 팀이 아니라 수신자에 의한 실현 가치의 독립적 검증, 기존 전달 지표와 실현 가치 사이의 관계를 검토할 수 있도록 하는 기존 전달 지표의 병행 수집, 그리고 스키마를 사용한 경우와 사용하지 않은 경우에 내려진 의사결정의 비교이다. 이러한 연구만이 가치 기반 우선순위 결정이 전달된 가치를 바꾸는지, 그리고 어떤 조건에서 그런지를 보여 줄 수 있다.

12 결론

전달 지표는 작업이 파이프라인을 통해 어떻게 이동하는지를 설명할 뿐, 그 작업이 수신자에게 무엇을 바꾸었는지는 설명하지 못한다. VMT에 따르면 지표는 그럴 수 없다. 가치는 맥락적이고, 사용 중에만 실현되며, 계획 가치와 실현 가치는 서로 달라지기 때문이다. VSS Editor로 구현된 가치 체계 스키마(Value System Schema)를 통해 소프트웨어 팀은 가설에서 실현 가치로, 그리고 다시 회사로 돌아오는 제품 가치 순환을 그릴 수 있다. 릴리스마다 계획 가치, 실현 가치, 회고 가치를 기록하면 이 순환이 측정이 된다. 저항과 누출이 눈에 보이게 되고, 공유 노드는 그것이 기여하는 모든 흐름에 걸쳐 평가되며, 팀 리더는 전달된 가치, 가치 기반 우선순위, 지연과 오류의 비용을 피드백으로 얻는다. 이 방법은 시스템 경계가 명시되고, 수신자가 실현 가치를 검증하며, 모든 산출물이 의사결정에 기여할 때에만 정직하게 유지된다. 이 방법이 실제로 전달된 가치를 개선하는지는 이 논문이 문제를 구성하되 답하지는 않는 실증적 질문이다.

참고문헌

• 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.
• Bolshakov, V. Value Management Theory (VMT), version 1.4. 2026.
• Bolshakov, V. Value Management Methodology Æilus, v2.0. 2026.
• Bolshakov, V. VMT, Æilus v2.0 and the Product Value System (presentation). 2026.
• Bolshakov, V. New Tool Released: Value System Schema Editor (VSS Editor). aeilus.tech, 2025.
• Bolshakov, V. Assessing the Value of Processes: Efficiency, Risks, and Anti-Value. aeilus.tech, 2025.
• Bolshakov, V. Artifacts and Reports. Æilus methodology, aeilus.tech/methodology/artifacts-and-reports/. 2026.
• Bolshakov, V. Æilus channel posts on value flows, team leadership and the VSS Editor (러시아어). 2022-2025.
• Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. The Principles of Product Development Flow. 2009.