조금씩, 한 걸음씩 — 아이디어를 설계까지 쌓아가는 사고의 캔버스

AI가 다 만들어주는 시대, 무엇을 · 왜 만들지 정의하고 계신가요?

 

📌 포스터 이미지 및 소개 영상은 추후 첨부할 예정입니다.

1. 프로젝트 소개

한 줄 요약

서비스를 만들고 싶은 사람이 “뭘 만들고 싶고, 왜 만드는지” 를 제 언어로 말할 수 있도록, AI가 다음 한 걸음의 선택지를 제시하고 의사결정의 궤적을 트리로 시각화해주는 사고의 캔버스.

세 줄 요약

만들고 싶은 건 있는데 어디서부터 정리해야 할지 모를 때, AI가 문제 정의부터 다음 할 일을 단계별로 추천하고 그 과정을 트리 형태로 시각화해주는 사고의 캔버스.

각 단계마다 용어 설명·멘토링·템플릿을 제공해서, 기획 경험이 없어도 검증된 소프트웨어 개발 프로세스를 자연스럽게 따라갈 수 있다.

“어떤 결정을 해왔고, 지금 어디까지 왔는지” 가 캔버스 위에 트리로 뻗어나가며 한눈에 정리된다.

핵심 가치

AI가 엄청난 속도로 모든 것을 만들어주는 시대, 진짜 경쟁력은 이 한 문장으로 요약된다.

“무엇을(What) 왜(Why) 만들지 스스로 정의하는 능력”

AI는 “어떻게(How)” 를 엄청난 속도로 만들어준다. 코드도, 디자인도, 문서도. 그러나 AI가 하지 못하는 것이 있다. 바로 “무엇을·왜 만들어야 하는가” 를 사용자 대신 결정해주는 것. Poco는 사용자가 그 영역을 구조적으로 수행할 수 있도록 돕는다.

소개 영상

📌 소개 영상은 추후 첨부할 예정입니다.

 

2. 문제 정의

2-1. 타겟 사용자

소프트웨어 프로젝트를 “처음부터 끝까지 스스로 설계해봐야 하는” 사람.

대표적으로 캡스톤·사이드 프로젝트를 시작하는 개인 또는 1~10명 규모의 소규모 팀이다. 만들고 싶은 것은 어렴풋이 있지만, 무엇을 어떤 순서로 정의해야 하는지에 대한 체계적 경험이 아직 쌓이지 않은 상태.

특히 기능 구현(How)은 AI가 도와주지만, “무엇을·왜 만들지(What·Why)”는 여전히 우리 몫이다. Poco는 그 답을 스스로 찾아가는 구조를 제공한다.

2-2. 실제로 겪는 Pain Point

“AI한테 뭐라도 시켜보려는데… 정작 내가 뭘 만들고 싶은 건지부터 모르겠다.
용어도 어렵고, 빠뜨린 단계는 없는지 불안하고, 사람들에게 ‘왜 이 결정을 했는지’ 설명할 자신도 없다.”

뭔가 만들고 싶은데 “문제 정의 → 요구사항 → 설계 → 개발 → 테스트” 로 이어지는 흐름을 모른다. 막연한 상태든, 어느 정도 구체화된 상태든 “다음에 뭘 해야 하는지” 가 안 보인다.

2-3. 기존 방식의 한계

구분	한계
Jira / Notion	할 일을 관리해주지만, “뭘 해야 하는지” 자체를 알려주지는 않는다.
방법론 문서 (SWEBOK, PMBOK)	수십 년간 검증된 체계적 지식이지만, 수백 페이지 분량의 공식 PDF 형태로만 존재한다. 방법론의 가치를 아는 전문가조차, 막 시작하는 학생·초보자가 이걸 직접 펴서 자신의 프로젝트에 적용할 것이라고는 기대하기 어렵다.
일반 AI 챗봇	질문을 잘 던져야 좋은 답을 주는데, “어떤 질문을 해야 할지 모르는 사람” 에게는 진입 장벽이 크다.
팀 협업 시	“뭘 만들기로 했는지, 왜 이 결정을 했는지” 가 정리되지 않아 방향이 흐트러지고, 과정이 텍스트로만 남아 전체 흐름을 한눈에 보기 어렵다.

2-4. AI 챗봇으로 대체 가능한가?

