또 SSAFY의 한 기수가 끝이 났다.

이번에 내가 맡은 반에서 한 팀이 프로젝트 후기를 올렸는데 기술적인 고민들과 그 해결방법들이 잘 드러나는 것 같아 여기에 공유를 해 본다. 싸피 초기 기수에 비하면 정말 장족의 발전을 한 것같다.

안녕하세요. SSAFY 14기 자율 프로젝트 팀 단위 AI Tool 생성 및 자동화를 위한 에이전트 플랫폼, ‘테세우스’ 프로젝트를 진행한 서울 A308팀입니다. 테세우스는 팀 단위 프로젝트에서 발생하는 반복적인 개발·운영 작업을 AI가 이해하고, 실행 가능한 Tool로 생성하여 재사용할 수 있도록 만든 에이전트 플랫폼입니다. 단순히 AI와 대화하는 서비스를 만드는 것이 아니라, 프로젝트를 진행하며 반복적으로 수행되는 작업을 Tool로 축적하고, 이후에는 자연어 요청만으로 자동화할 수 있는 구조를 만드는 것을 목표로 했습니다.

프로젝트 기획

저희 팀의 프로젝트는 처음부터 완전히 새로운 아이디어에서 출발한 것은 아니었습니다. 특화 프로젝트에서 진행했던 싸피증권 서비스를 더 고도화해보고 싶다는 고민에서 시작되었습니다. 싸피증권은 실시간 주식 거래소 기반 모의투자 서비스로, 실시간 데이터 처리, Kafka 기반 이벤트 처리, Redis 캐싱, Jenkins 기반 CI/CD, Docker Compose 배포 등 다양한 기술 요소가 포함된 프로젝트였습니다. 프로젝트를 운영하고 고도화하는 과정에서 서버 상태 확인, 로그 분석, 배포 후 점검, 장애 원인 파악과 같은 작업들이 반복적으로 발생했습니다. 저희는 이러한 반복 작업을 사람이 매번 직접 수행하는 것이 아니라, 우리가 직접 만든 AI Agent를 통해 분석하고 자동화할 수 있다면 기존 프로젝트를 한 단계 더 발전시킬 수 있겠다고 생각했습니다. 또한 최근 Windsurf, Claude Code와 같은 AI 개발 도구들이 빠르게 확산되면서 개발 과정에서 AI를 활용하는 방식이 보편화되고 있지만, 동시에 토큰 사용량 증가와 비용 문제도 함께 대두되고 있다고 느꼈습니다. 매번 비슷한 요청을 AI에게 새롭게 입력하고 긴 컨텍스트를 반복적으로 전달하는 방식은 편리하지만, 팀 단위 작업에서는 비효율적인 부분이 존재했습니다. 이 과정에서 저희는 AI가 한 번 수행한 작업을 구조화하고, 반복 가능한 Tool로 저장하며, 팀 단위로 재사용할 수 있는 구조가 필요하다고 판단했습니다. 그 결과 저희는 “팀 단위 AI Tool 생성 및 자동화를 위한 에이전트 플랫폼, 테세우스”를 기획하게 되었습니다.

프로젝트 수행 과정

