BEYOND SW 캠프 23기 25주차 회고

이지연·2026년 5월 25일
post-thumbnail

Week 25

기간: 2026.05.04 - 2026.05.08
커리큘럼: 최종 프로젝트 (HR 인사시스템 SaaS 플랫폼) - 발표 준비 및 기술 문서화


1. Facts — 무엇을 했나?

이번 주는 최종 발표를 준비하며 프로젝트 전체 구조와 흐름을 다시 정리하는 작업을 진행했다.

서비스 개요, 아키텍처, 도메인 흐름, AI 오케스트레이션, 이벤트 기반 구조, 배포 전략, 트러블슈팅 내용을 README와 기술 문서 형태로 체계화했다.

특히 플랫폼 기반 인프라, DevOps, 이벤트 처리, AI/RAG, 도메인 기술 문서를 각각 분리해 “왜 이런 구조를 선택했는가”를 설명할 수 있도록 정리했다.

또한 실제 시연 흐름 기준으로 인증, 전자결재, 채팅, AI 챗봇, ESG, 근태/급여 등 주요 기능들의 시나리오를 정리하고 발표용 데모 흐름을 구성했다.

발표 자료를 준비하면서 단순 기능 소개가 아니라, “기존 HR 시스템의 한계를 어떤 구조로 해결했는가”를 중심으로 프로젝트 전체 흐름을 다시 구성했다.

  • 발표 PDF 상세보기
    • 장표 및 스크립트 내용
    • 장표전달하고자 한 핵심 내용
      기존 HR 시스템의 반복 업무와 파편화 문제를 AI와 자동화 중심 구조로 해결하고자 했던 프로젝트 방향성을 먼저 전달한 장표다.
      프로젝트 배경 → 프로젝트 개요 → Workforce 솔루션 → 수행 결과 순서로 이어지는 전체 발표 흐름을 정리한 장표다.
      단순 기능 소개 이전에, 왜 지금 새로운 HR 솔루션 구조가 필요한지를 문제 중심으로 풀어가기 위해 구성한 프로젝트 배경 파트의 시작 장표다.
      HR 시스템이 단순 관리 도구를 넘어 데이터·운영·조직 문화까지 연결하는 기업 경쟁력의 핵심 인프라로 변화하고 있다는 문제의식을 담은 장표다.
      반복 수작업, 단순 문의 집중, 시스템 파편화 문제로 인해 실제 HR 담당자가 전략 업무보다 운영 유지에 더 많은 시간을 사용하고 있다는 현실 문제를 보여주기 위해 구성한 장표다.
      WORKFORCE가 기존 HR 시스템의 비효율을 자동화·AI·통합 플랫폼 구조로 해결하고자 했다는 방향성을 담은 장표다. 사람이 반복 업무보다 더 중요한 운영과 의사결정에 집중할 수 있는 환경 구축이 핵심 목표였다.
      팀 구성, 일정, 시스템 아키텍처를 중심으로 프로젝트가 어떤 구조와 흐름으로 진행되었는지 소개하기 위해 구성한 프로젝트 개요 장표다.
      각 팀원이 어떤 도메인과 기술 영역을 맡아 프로젝트를 진행했는지 역할 기준으로 정리한 장표다.
      분석·설계부터 핵심 기능 개발, 통합 테스트, 배포 안정화까지 이어지는 실제 프로젝트 개발 사이클을 정리한 장표다.
      Spring Boot 기반 MSA, Kafka·Redis 이벤트 구조, FastAPI 기반 AI 서비스, AWS EKS 운영 환경까지 전체 시스템 아키텍처와 기술 스택 흐름을 보여주기 위해 구성한 장표다.
      “One Data, One Flow” 기반으로 HR 데이터를 하나의 흐름으로 연결하는 통합 플랫폼 방향성을 전달하기 위해 구성한 Workforce 솔루션 파트의 시작 장표다.
      조직관리, 급여, 성과평가, ESG, 메신저처럼 분리되기 쉬운 기능들을 하나의 플랫폼 흐름 안으로 통합하려 했던 구조를 보여주는 장표다.
      Automation, Self-Service AI, Single Platform 세 가지 축을 중심으로 HR 운영 흐름을 어떻게 연결했는지 보여주기 위해 구성한 장표다.
      급여·근태·법정 의무 같은 반복 업무를 자동화해 운영 효율과 정확성을 높이고자 했던 Automation 구조의 시작 흐름을 담은 장표다.
      기본급, 근태 정보, 수당, 비과세 항목 등을 정책 기반으로 자동 계산하는 급여 자동화 흐름을 보여주기 위해 구성한 장표다.
      운영자가 연도별 기준값만 관리하면 세금과 4대보험 계산이 자동 반영되도록 설계한 정책 기반 급여 구조를 담은 장표다.
      지급 항목과 공제 항목을 통합 계산해 최종 실수령액과 급여 명세서 생성까지 이어지는 전체 파이프라인 흐름을 보여주기 위한 장표다.
      Quartz Scheduler와 Spring Batch 기반 자동 실행 구조가 실제 운영 환경에서 어떻게 동작하는지 보여주기 위해 구성한 시연 장표다.
      주 52시간 초과 감지, 연차 촉진, 미사용 연차 수당화처럼 회사 정책 기반 자동화 흐름이 어떻게 이어지는지를 보여주는 장표다.
      “언제 실행할지”와 “무엇을 처리할지”를 분리해 운영성과 확장성을 확보하려 했던 Quartz와 Spring Batch 구조를 정리한 장표다.
      단순 FAQ 챗봇이 아니라 임직원이 스스로 문제를 해결할 수 있는 AI 기반 업무 인터페이스를 만들고자 했던 흐름을 담은 장표다.
      연차, 내 정보, 결재 문서 같은 실시간 데이터를 자연어 기반으로 즉시 조회할 수 있도록 구성한 Self-Service AI 흐름을 보여주는 장표다.
      단순 FAQ 수준의 챗봇이 아니라, 자연어 요청이 실제 업무 액션까지 이어지는 워크플로우 구조를 만들고자 했던 흐름을 담은 장표다.
      일반 직원과 HR 운영자를 구분해 각각 다른 업무 흐름과 가이드를 제공하도록 구성한 역할 기반 챗봇 구조를 보여주는 장표다.
      회사별 정책 문서를 업로드하면 RAG 기반으로 맞춤형 답변을 생성할 수 있도록 구성한 정책 연동 흐름을 보여주는 장표다.
      실제 서비스 안에서 AI 챗봇이 동작하는 흐름을 보여주는 시연 장표다. 메뉴 탐색 없이 자연어 기반으로 기능 접근과 업무 연결이 가능하다는 사용자 경험을 전달하고자 했다.
      사용자 질문 → LLM 분류 → Router → API/RAG → 응답까지 이어지는 전체 AI 오케스트레이션 파이프라인을 시각화한 장표다.
      메신저, 결재, 평가, ESG 같은 기능들을 하나의 플랫폼 안에서 연결해 HR 운영 흐름 전체를 통합하려 했던 구조를 보여주는 장표다.
      목표 설정부터 승인, 평가 시즌 운영, 결과 공개까지 성과관리 전 과정을 하나의 흐름으로 연결한 평가 시스템 구조를 담은 장표다.
      ESG 활동 인증, 포인트 적립, 등급 시스템, 사내 그린샵까지 ESG 활동 데이터를 HR 흐름 안으로 연결하려 했던 구조를 보여주는 장표다.
      Whisper 기반 STT와 GPT 요약을 활용한 AI 회의록 생성 흐름과, WebSocket STOMP 기반 실시간 메신저 구조를 통해 협업 흐름까지 통합하려 했던 구조를 담은 장표다.
      지금까지 소개한 Automation, Self-Service AI, Single Platform 세 구조가 하나의 HR 운영 흐름으로 연결된다는 점을 다시 정리하기 위해 구성한 장표다.
      구현 자체보다 실제 HR 운영 흐름이 어떻게 바뀌는지를 보여주기 위해 프로젝트 수행 결과 파트를 구성했다.
      급여 정산, 직원 문의, 결재 작성 흐름에서 반복 단계가 얼마나 줄어들고 운영 효율이 어떻게 개선되는지를 보여주기 위해 구성한 장표다.
      ESG 자동 판정, AI 회의록 기반 성장 리포트 등 단순 자동화를 넘어 AI 기반 의사결정 보조 영역까지 확장하려 했던 향후 고도화 방향을 담은 장표다.
      발표를 마무리하고 질의응답 흐름으로 자연스럽게 연결하기 위해 구성한 Q&A 장표다.
      (백업장표)급여·결재·평가·ESG·채팅 등 다양한 도메인을 실제 운영 가능한 수준으로 통합 관리하기 위해 설계한 전체 ERD 구조를 보여주는 장표다.
      (백업장표)질문 분류, 액션 실행, API 호출, 응답 생성까지 이어지는 n8n 기반 AI 오케스트레이션 흐름을 시각화해, 단순 챗봇이 아니라 실제 업무 흐름을 자동화하는 구조라는 점을 보여주고자 했다.

