[GroSaaS 개발일지] 한 페이지에 모든 기능이? Agent GUI 개편 이야기

[GroSaaS 개발일지] 한 페이지에 모든 기능이? Agent GUI 개편 이야기

 

안녕하세요,

그로메트릭 입니다. 🐸

“Agent 등록은 완료됐는데, 로그는 왜 들어오지 않을까요?”

“설정을 저장했는데, 왜 실제 동작은 그대로일까요?”

 

관리 화면을 사용하다 보면 이런 의문이 생깁니다. 이번 개발일지에서는 GroSaaS Agent GUI의 기존 화면을 살펴보고, 기능을 쉽게 찾고 상태를 정확히 이해하도록 설계한 과정을 소개합니다.

 

이 글에서는 Agent 등록과 로그 수집의 차이, 설정 저장과 적용의 차이, 그리고 관리 화면을 개선할 때 고려한 기준을 확인할 수 있습니다.
※ 본문에 소개하는 개편 화면은 설계안입니다. 실제 구현·배포 완료를 의미하지 않으며, 이미지의 상태와 데이터는 이해를 돕기 위한 예시입니다

---

GroSaaS Agent 기존 화면과 개편 방향 요약

기존 한 화면에 모인 기능과 메뉴별로 구분한 개편 방향 비교 (재구성 이미지)

기능은 다 있는데, 찾으려면 보물찾기? 👀

먼저 살펴볼 화면은 기존 GroSaaS Agent GUI의 Fluent Bit 관리 화면입니다.

기존 화면에는 Fluent Bit 시작·중지, Inputs·Outputs·Filters 설정, 환경 변수, Hot Reload, 로그 조회 기능이 한 페이지에 모여 있었습니다. 기능은 충분했지만, 서로 다른 목적의 작업이 한 화면에 길게 나열되어 있었습니다.

 

예를 들어 Fluent Bit이 실행 중인지 확인하려는 상황을 생각해 보겠습니다.

사용자는 실행 상태를 확인할 영역부터 찾아야 합니다. 같은 페이지에 여러 설정과 로그 기능까지 있으니 원하는 정보를 찾는 과정이 복잡해집니다. 마치 필요한 물건이 어디에 있는지 몰라 서랍을 하나씩 열어보는 상황과 비슷합니다.

 

그래서 기존 기능을 삭제하지 않고, 작업 목적에 따라 화면을 나누는 방식을 검토했습니다.

Fluent Bit의 실행 상태와 시작·중지 기능은 한곳에 모으고, 수집 설정은 별도의 관리 화면에서 다루는 구성입니다.

이러한 구성은 사용자가 필요한 기능을 찾을 때 확인해야 할 영역을 명확하게 보여주는 것을 목표로 합니다.

수집기의 상태 확인·시작·중지 기능을 한곳에 모은 화면 (예시 시안)

핵심은 기능을 찾는 과정을 단순하게 만드는 것 

정보 구조(Information Architecture, IA)의 관점에서 설명해보면, 핵심은 콘텐츠와 기능을 분류하고 이름을 붙이며, 사용자가 원하는 항목까지 이동하는 경로를 체계화하는 작업입니다. Agent GUI에서는 실행 제어, 수집 설정, 로그 조회를 서로 다른 작업으로 구분하는 데 해당 관점이 유용합니다.

또한 Nielsen의 사용성 원칙 중 '회상보다 인식(Recognition Rather Than Recall)'을 참고할 수 있습니다. 사용자가 기능의 위치를 기억하도록 요구하기보다 화면에 명확한 메뉴와 이름을 제시하는 원칙입니다. 이번 메뉴 분리안은 자주 사용하는 작업을 화면에서 바로 알아볼 수 있는 구조인지 검토하는 데 초점을 맞췄습니다.

