우리가 가장 중요한 한 가지를 제외하고 소프트웨어에서 모든 것을 측정하는 이유

Source: Dev.to

(번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.)

누락된 품질 차원: Business Fit

비즈니스 소프트웨어는 비즈니스 규칙을 표현하고, 강제하며, 진화시키기 위해 존재합니다. 그 주요 책임은 기술적 우수성이 아니라 시간이 지나도 의미론적 정확성을 유지하는 것—우리가 business fit이라고 부를 수 있는 것입니다.

business fit이 뛰어난 시스템은 오늘날의 요구사항을 단순히 반영하는 것을 넘어, 도메인을 명시적이고 조합 가능하게 만듭니다. 새로운 기능은 최소한의 구조 재조정만으로 삽입될 수 있습니다. 예상치 못한 기능도 종종 모델 구조 자체에서 자연스럽게 나타나는데, 이는 과도한 설계 때문이 아니라 올바른 개념이 올바른 위치에 배치되었기 때문입니다.

예를 들어, 금전 이체를 처리하는 컴플라이언스 시스템을 생각해 보세요. 사유를 자유 텍스트로 기록하면 검색하기 어려운 취약한 문자열이 됩니다. 이체를 금액과 조건이 정의된 구조화된 임대 계약에 연결하면 자동 조정, 편차 감지, 풍부한 감사 추적과 같은 기능을 즉시 얻을 수 있습니다—개발자나 비즈니스 이해관계자가 명시적으로 요구하지 않았더라도 모델에서 직접 파생되는 기능입니다.

business fit은 다음과 같은 질문에서 드러납니다:

• 시스템이 비즈니스 도메인을 정확히 표현하고 있나요?
• 비즈니스 규칙이 구조적으로 강제되고 있나요, 아니면 절차적으로만 적용되고 있나요?
• 비즈니스가 변하거나 확장될 때, 시스템이 지역적으로 작은 마찰만으로 적응하나요, 아니면 전역적인 리팩터링이 필요하나요?
• 모델이 제약과 가능성을 드러내고 있나요, 아니면 숨기고 있나요?

이 질문들은 장기적인 비용, 위험, 유지보수성—그리고 시스템이 지속적인 진화와 우연한 강점을 유지할 수 있는 능력을 좌우합니다. 그러나 이러한 논의는 품질 토론에서 거의 완전히 빠져 있습니다.

왜일까요? business fit은 측정 가능한 지표가 없기 때문입니다.

비즈니스 적합성을 측정할 수 없는 이유

비즈니스 적합성은 구조적인 이유로 정량화하기 어렵습니다:

• 이는 기술적인 것이 아니라 의미론적인 것입니다.
• 절대적인 것이 아니라 상황에 따라 달라집니다.
• 비즈니스가 진화함에 따라 함께 진화합니다.
• 관찰이 아니라 이해가 필요합니다.

다음에 대한 메트릭은 존재하지 않습니다:

• “이 개념이 여기 속해 있는가?”
• “이 규칙이 본질적인가, 아니면 부수적인가?”
• “이 모델이 아직 현실과 일치하는가?”

비즈니스 적합성을 측정하려는 모든 시도는 결국 프록시로 전락하고, 프록시는 필연적으로 변질됩니다. 그래서 팀은 측정 가능한 것을 측정하게 됩니다.

해결책이 아닌 대체 수단으로서의 메트릭

비즈니스 적합성을 평가할 방법이 없을 때, 소프트웨어 개발 문화는 기술 메트릭으로 기울어집니다:

• 테스트 커버리지
• 빌드 상태
• 속도
• 정적 분석
• 신뢰성 지표

이 메트릭들이 틀린 것은 아니며, 단지 직교적일 뿐입니다.

그들은 다음 질문에 답합니다: “시스템이 정상적으로 동작하고 있는가?”

그들은 다음 질문에 답하지 않는다: “시스템이 비즈니스를 올바르게 표현하고 있는가?”

메트릭은 의미론적 품질 도구가 부재한 공백을 메우지만, 그것을 대체하지는 않습니다.

도메인 모델의 역할

문제는 메트릭이 언어의 사용을 측정하지만, 전달된 이야기가 올바른지 여부는 테스트하지 못한다는 점이다.

반면에 풍부한 도메인 모델은 비즈니스 도메인의 표현, 즉 이야기 자체이다.

모델은 적합성을 직접 측정하지는 않지만, 더 중요한 일을 한다: 비즈니스 적합성을 평가 가능하게 만든다.

도메인 모델은:

• 비즈니스 개념을 명시적으로 만든다
• 규칙과 불변 조건을 중앙집중화한다
• 의미에 행동을 부착한다
• 검토할 수 있는 안정적인 객체를 제공한다

이는 어떤 메트릭도 할 수 없는 비즈니스 검증을 가능하게 한다.

비즈니스 전문가는 도메인 모델을 보고 다음과 같이 말할 수 있다:

• “이것은 잘못되었습니다.”
• “이것이 누락되었습니다.”
• “이것은 현실을 반영하지 않습니다.”

이는 주관이 아니라 진리의 근원에 대한 검증이다. 도메인 모델이 없으면 그런 대화는 불가능하다.

로컬라이제이션: 어디서 무슨 일이 일어나는지 알기

강력한 도메인 모델은 기반이 되는 컨텍스트를 제공합니다. 그것은 다음을 알려줍니다:

• 무엇이 존재하는지
• 로직이 어디에 존재하는지
• 어떤 규칙이 어떤 개념에 적용되는지

이 로컬라이제이션은 변경 비용을 크게 줄여줍니다. 규칙이 변경될 때, 정확히 어디를 변경해야 하는지 알 수 있습니다.

로직이 서비스, 파이프라인, 스트림에 존재하는 시스템에서는:

• 의미가 흩어져 있다
• 규칙이 중복된다
• 소유권이 불분명하다
• 변경이 고고학이 된다

도메인 모델은 부하가 아니라, 방향성을 제공하는 인프라입니다.

지도 비유

도메인 모델은 소프트웨어에 있어 지도와 도시와 같은 관계입니다.

작은 마을에서는 지도가 없어도 길을 찾을 수 있습니다; 모든 것을 머릿속에 기억할 수 있죠. 도시가 커지면 방향 감각이 필수적이 됩니다.

모델이 없으면 개발자들은 큰 시스템을 지도 없는 낯선 도시를 탐험하는 관광객처럼 탐색합니다:

• 시도와 오류로
• 이전 경로를 기억하며
• 같은 질문을 반복해서 묻으며

움직일 수 있고, 결과물을 전달할 수 있습니다. 하지만 결코 방향을 잡지 못합니다.

Source: …

페라리 문제

비즈니스 적합성을 전혀 평가하지 않으면 어떻게 될까요?

즉시 실패하는 일은 없습니다. 시스템은 동작하고, 테스트는 통과하며, 릴리스가 이루어지고, 메트릭은 건강해 보입니다.

이것이 문제는 지속되는 이유입니다.

페라리 F40으로 밭을 갈아보는 것과 같습니다:

• 움직인다
• 강력하다
• 인상적이다

하지만 다음과 같습니다:

• 작업에 비해 심하게 부적합하다
• 부하가 걸리면 부서지기 쉽다
• 유지비가 비싸다
• 실제 갈기에는 부진하다

작업은 수행되지만, 엄청난 비용이 듭니다.

It looks like the source link that should appear at the top of the translation is missing. Could you please provide the “> Source: …” line so I can include it exactly as‑is before translating the rest of the text?

더 깊은 문제: 명확한 비교 대상이 없음

대부분의 팀은 비즈니스 적합도가 높은 시스템이 시간이 지나면서 진화하는 모습을 본 적이 없습니다.

아무도 트랙터가 밭을 갈아보지 못했다면, 페라리는 합리적인 선택처럼 보일 수 있습니다.

적합하고 모델 기반의 시스템

• 조용히 변화한다
• 인력이 적게 필요하다
• 드라마가 적다
• 영웅 이야기를 만들지 않는다

인상적이지 않아 보입니다—농업에 관심이 있다면 제외하고.

대비가 없으면 비효율이 필요와 구분되지 않게 됩니다.

실제 결론

대부분의 소프트웨어 시스템은 비즈니스 적합성을 측정하지 않습니다. 더 중요한 것은: 그럴 수 없다는 점입니다.

풍부한 도메인 모델이 없으면 비즈니스 정확성을 평가할 수 있는 실질적인 아티팩트가 없습니다. 품질은 대리 지표를 통해 추론되고, 정확성은 가정됩니다.

불편한 진실은 다음과 같습니다:

비즈니스 소프트웨어의 가장 중요한 품질 속성은 측정되지도, 측정 가능하지도 않습니다. 도메인 모델은 비즈니스 적합성을 정량화하지 않으며—그것을 가시화하고, 논의 가능하게 하며, 수정 가능하게 합니다.

그리고 이것이 무시되는 이유입니다.

중요하지 않아서가 아니라—도메인 모델 없이는 비즈니스 적합성이 단순히 측정되지 않는 것이 아니라, 알 수 없는 상태가 되기 때문입니다.