대체 불가능하다. 이유는 세 가지.

1. “선택지 제시형” 구조의 차별성 일반 AI 챗봇은 사용자가 질문을 던져야 답한다. 그러나 초심자는 “무엇을 질문해야 하는지” 부터 모른다. Poco는 사용자가 질문을 짜내지 않아도 되도록, AI가 다음 할 일의 선택지 3개를 먼저 제시한다. 사용자는 “가장 공감되는 것을 클릭” 만 하면 된다.

2. “의사결정 궤적의 시각화” 챗봇의 대화는 선형 텍스트로만 남아 이전 결정으로 되돌아가거나 다른 경로를 탐색하기 어렵다. Poco는 모든 선택을 캔버스 위 트리 구조로 시각화하고, 분기점으로 자유롭게 돌아가 다시 AI 추천을 받을 수 있다.

3. “검증된 방법론 기반의 안내” 챗봇은 매번 답이 흔들릴 수 있다. Poco는 DOJ SDLC 원문과 팀 자체 제작 가이드를 RAG 파이프라인으로 엮고, SWEBOK 토픽 구조를 자체 가이드의 학술적 뼈대로 삼아, 모든 단계의 안내가 일관된 방법론의 근거 위에서 제공된다. “이 단계에서 이걸 왜 하는지” 에 대해 항상 같은 학술적 근거를 가진다.

 

3. 해결 방법 — Top 3 핵심 기능

① AI 기반 Step Flow 생성

프로젝트 맥락에 맞춰, AI가 다음 한 걸음을 실시간 제안한다. 검증된 소프트웨어 개발 방법론의 6단계 프로세스를 따라 캔버스 위 노드가 동적으로 뻗어나가며, 각 단계의 핵심 관문은 특별한 형태의 노드(다이아몬드)로 자연스럽게 나타난다.

— 막연함을 “다음 한 걸음”으로 바꾼다.

② Step별 클릭 어시스턴트

노드를 클릭하면, 해당 단계의 멘토링과 용어 사전이 사이드패널로 펼쳐진다. 핵심 관문에 도달하면 팀이 설계한 노션 템플릿(웹 게시 링크)이 연결되어, 경험이 없어도 사고 흐름을 그대로 따라갈 수 있다.

— 딱딱한 방법론 문서 대신, 맥락에 맞는 가이드가 곁에 있다.

③ Footprint — 의사결정 궤적

아이디어가 흔들려도 괜찮다. 이전 분기점으로 돌아가면, AI가 바뀐 맥락에 맞춰 새로운 길을 다시 제안한다. 선택의 궤적이 캔버스에 그대로 남아, 프로젝트가 끝날 때쯤엔 “무엇을 왜 만들었는지” 를 스스로 설명할 수 있게 된다.

— 되돌아갈 수 있는 선택, 자산으로 남는 사고 과정.

 

4. 기술 설계

4-1. AWS 서버리스 중심 아키텍처

📐 아키텍처 다이어그램 준비 중입니다.

RAG 파이프라인과 “단기 기억 · 장기 지식” 분리 설계로, AI가 검증된 방법론을 실시간 참조합니다.

4-2. 설계 철학 — “단기 기억 · 장기 지식” 분리

구분	역할	저장소
단기 기억 (Short-term)	프로젝트별 상태, Step 히스토리, 사용자 선택 궤적	Amazon RDS PostgreSQL
장기 지식 (Long-term)	DOJ SDLC, SWEBOK, 자체 제작 가이드의 임베딩	Amazon S3 Vectors + Amazon Bedrock Knowledge Bases

이 분리 설계가 왜 중요한가? 프로젝트마다 상태는 매 요청마다 갱신되지만, 방법론 지식은 거의 변하지 않는다. 변경 빈도와 접근 패턴이 완전히 다른 두 층을 하나의 DB에 섞으면 확장성과 비용 효율이 모두 나빠진다. 그래서 저장소부터 구조적으로 분리하여, 지식은 한 번만 인덱싱하고 여러 프로젝트가 공유하도록 했다.

4-3. 기술 스택

Frontend

Backend

AI & RAG

DevOps (Local)

4-4. 백엔드의 AI 의존도와 기여점

AI 의존 범위 (정확히 명시)