정보 구조는 메뉴 수를 줄이는 것만으로 완성되지 않습니다. 'Fluent Bit', '설정 관리', '로그 조회'처럼 메뉴 이름만 보고 작업 내용을 예상할 수 있는지도 중요합니다. 따라서 설계 검증 단계에서는 처음 보는 사용자가 상태 확인과 설정 변경 메뉴를 어디서 찾는지 살펴볼 필요가 있습니다.

등록 완료’인데 로그는 조용하다면? 🤫

이번에는 Agent 등록 정보와 Fluent Bit 실행 상태를 보여주는 화면입니다.

여기서 혼동하기 쉬운 부분이 있습니다. Agent가 등록됐다는 사실과 로그 수집이 정상이라는 사실은 다릅니다.
Agent 등록이 완료되어도 Fluent Bit이 중지되어 있다면 로그가 수집되지 않을 수 있습니다.
반대로 Fluent Bit이 실행 중이라는 표시만으로 로그가 서버까지 정상적으로 전달됐다고 단정할 수도 없습니다.
자동차에 시동이 걸렸다고 해서 목적지에 도착한 것은 아닌 것과 같습니다. 시동은 출발을 위한 조건일 뿐, 도착 여부까지 알려주지는 않습니다.

Agent 등록과 로그 수집도 마찬가지입니다.
그래서 개편 설계에서는 Agent 등록 상태와 Fluent Bit 실행 상태를 각각 표시하도록 설계했습니다.
등록 정보와 서버 연결 상태 역시 구분해 보여주는 방식을 검토했습니다.

Agent 등록 정보와 Fluent Bit 실행 상태를 구분해 보여주는 예시 화면 (가상 데이터)

이렇게 서로 다른 상태를 구분하면 사용자가 어떤 항목을 먼저 확인해야 할지 판단하는 데 도움이 됩니다.

 

관련된 이론은 '시스템 상태의 가시성(Visibility of System Status)'입니다. 사용자가 현재 시스템에서 무슨 일이 일어나고 있는지 적절한 피드백을 통해 이해할 수 있어야 한다는 원칙입니다. 하나의 '정상' 표시로 여러 상태를 묶으면 어떤 단계가 확인됐는지 알기 어렵습니다.

 

이번 화면에서는 Agent 등록 여부, Fluent Bit 실행 여부, 서버 연결 상태를 서로 다른 의미의 정보로 취급했습니다. 이는 색상 배지를 늘리는 문제가 아니라 상태별 판단 기준을 구분하는 문제입니다. 특히 '실행 중'은 프로세스 상태를 의미하며, 로그가 서버까지 정상 도달했다는 검증 결과와 동일하지 않습니다.

 

여기에는 '일관성과 표준(Consistency and Standards)' 원칙도 관련됩니다. 같은 상태에는 같은 용어와 표시 규칙을 쓰고, 서로 다른 상태에는 의미가 구별되는 이름을 사용해야 합니다. 설계 검토 시에는 '등록됨', '실행 중', '서버 연결됨'을 각 화면에서 일관되게 표현하는지 확인할 계획입니다.

등록됨 ≠ 수집 정상

저장 버튼을 눌렀는데, 왜 설정은 그대로일까? 😥

이번에는 Inputs 설정 관리 화면을 살펴보겠습니다. 수집 설정을 수정하고 저장 버튼을 누르면 작업이 끝난 것처럼 느껴집니다.
하지만 여기에는 중요한 차이가 있습니다.
설정 파일에 변경 내용을 저장하는 것과 실행 중인 Fluent Bit에 해당 설정을 적용하는 것은 별개의 과정입니다.
구성과 실행 방식에 따라 Hot Reload를 통해 변경 사항을 반영하는 단계가 필요할 수 있습니다.

저장 버튼을 누르는 것은 서류를 접수하는 것과 비슷합니다. 서류가 접수됐더라도 실제 처리가 완료됐는지는 따로 확인해야 합니다.
설정을 저장했다는 사실과 실제로 적용됐다는 사실도 별도로 구분해 확인해야합니다.

