아키텍처 이행·적합성·기술부채

1. 그림에서는 분리했는데 왜 수정할 때 함께 깨질까

앞의 공방 예약·취소 서비스는 예약 규칙과 저장 기술을 구별하기로 했다. 그런데 구현을 살펴보니 예약 규칙 모듈이 특정 데이터베이스 라이브러리를 직접 불렀다. 화면의 취소 기능은 동작하고 시험도 몇 개 통과했지만 저장 기술을 바꾸자 예약 규칙까지 고쳐야 했다. 구조의 약속과 실제 구현 사이에 차이가 생긴 것이다.

이 절은 설계서를 만든 다음 단계에서 설계 의도를 구현에 연결하고, 실제 구조가 약속을 지키는지 확인하며, 차이를 처리하는 일을 다룬다. 코드만 보는 검사와 실행 경로를 보는 검사의 경계도 나눈다. 마지막에는 남겨 둔 구조적 문제가 미래 변경 비용으로 이어질 때 무엇을 기록하고 먼저 해결할지 판단한다.

모듈 의존, 검사 결과표, 인력 시간과 변경 횟수는 자체 학습 사례다. 기존 서비스의 실제 코드를 분석하거나 ArchUnit을 실행한 결과가 아니다.

설계의 관계와 문서의 그림을 구별한다

아키텍처 드라이버·뷰·스타일·문서화에서는 소프트웨어의 주요 요소·관계·원칙과 이를 표현한 뷰를 구별했다. 이번에는 같은 요소 식별자를 코드·설정·배포 자료에 연결하여 구현이 그 관계를 따르는지 확인한다.

평가 결과를 구현 확인으로 바꾸지 않는다

아키텍처 평가와 트레이드오프의 평가는 중요한 요구·제약에 대한 구조적 결정의 적합성과 위험을 근거로 살폈다. 설계가 타당하다는 설명만으로 구현이나 운영이 그 설명을 따랐다는 증거가 생기지는 않는다.

증거를 얻은 생명주기 단계를 붙인다

분석·설계·구현·시험·운영·변경에서는 설계·구현·시험·운영이 다른 활동과 피드백을 제공한다고 배웠다. 정적 코드 검사, 통합 실행 시험, 실제 운영 관찰은 서로 보완하지만 서로를 대체하지 않는다.

쉽게 말하면, 구조의 약속을 확인 가능한 작업으로 바꾼다

“업무 규칙은 저장 기술에 직접 의존하지 않는다”는 문장만 남겨 두면 무엇을 어디서 검사할지 모호하다. 어떤 코드가 업무 규칙에 해당하는지, 금지하는 의존은 import인지 실행 호출인지, 예외가 있는지를 밝혀야 한다. 그래야 구현자가 지킬 수 있고 검토자도 같은 기준으로 차이를 찾을 수 있다.

그림과 다른 관계를 발견했다고 늘 코드가 틀린 것은 아니다. 요구가 정당하게 바뀌었거나 설계 자체가 현실을 잘못 설명했을 수도 있다. 차이를 숨기지 않고 근거와 영향으로 판단하는 절차가 필요하다.

이 절의 이행·적합성·부채 관리 범위

아키텍처 이행은 선택한 구조와 설계 원칙을 코드·설정·배포 구성 및 검증 활동에 연결하고, 구현과 설계 의도 사이의 차이를 확인·처리하는 과정이다. 요소의 이름을 코드 폴더 이름에 붙였다고 이행이 끝나는 것은 아니다. 예를 들어 예약 모듈이라는 폴더 안에서도 저장 기술을 직접 호출하면 의존 분리의 의도는 지켜지지 않을 수 있다. [EV1][EV2]

이 절은 이행과 구현 적합성 확인, 발견된 차이와 기술부채의 관리 판단을 담당한다. 다음 절이 담당할 변경 제안·영향 분석·승인·전환 전체를 이 절만으로 완료했다고 세지 않는다.

같은 결정에서 구현과 증거까지 따라간다