AI가 담당하는 일	AI가 담당하지 않는 일
다음 Step 3개 동적 생성 (generate)	6개 Stage 정의 (백엔드 DB에 고정)
필수 Step 충족 판단 (accept)	24개 필수 Step의 목표·진입·충족 기준 정의 (팀 자체 정의)
사이드패널 멘토링·용어 생성 (side_panel, 일반 Step만)	필수 Step 사이드패널 콘텐츠 (팀 자체 제작, DB 사전 저장)
—	필수 Step 노션 템플릿 (팀 자체 제작)
—	Stage 진행 판단 (규칙 기반, AI 호출 없음)

즉 AI는 “동적 생성이 필요한 3개 시나리오”에만 한정되고, 나머지는 모두 사전 정의된 자산·규칙 기반으로 돌아간다. AI가 뱉어낸 결과물을 그대로 노출하는 것이 아니라, 팀이 설계한 구조(Stage·필수 Step·충족 기준)의 틀 안에서 작동하도록 제약했다.

프론트엔드/UX의 차별화된 기여

1. 캔버스 기반 트리 시각화 — 기존 챗봇의 선형 대화와 달리, 사용자의 의사결정 궤적을 분기·롤백 가능한 시각적 구조로 제공한다. 이것은 AI가 아닌 프론트엔드의 상호작용 설계의 몫이다.
2. 핵심 관문 노드(다이아몬드)의 UX — “필수 Step” 이라는 용어를 사용자에게 노출하지 않고, 특별한 형태의 노드로만 인식되도록 설계. 체계적 방법론을 따라가고 있다는 감각을 자연스럽게 형성한다.
3. 사이드패널 탭 구조 — AI 멘토링 / 용어 사전 두 탭을 사이드패널로 제공하고, 핵심 관문에서는 팀이 설계한 노션 템플릿(웹 게시 링크)이 연결되는 구조.
4. Footprint 시각화 — 롤백·재탐색이 캔버스 위에서 직관적으로 이루어지도록, 선택의 궤적을 시간이 아닌 공간(트리) 에 남기는 방식을 채택.

 

5. 데이터와 확장 가능성

5-1. 서비스가 축적하는 데이터와 가치

수집되는 정보

데이터	성격
사용자 행동	어떤 노드에서 많이 막히는지(이탈 지점), 어떤 선택지를 많이 고르는지, 어떤 분기에서 롤백하는지
기획 결과	어떤 노드 선택으로 프로젝트를 마무리했는지, 어떤 주제·도메인 프로젝트가 많이 기획되는지, 많이 선택된 노드 조합
AI 성능 피드백	AI가 생성한 Step 중 실제로 Accept된 비율, 어떤 RAG 검색 결과가 실제 선택으로 이어졌는지

예상 가치

• 교육 자산화 — 초심자가 어디에서 멈추는지가 데이터로 남으면, 개발 교육 커리큘럼의 취약점을 정량적으로 보완할 수 있다.
• 방법론 개선 루프 — DOJ SDLC·SWEBOK의 이론과 실제 사용 패턴 차이를 데이터로 관찰하여, 자체 제작 가이드 문서를 지속 개선할 수 있다.
• AI 프롬프트·RAG 품질 개선 — 실제 Accept된 Step의 맥락을 분석하여, 동적 생성 AI의 프롬프트와 RAG 검색 전략을 데이터 기반으로 튜닝한다.

5-2. 확장 가능성

다른 방법론·도메인으로의 확장

Poco의 지식 레이어는 방법론 독립적으로 설계되어 있다. 현재는 DOJ SDLC 원문의 10단계 Phase를 Poco 타겟 사용자(초심자·소규모 팀)에 맞게 재검토·선별하여 6단계로 재구성한 프로세스를 기준으로 Stage·필수 Step을 구성했지만, Stage 정의서 + 필수 Step 충족 기준 측면 + 템플릿 3종 세트만 교체하면 다음과 같은 확장이 가능하다.

• 다른 SDLC 모델 — Agile·Scrum·XP·V-Model 등 기존 방법론의 Stage 구성으로 치환
• 다른 지식 도메인 — 제품 기획(PMBOK), 연구 프로젝트(IMRaD), 논문 작성(학술 구조), UX 리서치(Double Diamond) 등

S3 Vectors를 RAG 저장소로 선택한 이유