Inputs 설정을 관리하는 화면 예시 — 저장 이후 적용·결과 확인이 필요한 이유

이번 개편 설계에서는 저장부터 적용 결과 확인까지의 과정을 구분하는 방식을 검토했습니다.

저장 완료 → 적용 요청 → 적용 결과의 3단계 흐름 (설계 예시)

 

첫 번째는 저장 완료, 변경한 설정이 파일에 저장되었는지 확인하는 단계입니다.

두 번째는 적용 요청, 변경된 설정을 실행 중인 Fluent Bit에 반영하도록 요청하는 단계입니다.

세 번째는 적용 결과, 설정 적용이 성공했는지, 실패했다면 어떤 문제가 발생했는지 확인하는 단계입니다.

이 세 단계를 구분하면 저장 이후 어떤 작업이 남아 있는지 더 명확하게 안내할 수 있습니다.

 

이 과정에는 '시스템 상태의 가시성(Visibility of System Status)'과 '오류 예방(Error Prevention)' 원칙을 함께 적용해 검토할 수 있습니다. 버튼을 누른 직후의 저장 성공 표시만으로는 설정이 실행 환경에 반영되었는지 알 수 없습니다. 따라서 저장 결과, 반영 요청, 반영 결과를 다른 상태로 안내하는 설계가 필요합니다.

 

또한 오류가 발생했을 때는 '오류를 인식하고 진단하며 복구하도록 돕기(Help Users Recognize, Diagnose, and Recover from Errors)' 원칙이 중요합니다. 단순한 '실패' 표시 대신 어느 단계에서 문제가 발생했는지와 재확인할 항목을 제시해야 합니다. 다만 이 안내 방식은 설계 검토 사항이며 실제 오류 복구 기능의 구현 완료를 뜻하지 않습니다.

 

추가로 '사용자 통제와 자유(User Control and Freedom)' 관점에서는 잘못된 설정을 저장하거나 적용을 요청한 이후의 행동도 살펴봐야 합니다. 취소·재시도·재확인 같은 선택지를 어느 단계에서 제공할지는 검토 대상입니다. 지원 여부가 확인되지 않은 기능을 구현된 것처럼 소개하지 않고, 필요한 인터랙션 조건으로 구분했습니다.

저장 ≠ 적용

길 잃지 않는 Agent GUI, 동선을 그려보니? ✏️

마지막으로 개편 설계의 메뉴 구조를 살펴보겠습니다.

기존 GUI의 문제점을 바탕으로 기능을 목적에 따라 구분하는 방식을 정리했습니다. 처음 Agent를 사용하는 상황을 기준으로 다음과 같은 흐름을 생각했습니다.

Agent 등록 → 수집 설정 → 실행 상태 확인 → 로그 조회

 

이 순서에는 이유가 있습니다.

앞 단계가 끝나야 다음 단계의 결과를 믿을 수 있기 때문입니다. 등록이 안 됐다면 설정은 의미가 없고, 설정이 적용되지 않았다면 로그가 들어오지 않는 것도 당연합니다. 처음 사용하는 사람에게 길 안내 표지판을 보여주는 것과 비슷합니다. 어떤 작업을 어디에서 해야 하는지 알 수 있다면 화면 전체를 외울 필요가 없습니다.

등록 → 수집 설정 → 상태 확인 → 로그 조회로 이어지는 사용 흐름 (설계 예시)

물론 모든 사용자가 이 순서를 반드시 따라야 하는 것은 아닙니다.

이미 등록된 장비를 관리하는 경우에는 실행 상태 확인이나 로그 조회부터 시작할 수도 있습니다.

따라서 정해진 순서를 강제하기보다, 사용자가 현재 목적에 맞는 기능으로 쉽게 이동하도록 설계하는 것이 핵심입니다.

 

