[크래프톤 정글 10기] 나만무 프로젝트 회고 (1)

2026. 5. 14. 17:28·Projects

들어가며

5개월간의 크래프톤 정글 여정의 마지막 관문, "나만의 무기 만들기(나만무)" 프로젝트. 5주라는 시간 동안 팀원들과 함께 실제 서비스를 기획하고 개발해야 했다. 우리 팀이 선택한 주제는 AI 에이전트 워크플로우 빌더, 프로젝트명은 SnapAgent였다.

  • GitHub (Frontend): https://github.com/Krafton-Jungle10-Team4/Frontend
  • GitHub (Backend): https://github.com/Krafton-Jungle10-Team4/Backend

SnapAgent 인트로/메인 이미지


기획 배경: 아이디어가 나오기까지

첫 번째 아이디어

처음 우리 팀이 가져간 아이디어는 GitHub 레포지토리 시각화 도구였다. 사용자가 GitHub URL을 입력하면 해당 레포지토리의 아키텍처를 시각적으로 재구성해주는 서비스를 구상했다. 이 아이디어는 deepwiki를 레퍼런스로 삼았다.

하지만 코치님의 피드백은 냉정했다.

코치님의 피드백

어떤 기준으로 시각적으로 정렬할 것인지 모르겠지만, 단순히 폴더 구조를 시각적으로 재구성하는 것은 이미 옛날부터 존재하는 구식 아이디어예요.

프로젝트를 모듈 기준으로 분석할 건지, 클래스 기준으로 분석할 건지, 함수 기준으로 분석할 건지에 대한 아이디어가 구체적이지 않다는 피드백이었다. 만약 함수를 기준으로 호출 플로우를 분석한다면 비동기 함수를 포함하는 복잡한 플로우는 분석하기 어려울 것이고, 폴더만을 기준으로 시각화한다면 그건 너무 단순한 프로젝트가 될 것이라는 지적도 있었다.

새로운 방향

코치님이 대안으로 제시한 방향은 이랬다.

코치님의 제안

요즘 langchain으로 AI agent를 구축하려는 시도가 굉장히 늘고 있는데, 그걸 시각적으로 표현하는 툴이 너무 약해요. 이 주제가 더 트렌디하다고 생각하는데 어때요?

이 힌트를 바탕으로 우리는 Dify, n8n 같은 시각적 AI 워크플로우 빌더를 조사하기 시작했다.

 

우리 팀원들은 모두 AI 관련 프레임워크를 처음 접하는 사람들뿐이었다. 이때부터 코치님께 RAG 파이프라인의 플로우에 대해 질문하거나 관련 도서를 추천받아서, 팀원들끼리 LLM과 AI 워크플로우 구축 방법을 따로 학습하기도 했다.

 

이런 과정을 거치면서 최종적으로 우리의 방향이 정해졌다.

노코드/로우코드로 AI 워크플로우를 시각적으로 구축하고, 원클릭으로 배포할 수 있는 서비스를 만들자.

방향을 찾기까지

사실 최종 방향이 바로 정해진 건 아니었다. 매주 발표와 피드백을 거치며 서비스의 형태가 계속 바뀌었다.

 

처음에는 비개발자를 타겟으로 잡았다. 그런데 노드-엣지 구조는 비개발자가 다루기엔 어려울 것이라는 의견이 팀 내에서 지배적이었다. 그래서 1주차에는 노드-엣지 구조 대신 폼 형식으로 데이터를 입력받아 RAG 파이프라인을 자동 생성하고, 프롬프트 테스트로 빠르게 프로토타이핑할 수 있는 서비스를 기획했다.

 

하지만 피드백은 "이 서비스를 누가 사용할지에 대한 고민이 없는 것 같다.", "타겟 유저가 애매하다"였다. 추가로 "도메인만 AI로 바뀌었지, 기획 단계에서 얘기했던 시각화 아이디어는 사라졌다"는 피드백도 받았다.

1주차 폼 형식 RAG 서비스 프로토타입

2주차에는 시각화 피드백을 수용해 Dify를 참고한 노드-엣지 구조를 도입했다. 하지만 비개발자 타겟은 쉽게 포기할 수 없었다. 결국 폼으로 입력받으면 "시작 → Knowledge → LLM → 종료" 워크플로우가 자동 생성되는 절충안을 선택했다. MVP를 빠르게 검증하기 위해 이 4개 노드는 하드코딩된 상태였다.

2주차 노드-엣지 도입

이번에도 이전과 같은 피드백을 받았다. "여전히 이 서비스의 타겟층을 잘 모르겠다"는 것이었다. 또한 비개발자를 위해 선택한 "폼을 입력하면 자동으로 생성되는 워크플로우"에 대해서는 "노드를 사용자가 직접 만들어야 하는데 왜 자동 생성되냐", "서비스의 사용 플로우가 어색하다"는 피드백을 받았다. 결국 우리팀은 시각화를 위한 노드-엣지 구조와 비개발자 타겟은 양립하기 어렵다는 결론을 내렸다. 3주차에 타겟을 개발자로 완전히 전환하고, 빈 워크플로우에서 시작해 사용자가 직접 노드를 추가하는 방식으로 확정했다.

이때부터 프로젝트명도 SnapAgent로 정해졌다.

최종 발표

[크래프톤 정글 뉴스 카드 — Snap Agent 소개]

[최종 발표회 YouTube 영상]

 


팀 협업 방식

5명이 5주간 협업하면서 Notion을 적극 활용했다.

  • 칸반 보드 — 태스크 관리 및 진행 상황 공유
  • 공유 문서 — 기술 조사 내용, 회의록, API 명세 등 정리