프로젝트를 성공적으로 수행하기 위해 저희 팀은 기능 개발을 시작하기 전부터 협업 방식과 개발 파이프라인을 먼저 정리했습니다. 테세우스는 프론트엔드, 백엔드, AI Core, 인프라, 배포 환경이 함께 연결되어야 하는 서비스였기 때문에, 단순히 각자 맡은 기능만 개발해서는 완성도 있는 결과를 만들기 어렵다고 판단했습니다. 따라서 저희는 역할 분리와 전체 흐름 공유를 기반으로, 실제 개발 조직처럼 프로젝트를 운영하는 것을 목표로 했습니다.

  1. Daily Scrum과 Notion 기반 협업 체계

    저희 팀은 매일 오전 9시 30분 Daily Scrum을 진행하며 각자의 진행 상황, 당일 목표, 발생한 이슈를 공유했습니다. 또한 Notion을 활용해 기획 문서, 회의록, API 명세, 기술 자료, Convention 등을 정리했습니다. 테세우스는 AI, 백엔드, 프론트엔드, 인프라가 모두 연결되는 서비스였기 때문에 구두 공유만으로는 전체 흐름을 맞추기 어려웠습니다. Notion을 공통 문서 저장소로 활용한 덕분에 기능 목적, API 흐름, 데이터 구조, 배포 방식을 지속적으로 확인하며 개발할 수 있었습니다.

  2. Jira Epic 기반 프로젝트 범위 관리

    Jira는 단순한 이슈 관리 도구가 아니라, 프로젝트 전체 범위를 구조화하기 위한 기준으로 활용했습니다. 저희 팀은 기획, 공통 기반 환경 및 표준 세팅, 디자인, 사용자, 채팅, AI 요청 해석 및 Tool 생성, Tool 실행 및 오케스트레이션, 인프라 및 배포 세팅, 싸피증권 AI 에이전트 고도화, 최종 발표 준비처럼 큰 도메인별로 Epic을 먼저 정의했습니다. 각 Epic 안에서는 실제 개발 가능한 Story와 Task를 세분화했고, 작업 제목에도 [AI], [BE], [FE], [COMMON]과 같은 prefix 컨벤션을 적용했습니다. 이를 통해 해당 작업이 어느 영역의 업무인지 한눈에 파악할 수 있었고, 각 파트의 작업이 서로 어떻게 연결되는지도 명확하게 관리할 수 있었습니다. 프로젝트 기간 동안 Jira Story 번호는 481번까지 생성될 정도로 작업을 세분화했습니다. 이는 단순히 이슈 개수를 늘리기 위한 것이 아니라, 실제 GitLab 브랜치 생성, Merge Request, 코드 리뷰와 연결되는 작업 단위였습니다.

  3. GitLab Merge Request 기반 리뷰 문화

    저희 팀은 Jira 이슈와 GitLab 브랜치, Merge Request가 자연스럽게 연결되도록 개발 흐름을 설계했습니다. 실제 개발 시에는 이슈 번호를 기반으로 브랜치를 생성하고, 작업 완료 후 Merge Request를 올려야 리뷰가 남는 구조로 운영했습니다. 또한 Git Convention, Jira Convention, Code Convention을 함께 정리하여 브랜치 네이밍 규칙, 커밋 메시지 규칙, Merge Request 작성 방식, 코드 리뷰 기준을 맞췄습니다. 그 결과 JIRA 리뷰 수 기준으로 전국 8등, 서울 1등에 해당하는 협업 활동량을 기록할 수 있었습니다. 이는 저희 팀이 기능 구현뿐만 아니라 개발 과정 자체를 체계적으로 관리하고자 노력했다는 점을 보여주는 지표라고 생각합니다.

  4. GitLab, Mattermost, Jenkins 기반 CI/CD 구성

    개발 후반부에 변경 사항이 꼬이지 않도록 GitLab, Mattermost, Jenkins를 활용한 CI/CD 흐름도 함께 구성했습니다. GitLab에서 Merge Request가 발생하거나 브랜치에 변경 사항이 반영되면 Jenkins Pipeline을 통해 빌드와 배포가 이어질 수 있도록 구성했고, Mattermost 알림을 통해 팀원들이 빌드 결과와 배포 상태를 빠르게 확인할 수 있도록 했습니다. 인프라 측면에서는 테스트 서버와 운영 서버를 분리한 이중 배포 환경을 목표로 했습니다. 실제 프로젝트를 진행하며 교보재 EC2가 추가되어 서버 자원이 2개가 되었지만, 이전 특화 프로젝트였던 싸피증권 서비스도 함께 배포하고 관리해야 했기 때문에 모든 자원을 처음 계획한 대로 사용할 수는 없었습니다. 이 과정에서 서버 리소스, 배포 우선순위, 네트워크 설정, Jenkins Job 구성을 계속 조율하며 실제 운영 환경을 설계하고 관리하는 경험을 쌓을 수 있었습니다.