선택지	S3 Vectors를 선택한 근거
비용 효율	전용 벡터 DB(OpenSearch·Pinecone)의 최대 1/10 수준 비용. 캡스톤·교육·스타트업 규모에서 운영 부담이 크게 낮다.
Bedrock 네이티브 통합	Bedrock Knowledge Base가 S3 Vectors를 데이터소스로 직접 지원. 별도 ETL·동기화 파이프라인 없이 콘솔에서 바로 인덱싱.
스케일 특성	장기 지식은 읽기 비중이 압도적이고 쓰기는 드물다. S3의 객체 스토리지 + 벡터 인덱스 결합 구조가 이 패턴에 최적.
메타데이터 필터링	Stage/Step/문서 유형(DOJ vs Custom)별 메타데이터 필터링을 네이티브 지원 → 같은 인덱스 안에서도 정밀 검색 가능.

결과적으로 새 방법론을 추가할 때마다 인덱스를 복제하거나 별도 DB를 띄울 필요 없이, 동일 저장소에 메타데이터만 붙여 추가할 수 있다. 운영 비용을 올리지 않고도 지식 레이어가 선형 확장되는 구조다.

5-3. 프로젝트 규모의 적절성

결론: 적절하다. 근거는 세 가지.

1. 분명한 역할 분리 + 상호 의존성 존재 FE(1명) · BE(2명) · AI/Infra(1명, 팀장)로 나뉘되, 각 파트가 독립적으로 개발 가능하면서도 최종 통합 시 팀 협업이 필수인 구조. 1인 프로젝트로는 전 영역을 깊이 있게 다루기 어려운 스코프다.
2. AI 자동화로도 대체 안 되는 설계 영역 24개 필수 Step의 목표·진입·충족 기준 정의, 사이드패널 콘텐츠 자체 제작, 노션 템플릿 설계 등은 팀의 전문적 판단이 필요한 영역이다. AI가 코드는 도와주지만, “어떤 기준으로 필수 Step을 정의할 것인가” 는 팀이 설계해야 한다.
3. AWS 아키텍처의 운영 복잡도 Bedrock, Lambda 2개, RDS, S3 Vectors, Knowledge Base 등 8개 AWS 서비스를 연동하고 CI/CD·배포·모니터링까지 구축하는 것은 1인 스코프로는 부담이 크다.

AI 활용으로 팀이 더 집중한 영역 — 단순 코드 작성에 들어가던 공수를 도메인 설계 · 방법론 문서 작성 · UX 실험 · RAG 품질 튜닝 등 AI가 대체할 수 없는 영역에 재배치했다.

 

6. 소프트웨어 방법론 근거

Poco가 참조하는 학술적 근거와, 각 출처가 실제 서비스 어디에서 어떻게 사용되는지를 투명하게 공개한다.

6-1. 참조 문서와 자체 제작 가이드 — 왜 이 구조인가

Poco의 방법론 구조는 “갖다 쓴 것”이 아니라 “재가공한 것” 이다. 핵심 흐름은 다음과 같다.

① DOJ SDLC가 가장 큰 틀이다.

미국 법무부(DOJ)가 공공 소프트웨어 개발 프로세스의 표준으로 공식 배포한 SDLC Guidance Document는 원래 10단계 Phase로 구성되어 있다. Poco는 이 원문을 그대로 RAG 지식 저장소에 탑재하여 AI가 참조하도록 하되, 서비스의 Stage 구조는 타겟 사용자(초심자·소규모 팀·1~12개월 프로젝트)에게 실제로 필요한 6단계만 선별하여 별도로 설계했다. 각 Stage의 목표·진입 기준·충족 기준, 그리고 Stage별 필수 Step 4개씩(총 24개)의 정의는 모두 팀의 설계 판단이다.

② SWEBOK는 “보완용 참고”로만 활용한다.

SWEBOK V4.0a (2024, IEEE Computer Society)는 소프트웨어 공학 지식체계의 국제 표준이지만, 저작권 보호 대상이라 원문을 RAG에 탑재할 수 없다. Poco는 SWEBOK의 토픽 구조(Knowledge Area → Topic)만 참조하여, AI가 혼자서는 잘 답하지 못하는 영역의 자체 가이드를 작성할 때 학술적 근거와 구조의 뼈대로 활용했다. 즉 SWEBOK 자체를 서비스에 노출하는 것이 아니라, 팀이 작성한 가이드의 출처 신뢰도를 확보하는 용도다.