2. Feelings — 어떻게 느꼈나?

  • 발표 준비는 단순히 PPT를 만드는 작업이 아니라, 우리가 만든 시스템을 다시 처음부터 이해하는 과정에 가까웠다.
    기능 하나씩 구현할 때는 보이지 않았던 전체 흐름이, 발표 구조를 정리하면서 비로소 하나의 시스템처럼 연결되어 보이기 시작했다.

  • 설명하려고 보니 내가 막연하게 이해하고 있던 부분들도 드러났다.
    특히 Kafka 이벤트 흐름이나 AI 오케스트레이션 구조는 단순히 “동작한다” 수준이 아니라, 왜 이런 구조를 선택했고 어떤 문제를 해결하려 했는지를 스스로 납득할 수 있어야 제대로 설명할 수 있었다.

  • 기능 구현 당시에는 빠르게 개발하는 데 집중했다면, 발표 자료를 정리하는 과정에서는 오히려 복잡한 구조를 얼마나 자연스럽게 전달할 수 있는지가 더 중요했다.
    실제로 문서를 정리하면서 “잘 만든 구조”보다 “설명 가능한 구조”가 훨씬 중요하다는 걸 많이 느꼈다.

  • README와 기술 문서를 정리하면서 처음으로 이 프로젝트가 단순 CRUD 수준은 아니라는 걸 객관적으로 체감했다.
    인증·인가, 이벤트 기반 구조, AI 오케스트레이션, 배치 자동화, Kubernetes 운영 환경까지 각각 따로 존재하는 기능이 아니라 하나의 흐름으로 연결되어 있었다.

  • 특히 시연 시나리오를 정리하면서 개발자 관점이 아니라 실제 사용자가 어떤 흐름으로 서비스를 이용하는지를 기준으로 다시 생각하게 되었다.
    예전에는 “이 기능이 동작하는가”에 집중했다면, 지금은 “사용자가 왜 이 흐름을 필요로 하는가”를 먼저 고민하게 되었다.

  • 발표 준비를 하면서 가장 크게 느낀 건, 결국 기술은 기능 구현 자체보다 “문제를 어떤 구조로 풀어냈는가”가 더 중요하다는 점이었다.
    같은 기능이라도 어떤 흐름으로 연결하고 어떤 운영 관점으로 설계했는지에 따라 프로젝트의 완성도가 완전히 달라진다는 걸 체감했다.


