[정보처리기사] 인터페이스 구현 및 통합 테스트 예상문제 1회

문제 1. EAI 연계 유형

기업 내 이기종 시스템을 연계하는 EAI(Enterprise Application Integration)는 구현 방식에 따라 여러 유형으로 분류됩니다. 다음 설명에 해당하는 EAI 유형으로 가장 알맞은 것은 무엇입니까?

“중앙의 허브(Hub)를 통해 모든 시스템이 메시지를 주고받는 방식으로, 허브 장애 시 전체 연계가 중단될 수 있다.”

1. Point-to-Point
2. Hub & Spoke
3. Message Bus
4. Hybrid

정답

② Hub & Spoke — 중앙 허브를 매개로 모든 시스템이 연결되는 방식입니다.

해설

Hub & Spoke 방식은 중앙 허브가 모든 메시지를 중계합니다. 연계 시스템이 늘어날수록 허브에 부하가 집중되고, 허브 단일 장애점(Single Point of Failure) 문제가 발생할 수 있습니다. 지문의 설명은 Hub & Spoke의 특징과 정확히 일치합니다.

오답: ① Point-to-Point — 시스템끼리 1:1로 직접 연결하는 방식이며, 시스템 수 증가 시 연결 수가 기하급수적으로 늘어납니다.
정답: ② Hub & Spoke — 중앙 허브를 경유하여 연결하며, 허브 장애 시 전체 연계가 중단되는 것이 특징입니다.
오답: ③ Message Bus — 공유 버스(Bus)를 통해 시스템들이 느슨하게 연결되며, ESB의 기반 개념입니다. 단일 장애점이 Hub & Spoke보다 적습니다.
오답: ④ Hybrid — Hub & Spoke와 Message Bus를 혼합한 방식으로, 대규모 분산 환경에서 사용합니다.

문제 2. ESB와 EAI 비교

ESB(Enterprise Service Bus)와 EAI를 비교한 설명으로 옳지 않은 것은 무엇입니까?

1. ESB는 버스 방식으로 각 시스템이 버스에 연결되어 느슨한 결합을 지향한다.
2. EAI는 기업 내부 시스템 간 연계에 주로 사용되고, ESB는 기업 간 서비스 연계에도 활용된다.
3. ESB는 중앙 집중형 허브를 두어 모든 메시지를 단일 허브에서 처리한다.
4. EAI는 Point-to-Point, Hub & Spoke 등 다양한 연계 유형을 포함하는 개념이다.

정답

③ — ESB는 중앙 집중형 허브 방식이 아니라 분산 버스 방식을 사용합니다.

해설

ESB는 공유 버스를 중심으로 각 서비스가 독립적으로 연결되는 분산 구조입니다. 단일 허브에 의존하지 않으므로 허브 장애 시 전체 시스템이 중단되는 문제를 줄일 수 있습니다. “중앙 집중형 허브”라는 표현은 Hub & Spoke 방식의 설명이지 ESB의 설명이 아닙니다.

오답: ① — ESB는 버스 방식의 느슨한 결합을 지향하므로 올바른 설명입니다.
오답: ② — EAI는 내부 시스템 연계에 초점을 두고, ESB는 SOA 기반으로 기업 간 서비스 연계에도 활용되므로 올바른 설명입니다.
정답(오류 보기): ③ — 중앙 집중형 허브 처리는 Hub & Spoke의 특징이며, ESB에 대한 설명으로는 틀렸습니다.
오답: ④ — EAI는 Point-to-Point, Hub & Spoke, Message Bus, Hybrid 등 여러 유형을 포괄하는 개념이므로 올바른 설명입니다.

문제 3. 통합 테스트 방식

통합 테스트(Integration Test) 방식에 대한 설명으로 옳은 것은 무엇입니까?

1. 빅뱅(Big Bang) 방식은 모듈을 점진적으로 통합하므로 오류 발생 위치를 쉽게 파악할 수 있다.
2. 하향식(Top-Down) 통합은 하위 모듈 대신 스텁(Stub)을 사용하여 상위 모듈부터 테스트한다.
3. 상향식(Bottom-Up) 통합은 드라이버(Driver) 대신 스텁(Stub)을 사용하여 하위 모듈부터 테스트한다.
4. 하향식 통합은 초기에 드라이버(Driver)가 필요하며, 상향식 통합에는 스텁(Stub)이 필요하다.

정답

② 하향식 통합은 상위 모듈부터 테스트하며, 미완성 하위 모듈을 스텁(Stub)으로 대체합니다.