이 화살표는 문서가 언제나 옳다는 뜻이 아니다. 의도와 관찰이 다를 때 어느 쪽을 바꿔야 하는지 판단할 수 있도록 연결을 남기자는 뜻이다. 결과를 수정한 뒤 기준까지 조용히 바꾸어 처음부터 일치했던 것처럼 보이게 해서는 안 된다.

2. 적합성은 특정 구조 규칙과의 관계다

아키텍처 적합성은 구현에서 관찰한 구조·관계가 명시한 아키텍처 규칙과 일치하는 정도다. 아키텍처 재구성은 코드·설정·실행 등의 자료에서 사실을 추출하고 추상화하여 실제 구현 구조를 다시 표현하는 활동이다. 하나는 비교 판단이고 다른 하나는 비교할 구현 구조를 얻는 활동이다. [EV1][EV2]

예약 모듈에서 저장 모듈로 향하는 의존을 추출하는 것은 재구성의 일부다. 그 의존이 금지 규칙에 어긋나는지 판단하는 것은 적합성 확인이다. 규칙이 애초에 중요한 요구를 놓쳤다면 적합성이 높아도 전체 품질이 충분하다는 결론을 낼 수 없다.

코드 의존과 실행 호출은 같은 화살표가 아니다

M-USECASE가 M-STORE-PORT를 참조하고 실행할 때 M-STORAGE 구현을 호출하는 것은 서로 모순이 아니다. 코드가 의존하는 추상 계약과 실행 시 연결된 구체 구현은 다른 질문에 대한 답이다. 단순한 호출 그림만 보고 정적 의존 규칙의 위반을 선언하지 않는다.

앞 절의 다섯 모듈을 같은 이름으로 사용한다

앞 절 아키텍처 드라이버·뷰·스타일·문서화의 다섯 모듈은 M-ENTRY, M-USECASE, M-RESERVATION, M-STORE-PORT, M-STORAGE다. 모두 같은 애플리케이션 APP-1 내부 모듈이라는 가정을 유지한다. 이번 절에서 갑자기 독립 배포하는 다섯 서비스로 바꾸지 않는다.

자체 정적 의존 검사 범위 EV-SCOPE-1은 이 다섯 모듈 사이의 직접 의존만 다룬다. 공통 표준 라이브러리와 모듈 내부 의존은 범위 밖이며, 제외했다는 사실을 기록한다. 다섯 모듈 모두의 분석 자료가 수집되었고 각 모듈의 실제 코드가 대응한다는 조건이 먼저 필요하다.

이 제한은 의도적으로 작게 만든 학습 범위다. 실제 시스템에서는 생성 코드·프레임워크 연결·동적 로딩 등의 추가 경로를 따로 확인해야 한다. 여기의 다섯 노드 그래프가 그 전체를 검사했다고 말하지 않는다.

허용 목록과 금지 관계를 실행 가능한 문장으로 만든다

이 사례의 허용 목록 EV-DEP-R1은 아래 네 관계다. 앞 절의 응답 유실 시나리오 EV-R1과는 다른 정적 의존 규칙이다. 표에 없는 다섯 모듈 사이의 직접 의존은 금지한다. 특히 업무 규칙인 M-RESERVATION에서 구체 저장 기술인 M-STORAGE로 향하는 의존을 허용하지 않는다.

M-STORAGE → M-STORE-PORT는 구체 구현이 계약을 참조하는 의존이다. 포트 이름을 붙였어도 M-RESERVATION → M-STORAGE가 남아 있으면 이 규칙에서는 위반이다. “함수가 정상 동작했다”는 이유로 구조 규칙을 통과시켜서는 안 된다.

검사의 입력이 비어 있으면 성공을 만들지 않는다

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

요소 대응과 의도한 규칙을 정한 뒤 입력 완전성을 먼저 확인한다. E2의 금지 관계 0건은 입력 부족을 지우지 못한다. E1의 적합은 수집한 판본·규칙·검사 범위에 한정되며 전체 기능이나 실행 계약의 증거는 아니다.