③ 팀의 재검토·가공이 핵심이다.

두 문서 모두 수백 페이지 분량의 영문 공식 PDF이며, 초심자가 직접 펴서 자기 프로젝트에 적용하기는 현실적으로 어렵다. Poco는 이 검증된 방법론과 초보자 사이에 “다리”를 놓는 역할에 집중했다. 팀이 직접 읽고, 재검토하고, Poco 사용자에게 맞는 형태로 가공한 자산(6 Stage 정의·24개 필수 Step·사이드패널 콘텐츠·노션 템플릿·RAG 가이드 문서)이 서비스의 안내 품질을 결정한다.

④ “표준 방법론 vs 소규모 팀 현실” — 이 갭이 Poco의 시장 위치다.

DOJ SDLC도 SWEBOK도 원래 대규모 환경을 전제로 설계된 표준이다. 소규모 팀이 처한 진짜 딜레마는 양극단 사이에 있다:

• 표준을 그대로 따르면 — SRS 100페이지, Design Doc 50페이지, ADR 30개… 한 학기 안에 못 끝남
• 표준을 무시하면 — 다음에 뭘 해야 할지 모름. 요구사항 도출 누락, 설계 없이 코딩, 테스트 0%

Poco는 제3의 길을 제시한다. 표준의 “원칙” 은 유지하되, “분량·도구·활동” 은 소규모 팀 현실에 맞춰 캘리브레이션한다. 이 갭이 존재한다는 것 자체가 시장 기회이며, 갭이 없다면 학생들은 그냥 원문을 읽으면 되고 Poco는 필요 없다.

그래서 Poco의 구조적 선택은 세 가지다.

• 선택 1 — 원문 그대로가 아닌, 재가공된 구조를 서비스에 탑재: DOJ 10단계 → 6단계 선별, 각 Stage별 필수 Step 4개씩 자체 정의, 충족 기준 측면까지 팀이 설계. SWEBOK 토픽 구조를 참고하되 내용은 팀이 초보자 관점으로 재작성.

• 선택 2 — AI가 부족한 영역에만 자체 가이드를 집중 투입: 일반적인 LLM은 소프트웨어 공학 지식을 폭넓게 학습한 상태다. 그러나 소규모 팀·단기 프로젝트 맥락에 맞춘 구체적 안내는 부족하다. SWEBOK도 “프로젝트 규모는 활동 선택의 주요 변수” 라는 원칙만 추상적으로 제시할 뿐, 1~10명 규모의 구체적 가이드는 제공하지 않는다. 이 빈칸을 Poco 팀이 채운 것이 자체 가이드 14편이며, Stage 3~4(요구사항·설계)에 11편이 집중된 이유는 이 구간이 “SWEBOK 권위 강 × LLM 약점 강” 의 교집합이기 때문이다.

• 선택 3 — LLM이 이미 잘 답하는 영역은 그대로 활용: “자체 문서를 많이 만들수록 답변이 좋아진다” 는 전제는 사실이 아니다. LLM이 이미 잘 답하는 영역은 그대로 두고, 약한 영역만 자체 문서로 보강하는 것이 품질 대비 효율이 가장 높다.

구간	Poco의 대응
AI 기본 지식으로 충분한 영역 (일반 SE 용어 정의, 기술 스택 개요, 범용 절차 설명 등)	자체 문서 투입하지 않음. LLM 기본 지식만으로 충분한 품질 확보.
팀 가이드가 필요한 영역 (아래 4개 영역)	DOJ·SWEBOK 구조를 근거로 한 자체 가이드 집중 투입.

6-2. 팀 자체 가이드가 필요한 4가지 영역

최근 LLM4SE(LLM for Software Engineering) 연구들은 LLM이 설계·아키텍처 추천 시 프로젝트 규모·맥락을 별도 조정 없이 과도하게 복잡한 제안을 할 수 있으며, 인간이 단순화·검증해야 한다고 반복 지적한다^[1]. 또한 RLHF 기반 정렬이 “더 많이, 더 상세하게 도와주려는” 방향으로 보상하는 구조이기 때문에, “여기서 멈춰라” 라는 브레이크는 별도로 설계해야 한다^[2].