해설

하향식 통합 테스트는 최상위 모듈에서 시작해 하위 모듈 방향으로 진행합니다. 아직 구현되지 않은 하위 모듈은 스텁(Stub)이라는 임시 모듈로 대체합니다. 반대로 상향식 통합은 하위 모듈에서 시작하므로 상위 모듈을 대체하는 드라이버(Driver)가 필요합니다.

오답: ① 빅뱅 방식은 모든 모듈을 한꺼번에 통합하여 테스트하므로, 오류 발생 위치를 파악하기 어렵습니다.
정답: ② 하향식 통합에서 미완성 하위 모듈은 스텁(Stub)으로 대체하며, 이 설명은 정확합니다.
오답: ③ 상향식 통합에서는 상위 모듈을 대체하는 드라이버(Driver)가 필요하며, 스텁(Stub)이 아닙니다.
오답: ④ 드라이버는 상향식 통합에서 필요하고, 스텁은 하향식 통합에서 필요합니다. 보기는 둘의 역할을 바꾸어 설명하였습니다.

문제 4. 인터페이스 보안 취약점

인터페이스 구현 시 보안을 강화하기 위한 방법으로 적절하지 않은 것은 무엇입니까?

1. 전송 데이터를 SSL/TLS 프로토콜로 암호화하여 도청을 방지한다.
2. API 호출 시 인증 토큰(Token)을 검증하여 비인가 접근을 차단한다.
3. 데이터 무결성 확인을 위해 해시(Hash) 값을 함께 전송하여 변조 여부를 검증한다.
4. 인터페이스 처리 속도 향상을 위해 송·수신 데이터의 유효성 검사를 생략한다.

정답

④ — 유효성 검사를 생략하면 보안 취약점이 발생하므로 적절하지 않습니다.

해설

인터페이스 보안에서 송·수신 데이터의 유효성 검사는 필수 절차입니다. 유효성 검사를 생략하면 비정상 데이터나 악의적인 입력이 그대로 처리되어 SQL 인젝션, XSS 등의 공격에 노출됩니다. 따라서 처리 속도보다 보안을 우선해야 합니다.

오답: ① SSL/TLS 암호화는 전송 구간 도청을 방지하는 올바른 보안 방법입니다.
오답: ② 인증 토큰 검증은 비인가 접근 차단을 위한 표준적인 보안 방법입니다.
오답: ③ 해시 값으로 데이터 변조 여부를 검증하는 것은 무결성 확보를 위한 올바른 방법입니다.
정답(오류 보기): ④ 유효성 검사 생략은 보안 취약점을 유발하므로 인터페이스 보안 강화 방법으로 적절하지 않습니다.

문제 5. 인터페이스 오류 처리

인터페이스 구현 중 오류를 처리하는 방법에 대한 설명으로 옳지 않은 것은 무엇입니까?

1. 오류 발생 시 오류 코드와 메시지를 로그(Log)에 기록하여 추적이 가능하도록 한다.
2. 인터페이스 오류는 사용자 화면에 시스템 내부 오류 메시지를 그대로 노출하여 디버깅을 돕는다.
3. 오류 재시도 정책을 수립하여 일시적인 통신 오류 시 일정 횟수만큼 재전송을 시도한다.
4. 오류 발생 시 트랜잭션을 롤백(Rollback)하여 데이터 일관성을 유지한다.

정답

② — 시스템 내부 오류 메시지를 사용자 화면에 그대로 노출하는 것은 보안상 위험합니다.

해설

내부 오류 메시지에는 시스템 구조, 경로, 데이터베이스 정보 등 민감한 정보가 포함될 수 있습니다. 이를 사용자 화면에 그대로 노출하면 공격자가 시스템 취약점을 파악하는 데 악용할 수 있습니다. 따라서 사용자에게는 범용 오류 메시지를 제공하고, 상세 내용은 내부 로그에만 기록해야 합니다.

오답: ① 오류 코드와 메시지를 로그에 기록하는 것은 추적과 디버깅을 위한 올바른 방법입니다.
정답(오류 보기): ② 내부 오류 메시지를 화면에 그대로 노출하는 것은 보안 취약점을 유발하므로 옳지 않습니다.
오답: ③ 재시도 정책 수립은 일시적 통신 장애를 극복하기 위한 표준적인 오류 처리 방법입니다.
오답: ④ 트랜잭션 롤백은 오류 발생 시 데이터 일관성을 보장하기 위한 올바른 처리 방법입니다.