먼저 분석 대상 코드 버전, 모듈 대응표, 포함·제외 범위를 고정한다. 이어 다섯 모듈 모두에서 분석 자료를 읽었는지 확인하고, 추출한 직접 의존을 허용 목록과 비교한다. 누락 모듈이나 알 수 없는 모듈 이름이 있으면 “위반 없음”이 아니라 입력 불충분 또는 범위 오류로 반환한다.

예를 들어 폴더 이름 변경으로 검사 대상이 하나도 선택되지 않았는데 위반 목록만 빈 배열이라고 출력될 수 있다. 빈 위반 목록과 전체 범위를 조사한 결과의 무위반은 다르다. ArchUnit의 문서에도 선택된 클래스가 없어 검사가 의미를 잃는 경우를 기본적으로 실패시키는 설정이 설명되어 있다. [EV3]

마지막에는 규칙 버전과 검사 범위, 발견한 위반, 제외·미확인 항목을 함께 남긴다. 숫자를 보기 전에 실제 대상이 들어왔는지 확인하는 것이 적합성 검사의 첫 조건이다.

같은 다섯 모듈에서 세 상태를 판정한다

자체 상태 E0에서는 다섯 모듈의 자료가 모두 있고 허용 의존 네 개와 금지 의존 한 개가 관찰되었다. 상태 E1에서는 금지 의존을 제거하여 허용 의존 네 개만 남겼다. 상태 E2에서는 자료 수집에서 M-STORAGE를 빠뜨렸기 때문에 금지 관계의 존재 여부도 충분히 확인하지 못했다.

E1의 적합은 다섯 모듈 사이의 직접 정적 의존에 대한 판정이다. 전체 코드의 결함이 없거나 실행 중 취소 결과의 저장 계약까지 검증되었다는 뜻은 아니다. E2는 오류 0이라는 숫자가 있어도 적합으로 집계하지 않는다.

기능 시험 통과와 구조 검사 통과를 서로 대용하지 않는다

금지 의존이 있는 E0에서도 취소 기능의 일부 시험은 통과할 수 있다. 그러나 저장 기술 변경 시 업무 규칙까지 바뀌는 결합은 남는다. 반대로 금지 의존을 없앤 E1에서도 응답 유실 때 같은 취소를 두 번 처리하는 실행 오류가 있을 수 있다.

따라서 구조 제약은 정적 의존과 실제 연결 자료로 확인하고, 취소 상태·결과 저장·재요청 동작은 해당 실행 시나리오로 별도 확인한다. 앞 절의 CONFIRMED, REJECTED, UNKNOWN 구분도 유지한다. 특정 종류의 시험을 늘렸다는 사실로 다른 경계의 미검증 항목을 숨기지 않는다.

3. 차이를 발견했을 때 기록할 단위

아키텍처 편차는 기준으로 삼은 설계 규칙과 관찰한 구현 구조 사이에 발견된 차이다. 편차 기록은 그 차이의 위치·규칙·관찰 근거·영향·처리 책임과 상태를 묶어 추적하는 기록이다. 편차를 발견했다는 사실과 그 편차를 남겨도 된다는 판단은 다르다. 이 기록 형식은 본 교재의 자체 적용 틀이다. [EV1]

E0의 편차 EV-D1에는 금지 의존의 출발·도착 모듈, 검사한 코드 버전, 적용 규칙 EV-DEP-R1을 적는다. 이어 저장 기술 변경의 영향이 업무 규칙에 번지는 이유와 담당자를 붙인다. “아키텍처가 나쁨” 같은 평가만으로는 수정 위치나 종료 조건을 알 수 없다.

기준을 유지할지 바꿀지는 근거를 보고 판단한다

중요 요구가 그대로이고 기존 분리 원칙이 타당하다면, 금지 의존을 제거하고 규칙에 맞는 책임·계약으로 구현을 수정한다. 반대로 요구나 제약이 바뀌어 기존 구조가 부적합해졌다면, 편차의 영향과 대안을 정식 변경 검토로 전달한다. 현재 구현을 그대로 설명하도록 그림만 고치는 것은 그 판단을 대신하지 않는다.