Poco는 이러한 LLM의 구조적 한계를 보완하기 위해, 아래 4개 영역에 팀 자체 가이드를 집중 투입했다.

영역 A — 소규모 팀·제한된 기간으로의 캘리브레이션

일반적인 LLM은 디폴트로 중대형 기업팀 사례를 기준으로 답하는 경향이 있다. Poco의 타겟(1~10명, 1~12개월)에서는 과도한 추천이 발생한다. SWEBOK Ch9(Management) §2에서도 “프로젝트 규모(size)는 활동 선택의 주요 변수” 라는 원칙을 명시하지만, 구체적인 소규모 팀 가이드는 제공하지 않는다. Poco가 타겟을 1~10명으로 설정한 것은 SWEBOK이 다루는 small team 범위(약 9~10명 이하)와 일치하며, 11명 이상은 sub-team 형성 등 다른 운영 패러다임이 필요해지는 구간이기 때문이다. 이 빈칸이 Poco 자체 가이드의 정확한 자리다.

Poco의 자체 가이드 문서는 각 기법·활동마다 팀 규모별 적용 차이(1인 / 2~3명 / 4~6명 / 7~10명) 를 기술해두고 있다. AI가 사용자의 사전 정보(인원 수)를 받으면, 해당 구간에 맞는 내용을 추출하여 사이드패널에 반영한다.

• 팀 규모별 역할 분담 패턴과 활동 수준 차등
• 기간별 MVP 범위 (1·3·6개월 각각의 기능 수준)
• 대학생 팀 특수 리스크 (시험기간 공백, 팀원 이탈, 의사결정 미루기)

영역 B — “그만하세요” 안티패턴

LLM은 “best practice 추천” 에 강하지만, “여기까지만 하면 됩니다·이건 하지 마세요” 는 약하다. 초심자의 과잉 기획을 막는 안내는 이 영역 없이는 제공되지 않는다.

• 문제 정의 단계에서 해결책 설계로 넘어가지 않기
• 소규모 MVP에 마이크로서비스·Kubernetes 넣지 않기
• 요구사항을 너무 상세히 적지 않기 (“이 정도면 충분” 기준)
• 첫 프로젝트에서 Event Sourcing 등 과잉 아키텍처 피하기

영역 C — 현실적으로 실행 가능한 수치 기준

LLM은 “사용자 인터뷰를 하세요” 까지는 잘 말하지만, “몇 명한테, 몇 분, 무엇을 물어야 하는지” 는 모호하게 답한다. 초심자에게 필요한 것은 당장 오늘 시작할 수 있는 수치다.

• 게릴라 사용자 인터뷰 방법 (5~8명 · 15분 · 질문 예시)
• 프로토타입 제작 예산표 (Figma 2~3일, 코드 1주 등)
• 소규모 팀의 현실적 스프린트 주기 (1주/2주 중 선택 기준)
• MVP 테스트 커버리지 목표 (100% 아님, 우선순위 영역)

영역 D — 한국어 맥락의 전문용어 해설

한국어 LLM 벤치마크(CLIcK, Ko-H5 등)에서도 문화·전문 용어·뉘앙스 이해가 영어 대비 일관되게 떨어진다는 점이 보고되고 있다^[3]. 용어의 사전적 정의는 LLM이 잘 처리하지만, “실무에서 한국어로 이렇게 쓰입니다” 수준의 뉘앙스는 약하다.

• 요구사항 추적 매트릭스의 한국어 실무 예시
• 유스케이스 vs 유저스토리 — 초심자가 먼저 써야 할 것
• 비기능 요구사항을 초심자가 실제 작성하게 만드는 포인트

_{[1] Zhang et al., “A Survey on Large Language Models for Software Engineering”, arXiv:2312.15223, 2023 — LLM이 프로젝트 규모·맥락 없이 과도한 설계를 제안할 수 있으며 인간 검토가 필요하다는 점을 지적.
[2] Christiano et al., “Deep Reinforcement Learning from Human Preferences”, NeurIPS 2017 — RLHF 정렬이 helpfulness를 강하게 보상하는 구조이며, 별도 제약 없이는 과도한 제안을 유도할 수 있음을 시사.
[3] Kim et al., “CLIcK: A Benchmark Dataset of Cultural and Linguistic Intelligence in Korean”, arXiv:2403.06412, 2024 — 한국어·한국 문화 맥락에서 LLM 성능이 영어 대비 저하되며, 전문 용어·뉘앙스에 별도 로컬 데이터가 필요함을 보고.}

