Secure OS·DBMS 운영·데이터 표준화·구축 시험 및 전환 | 정보처리기사 필기

핵심 요약

구축한 정보시스템을 안전하게 운영하려면 운영체제의 보호 기능, DBMS의 관리 기능, 데이터의 표준 정의를 함께 확인해야 한다. 시험과 전환은 이러한 구성이 실제 업무 요구를 충족하는지 확인하고 새 환경으로 옮기는 연결 과정이다.

1. Secure OS와 하드닝

Secure OS는 보안 정책에 따라 사용자·프로세스의 접근을 통제하고 보호·감사 기능을 강화한 운영체제다. 일반 운영체제의 설정을 안전하게 조정하는 하드닝(Hardening)과 관련되지만 같은 말은 아니다. 넓은 의미의 하드닝에는 취약점 패치도 포함되며, 아래에서는 불필요한 서비스·권한을 줄이는 구성 강화에 초점을 둔다.

개념	의미
신뢰 컴퓨팅 기반(TCB)	보안 정책을 집행하는 데 필요한 하드웨어·소프트웨어 등 보호 구성요소
참조 모니터	주체의 객체 접근이 보안 정책에 맞는지 중재하는 추상적 개념
보안 커널	참조 모니터 개념을 구현하는 TCB의 핵심 부분

참조 모니터는 모든 관련 접근을 검사할 수 있어야 하고, 변조로부터 보호되어야 하며, 정확성을 분석·검증할 수 있어야 한다. 백신을 설치했다는 사실만으로 Secure OS의 접근통제 구조가 완성되는 것은 아니다.

운영체제 보안의 기본은 불필요한 서비스·계정 제거, 최소 권한, 안전한 인증 설정, 보안 패치, 파일·설정의 무결성 점검, 로그 기록과 점검이다. 서버실의 물리적 출입통제와 서버 내부의 프로그램 실행 권한은 보호 위치가 다르다.

2. DBMS 운영과 DBA

DBMS의 기본 기능은 데이터의 구조·제약을 정하는 정의, 조회·삽입·수정·삭제를 수행하는 조작, 접근권한·무결성·동시성·복구를 다루는 제어로 구분할 수 있다.

DBA(Database Administrator)는 데이터베이스의 계정·권한, 구조와 저장 공간, 성능·용량, 무결성·동시성, 백업·복구, 장애 대응 등을 관리한다. 개발자에게 운영 DB의 모든 관리자 권한을 상시 부여하는 것은 최소 권한 원칙에 맞지 않는다.

트랜잭션이 동시에 실행될 때는 데이터 일관성을 지키도록 동시성을 제어하고, 실패 시에는 정상 상태로 복구할 수 있어야 한다. 무결성은 데이터가 정해진 제약을 만족하는 성질이며, ‘백업이 있다’는 사실과 같은 뜻이 아니다.

3. 백업과 복구의 기본 구분

백업 방식	저장 대상	복구 시 필요한 자료의 일반적 구성
전체 백업	해당 시점의 전체 대상	전체 백업본
증분 백업	직전 백업 이후 변경분	최근 전체 백업과 이후 필요한 증분 백업들
차등 백업	최근 전체 백업 이후 누적 변경분	최근 전체 백업과 마지막 차등 백업

예를 들어 일요일 전체 백업 후 월·화·수에 증분 백업했다면 수요일 상태 복구에는 전체본과 필요한 증분 사슬이 필요하다. 차등 방식이었다면 전체본과 수요일 차등본으로 복구하는 것이 일반적이다. 제품별 복구 방식이 주어지면 해당 조건을 따른다.

논리 백업은 SQL이나 논리적 객체·데이터 형태로, 물리 백업은 데이터 파일 등 저장 구조를 중심으로 보관한다. 온라인·오프라인 백업은 서비스 가동 여부에 따른 분류다. 이 분류들을 전체·증분·차등과 같은 기준으로 섞지 않는다.

트랜잭션 로그는 변경 정보를 보관하여 장애 복구와 특정 시점 복구에 사용될 수 있다. 백업 성공 메시지가 있다는 것과 실제로 데이터·권한·업무 기능을 복원할 수 있다는 것은 다르다. 복원 시험으로 확인해야 한다.

4. 데이터 표준화

데이터 표준화는 여러 시스템과 담당자가 데이터를 같은 의미·형식·규칙으로 다루도록 기준을 정하는 것이다.

표준 요소	의미	예
표준 단어	이름을 구성하는 기본 단어의 뜻과 표기	고객, 번호, 일자
표준 용어	단어를 조합한 업무 데이터 항목의 공통 이름·정의	고객번호, 가입일자
표준 도메인	데이터 형식·길이·허용 범위 등의 공통 규칙	일자 형식, 금액의 자릿수
표준 코드	분류값과 그 의미의 공통 정의	접수 상태 01=접수, 02=완료
메타데이터	데이터의 의미·구조·규칙 등을 설명하는 데이터	항목 정의, 소유 부서, 형식

한 시스템의 01이 ‘승인’이고 다른 시스템에서는 ‘반려’이면 코드 값이 같아도 의미가 다르다. 연계 전에 정의를 통일하거나 명확한 변환 규칙을 정해야 한다.