3. Findings — 무엇을 배웠나?

  • 좋은 코드는 결국 설명 가능한 코드여야 한다.
    구현만 가능한 수준과, 설계 이유까지 설명 가능한 수준은 큰 차이가 있었다.

  • 문서화는 개발 이후의 부가 작업이 아니다.
    실제로는 팀의 구조와 운영 기준을 정리하는 설계 과정에 가까웠다.

  • 발표는 기능 소개가 아니라 문제 해결 흐름을 전달하는 작업이다.
    어떤 기술을 썼는지보다, 왜 필요한 문제였고 어떻게 연결했는지가 더 중요했다.

  • 복잡한 시스템일수록 계층 분리가 중요하다.
    플랫폼, 이벤트, AI, 도메인, 운영 구조를 나눠 정리하면서 시스템 전체 흐름이 훨씬 선명하게 보였다.

  • 기술 선택에는 항상 맥락이 필요하다.
    Kafka, Redis, Kubernetes, RAG 구조 역시 “멋있어 보여서”가 아니라 실제 문제를 해결하기 위해 선택했다는 걸 설명할 수 있어야 했다.


4. Future — 다음에 어떻게 활용할까?

  • 앞으로는 구현 이후 문서화를 하는 것이 아니라, 설계 단계부터 구조와 흐름을 기록하는 습관을 만들고 싶다.

  • 기술 선택 시에도 “나중에 설명 가능한 구조인가?”를 하나의 기준으로 가져가려고 한다.

  • 이후에는 단순 기능 구현을 넘어, 아키텍처와 운영 관점까지 설명 가능한 개발자로 성장하고 싶다.

  • 이번에 정리한 기술 문서와 트러블슈팅 경험들을 기반으로, 블로그와 포트폴리오에도 설계 의도를 중심으로 기록을 남겨볼 예정이다.


🧩 마무리 한 줄

"기술은 구현하는 순간 끝나는 게 아니라, 다른 사람에게 이해 가능하게 설명할 수 있을 때 비로소 내 것이 된다."

profile
Eazy하게

0개의 댓글