6-3. 참조 문서와 활용 매트릭스

문서	분류	Poco에서의 활용 범위
DOJ SDLC Guidance Document (미국 법무부, Jan 2003)	소프트웨어 개발 방법론 (공공 문서)	원문을 RAG에 그대로 탑재하여 AI 참조 지식으로 사용. 서비스 Stage 구조는 원문 10단계 중 6단계를 선별하여 팀이 별도 설계. 24개 필수 Step의 목표·진입·충족 기준도 팀이 자체 정의.
SWEBOK V4.0a (2024, IEEE Computer Society)	소프트웨어 공학 지식 체계 (방법론이 아닌 지식 지도)	토픽 구조(Knowledge Area → Topic)만 참조. 원문 미탑재. 팀이 약점 4개 영역에 대한 자체 가이드 작성 시 출처·구조의 학술적 근거로 활용.

6-4. 자체 제작 자산

Poco는 참조 문서를 그대로 노출하지 않는다. 팀이 다음 자산들을 자체 제작하여, 참조 문서를 초심자 친화적인 형태로 변환했다.

자체 제작 자산	근거	설명
6개 Stage 구성	DOJ SDLC 기반, 팀 자체 재구성	DOJ 원문 10단계를 Poco 타겟(초심자·소규모 팀)에 맞게 재검토·선별하여 6단계로 재구성. 단순 축소가 아닌, 각 Stage의 목표·범위를 재정의.
24개 필수 Step (Stage별 4개씩)	DOJ SDLC 기반, 팀 자체 정의	각 필수 Step의 목표·진입 기준·충족 기준 측면을 팀이 모두 자체 정의.
필수 Step 사이드패널 콘텐츠	팀 자체 제작	Step 설명·생각해보면 좋은 관점·이 Step의 목표·자주 하는 실수·한 줄 팁 등 모든 항목 자체 작성.
필수 Step 노션 템플릿 (24개)	팀 자체 제작	각 필수 Step의 산출물 작성을 돕는 템플릿 페이지.
일반 Step RAG 참고 가이드 문서 (14편)	SWEBOK 토픽 구조 참조, 팀 자체 제작	위 LLM이 부족한 4개 영역을 집중 공략한 Glossary(용어 사전) + Technique(기법 가이드) 문서를 S3 Vectors에 인덱싱. Stage 3~4에 11편이 집중 — “SWEBOK 권위 강 × LLM 약점 강” 교집합 구간.

자체 가이드의 가장 큰 차별 가치는 “안티패턴 가이드(영역 B)”다. 14편 중 13편이 B를 커버한다. 일반 LLM이 절대 해주지 않는 “여기까지만 하면 충분, 이건 도입하지 마” 의 컷오프를 명시적으로 제공하는 것이 Poco RAG의 핵심 차별점이다.

이 구조의 의미는, Poco의 안내 품질이 AI의 즉흥성이 아닌, 팀이 설계한 학술적 근거 위에서 나온다는 것이다. AI는 팀이 만든 구조 안에서 동적 맥락 생성만 담당한다.

6-5. 왜 폭포수(워터폴) 기반인가

	Agile/Scrum	폭포수 (DOJ SDLC 기반)
소규모 친화도	높음 (원래 그렇게 설계됨)	낮음 (대규모 전제)
단계 명확성	낮음 (이터레이션 안에 모든 활동 섞임)	높음 (6단계 순차)
초보자 학습	코치·문화 필요	단계만 따라가면 됨
캡스톤 적합성	한 사이클 완주가 모호	“끝까지 가본” 경험 명확

Poco가 폭포수를 선택한 이유는 “교육 도구로서의 명확성” 이다. 학생이 처음 SDLC를 학습할 때 “지금 어느 단계인지” 항상 알 수 있어야 한다. Agile은 실무에 적합하지만, 첫 학습에는 폭포수가 적합하다. 한 사이클을 끝까지 가본 경험이 있어야 Agile도 의미를 가진다. Poco는 그 첫 사이클을 가이드하는 도구다.