핵심 기능 개발

  1. ToolPlan 생성 구조 (PLAN / REVIEW 기반)

    첫 번째 핵심 기능은 사용자의 자연어 요청을 AI가 이해하고, 이를 바로 실행하는 것이 아니라 PLAN과 REVIEW 단계로 나누어 실행 가능한 Tool 생성 흐름으로 구조화하는 기능입니다. 저희는 AI가 사용자의 명령을 즉시 실행하는 구조는 편리해 보일 수 있지만, 실제 프로젝트 서버나 외부 리소스에 접근하는 상황에서는 위험할 수 있다고 판단했습니다. 그래서 먼저 PLAN 단계에서 AI가 어떤 작업을 수행해야 하는지, 어떤 리소스 접근이 필요한지, 어떤 위험 요소가 있는지를 ToolPlan 형태로 정리하도록 설계했습니다. 이후 REVIEW 단계에서는 사용자가 AI가 생성한 ToolPlan을 확인하고, 필요하다면 수정하거나 승인할 수 있도록 했습니다. 이를 통해 AI가 무작정 실행하는 것이 아니라, 사람이 계획을 검토한 뒤 실행 가능한 Tool로 이어지는 안전한 흐름을 만들고자 했습니다. 이 구조를 통해 테세우스는 단순히 자연어 요청을 처리하는 AI 서비스가 아니라, AI가 계획을 세우고 사람이 검토한 뒤 팀 단위 자동화 Tool로 축적되는 에이전트 플랫폼으로 동작할 수 있었습니다.

  2. 프로젝트 기반 권한 관리와 승인 구조

    두 번째 핵심 기능은 프로젝트 단위 권한 관리와 승인 구조입니다. 테세우스는 AI가 단순히 답변만 생성하는 서비스가 아니라, 실제 프로젝트 파일과 서버 환경을 분석하고 Tool을 생성·실행할 수 있는 플랫폼입니다. 따라서 누가 어떤 프로젝트에 접근할 수 있는지, 어떤 사용자가 Tool을 생성하거나 실행할 수 있는지, 생성된 Tool을 승인할 권한이 누구에게 있는지를 명확히 관리하는 것이 중요했습니다. 이를 위해 프로젝트 멤버별 역할과 접근 레벨을 두고, Tool 생성, 사용, 수정, 삭제 권한을 분리했습니다. 사용자가 Tool 생성을 요청하면 AI가 바로 실행 가능한 Tool을 등록하는 것이 아니라, 먼저 ToolPlan을 생성하고 권한 있는 사용자의 승인 과정을 거친 뒤에야 실제 Tool로 등록되도록 설계했습니다. 이 구조를 통해 AI가 프로젝트 환경에서 수행할 수 있는 작업의 범위를 통제할 수 있었고, 팀 단위 협업 환경에서도 안전하게 Tool을 축적하고 재사용할 수 있는 기반을 마련했습니다.

  3. Tool 생성 및 재사용 구조

    세 번째 핵심 기능은 반복되는 요청을 실행 가능한 Tool로 생성하고 재사용할 수 있도록 하는 구조입니다. 기존 AI 사용 방식은 매번 비슷한 요청을 새롭게 입력하고, 필요한 컨텍스트를 다시 전달해야 하는 경우가 많았습니다. 저희는 이 방식이 토큰 사용량과 반복 작업 측면에서 비효율적일 수 있다고 생각했습니다. 그래서 한 번 생성된 Tool을 프로젝트 단위로 저장하고, 이후 비슷한 상황에서 다시 사용할 수 있도록 설계했습니다. 이를 통해 테세우스는 사용자가 요청할 때마다 일회성 답변을 제공하는 서비스가 아니라, 팀이 사용할 수 있는 자동화 도구를 축적해 나가는 플랫폼이 될 수 있었습니다.

  4. Remote Workspace 기반 외부 서버 연동

    네 번째 핵심 기능은 Remote Workspace 기반 외부 서버 연동입니다. 테세우스가 실제 팀 프로젝트나 조직 단위 개발 환경에서 활용되기 위해서는 코드나 문서만 이해하는 것을 넘어, 운영 중인 서버 환경까지 분석할 수 있어야 한다고 생각했습니다. 그래서 외부 서버를 Remote Workspace로 등록하고, SSH 기반으로 서버 상태, 로그, 배포 상태 등을 확인할 수 있는 구조를 설계했습니다. 이를 통해 사용자는 “현재 서버 상태 확인해줘”와 같은 자연어 요청만으로도 기존에는 직접 수행해야 했던 여러 운영 명령어와 점검 과정을 하나의 Tool로 실행할 수 있습니다. 이 기능은 저희가 생각한 테세우스의 방향성, 즉 AI가 프로젝트의 반복 업무를 이해하고 도구화한다는 메시지를 가장 잘 보여주는 기능이라고 생각합니다.

  5. 싸피증권 AI 에이전트 고도화

    다섯 번째 핵심 기능은 기존 특화 프로젝트였던 싸피증권과 테세우스를 연결하여, 실제 프로젝트 고도화에 AI Agent를 활용하는 것이었습니다. 저희는 테세우스가 단순히 독립적인 플랫폼으로만 존재하는 것이 아니라, 실제 운영 중인 프로젝트와 연결되어 반복 작업을 자동화할 수 있어야 한다고 생각했습니다. 이를 위해 싸피증권 배포 환경과 서버 상태를 대상으로 AI Agent가 점검하고 분석할 수 있는 구조를 고민했습니다. 예를 들어 기존에는 운영자가 직접 SSH로 접속하여 Docker 컨테이너 상태를 확인하고, 로그를 조회하고, API Health Check를 수행한 뒤 결과를 해석해야 했습니다. 하지만 테세우스를 활용하면 이러한 과정을 자연어 요청 기반의 Tool로 실행할 수 있습니다. 이처럼 싸피증권 고도화는 테세우스의 실제 활용 가능성을 검증하는 사례였고, 저희가 처음 기획했던 “AI Agent로 프로젝트를 개선한다”는 방향성과도 맞닿아 있었습니다.

