EA 목적·원칙·메타모델·거버넌스

세 부서가 모두 맞다고 하는데 신청 상태는 왜 다를까

문화강좌 센터의 온라인 화면에는 신청 완료, 상담원의 명단에는 대기, 강사의 명단에는 취소로 표시된다. 각 담당자가 자기 프로그램만 고치면 될까? 완료가 무엇인지, 누가 상태를 확정하는지, 변경이 어디로 전달되는지가 서로 다르면 화면 세 개를 새로 만들어도 같은 문제가 남는다.

앞 장에서는 신청·도움 채널을 개선할 전략을 정했다. 이번 장은 그 전략을 업무·정보·프로그램·운영 기반의 일관된 구조로 바꾼다. 첫 절에서 공통 표현과 결정 책임을 정하고, 둘째 절에서 실제 구조를 설계하며, 셋째 절에서 현재 구조를 어떻게 전환할지 판단한다. 센터와 모든 표·수치·운영 기준은 자체 교육 사례이지 실제 기관의 승인·측정 결과가 아니다.

큰 선택의 근거를 조직 전체로 넓힌다

아키텍처 결정은 주요 구조와 품질에 큰 영향을 주는 선택에 대안·근거·결과·재검토 조건을 남겼다. 한 신청의 의미와 책임이 여러 부서에 걸치면 한 프로그램만의 결정으로 끝나지 않는다. 여기서는 그 선택들이 조직의 같은 목표를 향하도록 연결한다.

1. 전사 관점은 모든 것을 한 서버에 넣는다는 뜻이 아니다

정보기술아키텍처(EA)는 조직의 목적에 맞게 업무·데이터·애플리케이션·기술의 구조와 관계, 원칙·결정 책임 및 현행에서 목표로의 전환을 정렬하는 체계다. 여기서 전사는 회사 전체뿐 아니라 함께 다뤄야 할 사업 범위를 뜻한다. 이번 범위는 센터의 신청·상담·강사 명단이며 급여나 모든 교육기관의 시스템까지 포함하지 않는다.

HHS의 2024년 판본은 EA를 기술 목록에 한정하지 않고 업무 중심의 구조·공유 정보·의사결정과 연결한다. 이 장은 그 보존 문서의 개념 설명만 참고한다. 해당 기관의 당시 의무나 인용 법령을 현재 한국 기관에 적용하는 근거로 쓰지 않는다.[EAA-C01]

공통 신청 상태를 쓰더라도 상담 화면과 강사 화면의 기능·권한은 다를 수 있다. 전사 정렬은 모든 기능을 같은 제품으로 통일하거나 개인정보를 모두에게 개방하는 명령이 아니다. 공유할 의미와 인터페이스, 분리할 책임과 접근권한을 구별하는 일이다. 중앙 저장소가 있어도 각 부서가 같은 이름을 다른 뜻으로 쓰면 정렬된 구조가 아니다.

지금의 사실과 앞으로의 설계를 다른 칸에 둔다

현행 아키텍처(AS-IS)는 정한 기준시점에 실제 존재하는 구조·관계와 운영 상태를 근거로 표현한 것이다. 목표 아키텍처(TO-BE)는 조직의 방향과 제약을 만족하도록 설계한 미래의 구조·관계다.

센터의 현행은 독립 명단과 수작업 전달, 목표는 같은 신청 상태를 역할별로 확인하는 구조다. 목표 그림에 선을 그었다고 현행의 연결이 생긴 것은 아니다. 현행 표에는 관찰일·자료원·미확인을, 목표 표에는 선택 이유·가정·검증 조건을 붙인다. 이 둘의 비교와 전환은 뒤 절에서 같은 대상·범위를 유지한 채 수행한다.

2. 원칙을 실제 선택 기준으로 만든다

아키텍처 원칙은 반복되는 구조적 선택에서 지킬 방향과 그 이유·실행상의 부담을 명시한 판단 기준이다. ‘좋은 시스템을 만든다’는 문구로는 두 대안 중 무엇을 고를지 알 수 없다. 자체 원칙 EA-P1은 다음처럼 적용 결과까지 적는다.

