개념
이 레슨의 자리 — 기술 규격 검증
공공 사업의 품질 활동은 두 갈래다. 하나는 절차와 증거 — 감리 대응, 검수조서, 하자담보책임 기간의 증거 관리이고, 모듈 56 레슨 3(공공 SI 검수)이 맡는다. 다른 하나는 기술 규격 검증 이다. 발주 문서가 "전자정부 표준프레임워크를 적용한다"고 썼을 때 그 말이 실제로 지켜졌는지 무엇을 보고 판정하는가. 이 모듈이 맡는 쪽이 후자이고, 이 레슨이 그 출발점이다.
"표준프레임워크 준수"가 검수 항목에 들어 있는데 무엇을 보면 준수인지 정의하지 않은 채 검수일을 맞으면, 그때부터는 합의가 아니라 협상이 된다. 기술 규격은 착수 시점에 판정 방법까지 정해 두는 것 이 원칙이다.
표준프레임워크가 정해 주는 것
전자정부 표준프레임워크는 행정·공공 정보화 사업의 개발 기반을 표준화하려고 만든 오픈소스 기반 프레임워크다. 한국지능정보사회진흥원(NIA)이 운영하고, 공식 포털은 egovframe.go.kr,
소스는 GitHub eGovFramework 조직에서 공개된다. QA 관점에서 중요한 것은 이것이 단일 라이브러리가 아니라 여러 환경의 묶음 이라는 점이다. 포털이 구분하는 축은 다음과 같다.
| 구성 | 대략의 내용 | QA 가 여기서 얻는 것 |
|---|---|---|
| 실행환경 | 실행 시 쓰는 공통 모듈 — 화면·업무·데이터 처리, 연계 통합, 공통 기반 | 동작의 기본 골격이 이미 정해져 있다 |
| 개발환경 | 구현·시험·배포·형상 관리 도구 묶음(IDE 기반) | 빌드·정적 분석 산출물 형태가 사업 간에 비슷해진다 |
| 운영환경 | 배포·모니터링·운영 지원 도구 | 운영 이관 시험의 대상 목록을 짐작할 수 있다 |
| 관리환경 | 프레임워크 자체의 변경·배포 관리 | 적용 버전을 추적할 근거가 있다 |
| 공통 컴포넌트 | 로그인·권한·게시판·파일 관리·메일·일정 등 업무 기능 기성품 | 시험 강도 차등의 근거 |
반드시 구분할 것이 하나 있다. 표준프레임워크는 기술 스택과 공통 기능의 기반 을 정해 주지만 업무 규칙을 정해 주지 않는다. 로그인 화면이 공통 컴포넌트로 제공된다고 해서 "이 기관의 로그인 정책"이 제공되는 것은 아니다. 비밀번호 규칙, 접속 차단 조건, 휴면 계정 처리, 기관 통합 인증 연계는 전부 사업에서 정하고 시험해야 한다. 프레임워크 준수 점검과 요구사항 검증은 별개의 활동 이고, 둘을 합쳐 놓은 시험 계획은 거의 항상 후자가 얇아진다.
버전과 호환성 — 확인된 것만 쓴다
버전은 이 분야에서 가장 자주 틀리게 인용되는 정보다. 사업 제안서와 블로그 글이 서로 다른 숫자를 쓰고, 그 숫자가 실행환경인지 개발환경인지도 흐릿하다. 1차 출처에서 확인한 것만 정리한다.
공식 GitHub 조직 eGovFramework 의 실행환경 저장소(egovframe-runtime) 릴리스 목록에서 확인한 태그와 공개 시점은 다음과 같다.
v5.0.2-Final 2026-09-22 v5.0.1-Final 2026-09-03
v5.0.0-Final 2026-05-18 v4.3.0-Final 2025-05-13
v4.2.0-Final 2024-02-28 v4.1.0-Final 2023-03-02
v4.0.0-Final 2022-03-02 v3.10.0 2021-03-29이 목록이 말해 주는 것은 두 가지다. 4.x 와 5.x 가 동시에 현장에 있고(기관 표준이 4.x 로 고정돼 있으면 최근 착수 사업도 4.x 로 간다), 같은 메이저 안에서도 패치가 계속 나온다. 그래서 "표준프레임워크 4.3 적용"이라는 문장만으로는 시험 전제가 되지 않는다.
5.0 계열의 구성 요소별 상세(스프링 계열 버전, 요구 JDK, 서블릿 스펙, 변경된 공통 컴포넌트 목록)는 포털 위키의 릴리즈 노트 페이지가 아직 비어 있어 원문 확인 대상으로 남긴다. 요구 JDK·WAS·DB 조합을 기억이나 2차 자료로 쓰지 않는다 — 이 조합이 틀리면 시험 환경 전체가 잘못된 전제 위에 선다.
프레임워크와 상용 솔루션 사이의 궁합에는 별도 제도가 있다. 표준프레임워크 오픈커뮤니티가 운영하는 호환성 확인 이다. 공식 안내에서 확인한 범위는, 대상이 기반SW(실행환경·공통 컴포넌트 위에 구축된 패키지 SW)·연동SW(DB·WAS·SSO·암호화 등)·지원SW(Case Tool·ALM 등) 세 갈래이고, 신청 → 사전 협의 → 계약 → 과제 제공 → 1·2차 점검 → 확인서 발급 → 포털 게시 절차에 사전 협의부터 평균 3~4주가 걸린다는 것이다. 안내문에 유효기간 항목은 확인되지 않았고, 솔루션이 변경되면 변경된 부분의 호환성은 보장되지 않는다 고 밝히고 있다.
마지막 문장이 QA 에게 직접적이다. 제안서에 "호환성 확인을 받은 솔루션"이라고 적혀 있어도, 사업에서 쓰는 그 버전 이 확인받은 버전인지는 따로 확인해야 한다.
QA 가 착수 2주 안에 확정해 문서로 박아야 하는 표는 이것이다.
[시험 전제 — 버전 고정표]
실행환경 버전 / 출처(포털 릴리스 노트 URL) / 적용 확인 방법(의존성 목록)
개발환경 버전 / 빌드 도구와 버전
JDK 배포판·버전 (개발/시험/운영이 같은가)
WAS 제품·버전 / 세션 클러스터링 구성 여부
DB / 드라이버 제품·버전 / JDBC 드라이버 버전
브라우저 지원 대상과 버전 하한 (레슨 2에서 판정 기준으로 만든다)
공통 컴포넌트 사용 목록 / 각각 "원본 그대로 / 설정 변경 / 소스 수정" 구분맨 아랫줄이 이 레슨의 핵심으로 이어진다.
공통 컴포넌트 — 시험 강도를 셋으로 나눈다
공통 컴포넌트는 로그인·권한 관리·게시판·파일 관리 같은 반복 기능을 미리 만들어 둔 것이다. 배포된 상태로 이미 검증을 거쳤으므로, 사업에서 이것을 그대로 쓴다면 기능 동작을 처음부터 전부 시험하는 것은 낭비다. 문제는 현장에서 "그대로 쓰는" 일이 거의 없다는 점이다. 화면을 기관 디자인에 맞추고, 필드를 추가하고, 권한 모델을 기관 조직도에 맞게 고친다. 그래서 시험 강도를 이렇게 나눈다.
| 등급 | 상태 | 시험 강도 | 근거 |
|---|---|---|---|
| A — 원본 사용 | 소스 수정 없음, 설정만 | 연결·통합 위주. 정상 흐름 + 기관 환경 연동(인증·DB·파일 저장소)만 확인 | 기능 자체는 배포 전 검증됨. 우리 환경에서 붙는지가 위험 |
| B — 설정·확장 | 소스는 그대로, 설정·속성·화면 템플릿 변경 | 변경한 설정이 영향을 주는 경로 전부 + 경계값 | 설정 하나가 조건 분기를 바꾼다 |
| C — 소스 수정·신규 | 컴포넌트 소스를 고쳤거나 새로 만듦 | 직접 개발한 기능과 동일한 강도 — 설계 기법 전면 적용 | 원본의 검증은 더 이상 근거가 아니다 |
C 등급이 가장 자주 과소평가된다. "공통 컴포넌트를 썼으니 안전하다"는 말이 회의에서 그대로 통과되는데, 실제로는 게시판 컴포넌트의 첨부파일 처리 로직을 고쳐 놓은 상태인 경우가 많다. 한 줄이라도 고쳤으면 C 다. 등급을 매기려면 개발팀에서 공통 컴포넌트 원본과 현재 소스의 차이 목록 을 받아야 한다. 형상 관리 도구에서 초기 도입 커밋 이후의 변경 이력을 뽑으면 된다. 이것을 요구하지 않으면 등급은 자진 신고에 의존하게 되고, 자진 신고는 항상 A 쪽으로 기운다.
실제로 깨지는 다섯 지점
표준프레임워크 기반 시스템에서 결함이 몰리는 곳은 프레임워크 자체가 아니다. 프레임워크와 사업 코드가 만나는 접합부 다. 반복해서 나타나는 다섯 지점을 시험 포인트로 정리한다.
1. 파일 업로드·다운로드. 가장 많이 고쳐지는 영역이고 결함도 가장 많다. 시험할 것은 용량 상한(애플리케이션 설정 ≤ WAS ≤ 웹서버가 일관적인가), 확장자 허용·차단 목록, 파일명에 한글·공백· 특수문자가 섞였을 때의 저장명과 표시명, 경로 조작 입력, 동시 업로드, 그리고 저장소가 다중 서버에서 공유되는가 다. 단일 서버에서 통과하고 이중화 운영에서 깨지는 전형이 여기다.
2. 세션과 인증. 로그인 컴포넌트를 쓰더라도 기관 통합 인증(SSO)·간편인증·공동인증서 연계가 붙는 순간 흐름이 재설계된다. 시험할 것은 세션 타임아웃의 실제 동작(화면 표시와 서버 만료 시각의 일치), 중복 로그인 정책, WAS 클러스터에서의 세션 유지, 그리고 인증 실패 경로 다. 성공 경로는 개발 중에 수없이 지나가지만 실패 경로는 그렇지 않다.
3. 트랜잭션 경계. 여러 공통 컴포넌트를 조합한 업무 흐름에서 트랜잭션이 어디서 시작하고 끝나는지가 흐려진다. 업무 저장은 됐는데 첨부파일 메타데이터가 안 남거나, 그 반대가 나는 결함이 여기서 나온다. 시험 방법은 흐름 중간에 실패를 주입하고 데이터 상태를 확인하는 것 이다.
4. 코드·공통 데이터. 공통 코드 관리, 조직·사용자 기준 정보는 거의 모든 화면이 참조한다. 여기서 깨지면 증상이 전역에 흩어져 원인 추적이 늦어진다. 시험 포인트는 코드 추가·비활성화 시 기존 데이터의 표시, 코드 캐시 갱신 시점, 조직 정보 변경의 화면 반영이다(레슨 3의 조직개편 회귀와 이어진다).
5. 로그와 오류 화면. 기본 오류 페이지가 그대로 노출되면서 스택 트레이스나 내부 경로가 보이는 사례가 검수 지적의 단골이다. 시험할 것은 예외 처리 경로, 오류 화면에 노출되는 정보, 그리고 감사 로그가 요구대로 남는가 다. 공공 시스템은 접속·조회·변경 이력 보존이 요구사항에 들어 있는 경우가 많은데, 이 요구는 기능 시험에서 자주 빠진다.
준수 점검 — 무엇을 보면 "적용"인가
발주 문서의 "표준프레임워크 적용" 문장을 판정 가능한 형태로 바꾸는 것이 QA 의 일이다. 판정에 쓸 수 있는 확인 항목은 대체로 이런 축이다.
1. 실행환경 라이브러리가 선언된 버전으로 실제 의존성에 존재하는가
→ 빌드 산출물·배포 아티팩트의 라이브러리 목록
2. 프레임워크가 전제하는 계층 구조를 따르는가
→ 화면·서비스·데이터 접근 계층 분리, 우회 호출 유무 (표본 추출 점검)
3. 공통 컴포넌트 사용 목록과 수정 범위가 문서와 일치하는가
→ 도입 시점 대비 변경 이력 (위 등급표의 입력값)
4. 시험·운영 환경의 버전 조합이 고정표와 일치하는가
→ 환경별 버전 수집 결과2번은 전수 점검이 불가능하므로 표본을 정하고 표본 추출 기준을 문서로 남긴다. "주요 업무 화면 20개를 업무 영역별로 3개씩"처럼 적어 두면 검수에서 그대로 근거가 된다. 표본 없이 "대체로 준수함"이라고 적은 점검 결과는 감리에서 되돌아온다.
실무에서 왜 필요한가
표준프레임워크 기반 사업에서 QA 가 가장 흔히 빠지는 함정은 시험 강도를 평평하게 주는 것 이다. 기능 목록을 받아 전부 같은 깊이로 케이스를 쓰면 이미 검증된 공통 컴포넌트의 정상 흐름에 시간을 쓰고 사업이 직접 만든 업무 로직과 접합부는 얕게 지나간다. 공공 사업의 일정은 뒤가 좁으므로 이 배분 실패는 그대로 미검증 영역으로 남는다.
버전 고정표가 필요한 이유도 일정 때문이다. 개발 환경과 시험 환경의 JDK 나 WAS 버전이 다르다는 사실은 대개 통합 시험 중반에 발견되고, 그 시점에 환경을 맞추려면 며칠이 날아간다. 착수 2주 안에 한 장짜리 표를 만들어 개발·인프라·QA 가 함께 확정해 두면 이 손실이 사라지고, 이 표는 검수 단계의 시험 환경 기술 근거로도 그대로 쓰인다.
등급표는 협상 도구 이기도 하다. "이건 프레임워크 기본 기능이라 우리 책임이 아니다"와 "납품물이니 전부 책임진다"는 말은 매 사업 반복된다. 착수 시점에 A·B·C 등급과 각 등급의 시험 범위를 합의해 두면 이 논쟁이 사업 후반이 아니라 초반에 한 번으로 끝난다.