기술적 고민과 해결 과정

프로젝트를 진행하며 가장 큰 기술적 고민은 AI Core와 API Server를 어떻게 안정적으로 연결할 것인가였습니다. 테세우스는 사용자의 자연어 요청을 AI Core가 분석하고 ToolPlan을 생성하는 구조입니다. 하지만 AI 처리 과정은 일반적인 API 요청처럼 항상 짧은 시간 안에 끝나지 않고, 중간에 실패하거나 추가 입력이 필요한 상황도 발생할 수 있습니다. 반면 API Server는 사용자 요청을 받고, 인증과 권한을 확인하며, DB와 Redis에 상태를 저장하고, 프론트엔드와 실시간으로 연결되어야 합니다. 이 두 서버를 강하게 결합하면 Core Server의 처리 지연이나 실패가 API Server 전체의 응답 지연으로 이어질 수 있다고 판단했습니다. 따라서 저희는 AI 처리 흐름을 일반적인 동기식 요청-응답 구조가 아니라, 이벤트 기반 비동기 구조로 분리하고자 했습니다. 또한 AI가 생성한 Tool이 실제 프로젝트 환경에서 실행될 수 있는 만큼, 기능 구현 과정에서 권한 검증과 승인 흐름은 단순한 부가 기능이 아니라 서비스 안정성을 위한 핵심 요소였습니다. 따라서 저희는 AI 처리 흐름뿐만 아니라, 어떤 사용자가 어떤 프로젝트에서 어떤 작업을 요청하고 승인할 수 있는지까지 함께 고려하며 구조를 설계했습니다.

  1. Kafka 기반 비동기 이벤트 처리

    첫 번째 고민은 API Server와 Core Server 사이의 통신 방식이었습니다. 사용자가 Tool 생성을 요청하면 API Server는 요청을 검증하고 DB에 저장한 뒤, Kafka를 통해 Core Server로 작업 요청 이벤트를 발행합니다. Core Server는 해당 이벤트를 소비하여 AI 작업을 수행하고, ToolPlan 생성 과정에서 발생하는 진행 상태와 결과를 다시 Kafka 이벤트로 발행합니다. API Server는 이 이벤트를 소비하여 상태를 저장하고, 프론트엔드에 전달하는 역할을 담당합니다. 이 구조를 통해 API Server와 Core Server의 결합도를 낮출 수 있었습니다. Core Server의 AI 처리 시간이 길어지더라도 API Server가 요청을 계속 붙잡고 있을 필요가 없었고, 작업 상태를 이벤트 단위로 분리하여 처리할 수 있었습니다. 또한 Kafka를 사용함으로써 AI 작업 요청과 결과 이벤트를 명확히 분리할 수 있었고, 추후 실패 이벤트, 재시도, 상태 추적과 같은 확장도 고려할 수 있었습니다. 단순히 AI 모델을 호출하는 기능을 만드는 것이 아니라, 실제 서비스 환경에서 안정적으로 AI 작업을 처리할 수 있는 구조를 만드는 것이 중요했습니다.

  2. 멀티턴 대화 처리를 위한 payload/history 구조 설계

    두 번째 어려움은 API Server와 Core Server 사이에서 주고받는 payload 구조를 설계하는 과정이었습니다. Core Server는 AI 요청을 처리하며 ToolPlan 생성 결과와 진행 상태를 이벤트 형태로 전달하고, API Server는 이를 다시 프론트엔드에 전달해야 했습니다. 처음에는 단일 요청과 단일 응답에 가까운 구조로 생각했지만, 실제 AI Agent 흐름은 이전 대화 내용과 생성된 ToolPlan, 사용자 피드백이 이어지는 멀티턴 구조였습니다. 특히 ToolPlan을 재생성하거나 사용자가 이전 응답을 바탕으로 추가 요청을 하는 경우, 단순히 현재 메시지만 Core Server에 전달해서는 맥락을 유지하기 어려웠습니다. 따라서 API Server에서 대화 이력을 저장하고, 필요한 history snapshot을 payload에 포함해 Core Server로 전달하는 방식으로 구조를 보완했습니다. 이 과정에서 어떤 데이터를 DB에 저장하고, 어떤 데이터를 Kafka payload로 전달하며, 어떤 상태를 Redis와 SSE를 통해 프론트엔드에 보여줄지 계속 조정해야 했습니다. 이를 통해 AI 기능을 서비스에 붙이는 일은 단순히 모델 API를 호출하는 것이 아니라, 대화 맥락과 상태 흐름을 안정적으로 설계하는 일이라는 점을 배울 수 있었습니다.

  3. Redis 기반 상태 저장과 복구 구조

    세 번째 고민은 AI 작업의 진행 상태를 어떻게 저장하고 복구할 것인가였습니다. ToolPlan 생성이나 Tool 실행은 즉시 완료되지 않는 경우가 많고, 사용자가 화면을 새로고침하거나 SSE 연결이 끊기는 상황도 발생할 수 있습니다. 이때 진행 상태가 사라지면 사용자는 현재 작업이 어디까지 진행되었는지 알 수 없게 됩니다. 이를 해결하기 위해 Redis를 활용해 Tool 생성 및 실행 과정의 최신 상태를 저장했습니다. API Server는 Core Server로부터 Kafka 이벤트를 소비할 때마다 최신 상태를 Redis에 반영하고, 프론트엔드는 필요할 경우 Redis에 저장된 상태를 기준으로 현재 진행 상황을 다시 확인할 수 있도록 설계했습니다. Redis는 빠른 읽기와 쓰기가 가능하기 때문에 실시간 상태 관리에 적합했습니다. DB에는 영속적으로 보관해야 하는 Tool, ToolPlan, 채팅 이력 등을 저장하고, Redis에는 현재 진행 중인 작업의 최신 상태를 저장하는 식으로 역할을 나누었습니다. 이를 통해 단순히 실시간으로 보여주는 것뿐만 아니라, 연결이 끊기거나 화면이 갱신되는 상황에서도 사용자가 작업 흐름을 이어갈 수 있는 구조를 만들고자 했습니다.

  4. SSE 기반 실시간 진행 상황 전달

    네 번째 고민은 사용자에게 AI 작업의 진행 과정을 어떻게 보여줄 것인가였습니다. AI 작업은 처리 시간이 일정하지 않기 때문에, 사용자가 결과가 나올 때까지 아무런 피드백 없이 기다리게 되면 서비스가 멈춘 것처럼 느껴질 수 있습니다. 따라서 저희는 SSE를 활용해 Tool 생성 진행 상황을 실시간으로 전달하도록 설계했습니다. 사용자가 요청을 보내면 프론트엔드는 SSE 연결을 통해 요청 접수, 분석 중, ToolPlan 생성 중, 완료 또는 실패와 같은 상태를 받을 수 있습니다. 이를 통해 사용자는 AI가 현재 어떤 작업을 수행하고 있는지 확인할 수 있고, 긴 처리 시간이 발생하더라도 서비스 흐름을 이해할 수 있습니다. 또한 SSE는 단방향 실시간 이벤트 전달에 적합했기 때문에, 서버에서 발생하는 진행 상태를 프론트엔드로 전달하는 구조에 잘 맞았습니다. 이 과정에서 API Server는 Kafka 이벤트를 소비하고, Redis에 최신 상태를 저장하며, 동시에 SSE를 통해 프론트엔드에 상태를 전달하는 중간 허브 역할을 수행했습니다. 이 구조를 통해 AI Core의 처리 과정이 사용자에게 보이지 않는 블랙박스가 되지 않도록 하고, 진행 상황을 단계별로 확인할 수 있는 사용자 경험을 만들고자 했습니다.

  5. 권한 검증과 승인 흐름 설계

    다섯 번째 고민은 AI가 생성한 Tool을 어떤 기준으로 생성하고 실행하게 할 것인가였습니다. 테세우스는 단순히 텍스트 답변을 생성하는 서비스가 아니라, 프로젝트 파일과 서버 환경을 분석하고 Tool을 생성·실행할 수 있는 플랫폼입니다. 따라서 AI가 생성한 결과를 바로 실행 가능한 Tool로 등록하거나, 누구나 서버 관련 작업을 실행할 수 있도록 두는 것은 위험할 수 있다고 판단했습니다. 이를 해결하기 위해 프로젝트 멤버의 역할과 권한을 기준으로 Tool 생성, 수정, 실행, 승인 흐름을 분리했습니다. 사용자가 Tool 생성을 요청하면 먼저 PLAN 단계에서 AI가 ToolPlan을 생성하고, 이후 REVIEW 단계에서 권한 있는 사용자가 해당 계획을 검토하고 승인할 수 있도록 했습니다. 즉, AI가 작업 계획을 생성하더라도 최종적으로 팀의 권한 체계 안에서 검토되고 통제되는 구조를 만들고자 했습니다. 이를 통해 AI Agent의 자동화 편의성은 유지하면서도, 실제 프로젝트 환경에서 필요한 안전성과 책임 흐름을 함께 확보할 수 있었습니다. 이 경험을 통해 AI 기반 자동화 서비스에서는 기능 자체만큼이나 누가 어떤 작업을 요청하고, 누가 승인하며, 어떤 범위까지 실행할 수 있는지를 설계하는 것이 중요하다는 점을 배울 수 있었습니다.

  6. Docker Compose와 Jenkins 기반 배포 전략

    마지막 고민은 여러 서버와 컨테이너로 구성된 서비스를 어떻게 안정적으로 배포할 것인가였습니다. 테세우스는 API Server, Core Server, Redis, Kafka, Nginx 등 여러 구성 요소가 함께 동작해야 하는 서비스였습니다. 따라서 전체 서비스를 한 번에 재배포하는 방식은 배포 시간이 길어지고, 특정 서비스의 변경이 전체 장애로 이어질 가능성이 있다고 판단했습니다. 이를 해결하기 위해 Docker Compose와 Jenkins를 활용한 CI/CD 환경을 구성했습니다. GitLab에서 변경 사항이 반영되면 Jenkins Pipeline을 통해 빌드와 배포가 이어지도록 했고, 변경된 서비스만 선택적으로 재배포할 수 있는 구조를 목표로 했습니다. 또한 Mattermost 알림을 통해 빌드와 배포 상태를 팀원들이 빠르게 확인할 수 있도록 했습니다. 이를 통해 누가 어떤 변경 사항을 반영했고, 해당 변경이 어떤 배포 결과로 이어졌는지 추적할 수 있었습니다. 이 과정을 통해 배포 자동화는 단순히 명령어를 줄이는 작업이 아니라, 서비스 안정성과 팀 협업 흐름을 함께 관리하는 중요한 개발 과정이라는 점을 느낄 수 있었습니다.