원칙은 한 개씩 적용하지 않는다. 공유를 늘리자는 원칙과 필요한 정보만 전달하자는 원칙이 만날 때에는 누구에게 어떤 항목을 어떤 목적으로 제공할지 결정한다. ‘재사용 우선’도 기존 제품이 요구를 만족하지 못하거나 지원·운영 근거가 없는 경우까지 억지로 유지하라는 뜻은 아니다. 예외의 근거와 종료 조건을 남기되 법적 의무를 내부 승인으로 면제하지 않는다.

3. 메타모델은 그림들을 같은 말로 묶는 문법이다

EA 메타모델은 아키텍처를 기록할 요소의 종류·속성·허용 관계를 정한 표현 규칙이다. 실제 ‘접수서비스’는 요소이고 ‘애플리케이션은 데이터를 읽는다’는 그 요소를 기록할 규칙이다. HHS 보존 문서의 용어집도 메타모델을 아키텍처 개념의 기록·저장·조회에 쓰는 요소 집합으로 설명한다. 아래 문법은 그 원문 도식을 옮긴 것이 아니라 이 사례에 필요한 자체 최소 모델이다.[EAA-C02]

요소에는 식별자, 종류, 설명, 책임자와 기준시점을 둔다. 같은 이름의 서로 다른 요소는 식별자로 나누고, 같은 요소를 여러 그림에 그릴 때에는 같은 식별자를 쓴다. 관계에도 출발·도착, 관계 종류, 근거와 확인 상태를 둔다. 단순한 연결선은 ‘정보를 읽음’, ‘실행 기반’, ‘책임짐’ 중 무엇인지 알 수 없다.

자체 메타모델 EA-M1과 실제 요소

EA-M1은 업무→애플리케이션의 지원 관계, 애플리케이션→데이터의 읽기 관계, 애플리케이션→기술 기반의 실행 관계를 허용한다. 책임자→업무 또는 데이터의 책임 관계도 허용한다. 이는 모든 EA 도구의 공통 문법이 아니다.

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

O1은 B1을 책임지고, B1은 A1의 지원을 받는다. A1은 D1을 읽고 T1 위에서 실행되며, A2도 같은 D1을 읽는다. 화살표는 자체 메타모델의 관계 종류이며 실제 시간 순서나 통신 방향이 아니다.

B1은 신청 운영, A1은 접수서비스, A2는 상담 화면, D1은 신청 상태 자료, T1은 운영 플랫폼, O1은 접수 책임자다. 선은 이 문법의 관계이며 실제 통신 방향이나 시간 순서와 같지 않다. 업무를 서버 위에 실행한다고 적거나 데이터가 업무 위에서 실행된다고 적으면 이 모델의 종류 규칙을 위반한다.

목록은 요소를 빠짐없이 찾는 데, 행렬은 어떤 요소가 무엇과 연결되는지 비교하는 데, 도식은 선택한 관계를 읽는 데 사용한다. 셋은 별도 사실의 원천이 아니라 같은 기록의 서로 다른 표현이어야 한다. EA 저장소는 이런 기록·근거·판본을 보관하는 곳이며 고객 개인정보 원장을 통째로 복제하는 곳이 아니다.

따라 계산: 연결선 여덟 개가 여덟 개의 확인은 아니다

EA-M2는 EA-M1의 여덟 관계 주장이다. ‘확인’은 종류 규칙과 해당 관계의 운영 근거를 이 사례에서 모두 대조했다는 가정이다. 미확인은 거짓이라는 뜻이 아니라 아직 근거를 대조하지 않았다는 뜻이다.

기록은 8개지만 검토한 관계는 6개여서 검토율은 6/8=75%다. 검토한 것 중 확인 비율은 5/6≈83.33%, 전체 주장 중 확인은 5/8=62.5%다. R6을 미확인에 섞거나 R7·R8을 통과로 세지 않는다. 실제 배치와 데이터 책임이 빠지면 도입 후 장애와 정정 책임을 잘못 넘길 수 있으므로 평균만으로 다음 설계를 승인하지 않는다.