어느 경로를 택해도 기존 발견 기록을 지우지 않는다. 수정한 코드·설계·규칙의 새 버전을 연결하고 같은 범위를 다시 검사하며 필요한 실행 시나리오도 재확인한다. 설계를 바꾸는 경우의 승인과 전환 전체는 다음 절의 변경관리 절차에 연결한다.

알려진 위반을 기준선에 넣었다고 해결된 것은 아니다

기존 코드에 위반이 많을 때 새 위반만 막고 기존 위반은 별도로 줄이는 검사 방식을 쓸 수 있다. ArchUnit의 freezing 규칙은 처음 기록한 위반과 이후 결과를 비교하는 기능을 제공한다. 이것은 기존 위반이 올바른 구조로 바뀌었다는 뜻이 아니다. [EV3]

자체 사례 E0의 금지 관계 한 개를 알려진 위반으로 기록했더라도 판정은 “기존 위반 1, 신규 위반 0”이다. “전체 적합”으로 바꾸지 않는다. 담당자·해결 조건 없이 기준선 파일을 반복 갱신하여 새 위반을 기존 위반으로 숨기는 사용도 피한다.

정말 금지 관계를 제거했다면 E1의 입력과 결과를 남기고 해당 편차의 종료 조건을 확인한다. 새 실행 우회 경로를 덧붙이는 대신 구조적 원인을 수정하는 것이 목표다.

기술부채는 코드 길이가 아니라 미래 결과로 설명한다

기술부채는 현재의 기술적 선택이나 미해결 구조가 이후 변경·유지 작업에 추가 비용 또는 위험을 발생시키는 상태다. 모든 미구현 기능이나 마음에 들지 않는 코드가 자동으로 기술부채인 것은 아니다. 어떤 미래 작업에서 어떤 추가 부담이 생기는지 설명할 수 있어야 한다. [EV4][EV5]

이 사례에서는 저장 기술을 바꿀 때 예약 규칙까지 함께 수정·확인해야 하는 부담이 부채의 결과다. 현재 코드가 읽기 쉽더라도 그 의존 구조가 반복 변경을 어렵게 하면 부채 문제가 될 수 있다. 반대로 긴 코드라는 관찰 하나만으로 상환 우선순위를 결정하지 않는다.

편차·결함·부채를 한 열에 섞지 않는다

같은 문제에 세 관점이 겹칠 수 있지만 반드시 셋 모두인 것은 아니다. 오래된 설계 문서와 달라진 구현의 차이는 먼저 원인을 살펴야 한다. 반대로 문서의 규칙을 모두 지켜도 설계 자체가 미래 변경을 불필요하게 어렵게 만들면 부채가 남을 수 있다.

따라서 결함 건수, 규칙 위반 건수, 부채 추정 시간을 단순히 합쳐 하나의 품질 점수로 만들지 않는다. 판단 대상과 단위가 다르므로 각 근거를 구분해 의사결정에 사용한다.

비용도 분모와 기간을 고정하고 비교한다

측정값·지표·목표·기준선에서 지표는 목적·대상·기간·분자·분모·자료원을 고정해야 비교할 수 있다고 배웠다. 이번에 비교하는 인력 시간도 관찰값과 추정값을 구별하고, 같은 종류의 미래 변경 횟수 안에서 비교한다.

4. 상환 비용과 반복 부담을 나눈다

상환 비용은 특정 기술부채를 제거하거나 줄이기 위해 추가로 필요한 수정·검증 등의 비용 추정이다. 반복 부담은 그 부채를 남겨 둘 때 정한 미래 작업에서 거듭 발생하는 추가 비용 추정이다. 금융 대출의 확정 원금·이자율과 같은 수학 법칙으로 취급하지 않는다. 향후 변경이 실제로 생기지 않거나 작업 성격이 달라지면 부담도 달라진다. [EV5]

예를 들어 의존을 정리하는 데 수정과 검증을 합쳐 12시간이 들고, 그대로 둘 때 같은 종류의 변경 한 번마다 3시간이 추가된다고 예상할 수 있다. 두 값은 이 예제의 추정이며 기존 팀의 실측이 아니다. 일반 개발 시간은 양쪽에 공통이라고 가정하고 부채 때문에 추가되는 시간만 비교한다.