Notion 공유 문서 — API 명세/회의록, Notion 칸반 보드 — 태스크 관리

기술 스택

나는 이번 프로젝트에서 React Flow 기반 워크플로우 에디터 프론트엔드를 담당했다.

 

우리 팀은 전반적으로 비전공자로 구성되었고, 특히 프론트엔드 경험자가 없었다. 그래서 문서화가 잘 되어 있고 초기 러닝커브가 적은 스택을 우선적으로 선택했다.

Frontend

  • React + TypeScript
    • 나만무를 시작하기 전에 JavaScript가 TypeScript보다 러닝커브가 낮다는 말을 많이 들었다. 그런데 나만무 직전까지 C 언어를 사용하다 보니 타입이 명시되는 TypeScript가 오히려 더 익숙해서 함께 채택했다.
  • React Flow
    • 노드 기반 워크플로우 에디터의 핵심. 레퍼런스 프로젝트인 Dify도 이 기술 스택을 차용하고 있어서 채택했다.
  • Zustand
    • 가벼운 전역 상태 관리. 이것도 Redux 대비 학습 난이도가 낮아서 빠르게 우리 프로젝트에 도입하기 위해 채택했다.

Backend

  • Python + FastAPI — 비동기 처리와 자동 API 문서화
  • SQLAlchemy + PostgreSQL — ORM과 관계형 데이터베이스
  • pgvector — PostgreSQL 확장으로 벡터 검색 지원
  • Redis — 응답 캐싱으로 비용·속도 최적화
  • Alembic — DB 마이그레이션 관리

AI

  • OpenAI API — GPT 모델 활용
  • AWS Bedrock — Titan Embeddings로 문서 임베딩

Infrastructure

  • Vercel — 프론트엔드 배포
  • AWS ECS — 백엔드 배포
  • Docker Compose — 로컬 개발 환경 구성

프로젝트 타임라인

주차 계획 실제 진행
1주차 주제 선정 & 기획 주제 선정 & 기획 (폼 형식 RAG)
2주차 MVP 개발 노드-엣지 도입, 하드코딩된 워크플로우
3주차 MVP 추가 개발 타겟 전환, _base 컴포넌트 리팩토링, 노드 4종(IF-ELSE / Question Classifier / Variable Assigner / Answer) 신규 구현
4주차 개발 마켓플레이스 / 템플릿 시스템(ImportedWorkflowNode) 구축, Dify 스타일 NodeSelector
5주차 폴리싱 UI 통일, 발표 준비

앞서 말했듯이 2~3주차는 기획 방향이 계속 바뀌면서 개발 속도가 나지 않았다. 특히 3주차에는 타겟을 개발자로 전환하면서 기존 하드코딩된 노드를 _base 컴포넌트 기반으로 리팩토링하는 작업을 진행했는데, 발표 피드백은 "겉으로 보기엔 저번 주와 차이가 없다, 1주일 동안 뭐 했냐"였다. 내부 구조는 완전히 바뀌었지만 눈에 보이는 결과물은 여전히 4개 노드뿐이었기 때문이다.

 

결국 3주차 후반에 IF-ELSE, Question Classifier, Variable Assigner, Answer 등 4개 노드 타입을 한꺼번에 만들고, 4주차에는 마켓플레이스와 템플릿 시스템(ImportedWorkflowNode)까지 구축하며 MVP의 대부분을 완성했다. 4주차 발표에서야 "서비스는 잘 만든 것 같다"는 피드백을 받을 수 있었다.


마치며

이번 글에서는 나만무 프로젝트의 기획 배경과 매주 피드백을 받으며 방향을 찾아가는 과정을 이야기했다. 비개발자에서 개발자로 타겟을 전환하고, 폼 형식에서 노드-엣지 구조로 바꾸기까지 2주가 걸렸다. 그 과정에서 개발 일정이 밀렸고, 3주차 후반부터 4주차에 걸쳐 MVP 대부분을 몰아서 구현하는 상황이 벌어지기도 했다.

 

5주차에 팀 내부적으로 작은 트러블이 있기도 했지만, 결과적으로 5주간의 프로젝트는 무사히 마무리되었다. 이 이야기는 4편 회고에서 다룰 예정이다.

 

다음 편에서는 팀 협업을 위한 컴포넌트 설계와 노드 생성 가이드 문서화 과정을 다룰 예정이다

'Projects' 카테고리의 다른 글

[크래프톤 정글 10기] 나만무 프로젝트 회고 (4)  (0) 2026.05.19
[크래프톤 정글 10기] 나만무 프로젝트 회고 (3)  (0) 2026.05.19
[크래프톤 정글 10기] 나만무 프로젝트 회고 (2)  (0) 2026.05.19
'Projects' 카테고리의 다른 글
  • [크래프톤 정글 10기] 나만무 프로젝트 회고 (4)
  • [크래프톤 정글 10기] 나만무 프로젝트 회고 (3)
  • [크래프톤 정글 10기] 나만무 프로젝트 회고 (2)
onebrotravel
onebrotravel
  • onebrotravel
    매일을 여행처럼
    onebrotravel
  • 전체
    오늘
    어제
    • 분류 전체보기
      • Embedded
      • Language
        • C
      • OS
      • DSA
      • DevTools
      • Infra
      • Projects
  • 인기 글

  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.6
onebrotravel
[크래프톤 정글 10기] 나만무 프로젝트 회고 (1)
상단으로

티스토리툴바