R6은 원기록을 확인해 오기와 잘못된 모델링을 구별한다. 이미 확인한 다른 관계를 복사하여 분자를 늘리지 않는다. R7·R8은 실행 근거와 책임 위임을 확인할 담당·기한을 정한다. 종류 검사가 맞아도 관계의 실제 존재를 증명하는 것은 아니므로 자동 형식 검사와 내용·운영 확인을 나눈다.

4. 누가 어떤 근거로 바꿀 수 있는가

EA 거버넌스는 원칙·구조·예외·변경을 누가 어떤 근거와 절차로 결정하고 이행을 확인할지 정한 책임 체계다. 검토회의를 많이 여는 것이 목적이 아니다. 부서 간 충돌을 조정할 결정권과 현장에서 실제로 지키는지를 확인할 경로가 있어야 한다.

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

목록·관계 행렬·역할별 뷰는 같은 식별자와 기준시점의 기록을 대조한다. 제안은 담당의 근거 대조를 거쳐 승인·보완·기각으로 갈라진다. 승인 뒤에도 실제 운영 확인과 관련 표현 갱신이 필요하며 보완은 승인 완료가 아니다. 같은 신청 의미·역할별 정보·확인된 능력·실패 책임의 원칙은 본문에 그대로 유지한다.

자체 운영안 EA-G1에서는 접수 책임자가 상태의 업무 의미를, 데이터 담당이 사전·품질·수신처를, 개발·운영 담당이 인터페이스·권한·복구를 맡는다. 센터 책임자는 여러 부서의 예산·위험·예외가 충돌할 때 결정한다. 작성자는 자기 설계를 제안할 수 있지만 그 사실을 독립 검수나 사용자 승인으로 바꾸지 않는다.

변경 요청에는 이유, 영향을 받는 요소·관계, 대안, 원칙 충돌, 비용·위험, 시험 결과와 종료 조건을 넣는다. 판단 결과는 승인·보완·기각으로 나누며 보완 요청은 승인 완료가 아니다. 예외를 허용했다면 허용 범위·책임자·만료·재검토와 원칙으로 돌아갈 조치를 남긴다. 같은 예외가 반복되면 개별 요청만 늘리지 말고 원칙과 공통 능력 자체를 재검토한다.

전략·EA·개별 설계의 경계

EA는 전략을 대신 정하지도, 모든 코드를 직접 설계하지도 않는다. 같은 신청의 의미처럼 전사 구조에 영향을 주는 결정은 EA로 올리고, 합의된 경계 안의 세부 구현은 해당 담당자가 결정한다. 모든 사소한 수정에 중앙 승인을 요구하면 책임 분리 대신 병목을 만들 수 있다.

센터의 첫 EA 산출물

EA-G1은 신청·상담·강사 명단을 범위로 한 원칙표, 현행 요소·관계 목록, 역할별 뷰와 결정 대장을 만든다. 데이터 원천을 정하지 않은 채 모든 화면을 한 제품으로 교체하는 안과, 명단 전체를 누구나 내려받게 하는 안은 기각한다. 목표 구조의 구체 설계는 다음 절로 넘기되 R6 오류와 R7·R8 미확인을 숨기지 않는다.

접수·데이터·개발·운영 담당이 같은 식별자와 기준시점으로 기록을 대조한다. 원칙 위반, 서로 다른 상태 의미, 책임 공백 또는 운영 근거 누락이 발견되면 영향받는 결정을 보류한다. 수정 후에는 해당 관계뿐 아니라 이를 참조하는 표·그림·선택 근거도 갱신한다. 도구 구매·그림 개수·회의 개최를 EA의 효과로 세지 않는다.

완벽한 그림보다 일치하는 작은 기준본

전사라는 이유로 모든 세부를 먼저 수집하면 실제 결정이 늦어지고 곧 오래된 목록만 남을 수 있다. 현재 결정에 필요한 범위를 정하고 그 안의 의미·관계·책임을 확인한다. 반대로 작은 범위라는 이유로 연결된 수신처·지원 업무·보호 조건을 지워서도 안 된다.