12시간의 구조 개선을 언제 회수하는가

자체 항목 TD-A는 상환 비용 P = 12시간이고, 미상환 상태의 동일 종류 변경 한 번당 추가 부담 I = 3시간이다. 상환하면 그 추가 부담이 모두 사라지고, 상환 자체의 이후 유지 부담은 없으며, 시간 할인도 적용하지 않는 단순 가정이다. 미래 변경 n번에 대해 그대로 두면 3n시간, 지금 상환하면 12시간이 추가된다.

상환 이득은 nI − P = 3n − 12시간이다. 네 번의 변경에서 두 선택의 추가 시간이 같고 다섯 번이면 3시간, 여섯 번이면 6시간이 줄어든다. 이 값은 정한 추가 시간의 산술이지 출시 일정 단축이나 현금 수익의 실측이 아니다.

변경 횟수의 예상이 두 번으로 줄면 시간만 놓고는 상환의 이득이 음수가 된다. 그래도 안전·보안·필수 계약 위반은 별도의 필수 조건으로 먼저 판단해야 한다. 단순 계산의 양수·음수로 모든 문제의 허용 여부를 정하지 않는다.

여기서 P는 한 번 들이는 상환 시간, I는 변경 한 번마다 더 드는 시간, n은 같은 종류의 미래 변경 횟수다. 3n은 3과 n을 곱한다는 뜻이고 nI − P는 변경 횟수 곱하기 회당 부담에서 상환 시간을 뺀다고 읽는다. 단위로는 회 × 시간/회 − 시간이므로 결과는 시간이다. 같은 n=6에서 회당 부담만 3시간에서 1시간으로 낮아졌다고 바꾸면, 미상환은 6 × 1 = 6시간, 상환은 12시간이므로 시간 이득은 6 − 12 = −6시간이다. 음수는 총 작업 시간이 음수라는 뜻이 아니라 이 가정에서는 지금 상환하는 쪽이 6시간 더 든다는 뜻이다. I가 줄었는데도 원래의 +6시간 결론을 유지했다면 4. 상환 비용과 반복 부담을 나눈다의 추가 비용 범위와 12시간의 구조 개선을 언제 회수하는가의 대입 과정을 다시 확인한다. 이 계산 뒤에도 필수 위험의 판단은 따로 남긴다.

부채 항목 사이에서도 분모가 같아야 우선순위를 정한다

같은 기간에 각각 여섯 번의 동일 종류 변경이 예상되는 두 부채 항목을 비교한다고 하자. TD-A는 앞의 12시간 상환·회당 3시간 부담이고, TD-B는 20시간 상환·회당 2시간 부담이다. 두 항목이 서로 독립이고 상환 자원을 함께 비교할 수 있다는 추가 가정이다.

이 조건의 추가 시간만 보면 TD-A가 먼저다. 그러나 TD-B가 필수 안전 조건을 위반하거나 다른 작업을 막는 선행 문제라면 그 판단이 우선한다. 비교표에 위험의 심각도, 예상 변경의 근거, 상환 의존성과 재검증 범위를 함께 붙이는 이유다.

여섯 번이라는 숫자가 근거 없는 희망이면 계산이 정확해도 결정 근거는 약하다. 변경 요청 기록이나 확정된 계획을 통해 예상 범위를 설명하고, 계획이 바뀌면 같은 식의 입력을 갱신한다. 결과에 맞춰 기간이나 제외 비용을 조용히 바꾸지 않는다.

처리 담당과 종료 증거가 없는 부채 목록은 실행 계획이 아니다

자체 부채 기록에는 문제 위치, 관련 설계 결정과 편차, 미래 부담이 생기는 장면, 상환 방안·추정 시간·담당자·검토 시점·종료 조건을 넣는다. “나중에 리팩터링”이라는 문구만 적으면 어느 변경에서 무엇을 확인해야 할지 알 수 없다. 항목을 남기는 목적은 숫자를 늘리는 것이 아니라 책임과 검증을 연결하는 것이다.