정규화는 관계형 스키마의 종속성을 정리하여 이상 현상을 줄이는 설계 기법이고, 표준화는 이름·정의·형식·코드 등의 일관성을 맞추는 활동이다. 데이터 품질 관리는 실제 데이터의 정확성·완전성·일관성·유효성 등을 점검한다. 이름이 표준에 맞아도 실제 값이 잘못될 수 있다.

5. DB 기술의 기본 구분

기술	핵심 개념
관계형 DB	테이블과 관계·제약을 중심으로 데이터 관리
NoSQL	키-값, 문서, 열 계열, 그래프 등 다양한 비관계형 모델을 포괄
분산 DB	여러 위치에 있는 데이터를 논리적으로 연계하여 관리
샤딩	데이터를 여러 노드·저장 단위로 나누어 배치
복제	같은 데이터를 여러 위치에 유지
데이터 웨어하우스	분석을 위해 여러 원천의 데이터를 통합하여 저장

NoSQL이라고 모든 제품이 같은 일관성·트랜잭션 특성을 가지는 것은 아니다. 샤딩은 나누어 저장, 복제는 같은 데이터의 사본 유지라는 차이가 있다. 둘은 함께 사용할 수 있다.

분석 시스템의 ETL은 추출(Extract)·변환(Transform)·적재(Load)다. 단순히 원천 파일을 복사하는 일뿐 아니라 형식과 의미를 맞추는 변환이 포함될 수 있다.

6. 구축 시험의 연결

단위 시험은 개별 모듈, 통합 시험은 모듈 간 상호작용, 시스템 시험은 전체 시스템, 인수 시험은 사용자·고객의 수용 기준을 중심으로 한다.

기능 시험은 요구한 기능이 동작하는지 확인하고, 비기능 시험은 성능·보안·가용성 등의 품질 조건을 확인한다. 부하 시험은 예상 부하에서의 동작, 스트레스 시험은 한계를 넘거나 비정상적인 조건에서의 반응을 확인한다.

구축 관리에서는 정상 기능만 되는지가 아니라 접근권한, 데이터 일관성, 장애 시 복구, 기존 기능의 회귀 오류도 점검한다. 자세한 테스트 케이스 설계 기법과 SQL·DB 설계 절차는 각각의 전문 영역과 연결된다.

7. 전환 방식과 이행 검증

전환 방식	의미	장점과 위험
직접 전환	특정 시점에 기존 시스템을 중단하고 신규로 교체	빠르고 중복 비용이 작지만 실패 영향이 큼
병행 전환	기존·신규를 일정 기간 함께 운영	비교·복귀가 유리하지만 비용·중복 작업 증가
단계 전환	기능·업무 등을 나누어 순차적으로 전환	영향을 나눌 수 있지만 신구 연계가 복잡할 수 있음
파일럿 전환	일부 조직·지점 등에 먼저 적용	제한된 범위에서 문제를 확인한 뒤 확대

데이터 이행의 기본은 원천 분석 → 정제·매핑 → 변환·적재 → 검증이다. 건수만 같다고 성공이 확정되는 것은 아니다. 금액 합계, 키·관계, 누락·중복, 업무 규칙의 일치도 확인해야 한다.

전환 전에 성공 기준과 실패 시 복구 방법을 준비한다. 전환 이후 새 거래가 발생했다면 예전 복사본으로 돌아가는 것만으로는 새 거래가 보존되지 않을 수 있다. 따라서 복구 가능성까지 포함하여 전환을 검증해야 한다.

직접은 한 시점 교체, 병행은 구·신 동시 운영, 단계는 기능별 전환, 파일럿은 일부 조직에 먼저 적용한다.

데이터 운영·전환과 구성 기준선

논리 백업은 테이블 구조·데이터 등 논리 객체를 내보내는 관점이고, 물리 백업은 데이터 파일·블록 등 DBMS 저장 구조를 보존하는 관점이다. 복구 가능성은 DBMS 버전·로그·백업 방법의 호환 조건을 확인해야 한다. 온라인 백업은 시스템이 실행 중인 상태에서 수행하므로 DBMS가 지원하는 일관성 있는 백업·복구 절차가 필요하다. 쓰는 중인 파일을 임의 복사하는 것과 동일하지 않다.

ETL의 추출은 원천에서 데이터를 가져오고, 변환은 단위·형식·코드·결측 등을 목적에 맞게 처리하며, 적재는 목표 저장소에 반영하는 단계다. 금액 단위 변환이 필요하다면 문자열의 이름만 바꿔 같은 숫자를 저장해서는 안 된다. NoSQL은 단일 모델이 아니라 키-값·문서·열 계열·그래프 등 여러 모델을 포함한다. 데이터 웨어하우스는 통합된 이력 데이터를 분석하는 목적에 적합하도록 구성하며 일상 거래 처리의 동작과 구별한다.

구성 기준선과 변경 이력

구성 기준선(Configuration Baseline)은 특정 시점에 승인된 시스템 구성의 참조 상태다. 운영체제·패키지·설정·권한·네트워크 구성과 관련 버전을 식별할 수 있어야 한다. 실제 상태가 기준선과 다르면 승인된 변경인지 미승인 드리프트인지 조사한다. 변경 요청→영향·위험 분석→승인→적용·검증→기준선 갱신의 이력을 연결한다. 기준선을 무조건 현재 상태로 덮어쓰면 변경 탐지의 근거를 잃는다.