6-6. 6 Stage 진행 플로우

번호	한글명	영문명	설명
1	아이디어 구체화	Ideation	막연한 아이디어를 “왜 만들 가치가 있는가”로 다듬는다.
2	프로젝트 계획	Planning	기간·인원·역할을 정하고, 어떻게 일할지 설계한다.
3	요구사항 정의	Requirement	시스템이 “무엇을” 해야 하는지 구체적으로 정의한다.
4	설계	Design	요구사항을 구조·데이터·인터페이스로 그려낸다.
5	개발	Development	설계를 실제 동작하는 코드로 구현한다.
6	테스트 및 검증	Test	만든 것이 처음 정의한 요구사항을 충족하는지 확인한다.

 

7. 팀 소개

정연승 (팀장)	장우리	김한림	박수연
기획, AI, Infra	Frontend, UI/UX	Backend, DB, CI/CD	Backend, DB

 

8. 레포지토리 탐색 가이드

2026-capstone-59/
│
├── frontend/               → React SPA (UI/UX, 캔버스 시각화)
│   ├── src/
│   └── public/
│
├── backend/                → FastAPI 메인 서버
│   ├── app/
│   │   ├── ai/             → AI 모듈 납품 자리 (ai/ 폴더에서 검증 후 이관)
│   │   ├── core/
│   │   │   ├── models/     → SQLAlchemy 모델 (Project, Stage, Step, RequiredStep ...)
│   │   │   └── seeds/      → 24개 필수 Step 시드 데이터 + 필수 Step 사이드패널 콘텐츠
│   │   └── routers/        → API 엔드포인트
│   ├── alembic/            → DB 마이그레이션
│   └── tests/
│
├── ai/                     → AI 모듈 독립 개발·검증 공간
│   ├── services/           → step_generator, required_step_judge, side_panel_generator
│   ├── clients/            → Bedrock Claude, Knowledge Base 공통 클라이언트
│   ├── prompts/            → 시나리오별 프롬프트 템플릿 (.txt)
│   ├── schemas/            → Pydantic 스키마 (generate, accept, side_panel)
│   ├── data/               → RAG 인덱싱 원본 (Bedrock Knowledge Base로 업로드)
│   │   ├── doj/            →   KB-A: DOJ SDLC Guidance Document 마크다운 변환본
│   │   └── custom/         →   KB-B: 팀 자체 제작 가이드 문서
│   │       ├── glossary/   →     용어 사전 (1 파일 = 1 개념)
│   │       └── technique/  →     기법 가이드 (1 파일 = 1 기법)
│   └── tests/              → 단위 테스트 + Property-Based Tests (hypothesis)
│
├── assets/                 → 소개 페이지 이미지 (로고, 아키텍처 다이어그램, 포스터 등)
├── docker-compose.yml      → 로컬 개발 환경
├── index.md                → GitHub Pages 소개 페이지 (이 페이지)
└── README.md               → 프로젝트 개요

주요 문서

• 프로젝트 전체 레포
• backend/README.md — 백엔드 실행 방법
• ai/README.md — AI 모듈 독립 검증 방법
• ai/data/README.md — RAG 인덱싱 원본 가이드
• frontend/README.md — 프론트엔드 실행 방법

 

9. 사용법

9-1. 배포 버전

📌 현재 개발 중입니다. 배포 완료 후 서비스 링크를 추가할 예정입니다.

9-2. 로컬 실행

# 1. 레포 클론
git clone https://github.com/kookmin-sw/2026-capstone-59.git
cd 2026-capstone-59

# 2. Docker Compose로 전체 스택 실행
docker-compose up -d

# 3. 개별 실행 시
# - Backend: cd backend && uvicorn app.main:app --reload
# - Frontend: cd frontend && npm install && npm run dev
# - AI 모듈 테스트: cd ai && uv run pytest

자세한 환경 변수 및 AWS 자격증명 설정은 각 폴더의 README.md를 참조해주세요.

---

_{본 프로젝트는 미국 법무부(DOJ) SDLC Guidance Document의 10단계 Phase를 재검토·선별하여 6단계로 재구성하고, SWEBOK V4.0a (2024, IEEE Computer Society)의 토픽 구조를 참고하여 자체 가이드를 제작했습니다.}