유스케이스 다이어그램을 이해하는 여정은 세 명의 핵심 주인공을 만나는 것에서부터 시작합니다. 바로 시스템과 상호작용하는 ‘액터(Actor)’, 액터가 달성하고자 하는 목표인 ‘유스케이스(Use Case)’, 그리고 이 모든 이야기가 펼쳐지는 무대인 ‘시스템(System)’입니다. 이 세 가지 구성요소는 마치 연극의 배우, 대본, 무대와 같이 각자의 명확한 역할을 수행하며, 이들의 관계를 정확히 이해하는 것이야말로 명확한 요구사항 정의의 첫걸음이자 정보처리기사 합격의 초석이 됩니다.
이 글은 유스케이스 다이어그램의 가장 근본적인 세 가지 기둥인 액터, 유스케이스, 시스템에 대해 그 어떤 자료보다 깊고 상세하게 파고들 것입니다. 각각의 개념을 단순히 정의하는 것을 넘어, 실무에서 마주할 수 있는 다양한 유형과 좋은 요소를 식별하는 노하우, 그리고 흔히 저지르는 실수까지 꼼꼼하게 짚어보겠습니다. 이 글을 통해 여러분은 흩어져 있던 개념의 조각들을 하나로 꿰어, 시스템의 요구사항을 꿰뚫어 보는 단단한 관점을 갖게 될 것입니다.
액터 (Actor): 시스템에 생명을 불어넣는 존재
액터의 정의: 단순한 ‘사람’을 넘어서
액터는 우리가 만들고자 하는 시스템의 외부에 존재하면서 시스템과 의미 있는 상호작용을 하는 모든 것을 지칭합니다. 많은 사람이 액터를 사람 모양의 아이콘 때문에 ‘사용자’나 ‘사람’으로 한정하여 생각하지만, 이는 액터라는 개념의 일부만을 이해한 것입니다. 액터는 시스템에 어떤 행위를 유발하고 그 결과에 영향을 받는 역할(Role)의 개념이며, 그 주체는 사람일 수도, 다른 시스템일 수도, 심지어 시간일 수도 있습니다.
가장 흔한 유형은 사람 액터(Human Actor)입니다. 쇼핑몰의 ‘고객’, 은행 시스템의 ‘은행원’, 회사 내부 시스템의 ‘관리자’처럼 시스템을 직접 조작하는 사용자의 역할을 의미합니다. 두 번째는 시스템 액터(System Actor)로, 최신 서비스 아키텍처에서 그 중요성이 날로 커지고 있습니다. 우리가 만드는 시스템이 신용카드 결제를 위해 외부 ‘결제 게이트웨이’와 통신하거나, 소셜 로그인을 위해 ‘카카오 인증 서버’와 정보를 주고받을 때, 이 외부 시스템들이 바로 액터가 됩니다. 마지막으로 시간 액터(Time Actor)라는 특별한 유형도 있습니다. ‘매일 자정’이 되면 자동으로 통계 데이터를 생성하는 배치 작업처럼, 특정 시간이 시스템의 기능을 촉발하는 경우 이 ‘시간’이 액터의 역할을 수행하게 됩니다.
주 액터 vs 부 액터: 이야기의 주인공과 조연
모든 액터가 시스템과 동일한 무게감으로 상호작용하는 것은 아닙니다. 액터는 그 역할의 능동성에 따라 이야기의 주인공인 주 액터(Primary Actor)와 조연인 부 액터(Secondary Actor)로 나뉩니다. 이 둘을 구분하는 것은 시스템의 핵심 가치가 누구를 향하는지, 그리고 시스템의 주요 흐름이 어떻게 흘러가는지를 파악하는 데 결정적인 단서를 제공합니다.
주 액터는 시스템을 사용하여 자신의 목표를 달성하려는 능동적인 존재입니다. 즉, 유스케이스를 먼저 시작(initiate)시키는 쪽입니다. 예를 들어, 사용자가 온라인 강의 사이트에서 ‘강의를 수강하다’라는 유스케이스를 실행할 때, 이 ‘사용자’가 바로 주 액터입니다. 시스템은 주 액터의 목표를 달성시켜주기 위해 존재하며, 시스템의 핵심 기능은 대부분 주 액터를 위해 설계됩니다. 반면, 부 액터는 주 액터의 목표 달성 과정을 돕기 위해 시스템에 의해 호출되는 수동적인 존재입니다. 시스템이 ‘강의 수강’ 요청을 처리하기 위해 해당 사용자의 수강 이력을 ‘학사 관리 시스템’에서 조회해야 한다면, 이때 시스템의 요청에 응답하는 ‘학사 관리 시스템’이 부 액터가 됩니다.
좋은 액터를 식별하는 실무 팁
프로젝트 초기 단계에서 정확하게 액터를 식별하는 것은 요구사항의 누락을 막는 중요한 활동입니다. 액터를 효과적으로 찾아내기 위해서는 다음과 같은 질문들을 스스로 또는 고객에게 던져보는 것이 좋습니다. “누가 시스템에 로그인하여 주된 기능을 사용할 것인가?”, “누가 시스템의 유지보수나 관리를 담당하는가?”, “시스템이 동작하는 데 필요한 정보를 제공하거나, 시스템으로부터 정보를 받아보는 대상은 누구인가?”, “우리가 만드는 시스템이 통신해야 하는 외부의 다른 하드웨어나 소프트웨어 시스템은 없는가?”, “특정 시간이 되면 자동으로 실행되어야 하는 기능이 있는가?”
액터를 식별할 때 몇 가지 흔한 실수를 피해야 합니다. 가장 대표적인 실수는 역할을 사람 그 자체와 혼동하는 것입니다. ‘영업팀 김대리’가 액터가 아니라, 김대리가 수행하는 역할인 ‘판매 담당자’가 액터가 되어야 합니다. 또한, 시스템의 일부를 액터로 착각해서는 안 됩니다. 예를 들어, 시스템이 사용하는 ‘데이터베이스’는 시스템의 내부에 속한 구성요소이지, 시스템 외부에서 상호작용하는 액터가 아닙니다. 액터는 항상 시스템 경계선 바깥에 존재한다는 원칙을 기억하는 것이 중요합니다.
유스케이스 (Use Case): 액터의 목표이자 시스템의 존재 이유
유스케이스의 본질: 관찰 가능한 가치의 전달
유스케이스는 특정 액터가 시스템을 통해 달성하고자 하는 하나의 완전한 목표를 의미하며, 이는 시스템의 가장 중요한 존재 이유가 됩니다. 좋은 유스케이스의 핵심 조건은 ‘액터에게 관찰 가능한 가치를 제공해야 한다’는 것입니다. 즉, 유스케이스가 성공적으로 완료되었을 때, 액터는 자신의 목표가 달성되었음을 명확하게 인지하고 그로부터 어떤 이득을 얻어야 합니다.
예를 들어 ‘비밀번호를 입력하다’나 ‘아이디 중복을 체크하다’는 그 자체만으로는 액터에게 아무런 가치를 주지 못합니다. 이것들은 ‘회원가입을 하다’라는 더 큰 목표를 달성하기 위한 과정의 일부일 뿐입니다. 반면, ‘회원가입을 하다’는 성공적으로 완료되면 사용자가 사이트의 회원이 되어 다양한 서비스를 이용할 수 있다는 명확한 가치를 제공하므로 훌륭한 유스케이스가 될 수 있습니다. 이처럼 유스케이스는 시스템의 기능 목록이 아니라, 액터의 관점에서 의미 있는 작업의 완결된 단위를 나타내야 합니다.
유스케이스 명명법과 상세화 수준
유스케이스를 명확하게 정의하기 위한 가장 기본적인 규칙은 명명법을 지키는 것입니다. 유스케이스의 이름은 반드시 ‘동사 + 명사’ 형태의 서술형으로, 액터의 행위를 명확히 표현해야 합니다. ‘주문’, ‘검색’과 같은 명사형이 아니라 ‘상품을 주문하다’, ‘도서를 검색하다’와 같이 구체적인 목표를 서술하는 것이 올바른 표현입니다. 이는 유스케이스가 정적인 기능이 아닌, 액터의 동적인 목표 달성 과정임을 상기시켜 줍니다.
또한, 유스케이스는 필요에 따라 여러 상세화 수준(Level of Detail)으로 표현될 수 있습니다. 가장 상위 레벨은 ‘요약 수준(Summary Level)’으로, ‘고객을 관리하다’처럼 여러 하위 목표를 포함하는 거시적인 비즈니스 프로세스를 나타냅니다. 이는 주로 경영진 보고나 프로젝트의 큰 그림을 설명할 때 유용합니다. 가장 일반적으로 사용되는 레벨은 ‘사용자 목표 수준(User-goal Level)’으로, ‘신규 고객을 등록하다’처럼 액터가 시스템에 앉아서 한 번에 끝낼 수 있는 구체적인 단일 목표를 의미합니다. 대부분의 유스케이스 다이어그램은 이 레벨을 기준으로 작성됩니다. 이보다 더 상세한 ‘하위 기능 수준(Sub-function Level)’은 ‘우편번호를 검색하다’와 같이 상위 유스케이스를 구성하는 작은 단계를 의미하는데, 이러한 기능들은 다이어그램을 복잡하게 만들 수 있어 별도의 유스케이스로 그리기보다는 상위 유스케이스의 명세서에 기술하는 것이 일반적입니다.
유스케이스를 효과적으로 도출하는 방법
효과적인 유스케이스 도출은 체계적인 접근법을 통해 이루어집니다. 가장 좋은 출발점은 앞에서 식별한 액터 목록을 활용하는 것입니다. 각각의 액터에게 빙의하여, “이 시스템을 통해 궁극적으로 이루고 싶은 목표는 무엇인가?”, “업무를 처리하기 위해 시스템으로 해야 하는 주요 과업들은 무엇인가?”, “시스템에서 어떤 정보를 생성(Create), 조회(Read), 수정(Update), 삭제(Delete)해야 하는가?”와 같은 질문을 던지는 것이 핵심입니다.
‘액터-목표 목록(Actor-Goal List)’을 작성하는 것은 매우 실용적인 기법입니다. 표를 하나 만들고 왼쪽 열에는 액터의 이름을, 오른쪽 열에는 해당 액터가 시스템을 통해 달성하고자 하는 목표를 모두 나열하는 것입니다. 예를 들어 ‘학생’ 액터의 목표 목록에는 ‘수강 신청하다’, ‘강의 계획서를 조회하다’, ‘성적을 확인하다’ 등이 포함될 수 있습니다. 이렇게 작성된 목표 목록이 바로 유스케이스의 후보가 되며, 이 목록을 정제하고 다듬어 최종적인 유스케이스 집합을 완성하게 됩니다. 이 과정은 요구사항을 누락 없이 꼼꼼하게 챙기는 데 큰 도움이 됩니다.
시스템 (System): 기능이 펼쳐지는 무대
시스템 경계(System Boundary)의 역할과 중요성
시스템 경계는 유스케이스 다이어그램에서 사각형으로 표현되며, 우리가 개발하고자 하는 시스템의 범위, 즉 ‘안’과 ‘밖’을 구분하는 명확한 선입니다. 이 사각형 안쪽에 그려지는 유스케이스들은 이번 프로젝트를 통해 개발팀이 책임지고 만들어야 할 기능들을 의미합니다. 반면, 사각형 바깥에 존재하는 액터들은 시스템의 사용 주체이거나 연동 대상이지만, 우리 팀의 개발 범위는 아님을 명시적으로 보여줍니다.
시스템 경계의 가장 중요한 역할은 바로 ‘프로젝트 범위 관리(Scope Management)’입니다. 프로젝트 초기에 모든 이해관계자가 이 경계선을 통해 “우리가 만들 것”과 “만들지 않을 것”에 대해 명확하게 합의할 수 있습니다. 이는 “이 기능도 추가해 주세요”와 같은 요구사항이 무분별하게 늘어나는 것을 방지하는 강력한 방어벽이 됩니다. 마치 집을 지을 때 대지의 경계를 명확히 측량해야 하는 것처럼, 시스템 개발 역시 이 경계선을 명확히 긋는 것에서부터 안정적으로 시작될 수 있습니다.
시스템 경계 설정 시 고려사항
시스템의 경계는 절대적인 것이 아니라 프로젝트의 맥락과 목표에 따라 유연하게 설정될 수 있습니다. 예를 들어 ‘결제 기능’을 생각해 봅시다. 만약 프로젝트의 목표가 우리 회사만의 독자적인 결제 솔루션을 처음부터 끝까지 만드는 것이라면, ‘신용카드로 결제하다’, ‘계좌이체로 결제하다’ 등의 상세한 유스케이스들이 모두 시스템 경계 안쪽에 위치할 것입니다.
하지만 대부분의 서비스처럼 외부 PG(결제 대행)사의 모듈을 연동하여 사용하는 경우, 상황은 달라집니다. 이때 우리 시스템의 역할은 고객의 결제 정보를 받아 외부 PG사에 전달하고 그 결과를 받는 것입니다. 따라서 우리 시스템 경계 안에는 ‘결제를 요청하다’라는 유스케이스가 존재하고, 실제 결제를 처리하는 ‘결제 게이트웨이’는 시스템 경계 바깥에 존재하는 외부 액터가 됩니다. 이처럼 경계를 어떻게 설정하느냐에 따라 프로젝트의 개발 범위와 책임 소재가 완전히 달라지므로, 이는 기술적인 결정인 동시에 매우 중요한 비즈니스적인 결정이기도 합니다.
‘블랙박스’ 관점의 유지
시스템 경계는 자연스럽게 시스템을 ‘블랙박스(Black Box)’로 바라보는 관점을 유지하도록 돕습니다. 블랙박스 관점이란, 시스템의 내부 구조나 동작 원리를 알지 못하더라도, 무엇을 넣으면(Input) 무엇이 나오는지만(Output) 알면 시스템을 사용할 수 있다는 개념입니다. 액터는 시스템 경계 바깥에 존재하므로, 경계 안에서 유스케이스들이 어떤 복잡한 기술과 로직으로 구현되는지 알 필요가 없습니다. 그저 약속된 기능을 올바르게 수행하고 자신이 원하는 목표(가치)를 달성시켜 주는지만이 중요할 뿐입니다.
이러한 추상화는 매우 중요한 설계 원칙입니다. 시스템의 내부 구현 방식(How)을 외부의 요구사항(What)으로부터 분리(decoupling)시키기 때문입니다. 덕분에 개발팀은 나중에 내부 기술 스택을 바꾸거나 로직을 개선하더라도, 시스템 경계 바깥의 액터와의 약속, 즉 유스케이스의 기능만 그대로 유지한다면 외부에 미치는 영향 없이 자유롭게 시스템을 발전시켜 나갈 수 있습니다. 시스템 경계는 이처럼 시스템의 유연성과 유지보수성을 높이는 데에도 기여하는 보이지 않는 힘을 가지고 있습니다.
마무리하며: 명확한 설계를 위한 세 가지 초석
지금까지 우리는 유스케이스 다이어그램을 구성하는 가장 본질적인 세 요소인 액터, 유스케이스, 그리고 시스템에 대해 깊이 있게 탐험했습니다. 시스템과 상호작용하는 ‘누가(Who)’를 정의하는 액터, 그들이 이루려는 ‘무엇을(What)’을 정의하는 유스케이스, 그리고 이 모든 일이 일어나는 ‘어디서(Where)’를 정의하는 시스템 경계. 이 세 가지 개념은 각각 독립적으로 존재하지 않고, 서로를 정의하며 유기적으로 연결되어 하나의 완성된 요구사항 그림을 만들어냅니다.
정보처리기사 시험을 준비하며 이들의 관계와 정의를 암기하는 것도 중요하지만, 더 나아가 각 요소가 왜 필요하며 실무에서 어떻게 작용하는지를 이해하는 것이 핵심입니다. 액터, 유스케이스, 시스템이라는 세 가지 초석을 단단히 다질 때, 여러분은 비로소 흔들림 없는 시스템 설계의 첫 단추를 성공적으로 꿰었다고 말할 수 있을 것입니다. 명확하게 정의된 이 세 가지 요소는 복잡한 요구사항의 안개를 걷어내고, 프로젝트의 모든 구성원을 성공이라는 동일한 목적지로 이끄는 가장 확실한 나침반이 되어줄 것입니다.