이 동선은 사용자 작업 흐름(Task Flow) 관점에서 설명할 수 있습니다. 화면에 존재하는 기능을 나열하는 것이 아니라, 사용자가 어떤 목표를 가지고 어떤 작업을 수행하는지 기준으로 이동 경로를 검토하는 방식입니다. 신규 등록 시에는 등록부터 로그 확인까지의 흐름을 이해할 수 있도록 하고, 기존 장비를 점검할 때는 필요한 화면에 바로 접근할 수 있어야 합니다.

 

여기에는 Nielsen의 '유연성과 사용 효율성(Flexibility and Efficiency of Use)' 원칙도 연결됩니다. 익숙하지 않은 사용자에게는 분명한 이동 경로를 제공하면서, 숙련된 사용자가 불필요한 단계를 반복하지 않도록 하는 접근입니다. 이번 설계에서는 두 사용 상황을 모두 고려한 메뉴 접근 방식을 검토했습니다.

 

이론을 실제로 검증하려면 메뉴 배치가 직관적이라는 추정만으로는 부족합니다. 신규 사용자가 '로그 수집 상태 확인'을 어디서 시작하는지, 숙련 사용자가 실행 상태 화면에 얼마나 직접적으로 접근하는지 확인하는 작업 시나리오가 필요합니다. 이러한 사용성 검증은 후속 과제로 남겨두었습니다.

마치며

기존 Agent GUI를 살펴보면서 가장 중요하게 느낀 것은 기능의 개수보다 정보를 보여주는 방식이었습니다.
기능이 많더라도 현재 상태를 이해하기 어렵거나 다음에 무엇을 해야 할지 알 수 없다면 관리 화면은 복잡하게 느껴집니다.
좋은 관리 화면은 기능을 많이 보여주는 화면이 아니라, 사용자가 현재 상태와 다음 행동을 이해할 수 있는 화면입니다.
이번 개편 설계에서 정리한 기준은 세 가지입니다. 다른 관리 화면에도 적용해 볼 수 있습니다.

① 상태가 다르면 표시도 분리하기: 등록, 실행, 서버 연결 상태를 하나의 '정상'으로 묶지 않습니다.
② 버튼을 누른 뒤의 결과와 다음 행동 보여주기: '저장 완료'가 '적용 완료'로 오해되지 않도록 단계를 나눠 안내합니다.
③ 기능 이름이 아니라 사용자의 작업을 기준으로 메뉴 나누기: 상태 확인, 설정 변경, 로그 조회처럼 목적이 다른 작업은 따로 찾을 수 있게 합니다.

이번 작업에서는 이 세 가지 기준을 바탕으로 Agent GUI의 메뉴 구조와 상태 표시, 설정 적용 흐름을 정리했습니다.
앞으로 설계안과 실제 구현 화면을 비교하며 보완할 부분을 확인할 예정입니다.

 

마지막으로 여러분께 질문 하나 드리겠습니다.

설정을 저장했는데 실제 동작이 바뀌지 않았다면, 어떤 안내가 가장 먼저 보이면 좋으신가요? (댓글로 알파벳을 남겨주세요!)

A. 저장 상태
B. 적용 상태
C. 오류 원인

 

다음 글에서는 에이전트 → 수집기 구간의 mTLS 구성에 대해 다룹니다. 에이전트와 수집기 간 상호 인증과 암호화 통신을 위한 구성 요소 설명으로 돌아오겠습니다. 다음 시리즈도 기대해주세요!

---

출처

Fluent Bit 공식 문서 — Hot Reload: https://docs.fluentbit.io/manual/administration/hot-reload

Nielsen Norman Group — 10 Usability Heuristics for User Interface Design: https://www.nngroup.com/articles/ten-usability-heuristics/

IEEE Technology Navigator — Information Architecture: https://technav.ieee.org/topic/information-architecture/

Nielsen Norman Group — Information Architecture vs. Sitemaps: https://www.nngroup.com/articles/information-architecture-sitemaps/

Nielsen Norman Group — Memory Recognition and Recall in User Interfaces: https://www.nngroup.com/articles/recognition-and-recall/