TD-A의 종료 조건은 금지 의존 제거, 다섯 모듈 수집 확인, EV-DEP-R1 재검사에서 명시 범위 무위반, 취소의 필요한 실행 시나리오 재확인으로 정한다. 구조 규칙 통과만 남기고 실행 동작 확인을 생략하지 않는다. 실제 상환 후의 추가 시간이 줄었는지는 이후 같은 종류의 변경에서 별도로 관찰한다.

완료 표시는 수행한 증거가 있을 때만 붙인다. 검토 시점이 왔지만 처리하지 못했다면 미완료 상태와 영향·다음 판단을 그대로 남긴다. 기존 부채 기록을 삭제하거나 기준선에 숨기는 것은 상환이 아니다.

5. 이행의 완료 조건과 변경관리의 접점을 연결한다

아키텍처 이행은 의도를 구현에 연결하고, 범위를 고정해 구조를 확인하고, 편차를 처리한 뒤 필요한 증거를 다시 얻는 흐름이다. 변화가 필요하다는 근거는 변경관리로 전달하지만, 전달했다는 사실을 변경 승인이나 안전한 전환 완료로 세지 않는다. 이 절의 직접 기여는 이행과 적합성 확인이고 변경관리에 대한 기여는 그 입력과 재검증의 경계까지다.

자가 점검: 통과 문장에 범위를 붙여 본다

“E1은 명시된 다섯 모듈 사이의 직접 정적 의존 규칙에 적합하다”는 말은 이 예제에서 가능하다. “E1은 모든 품질 문제가 없다”는 말은 불가능하다. “TD-A는 여섯 번의 동일 변경 가정에서 추가 시간을 6시간 줄인다”는 계산도 가능하지만 “실제 일정이 6시간 단축됐다”는 말은 실행과 측정 없이는 할 수 없다.

설계 의도를 구현 가능한 규칙으로 바꾸되, 검사하기 쉬운 규칙만 남겨 중요한 요구를 잃지 않는다. 모든 편차가 즉시 부채이고 모든 부채가 기능 결함이라는 식의 동일시도 피한다. 무엇을 확인했고 무엇이 아직 남았는지를 함께 적는 것이 기술자의 판단이다.

독립 연습 — 위반 0건을 보고하기 전에 입력을 확인한다

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

새 수집 결과에는 요구한 다섯 모듈 중 네 개만 있고 금지 의존은 0 개다. 별도의 실행 시험에서는 화면 취소 한 건이 성공했다. 담당자가 두 결과를 합쳐 “전체 구조 적합, 저장 재요청 안전까지 확인”이라고 보고했다.

• 각 증거로 판정할 수 있는 범위를 쓰라.
• 수집 누락을 보완한 뒤 무엇을 다시 확인해야 종료할 수 있는지 적어라.

풀이와 오답 교정 보기

네 모듈의 수집은 E2와 같은 입력 불충분 상태다. 금지 의존 0 개는 누락된 모듈까지 검사했다는 뜻이 아니므로 구조 적합으로 보고하지 않는다. 화면 취소 한 건의 성공도 저장 확정·응답 유실·동일 식별자 재요청의 실행 확인을 대신하지 못한다. 대상 버전과 다섯 모듈의 입력을 갖춰 명시한 직접 정적 의존을 다시 검사하고, 필요한 실행 계약은 별도 조건과 증거로 재확인한다.

0 건을 곧 통과로 썼다면 세 수집 상태, 실행 성공을 구조 판정으로 확장했다면 범위별 완료 조건에서 보고 범위를 좁힌다.

10점 자체 문제

아키텍처 이행과 적합성의 관계를 설명하고, 기능 시험 통과 또는 빈 위반 목록만으로 적합성을 선언할 수 없는 이유를 제시하시오.

이 문항은 자체 제작이며 실제 기출이나 출제 빈도를 뜻하지 않는다. 본문의 가정 안에서 원리·경계·판정 근거를 연결한다. 답안은 학습용 작성 예이며 제한시간 필기 재현성의 사람 검증은 남아 있다.