프로젝트 후기

이번 프로젝트를 진행하며 가장 크게 느낀 점은 기술의 사용 이유를 명확히 하는 것이 중요하다는 점이었습니다. AI, Kafka, Redis, Remote Workspace, SSE 등 여러 기술을 사용했지만, 단순히 기술을 많이 사용하는 것이 중요한 것은 아니었습니다. 각각의 기술이 어떤 문제를 해결하기 위해 도입되었고, 사용자에게 어떤 가치를 줄 수 있는지를 계속 고민해야 했습니다. 특히 테세우스는 AI Agent라는 추상적인 주제를 다루는 프로젝트였기 때문에 기획 과정에서 많은 어려움이 있었습니다. 하지만 “AI가 실제 프로젝트의 반복 작업을 이해하고, 이를 Tool로 생성하며, 이후 재사용할 수 있게 하자”는 방향을 잡은 이후에는 팀원 모두가 같은 목표를 바라보며 개발할 수 있었습니다. 또한 이번 프로젝트를 통해 협업의 중요성도 다시 한번 느꼈습니다. Jira Epic을 기준으로 프로젝트 범위를 나누고, GitLab Merge Request를 기반으로 리뷰 문화를 만들며, Jenkins와 Mattermost를 통해 배포 및 알림 흐름을 구성하는 과정은 단순 기능 개발 이상의 경험이었습니다. 이번 프로젝트를 통해 좋은 서비스는 새로운 기술을 적용하는 것만으로 만들어지는 것이 아니라, 사용자가 반복적으로 겪는 문제를 발견하고 이를 지속 가능한 구조로 해결하는 과정에서 만들어진다는 점을 배웠습니다.

