출제기준 세세항목: 내외부 인터페이스 요구사항 · 요구공학
요즘 시스템은 혼자 일하는 경우가 거의 없습니다. 쇼핑몰은 결제를 위해 결제 대행사와 연결되고, 배송 조회를 위해 택배사와 연결되며, 회원 정보를 위해 사내 인사 시스템과 연결되기도 합니다. 이렇게 두 시스템(또는 두 모듈)이 만나 데이터를 주고받는 접점을 인터페이스라고 합니다.
인터페이스는 양쪽이 같은 약속을 지켜야 동작합니다. 한쪽은 날짜를 '20261012'로 보내는데 다른 쪽은 '2026-10-12'를 기다린다면, 두 시스템이 각자 완벽해도 연결은 실패합니다. 그래서 '무엇을, 언제, 어떤 모양으로, 어떤 방법으로 주고받을지'에 대한 요구를 미리 정리해 두는데, 이것이 인터페이스 요구사항입니다.
이 항목의 목표는 그 요구사항을 빠짐없이 모으고, 양쪽이 같은 뜻으로 이해했는지 확인하는 것입니다. 이때 쓰는 체계적인 방법이 요구공학입니다.
인터페이스는 연결되는 상대에 따라 둘로 나눠 봅니다. 내부 인터페이스는 우리가 만드는 시스템 안의 구성 요소끼리 연결되는 부분입니다. 주문 모듈이 재고 모듈에 '이 상품 재고 있나요?'라고 묻는 경우가 그렇습니다. 양쪽을 우리 팀이 함께 만들기 때문에 형식을 맞추기가 비교적 쉽습니다.
외부 인터페이스는 우리 시스템과 바깥의 무언가가 연결되는 부분입니다. 상대는 다른 회사의 시스템일 수도, 바코드 리더기 같은 하드웨어일 수도, 화면을 보는 사용자일 수도 있습니다. 상대 쪽 규칙은 우리가 마음대로 바꿀 수 없는 경우가 많아, 상대의 기준과 제약을 먼저 정확히 알아내는 것이 중요합니다.
인터페이스 요구사항을 정리할 때는 보통 다음과 같은 내용을 담습니다. 인터페이스 이름과 식별자, 연결되는 대상 시스템, 주고받는 데이터 항목, 송수신 방식(실시간인지 모아서 한꺼번에 보내는지), 처리 주기, 데이터 형식, 성능 조건(예: 몇 초 안에 응답), 보안 조건(암호화, 인증) 등입니다. 이렇게 정리한 문서를 인터페이스 요구사항 명세서라고 부릅니다.
인터페이스 요구사항도 결국 요구사항이므로 기능 요구사항과 비기능 요구사항으로 나눠 볼 수 있습니다. '주문 정보를 택배사로 보낸다'는 기능 요구사항이고, '3초 안에 응답해야 한다', '전송 데이터는 암호화한다'는 비기능 요구사항입니다.
요구사항은 처음부터 깔끔한 모양으로 주어지지 않습니다. 사용자는 원하는 것을 정확히 말로 설명하기 어려워하고, 이해관계자마다 바라는 것이 서로 부딪히기도 하며, 개발 도중에 마음이 바뀌기도 합니다. 요구공학은 이런 요구사항을 감으로 다루지 않고, 정해진 절차와 기법으로 모으고 정리하고 관리하는 활동입니다.
요구공학은 크게 두 부분으로 나뉩니다. 요구사항 개발은 요구사항을 처음 만들어 내는 과정이고, 요구사항 관리는 만들어진 요구사항이 바뀔 때 그 변경을 통제하고 추적하는 과정입니다.
요구사항 개발은 네 단계로 진행합니다. 도출(Elicitation)에서 요구를 모으고, 분석(Analysis)에서 정리하고 다듬고, 명세(Specification)에서 문서로 적고, 확인 단계에서 사용자 요구를 제대로 담았는지와 문서가 올바른지를 함께 점검합니다. 시험에는 이 순서가 그대로 자주 나오니 '도출 → 분석 → 명세 → 확인'으로 외워 두면 좋습니다. 마지막 단계를 '검증'이라고 부르는 자료도 있습니다. 단계 이름으로는 확인과 검증을 섞어 쓰지만, 다음 절에서 보듯 V&V 용어로는 둘을 구분합니다.
도출은 이해관계자에게서 요구를 끌어내는 단계입니다. 직접 묻는 인터뷰, 여러 사람이 자유롭게 아이디어를 내는 브레인스토밍, 많은 사람에게 같은 질문을 돌리는 설문, 실제 업무 현장을 지켜보는 관찰, 이해관계자를 모아 집중적으로 논의하는 워크숍 등이 쓰입니다. 간단한 시제품을 보여 주고 반응을 듣는 프로토타이핑, 사용자가 시스템으로 하려는 일을 시나리오로 정리하는 유스케이스도 도출에 많이 씁니다.
외부 인터페이스라면 상대 시스템 담당자와의 협의가 특히 중요합니다. 상대가 이미 정해 둔 연동 규격서가 있다면 그것도 중요한 요구사항의 출처입니다.
분석은 모은 요구를 정리하는 단계입니다. 서로 모순되는 요구는 없는지, 빠진 것은 없는지, 너무 모호해서 구현할 수 없는 요구는 없는지 살핍니다. 요구를 기능과 비기능으로 분류하고, 우선순위를 정하고, 실현 가능한지 따져 봅니다. 데이터가 어디서 어디로 흐르는지 그리는 자료 흐름도(DFD), 데이터 항목의 뜻을 정리한 자료 사전(DD) 같은 도구가 분석을 돕습니다.
명세는 분석한 요구사항을 누구나 같은 뜻으로 읽을 수 있게 문서로 적는 단계입니다. 이렇게 만든 문서를 요구사항 명세서(SRS, Software Requirements Specification)라고 합니다.
명세 방법은 둘로 나뉩니다. 비정형 명세는 자연어 문장이나 다이어그램으로 적는 방법입니다. 작성하고 읽기 쉬워 이해관계자와 소통하기 좋지만, 같은 문장도 사람마다 다르게 읽을 수 있다는 약점이 있습니다. 정형 명세는 수학적 기호와 논리로 적는 방법으로, Z, VDM 같은 명세 언어가 대표적입니다. 뜻이 하나로 정확히 정해지고 모순을 검사하기 좋지만, 작성과 이해에 전문 지식이 필요합니다.
좋은 명세서는 몇 가지 성질을 갖춥니다. 사실과 맞고(정확성), 한 가지 뜻으로만 읽히며(명확성), 빠진 것이 없고(완전성), 서로 어긋나지 않으며(일관성), 실제로 맞는지 시험해 볼 수 있고(검증 가능성), 어디서 나온 요구인지 따라갈 수 있으며(추적성), 바뀌어도 고치기 쉬워야(변경 용이성) 합니다. '빠르게 응답해야 한다'보다 '3초 안에 응답해야 한다'가 좋은 명세인 이유가 바로 검증 가능성입니다.
명세서를 다 썼다고 끝이 아닙니다. 이 문서가 정말 사용자가 원하는 것을 담았는지, 그리고 문서 자체가 올바르게 작성되었는지 점검해야 합니다. 앞의 것을 확인(Validation, 올바른 제품을 만드는가), 뒤의 것을 검증(Verification, 제품을 올바르게 만드는가)으로 구분하기도 합니다.
점검에는 사람이 문서를 함께 읽으며 결함을 찾는 검토 기법을 주로 씁니다. 세 가지 기법은 '얼마나 격식을 갖추는가'를 기준으로 견주면 구분하기 쉽습니다. 가장 가벼운 쪽인 동료 검토(Peer Review)에서는 문서를 쓴 사람이 직접 내용을 짚어 가며 이야기하고, 함께 일하는 동료들이 듣다가 이상한 점을 짚어 줍니다. 워크스루(Walkthrough)는 한 단계 더 준비된 방식으로, 참석자들이 모이기 전에 자료를 받아 미리 읽어 오기 때문에 실제 모임은 짧게 끝나고 그 자리에서는 찾아 온 결함을 확인하는 데 집중합니다. 가장 엄격한 인스펙션(Inspection)은 문서를 쓴 사람이 아니라 검토를 맡은 사람들이 미리 정해 둔 역할·절차·점검표에 따라 진행하고, 찾은 결함을 기록해 고쳐졌는지까지 따라갑니다. 참고로 국제 표준 문서에서는 워크스루를 작성자가 이끄는 검토로 설명하기도 하니, 시험에서는 위 구분을 기준으로 기억하면 됩니다.
이 밖에도 프로토타입을 만들어 사용자에게 직접 확인받거나, 요구사항마다 테스트 케이스를 미리 설계해 보며 검증 가능한지 따져 보는 방법도 있습니다. 테스트 케이스를 만들 수 없는 요구사항이라면 너무 모호하다는 뜻입니다.
인터페이스 요구사항의 검증은 보통 '검토 계획 수립 → 검토 및 오류 수정 → 베이스라인 설정' 순서로 진행합니다. 베이스라인은 검토를 마치고 관계자들이 합의한 기준 버전입니다. 이후 요구사항을 바꾸려면 정해진 변경 절차를 거쳐야 하며, 이것이 요구사항 관리의 출발점입니다.
쇼핑몰이 결제 대행사와 연결하는 것은 외부 인터페이스입니다. 대행사가 제공한 연동 규격서를 바탕으로 '주문번호, 결제 금액, 결제 수단을 실시간으로 보내고 결과 코드를 5초 안에 받는다', '금액과 카드 정보는 암호화해 보낸다'처럼 대상, 데이터, 방식, 성능, 보안 조건을 인터페이스 요구사항 명세서에 적습니다.
인터뷰에서 '재고 정보는 빨리 맞춰졌으면 좋겠다'는 요구가 나왔습니다. 분석 단계에서 담당자와 다시 이야기해 '창고 시스템의 재고 변동은 10분 이내에 쇼핑몰에 반영한다'로 고쳐 명세했습니다. 이제 시험해 볼 수 있는 요구가 되었고, 송수신 방식도 10분 주기의 배치로 정할 근거가 생겼습니다.
인터페이스 요구사항 명세서를 인스펙션하던 중, 택배사로 보내는 데이터에 '받는 사람 연락처'가 빠져 있는 것을 발견했습니다. 개발 전에 찾아냈기 때문에 문서 한 줄을 고치는 것으로 끝났습니다. 수정이 반영된 문서는 베이스라인으로 확정되었습니다.