공공·기업 업무 소프트웨어 QA — 전자정부 표준·ERP·협업 도구 호환성

학습 목표

이 모듈 한 줄 요약 — "합격 기준을 우리가 정하지 않는 곳". 국내 공공기관과 대기업의 업무 소프트웨어를 다룬다. 이 환경이 특별한 이유는 한 문장이다 — 품질 판정의 기준이 팀이 정한 것이 아니라 바깥에서 주어진다. 쓸 기술도, 지켜야 할 지침도, 검수 항목도 발주 조건으로 이미 정해져 온다.

모듈 2에서 요구사항을 읽는 법을, 모듈 4에서 테스트 계획과 리스크 기반 우선순위를 배웠다. 이 모듈은 그 두 가지를 국내 공공기관과 대기업의 업무 소프트웨어 라는 특정한 환경에 적용한다. 이 환경이 특별한 이유는 한 문장으로 요약된다. 여기서는 품질 판정의 기준이 팀이 정한 것이 아니라 바깥에서 주어진다. 프레임워크는 발주 조건으로 정해져 있고, 접근성은 법령이 의무로 걸고, 업무 규칙은 회계 규정과 사규가 정하고, 문서 포맷과 협업 도구는 기관이 이미 쓰고 있는 것이 있으며, 시험 환경조차 망분리 정책이 허용하는 범위 안에서만 만들 수 있다.

이 모듈은 기술 규격을 검증하는 쪽 에 집중한다. 같은 공공 사업이라도 감리 대응·검수조서·하자보수처럼 절차와 증거 관리 는 모듈 56 레슨 3이 맡는다. 두 레슨은 한 사업의 앞뒤다 — 여기서 "규격대로 만들어졌는가"를 확인하고, 거기서 "그것을 어떤 문서로 인수받는가"를 다룬다. 접근성도 마찬가지로 갈랐다. WCAG 성공 기준 자체와 스크린 리더 조작 절차는 모듈 49·52가 이미 다루므로, 이 모듈의 레슨 2는 국내 법령이 만든 의무와 그 의무를 검수 판정 문장으로 옮기는 일 만 다룬다.

다섯 갈래로 간다. 첫째, 전자정부 표준프레임워크 다. 프레임워크가 무엇을 정해 주고 무엇을 정해 주지 않는지 구분하면, 공통 컴포넌트를 쓴 기능과 직접 만든 기능에 시험 강도를 다르게 줄 수 있다. 둘째, 웹 표준과 웹 접근성 의무 다. 법령 근거를 확인하고, 검사항목을 판정 가능한 문장으로 바꾸고, 자동 점검과 수동 점검을 나눈다. 셋째, ERP 업무 규칙 이다. 마감·전표 승인·권한 분리처럼 조건이 얽힌 기능을 결정표로 풀고, 회계연도와 조직개편 같은 구조 변경의 회귀를 설계한다. 넷째, 문서와 협업 도구 호환성 이다. HWP 문서를 다루는 기능과 메신저·화상회의·문서 협업 도구 연동에서 실패가 나는 지점을 지도로 만든다. 다섯째, 망분리 환경의 시험 이다. 외부가 막힌 안에서 시험 환경을 어떻게 세우고, 시험 데이터를 어떻게 넣고 빼며, 개학·연말정산 같은 피크 부하를 어떻게 다루는지다.

관통하는 문장은 emphasis 그대로다. 공공 업무 소프트웨어의 품질은 기능이 되는가보다 규정대로 되는가로 판정된다. 잘 도는데 규격을 벗어난 구현은 여기서 결함이고, 불편하지만 규정대로인 동작은 여기서 개선 요청이다. 이 판정 기준을 착수 시점에 세워 두는 것이 이 모듈의 목표다.

완료 후 할 수 있는 것