마무리

프로젝트를 마무리하며, 기획부터 개발, 발표까지 많은 도움을 주신 …..(익명처리) 님께 진심으로 감사드립니다. 프로젝트의 방향성을 잡는 과정에서 주신 조언과 피드백 덕분에 서비스의 가치를 더 명확하게 정리할 수 있었고, 완성도를 높일 수 있었습니다. SSE채팅 및 개발한 여러 기능들을 안정적으로 운영 할 수 있게 도움을 주신 SSAFY SuperApp에도 감사를 드립니다. 또한 쉽지 않은 일정 속에서도 끝까지 최선을 다해준 팀원들에게도 깊은 감사의 마음을 전합니다. 각자의 역할은 달랐지만, 모두가 같은 목표를 바라보며 책임감 있게 프로젝트에 임했기 때문에 좋은 결과를 얻을 수 있었다고 생각합니다. 프로젝트 막바지에는 배포, 서버 간 통신, 이벤트 흐름을 맞추는 과정에서 많은 시행착오가 있었지만, 팀원들과 함께 문제를 해결해 나가며 서비스가 실제로 동작하는 모습을 확인할 수 있었습니다. 그 결과, 우수 프로젝트로 선정되는 값진 성과를 얻을 수 있었고, 이는 팀원 모두가 함께 만들어낸 결과라고 생각합니다. 이번 경험을 바탕으로 앞으로의 프로젝트에서도 기술을 단순히 적용하는 것에 그치지 않고, 사용자 가치와 차별화된 아이디어를 중심으로 서비스를 설계하는 개발자가 되겠습니다. 감사합니다.