10점 풀이와 답안 구성 보기

10점 답안 목차

1. 설계 의도를 구현과 증거에 연결
2. 정적 의존과 실행 동작의 분리
3. 입력 완전성과 범위 확인
4. 차이 처리와 재확인

10점 답안 도식

수집 완전성 판정 그림에서 설계 의도·구현 대응과 입력을 먼저 확인하고 범위별 검사를 수행한다. 편차를 기록해 원인을 판단하고 구현 수정 또는 변경 검토 뒤 재확인한다. 기능 시험 통과 ≠ 전체 구조 적합 ≠ 모든 품질 보장이다.

10점 답안 예시

아키텍처 이행은 선택한 구조·원칙을 코드·설정·배포와 검증 활동에 연결하는 과정이다. 적합성은 그 구현에서 관찰한 관계가 명시한 규칙과 일치하는지에 대한 범위가 정해진 판단이다.

포트를 참조하는 코드 의존과 실행 시 구체 구현을 호출하는 관계를 구별한다. 기능 시험이 성공해도 금지 의존은 남을 수 있고 구조 검사가 통과해도 미실행 상황의 동작은 보증되지 않는다.

분석 대상 버전과 모듈 대응을 고정하고 모든 대상의 자료가 수집되었는지 먼저 검사한다. 누락이나 빈 선택이 있으면 위반 수 0이어도 입력 불충분이지 적합이 아니다.

관찰한 편차에는 규칙·위치·근거를 남기고 구현 수정 또는 근거 있는 변경 검토로 처리한다. 사후 문서 맞춤으로 차이를 숨기지 않고 같은 범위의 구조 검사와 필요한 실행 확인을 다시 수행한다.

25점 자체 문제

다섯 모듈 사례의 E0·E1·E2를 판정하고, TD-A의 상환 비용 12시간·회당 부담 3시간과 TD-B의 20시간·회당 부담 2시간을 여섯 번 변경 가정에서 비교하시오. 편차 처리와 부채 종료 조건 및 변경관리의 접점도 제시하시오.

이 문항은 자체 제작이며 실제 기출이나 출제 빈도를 뜻하지 않는다. 본문의 가정 안에서 원리·경계·판정 근거를 연결한다. 답안은 학습용 작성 예이며 제한시간 필기 재현성의 사람 검증은 남아 있다.

25점 풀이와 답안 구성 보기

25점 답안 목차

1. 검사 범위와 금지 관계
2. E0·E1·E2의 서로 다른 판정
3. 부채의 결과와 조건부 계산
4. 위험과 추정의 경계
5. 상환 종료와 실행 증거
6. 변경관리로 넘기는 입력과 미완료 경계

25점 답안 도식

수집 완전성과 E0·E1·E2 판정 그림을 답안에 다시 사용한다.

텍스트 표현으로 다시 확인하기

같은 범위에서 확인할 것	답안의 판단
E0: 완전 입력·금지 1	위반
E1: 완전 입력·금지 0	명시 범위 적합
E2: 입력 누락·금지 0	입력 불충분
편차·원인·영향	구현 수정 또는 변경관리 입력
필수 위험을 먼저 판단한 같은 추정 가정	TD-A +6시간, TD-B −8시간
책임·종료 조건	구조 재검사와 필요한 실행 재확인

25점 답안 예시

검사 범위는 같은 APP-1의 다섯 모듈 사이 직접 정적 의존이다. 허용 관계 네 개 이외는 금지하며 M-RESERVATION에서 M-STORAGE로 향하는 직접 의존은 위반으로 판단한다.

E0은 다섯 모듈을 수집했지만 금지 의존 하나가 있어 규칙 위반이다. E1은 같은 범위의 네 허용 의존만 있어 명시 범위 적합이다. E2는 모듈 하나가 누락되어 위반 수가 0이어도 입력 불충분이다.

