공통 버스
서비스를 공통 버스를 통해 연계하는 미들웨어 구조의 약어는?
정답과 풀이 확인
정답 ESB
Enterprise Service Bus. 서비스 연계의 공통 기반이다.
정보처리 실무 · 학습 노트
통합 구현·배포
실무 경험으로 마무리할 보완 범위
최근 기출 주제만으로 범위를 좁히면 낯선 단답형에 취약해진다. 공식 출제경향의 통합·인터페이스·서버·패키징 영역을 보완한다. 이 장의 항목 모두가 특정 회차에 나왔다는 뜻은 아니다.
처음 배우는 분의 학습 순서
기호와 용어가 낯설면 기초·상세 보강을 먼저 읽고, 기존 핵심 정리로 연결하세요. 예제의 값을 손으로 계산한 뒤 확인 질문을 답하고 마지막에 문제를 풉니다.
추가된 상세 학습 6개 펼쳐보기
이 단원 목차 12개
핵심 규칙을 설명하고, 연습문제의 답과 이유를 해설 없이 적을 수 있으면 체크하세요. 이해 체크와 정답 기록은 별도로 저장됩니다.
01
연계와 인터페이스
EAI는 기업 내부 애플리케이션 통합, ESB는 공통 버스를 중심으로 서비스 연계, SOA는 서비스를 단위로 구성하는 아키텍처다. Point-to-Point는 직접 연결, Hub-and-Spoke는 중앙 허브를 통한다.
답을 가리고 확인
“연계와 인터페이스”의 핵심 규칙과 헷갈리는 지점을 설명해 보세요.
확인 답안 보기
JSON은 데이터 교환 형식, XML은 태그 기반 구조, SOAP는 XML 기반 메시지 프로토콜, REST는 자원 중심 제약의 아키텍처 스타일. REST를 JSON 형식의 다른 이름으로 쓰지 않는다. HTTP API라고 모두 REST 제약을 충족하는 것도 아니다.
꼭 기억할 것
JSON은 데이터 교환 형식, XML은 태그 기반 구조, SOAP는 XML 기반 메시지 프로토콜, REST는 자원 중심 제약의 아키텍처 스타일.
헷갈리는 지점 REST를 JSON 형식의 다른 이름으로 쓰지 않는다. HTTP API라고 모두 REST 제약을 충족하는 것도 아니다.
02
미들웨어와 트랜잭션 연계
미들웨어는 응용과 기반 환경 사이 공통 통신·실행 기능을 제공한다. RPC는 원격 함수를 호출하는 추상화, MOM은 메시지 기반 비동기 통신, TP 모니터는 트랜잭션 처리 관리다.
답을 가리고 확인
“미들웨어와 트랜잭션 연계”의 핵심 규칙과 헷갈리는 지점을 설명해 보세요.
확인 답안 보기
동기는 응답 대기, 비동기는 요청과 결과 처리를 분리. 송수신 전문의 헤더·데이터·종료 구조와 오류 처리를 구분한다. 비동기라고 처리 성공이 보장되지 않는다. 재시도·중복 처리·순서 정책을 설계해야 한다.
꼭 기억할 것
동기는 응답 대기, 비동기는 요청과 결과 처리를 분리. 송수신 전문의 헤더·데이터·종료 구조와 오류 처리를 구분한다.
헷갈리는 지점 비동기라고 처리 성공이 보장되지 않는다. 재시도·중복 처리·순서 정책을 설계해야 한다.
03
형상 관리와 배포
형상 식별→변경 통제→상태 보고→감사의 흐름으로 버전과 변경을 관리한다. 기준선은 공식 검토·승인된 기준 상태다. CI는 빈번한 통합과 자동 검증, CD는 전달/배포 자동화를 뜻한다.
답을 가리고 확인
“형상 관리와 배포”의 핵심 규칙과 헷갈리는 지점을 설명해 보세요.
확인 답안 보기
Git commit은 로컬 이력, push는 원격 반영. 릴리스 노트는 변경·수정·알려진 문제·영향을 전달한다. 버전 관리 도구를 쓰는 것만으로 변경 승인·감사까지 포함하는 형상 관리 전체를 수행한 것은 아니다.
꼭 기억할 것
Git commit은 로컬 이력, push는 원격 반영. 릴리스 노트는 변경·수정·알려진 문제·영향을 전달한다.
헷갈리는 지점 버전 관리 도구를 쓰는 것만으로 변경 승인·감사까지 포함하는 형상 관리 전체를 수행한 것은 아니다.
04
패키징과 문서·DRM
패키징은 실행·설치에 필요한 구성물을 묶어 전달하는 작업이다. 사용자 매뉴얼과 설치 매뉴얼의 대상·절차를 구분한다. DRM은 콘텐츠 사용 권한을 통제한다.
답을 가리고 확인
“패키징과 문서·DRM”의 핵심 규칙과 헷갈리는 지점을 설명해 보세요.
확인 답안 보기
DRM 구성: 콘텐츠 제공자, 배포자, 클리어링 하우스, 소비자, 패키저, 컨트롤러 등을 역할로 이해한다. 릴리스 노트는 기능 변경 안내이며 설치 절차 전체를 대신하지 않는다.
꼭 기억할 것
DRM 구성: 콘텐츠 제공자, 배포자, 클리어링 하우스, 소비자, 패키저, 컨트롤러 등을 역할로 이해한다.
헷갈리는 지점 릴리스 노트는 기능 변경 안내이며 설치 절차 전체를 대신하지 않는다.
05
추가 단답 점검
SOAP·WSDL·UDDI는 메시지·서비스 기술·서비스 등록/탐색이라는 서로 다른 역할이다. ETL은 추출·변환·적재, EAI는 시스템 간 연계다. 백업의 RPO는 감내 가능한 데이터 손실 시점, RTO는 복구 목표 시간이다.
답을 가리고 확인
“추가 단답 점검”의 핵심 규칙과 헷갈리는 지점을 설명해 보세요.
확인 답안 보기
Full 백업 전체 / Incremental 직전 백업 이후 / Differential 마지막 전체 백업 이후 변경분. 증분 복구에는 전체 백업과 이후 필요한 증분 체인이 필요하다. 차등은 마지막 전체와 마지막 차등이 핵심이다.
꼭 기억할 것
Full 백업 전체 / Incremental 직전 백업 이후 / Differential 마지막 전체 백업 이후 변경분.
헷갈리는 지점 증분 복구에는 전체 백업과 이후 필요한 증분 체인이 필요하다. 차등은 마지막 전체와 마지막 차등이 핵심이다.
06
IaC와 GitOps
IaC(Infrastructure as Code)는 서버·네트워크 등 인프라 구성을 코드·설정 파일로 작성해 버전 관리하고 자동으로 적용하는 방식이다. GitOps는 Git 저장소의 선언적 설정을 배포의 단일 진실 공급원으로 삼아, 저장소 변경이 자동으로 실제 환경에 반영되도록 하는 운영 방식이다. CI/CD 자동화를 인프라·배포 설정 관리까지 확장한 개념으로 이해한다.
답을 가리고 확인
“IaC와 GitOps”의 핵심 규칙과 헷갈리는 지점을 설명해 보세요.
확인 답안 보기
IaC는 수동으로 콘솔에서 서버를 설정하는 대신 코드로 재현 가능하게 만든다. GitOps는 배포 상태를 Git 커밋 이력으로 추적할 수 있게 한다. IaC를 사용한다고 코드 자체의 품질(테스트·리뷰)이 자동으로 보장되는 것은 아니다.
꼭 기억할 것
IaC는 수동으로 콘솔에서 서버를 설정하는 대신 코드로 재현 가능하게 만든다. GitOps는 배포 상태를 Git 커밋 이력으로 추적할 수 있게 한다.
헷갈리는 지점 IaC를 사용한다고 코드 자체의 품질(테스트·리뷰)이 자동으로 보장되는 것은 아니다.
07
EAI 유형·ESB·연계 흐름
연계는 송신 시스템에서 데이터를 추출하고 변환해 수신 시스템에 전달·검증·반영하는 과정이다. EAI는 기업 내 응용 통합이고 Point-to-Point는 개별 연결, Hub-and-Spoke는 중앙 허브, Message Bus는 공통 버스 중심 구조다.
ESB는 서비스 메시지 라우팅·변환 등 공통 연계를 제공한다. 전문은 통신 규약에 맞춘 메시지로 헤더·데이터·종료 부분 등을 구분한다. 장애 시 재시도·중복·순서·오류 응답 정책을 정해야 한다.
과정으로 이해하기
- 결제 완료 메시지가 재전송되어 두 번 도착할 수 있다.
- 주문번호·이벤트번호 등으로 이미 처리한 메시지를 식별해 중복 효과를 막는다.
답을 가리고 확인
같은 요청을 여러 번 적용해도 의도한 효과가 한 번 적용과 같은 성질은?
확인 답안 보기
멱등성.
꼭 기억할 것
직접 연결 P2P / 중앙 연결 허브 / 공통 통로 버스. 송신→변환→전달→검증→반영.
헷갈리는 지점 재시도 때문에 같은 요청이 여러 번 올 수 있다. 처리 성공과 전송 성공을 구별한다.
08
REST·HTTP·SOAP·WSDL·UDDI
REST는 자원 중심 인터페이스·무상태 등 제약을 가진 아키텍처 스타일이다. HTTP GET은 조회, POST는 처리·생성 등에 사용, PUT은 대상 자원 대체, PATCH는 부분 변경, DELETE는 삭제에 사용한다. GET 같은 안전 메서드는 서버 상태 변경을 요청하는 의미가 아니다.
SOAP는 XML 기반 메시징 프로토콜, WSDL은 서비스 동작·메시지·접속 정보 기술, UDDI는 서비스 등록·탐색 역할이다. JSON은 키·값·배열 등을 표현하는 데이터 형식이며 XML은 태그 기반 구조다. 형식과 통신 규칙과 설계 스타일을 구분한다.
| HTTP 코드 | 의미 |
|---|---|
| 200 | 성공 |
| 201 | 생성됨 |
| 204 | 성공·응답 본문 없음 |
| 400 | 잘못된 요청 |
| 401 | 인증 필요·실패 |
| 403 | 접근 거부 |
| 404 | 찾을 수 없음 |
| 500 | 서버 내부 오류 |
답을 가리고 확인
SOAP 서비스의 동작과 메시지 형식을 기술하는 것은?
확인 답안 보기
WSDL.
꼭 기억할 것
REST 스타일 / HTTP 통신 의미 / JSON·XML 형식 / SOAP 메시지 / WSDL 기술 / UDDI 탐색.
헷갈리는 지점 POST가 반드시 생성만 한다는 규칙은 아니다. 무상태는 서버에 데이터 저장이 없다는 뜻이 아니다.
09
미들웨어·DB 연결·서버 흐름
미들웨어는 응용과 OS·통신·데이터 환경 사이의 공통 기능을 제공한다. RPC는 원격 호출 추상화, MOM은 메시지 지향 통신, ORB는 분산 객체 요청 중개, TP 모니터는 트랜잭션 처리 관리, WAS는 서버 응용 실행 환경을 제공한다.
DB 연결에서는 연결 생성→SQL 준비·바인딩→실행→결과 읽기→자원 정리 순서를 이해한다. 연결 풀은 연결을 재사용해 생성 비용을 줄인다. 서버는 입력 검증·업무 규칙·트랜잭션·예외 처리·인가를 책임별로 나눠 구현한다.
과정으로 이해하기
- 요청 입력 검사→사용자 권한 확인→업무 서비스→DB 트랜잭션→응답.
- DB 실패 시 성공 응답을 보내지 않고 오류·롤백 정책을 적용한다.
답을 가리고 확인
연결을 매 요청마다 새로 만들지 않고 재사용하는 구조는?
확인 답안 보기
커넥션 풀(연결 풀).
꼭 기억할 것
RPC 호출 / MOM 메시지 / ORB 객체 / TP 모니터 트랜잭션 / WAS 응용 실행.
헷갈리는 지점 연결 풀을 쓰더라도 빌린 연결을 적절히 반환해야 한다. 동기·비동기와 성공 보장은 별개다.
10
형상 관리·빌드·배포 전략
형상 관리는 구성 항목을 식별하고 변경을 통제하며 상태를 기록·감사한다. 기준선은 검토·승인되어 변경 관리 기준이 된 상태다. 빌드는 소스에서 실행·배포 산출물을 만드는 과정이고 배포는 그 결과를 대상 환경에 반영하는 과정이다.
CI는 자주 통합해 자동 빌드·테스트로 문제를 찾고 Continuous Delivery는 배포 가능한 상태를 유지하며 Continuous Deployment는 변경을 자동으로 운영에 배포한다. Blue-Green은 두 환경 전환, Canary는 일부 사용자·트래픽에 먼저 배포, Rolling은 순차 교체다.
과정으로 이해하기
- 신버전을 트래픽 5%에 먼저 적용→지표 확인→확대는 Canary.
- 동일 규모 새 환경 검증 후 트래픽 일괄 전환은 Blue-Green.
답을 가리고 확인
공식 검토·승인된 변경 관리의 기준 상태는?
확인 답안 보기
기준선(Baseline).
꼭 기억할 것
CI 통합·검증 / 전달 배포 가능 / 자동 배포 운영 반영. Blue-Green 두 환경, Canary 일부, Rolling 순차.
헷갈리는 지점 Git 사용만으로 승인·감사까지 포함한 형상 관리 전체를 대체하지 않는다.
11
백업·복구·RPO·RTO·패키징·DRM
전체 백업은 모든 대상, 증분은 직전 백업 이후 변경, 차등은 마지막 전체 백업 이후 변경이다. 월 전체·화 증분·수 증분이라면 수요일까지 복구하려면 전체와 이후 증분 체인을 사용한다. 차등은 전체와 원하는 시점의 차등을 사용한다.
RPO는 감내 가능한 데이터 손실 기간, RTO는 복구 목표 시간이다. 패키징은 실행·설치 구성물을 전달 형태로 묶고 릴리스 노트는 변경·수정·알려진 문제를 알린다. DRM은 패키저가 보호 형태로 포장, 컨트롤러가 사용 권한 통제, 클리어링 하우스가 라이선스·권한 관리를 맡는 역할을 구분한다.
과정으로 이해하기
- RPO 1시간: 장애 직전 1시간 이내 데이터 손실을 감내하는 목표.
- RTO 2시간: 장애 이후 2시간 이내 서비스 복구 목표.
답을 가리고 확인
릴리스 노트와 설치 매뉴얼의 차이는?
확인 답안 보기
릴리스 노트는 변경·문제 안내, 설치 매뉴얼은 환경·설치·설정 절차 안내.
꼭 기억할 것
RPO 데이터 손실 허용 / RTO 복구 소요 목표. 증분 직전 이후, 차등 전체 이후.
헷갈리는 지점 백업 파일이 있다고 복구가 검증된 것은 아니다. 복구 절차·자원·시간까지 확인한다.
12
안전성과 멱등성 답안 구별
안전한 메서드는 클라이언트가 서버 상태 변경을 요청하지 않는 의미다. 멱등성은 같은 요청을 여러 번 했을 때 서버에 의도된 효과가 한 번과 같다는 뜻이다. GET은 안전하고 멱등이며 PUT·DELETE는 멱등이지만 안전하지 않다.
답을 가리고 확인
DELETE의 첫 응답은 204, 다음은 404이면 멱등성이 깨졌는가?
확인 답안 보기
아니다. 멱등성은 응답 코드의 동일성이 아니라 의도된 서버 효과로 판단한다.
2026.10.14 재확인: IETF RFC 9110 HTTP 의미론
꼭 기억할 것
GET·HEAD는 안전/멱등, PUT·DELETE는 멱등, POST는 일반적으로 멱등 보장이 없다.
헷갈리는 지점 DELETE를 반복해서 응답 코드가 달라져도 의도된 서버 효과가 같으면 멱등이다.
직접 풀어보기 12문제
모두 유형 연습을 위해 직접 만든 문제입니다. C 예제의 printf·strlen은 필요한 표준 헤더가 포함된 상황을 가정합니다. Java는 표시된 클래스·main 위치에서 실행합니다. 단답은 동의어가 있을 수 있어 자동 판정 대신 자기 채점을 사용합니다.
데이터 이동
원천에서 데이터를 뽑고 가공하여 목적 저장소에 넣는 절차의 약어는?
정답과 풀이 확인
정답 ETL
Extract, Transform, Load.
복구 목표
장애 후 서비스를 다시 사용할 수 있게 하기까지의 목표 시간은?
정답과 풀이 확인
정답 RTO
Recovery Time Objective. 허용 데이터 손실 시점의 목표인 RPO와 구별한다.
변경 안내
새 버전의 변경 기능·수정 결함·알려진 문제를 전달하는 문서는?
정답과 풀이 확인
정답 릴리스 노트
설치 매뉴얼·사용자 매뉴얼과 목적이 다르다.
인프라 코드화
서버·네트워크 구성을 코드로 작성해 버전 관리·자동 적용하는 방식의 약어는?
정답과 풀이 확인
정답 IaC
Infrastructure as Code.
배포 자동화 확장
Git 저장소의 선언적 설정을 배포의 단일 진실 공급원으로 삼는 운영 방식은?
정답과 풀이 확인
정답 GitOps
Git 변경 이력이 실제 배포 상태 반영의 기준이 된다.
RPO와 RTO
데이터 손실 허용 기간 30분, 복구 목표 시간 2시간일 때 RPO와 RTO는?
정답과 풀이 확인
정답 30분 / 2시간
RPO는 데이터 손실 시점, RTO는 복구 시간 목표.
증분 복구 순서
월요일 전체, 화요일 증분, 수요일 증분 백업이 있다. 수요일까지 복구할 때 필요한 백업은?
정답과 풀이 확인
정답 월 전체 + 화 증분 + 수 증분
증분은 직전 백업 이후 변화라 이후 필요한 체인을 모두 적용한다.
부분 배포
신버전을 사용자 5%에 먼저 배포하고 지표를 보며 확대하는 전략은?
정답과 풀이 확인
정답 Canary 배포
Blue-Green은 두 환경 전환, Rolling은 순차 교체.
서비스 기술 문서
서비스의 동작·메시지·접속 정보를 기술하는 SOAP 관련 표준은?
정답과 풀이 확인
정답 WSDL
UDDI 등록·탐색, SOAP 메시징과 구분한다.
멱등성의 대상
DELETE를 반복했더니 204 다음 404가 반환됐다. 이것만으로 멱등성을 위반했다고 할 수 있는가?
정답과 풀이 확인
정답 아니오
의도된 서버 효과가 한 번과 같은지가 기준이다. 응답 코드가 같아야 하는 것은 아니다.
복구 시점과 시간
허용 데이터 손실 시점은 15분, 서비스 복구 목표 시간은 2시간이다. 각 지표는?
정답과 풀이 확인
정답 RPO=15분, RTO=2시간
RPO는 복구 시점 목표로 데이터 손실 허용 범위, RTO는 복구 시간 목표다.
기출과 연결하기
코드 공통 원리 또는 공식 출제경향을 보완하는 단원입니다. 특정 회차의 직접 출제를 주장하지 않습니다.