• 전자정부 표준프레임워크가 정해 주는 범위(실행환경·개발환경·공통 컴포넌트)와 사업이 직접 만드는 범위를 구분하고, 시험 강도를 셋으로 나눠 배분할 수 있다
• 프레임워크·JDK·WAS·DB 드라이버의 버전 조합을 시험 전제로 문서화하고, 버전 혼용과 라이브러리 충돌이 드러나는 지점을 미리 점검할 수 있다
• 웹 접근성 의무의 국내 법령 근거와 국가표준(KS X OT0003)의 위치를 설명하고, 조문을 직접 확인해 인용할 수 있다
• 접근성 검사항목을 "무엇을 어떻게 확인하면 통과인가"가 적힌 검수 판정 문장으로 바꾸고, 자동 점검 도구와 수동 점검의 분업표를 만들 수 있다
• 정보통신접근성 품질인증이 발주 산출물로 걸렸을 때 준비할 것과 일정 역산을 설계할 수 있다
• ERP 의 마감 기간·전표 승인 단계·권한 분리 규칙을 결정표로 풀고, 규칙 누락과 모순을 표 위에서 찾아낼 수 있다
• 마감 전후로 동작이 달라지는 기능의 경계값을 회계일·입력일·시스템일로 나눠 설계할 수 있다
• 권한 조합의 폭발을 역할 등급화와 조합 기법으로 줄이고, 권한 분리(SoD) 위반을 판정하는 시험을 만들 수 있다
• 회계연도 전환·조직개편처럼 시간과 구조가 바뀌는 사건의 회귀 시험 범위를 산정할 수 있다
• HWP·HWPX 문서를 다루는 기능(뷰어·편집기·변환·미리보기·첨부·전자결재)의 시험 관점을 나누고, 대표 문서 세트를 근거를 갖고 구성할 수 있다
• 메신저·화상회의·문서 협업 도구의 연동 지점을 도식화하고, 각 지점의 대표적 실패 모드에 대응하는 케이스를 쓸 수 있다
• 망분리(물리·논리) 환경에서 시험 환경 구성안을 만들고, 외부 의존이 끊겼을 때 드러나는 문제를 사전에 목록화할 수 있다
• 시험 데이터의 반입·반출 통제 절차를 설계하고, 운영 데이터를 쓸 수 없는 조건에서 대체 데이터 전략을 세울 수 있다
• 개학·연말정산·청약 같은 피크 부하 시험의 목표와 제약을 정리하고, 실제로 가능한 수준의 시험 계획으로 줄일 수 있다

채용시장에서의 위치

이 모듈이 겨냥하는 시장은 국내 QA 채용에서 물량이 가장 많은 쪽이다. 공공 SI·행정기관 시스템 운영사·대기업 그룹 IT 자회사·ERP 구축 및 운영사 가 여기에 해당한다. 공고 문구는 대개 "공공 프로젝트 경험", "전자정부 표준프레임워크 기반 시스템", "웹 접근성 인증 대응", "ERP 업무 테스트", "전자결재·그룹웨어", "내부망 환경 근무" 같은 형태로 나타난다. 이 말들이 붙은 공고는 도구 숙련도보다 그 환경의 규칙을 아는 사람 을 찾는다.

여기서 경쟁력이 되는 것은 세 가지다. 첫째, 규정을 시험 요건으로 번역하는 능력 이다. 접근성 검사항목 33개를 외우는 사람보다, 그중 자동 도구로 판정되지 않는 것이 무엇이고 그것을 누가 어떤 절차로 확인해 어떤 증거를 남길지 설계하는 사람이 필요하다. 둘째, 업무 규칙을 구조로 다루는 능력 이다. ERP·그룹웨어 도메인은 기능 수보다 규칙의 조합이 문제이고, 결정표를 실제로 쓸 줄 아는 사람은 케이스 수를 절반으로 줄이면서 커버리지를 설명할 수 있다. 셋째, 제약 안에서 시험을 성립시키는 능력 이다. 망분리·데이터 반출 금지·운영 데이터 사용 불가 같은 조건에서 "그래서 못 합니다" 대신 대안을 설계해 오는 사람은 어느 조직에서나 희소하다.

자격증 축에서는 정보처리기사 가 공공 사업의 인력 등급 산정과 제안서 투입 인력 기재에서 여전히 직접적인 의미를 갖고, ISTQB CTFL·CTAL-TA 는 결정표·경계값 같은 설계 기법의 공통 언어로 쓰인다. ERP 쪽에서는 회계 기초 지식(전표·계정과목·마감)이 자격증보다 실질적인 진입 장벽이고, 접근성 쪽은 인증 심사 경험 자체가 이력이 된다. 다만 이 시장에서 최종적으로 평가되는 것은 "그 규격 아래에서 사업을 끝내 봤는가" 다. 이 모듈의 실습 과제는 그 경험이 없는 상태에서 경험에 해당하는 산출물을 미리 만들어 두는 방향으로 설계했다.