그림은 최신인데 실제 계약·배치가 바뀌었거나, 형식 검사를 통과한 관계가 운영에서 존재하지 않는 경우가 있다. 기준시점·근거·미확인과 변경 이력을 같이 관리한다. 원칙을 사후에 선택을 꾸미는 문구로 쓰지 않고, 실제 설계와 운영이 달라지면 그 차이를 남긴다.

아키텍처 설계를 보조하는 범위

EA의 개념을 정리하면 다음 설계에서 정보기술 구조를 업무의 목적·정보·책임과 연결할 수 있다. 신청·상담·명단의 원칙·요소·관계·책임을 대상과 기준시점에 맞춰 정한다. 전략과 구조, 기록과 확인, 중앙 정렬과 모든 권한의 집중을 구별한다. 종류 오류·책임 미확인·원칙 충돌이면 보류·수정·재검토한다. 전체 표준의 적합성 인증, 모든 부서의 완성 설계와 실제 기관 승인은 제외한다.

5. 자체 10점 문제

EA의 목적과 EA-M2의 검토율·확인 비율을 설명하고, 오류·미확인 및 변경 책임을 어떻게 처리할지 제시하라.

정의, 분모가 다른 수치, 설계를 진행할 조건을 각각 답한다. 아래 문제와 답안은 자체 교육용이다.

답안 목차·풀이·교정 근거 보기

답안 목차

1. 목적·범위와 구조의 정렬
2. 관계 검토의 분모와 상태
3. 책임·변경·보류 조건

EA-M2 관계 상태	주장 수	처리
확인	5	종류·운영 근거를 대조한 범위만 인정
종류 오류	1	R6 원기록과 종류를 수정
미확인	2	R7·R8 실행·책임 근거 확보

검토 6/8=75%, 검토 중 확인 5/6≈83.33%, 전체 확인 5/8=62.5%로 분모를 구별한다. 목적에 맞는 업무·자료·프로그램·기반 관계와 원칙·책임의 종류는 관계 그림을 함께 읽고, 아래 완성 답안에서 조건과 판단을 확인한다.

완성 답안

EA는 조직 목적에 맞게 업무·데이터·애플리케이션·기술의 관계와 결정 책임·전환을 정렬한다. 센터의 범위는 신청·상담·강사 명단이며 모든 기능을 한 서버나 제품으로 통일하는 것이 아니다. 현행은 실제 근거, 목표는 선택 이유와 검증 조건으로 구별한다.

EA-M2의 검토율은 6/8=75%, 검토 중 확인은 5/6≈83.33%, 전체 확인은 5/8=62.5%다. R6은 종류 오류이며 R7·R8은 미확인이다. 선이 있다는 사실이나 형식 통과만으로 실제 관계가 확인됐다고 보지 않는다.

접수·데이터·개발·운영 담당이 상태 의미·실행·책임 근거를 대조하고 센터 책임자가 부서 간 충돌을 결정한다. 오류와 책임 공백을 고치기 전 영향받는 설계 결정을 보류한다. 변경에는 이유·대안·시험·예외의 범위와 종료 조건을 남긴다.

6. 자체 25점 문제

서로 다른 신청 상태를 가진 센터에 EA-G1을 설계하라. 목적·원칙, 메타모델·근거, 역할·변경·예외와 보류 조건을 실제 산출물로 제시하라.

도구 이름 대신 무엇을 기록하고 누가 어떤 선택을 하는지 적는다.

답안 목차·풀이·교정 근거 보기

설계 목차

1. 범위·원칙과 기각 대안
2. 요소·관계·근거의 기준본
3. 결정권·예외·변경 확인

같은 ID·기준시점의 목록·행렬·역할별 뷰를 대조하고 제안→담당 근거→승인/보완/기각→운영 확인·갱신으로 잇는 관계는 관계 그림을 함께 읽고, 아래 완성 답안에서 조건과 판단을 확인한다.

완성 설계 답안

EA-G1은 센터의 신청·상담·강사 명단을 범위로 정한다. 신청 상태의 의미·확정 책임 일치, 역할별 최소 정보, 확인된 기존 능력의 우선 비교, 실패 상태·운영 책임의 동시 설계를 원칙으로 둔다. 모든 화면의 일괄 교체나 명단 전체의 무제한 공유는 문제 원인과 보호 조건을 해결하지 못하므로 기각한다.