TD-A의 미상환 추가 시간은 6 × 3 = 18시간이므로 지금 12시간을 들여 상환하면 6시간이 줄어든다. TD-B는 6 × 2 − 20 = -8시간이다. 반복 부담이 완전히 제거되고 항목이 독립이라는 같은 가정의 추가 시간만 비교하면 TD-A가 우선이다.

비용표만으로 필수 안전·보안·계약 위반을 남길지 결정하지 않는다. 예상 변경의 근거, 선행 의존, 제외한 비용과 측정 여부를 명시하며 입력이 바뀌면 비교를 다시 수행한다.

TD-A는 금지 의존을 제거한 뒤 다섯 모듈 입력과 규칙 재검사를 확인하고 필요한 취소 실행 시나리오를 재확인해야 한다. 기존 위반을 기준선에 기록한 것 또는 앞으로 시간을 절감할 것이라는 추정만으로 완료하지 않는다.

요구·제약 변화로 기존 구조를 바꿔야 한다면 편차와 영향·대안·재검증 근거를 변경관리로 전달한다. 이 전달은 변경 승인이나 안전한 전환 완료가 아니며 다음 담당 절의 절차와 연결한다.

출처와 확인 범위

관찰 기준일은 2026-09-06이다. 아래는 명시된 HTML 본문 위치만 사용했으며 외부 도표를 복제하지 않았다. 버전이 있는 문서는 그 판본으로 한정하고, 동적 문서는 보존 시점 바이트와 재검토일로 관리한다. 수치·식별자·상태 예는 저자가 만든 것이며 실제 제품 실행·성능·법적 이용권한 승인이 아니다.

[EV1] Carnegie Mellon University, Software Engineering Institute. Why Architecture Conformance Matters for Software Systems. Public abstract of 2022 presentation. 위치: HTML Abstract only; implementation/design alignment and project-specific incremental checking. Linked slides not used. 원문: https://www.sei.cmu.edu/library/why-architecture-conformance-matters-for-software-systems/

[EV2] Carnegie Mellon University, Software Engineering Institute. Automated Design Conformance during Continuous Integration. Public abstract of 2022 presentation. 위치: HTML Abstract only: facts, abstractions, synthesis and inference limitations; prototype scope, not universal performance 원문: https://www.sei.cmu.edu/library/automated-design-conformance-during-continuous-integration-5/

[EV3] ArchUnit project. ArchUnit User Guide. Named HTML passages observed 2026-09-06; not a claim about the latest release. 위치: Package Dependency Checks; Architectures; Freezing Arch Rules; Fail Rules on Empty Should. 기존 2026-09-06 관찰 기록의 절번호는 각각 7.1·8.1·8.6·10.4이며, 2026-09-30 공개 안내 1.5.1에서 다시 확인한 Package Dependency Checks의 위치는 4.1이다. 이전 관찰 기록을 현재 판본의 번호로 덮어쓰지 않으며 실제 사용 판본에서는 제목과 동작을 함께 대조한다. 원문: https://www.archunit.org/userguide/html/000_Index.html

[EV4] Carnegie Mellon University, Software Engineering Institute. Managing Technical Debt in Complex Software Systems. Public abstract of 2016 brochure. 위치: HTML Abstract only: technical debt definition, visibility and planning. Linked brochure not used. 원문: https://www.sei.cmu.edu/library/managing-technical-debt-in-complex-software-systems/

[EV5] Ipek Ozkaya and Robert Nord / CMU SEI. Managing the Consequences of Technical Debt: 5 Stories from the Field. Dated author article. 위치: Technical Debt A-B-C; contingent impact on future change. Source business stories not reproduced. 원문: https://sei.cmu.edu/blog/managing-the-consequences-of-technical-debt-5-stories-from-the-field/

30초 정리

이행은 설계 의도를 구현과 검증에 연결하고 편차를 처리하는 과정이다. 적합성을 말할 때는 규칙·입력 완전성·증거 범위를 붙이고, 기능 시험이나 빈 결과로 다른 경계까지 승인하지 않는다. 기술부채는 미래 부담과 상환 책임·종료 증거로 관리하며, 비용 계산은 가정과 필수 위험을 함께 밝힌다.