업무·앱·데이터·기술·책임자에 식별자와 기준시점을 부여하고 지원·읽기·실행·책임 관계의 종류와 근거를 기록한다. 목록·행렬·도식은 같은 기록에서 대조한다. EA-M2의 R6은 원기록을 확인해 종류 오류를 수정하고 R7·R8은 실행·책임 증거를 보완한다. 전체 확인 5/8을 8/8로 바꾸거나 형식 검사로 운영 확인을 대체하지 않는다. 저장소에는 구조와 근거 위치를 담고 고객 원자료 전체를 복제하지 않는다.

접수 책임자는 상태 의미, 데이터 담당은 사전·품질·수신처, 개발·운영 담당은 인터페이스·권한·복구를 맡고 센터 책임자가 부서 간 충돌을 조정한다. 변경 대장은 이유·영향·대안·원칙 충돌·시험과 승인 상태를 연결한다. 예외는 범위·책임·만료·후속 조치를 정하고 법적 의무의 면제로 쓰지 않는다. 책임 공백·원칙 위반·미확인이 남으면 영향받는 결정을 보류하며 실제 변경 뒤 관련 표·뷰도 갱신한다.

7. 자기교정

조건 변경

R7·R8만 추가 확인되면? 먼저 바뀐 분모·가정과 가능한 결론을 적어 본다.

해설과 판단 근거 보기

검토는 8/8, 확인은 7/8=87.5%지만 R6 오류는 남는다. 관계표의 서로 다른 상태를 유지한다.

같은 A1을 다른 그림에서 별도 서비스로 적으면? 먼저 바뀐 분모·가정과 가능한 결론을 적어 본다.

해설과 판단 근거 보기

먼저 같은 실체의 중복 표현인지 실제 다른 앱인지 확인하고 식별자·범위를 맞춘다. 메타모델의 규칙만 바꾸어 모순을 숨기지 않는다.

작은 화면 문구 수정이면? 먼저 바뀐 분모·가정과 가능한 결론을 적어 본다.

해설과 판단 근거 보기

상태 의미·권한·다른 부서의 계약을 바꾸지 않는지 확인한 뒤 영향 범위의 담당자가 결정한다. 수준 비교처럼 모든 변경을 전사 심의로 올리지 않는다.

근거와 한계

EA 구조·원칙 설명은 HHS-OCIO-OES-2024-10-005, version2.0의 6.1~6.4·7.5~7.6과 용어집 중 EA·Baseline·Target·Metamodel·Principle·Repository를 사용한다. 공식 IT Policy Archive에서 2026-09-20에 확인한 2024년 판본이다. 당시 기록한 승인일 2024-10-08·화면 검토일 2024-10-24와 문서를 읽은 날짜를 구별하며 현재 미국 정책 효력이나 한국 법정 의무를 확정하지 않는다. 2026-10-06에는 같은 공식 보존 페이지의 6.1~6.4와 용어집에서 영역·현행·목표·저장소·메타모델·전환의 설명을 다시 읽었다. 이번 화면은 문서 머리말의 검토월을 2024-10, 페이지 하단의 콘텐츠 검토일을 2026-08-13으로 각각 표시한다. TOGAF 전문·표준 적합성·EA 도구 인증을 검수한 것이 아니다.

EA-P1·M1·M2·G1의 표·문법·그림·수치·답안은 자체 작성이며 기관의 원문 도식·개인정보·로고를 복제하지 않았다. 종류·계산 검사는 실제 시스템 연결·법률·사람의 독립적인 승인과 다르다. 다음 절의 설계를 이해하는 데 필요한 설명은 이 본문에 두었다.

회독의 핵심

EA는 조직 목적을 구조·관계·원칙·책임과 전환에 연결한다. 현행 사실과 목표 설계, 요소와 메타모델, 기록·형식 통과·실제 확인을 구별한다. 같은 식별자와 근거를 가진 작은 기준본에서 선택·보류·변경을 관리한다.