[목표]
프로젝트 요약 및 본인 커밋 및 댓글 기반 본인 기여도 분석 요약 Ai 기능 추가(기록저장 중단)
폴리싱 2차 내용 탐색 후 진행(버그 픽스 위주)
전체적인 발표 내용 구상 (초안)
개발 마감에 따른 Codeplanner 이슈 카드 점검
증명사진 모으기
PPT와 스크립트 내용 작성
어제 내용 요약 및 병합은 완료(대강완료)
멘토님 말씀 정리(대충)
요약 페이지의 이슈 분포 변경 및 한글화
12:00 ~ 13:00
식사 후 휴식
13:00 ~ 13:30
EC2 본 서버를 t3.large로 사양을 올렸고, 오토스케일링 서버는 t3.medium으로 올렸다. t3가 t2보다 더 빠른 네트워크 속도를 제공하기 때문이다. Gigabite대여서 빠르다.
13:30 ~ 15:30
우리의 코드플래너 폴리싱 2차 이슈 카드를 보면서, 전체 점검사항에 대해서 확인을 했다. 핫픽스 부분을 선정하여 먼저 조치했다.
명석이 형은 요약 페이지의 이슈 분포 변경 및 한글화를 했고, 나는 권호형 레이블 모달창 오류를 수정했다.(이슈 카드에서 레이블 추가에서 비정상적으로 전체 모달 닫히는 현상 픽스)
오토스케일링 서버 설정
맥북과 내용 동기화
발표 자료 및 포스터 구성내용 이야기
15:30 ~
집갈 준비
가지고올 옷이 있어서 집으로 갔다왔다.
버스에서 오토스케일링 서버 재구성.
팀원 결정 내용 결정.
동영상 내용 피드백
~ 11:00
할것..
다른 팀에게 우리 서비스 써보는거 어떨지 제의하기
권호형 멘토링 내용 정리
권호형에게 전달할 멘토링 내용 정리하기
7월 7일 멘토링
| 구분 | 핵심 내용 |
|---|---|
| 서비스 방향 | “초등학생도 쓸 수 있을 정도로 단순화된 Jira” 컨셉 재확인. 사용 동기(왜 써야 하는가) 명확화 필요. |
| 기능/UX | 백로그를 통한 이슈 흐름 단순화 제안. 이슈 1개=브랜치 1개 방식은 과도한 분기 가능 → 백로그→선택→작업 흐름 정리 필요. |
| 통합 아이디어 | GitHub + IDE + Code Planner 연계(개발 흐름 근접 통합) 탐색. |
| 차별화 | Jira는 복잡·과다기능, 우리 서비스는 “필수 축소 + AI 적극 활용.” |
| 사용자 가치 질문 | “유저 입장에서 직접적인 이득(시간 절약, 맥락 자동화, 문서/요약 자동 생성 등) 명확히 서술 필요.” |
| AI 활용 | Codex(LLM) 적극 실험 권고. 시나리오(Use Case)로 가치 설득. |
| 조직/산업 맥락 | 개발자 역할 → PM/기획 일부 동시 수행 추세. 도구가 ‘경량 PM + 개발 맥락 자동화’ 지원해야 차별성. |
| 기술 전략 | 5주 안에 ‘AI 활용으로 과감한 품질’ 보여줄 수 있는 범위 선정. |
| 인프라 | 오토스케일링: “명분(실서비스/대량 트래픽 시뮬레이션)이 있다면 채택 가치 있음.” 본인 의지가 있으므로 진행 가능. |
| 파이프라인 | 제시한 CI/CD 파이프라인 이해된 것으로 확인. 추가 요구 없음. |
7월 14일 멘토링
| 구분 | 핵심 내용 |
|---|---|
| 전략 재초점 | “AI 에이전트를 어떻게 자연스럽게 녹여 플랫폼 레벨 가치를 낼 것인가”가 핵심 질문. 단순 AI 기능 삽입이 아니라 에이전트가 작동할 무대(데이터·워크플로 구조) 설계 필요. |
| 에이전트 활용 | 업무 흐름 내 반복 패턴(이슈 정리, 변경 영향, 커밋 요약, 코드 리뷰 후보 라인 선별 등)에 에이전트 삽입 검토. |
| 모델 한계 언급 | HTML 기반 문맥 해석 비효율 언급 → 구조화 포맷(내부 DSL, JSON 스키마 등) 제공 시 해석 정확도↑. 구글이 ‘모델 친화 포맷’을 연구 중이라는 인사이트. |
| 과제 | “서비스 데이터→구조화→AI 에이전트 소비→액션/요약/추천” 흐름 정의 필요. |
| 비교 기준 | 크래프톤 내부도 Jira 사용 → 우리 서비스 채택 이유는 “(1) 과잉 제거 (2) 반복 자동화 (3) 기획/문서/요약 즉시화” 여야 함. |
| 일정/피드백 | 수요일 피드백→금요일(7월 19일) 11시 반영 계획(시간 기준 재확인 필요). |
7월 18일 피드백 세션
| 구분 | 핵심 내용 |
|---|---|
| 모델/프롬프트 | 고성능 모델 사용 시 해결될 세부 프롬프트 튜닝 요소 존재하나, 실무에서는 과도 튜닝보다 모델 선택이 일반적이라 “심한 커스텀”은 비추 의견. |
| 적용 결정 | 프롬프트 고도화 대신 이중 검증(AI 2단계 Double-Check 구조) 채택. (1차 생성→2차 검수/교정). |
| 상태 평가 | 현재 구조 위에 “검증용 보조 모델” 추가로 품질 안정성 보강. |
| 후속 필요 정리 | 7월 7일·14일 제안된 ‘시나리오 명문화’ 및 ‘에이전트 동선 정의’는 아직 문서화 필요. |
2. 종합 주제별 정리
| 주제 | 정리 |
|---|---|
| 핵심 포지셔닝 | “경량화 + AI 에이전트 내재화”로 Jira 대비 러닝커브·조작성 감소. |
| 사용자 가치 명확화 필요 요소 | (1) 자동 백로그 요약 (2) 커밋/PR/이슈 맥락 자동 연결 (3) ‘다음 행동’ 추천 (4) 기획/회고 문서 자동 드래프트 (5) 신규 기여자 온보딩 요약. |
| 워크플로 단순화 | 이슈 폭증/브랜치 남용 방지 → 백로그 큐 중심 Pull 방식, 상태 전이 최소화(예: Backlog→Active→Review→Done). |
| AI 에이전트 구조 초안 | Data Layer(이벤트 스트림) → Normalizer(JSON/구조화) → Insight Generators(기여 분석, 리스크 탐지) → Draft Producers(요약/문서) → Reviewer(2차 모델) → Delivery(알림/대시보드). |
| 프롬프트 전략 | 세밀 튜닝 최소화, 대신 구조화 입력 + 2단계 검증. |
| 기술 데모 목표(5주 범위) | “AI 에이전트가 실시간/주기적으로: (a) 활동 요약, (b) 리스크/지연 이슈 감지, (c) 문서 초안 생성” 세 가지를 안정적으로 보여줄 수준. |
| 인프라/스케일 | 오토스케일링은 ‘실서비스 시뮬레이션’ 명분 확보 시 유지. 초기 부하 테스트 시나리오(가짜 트래픽) 간단히 준비. |
| 차별화 논리 문서화 필요 | 경쟁표(컬럼: 기능 / Jira / Code Planner) 작성 권장. 과잉 UI, 복잡 워크플로 제거 항목 명시. |
| 리스크 | (1) 가치 스토리 불명확 시 “Jira 라이트”로만 인식 (2) AI 에이전트 실사용 시나리오 부재 (3) 구조화 데이터 모델 미완성. |
7월 7일 멘토링 요약
이날은 서비스의 정체성과 차별화를 다시 점검했다. 컨셉은 “초등학생도 쓸 수 있을 정도로 단순화한 Jira”로 정리되었으나, 단순 축소가 아니라 왜 이 서비스를 써야 하는지(사용 동기)를 명확한 문장과 시나리오로 제시해야 한다는 지적이 있었다. 이슈 1개당 브랜치를 그대로 대응시키면 브랜치 남발로 복잡성이 증가할 수 있으므로, 우선 ‘백로그 큐’를 중심으로 선별·활성화 과정을 단순화하는 흐름이 낫다는 의견이 나왔다. GitHub, IDE, Code Planner를 유기적으로 엮어 개발자가 맥락을 이동하지 않고 작업·이슈·코드 변화를 다룰 수 있는 통합 경험을 탐색하라는 방향도 제시되었다. Jira는 과기능·복잡성으로 인해 피로도가 높으니, 우리 쪽은 불필요한 단계 축소 + AI 자동화(요약, 문서화, 다음 작업 제안)에 집중해 ‘시간 절약’과 ‘사고 부담 감소’라는 사용자 가치를 전면에 내세워야 한다. 최근 개발자에게 기획/PM 역할이 부분적으로 요구되는 시장 흐름을 고려해, “경량 PM 기능을 AI로 보조”하는 스토리가 설득력 있다는 조언도 있었다. 5주 안에 “AI 적극 활용으로 얻은 과감한 품질”을 눈에 보이게 하는 범위를 한정해 집중하라는 점이 강조되었고, 인프라 측면에서는 오토스케일링을 채택할 명분(실서비스 시뮬레이션·대량 트래픽 대비)을 명확히 정의한다면 진행해도 괜찮다는 평가가 내려졌다. 제시했던 CI/CD 파이프라인은 이해된 것으로 확인되었고 추가 수정 요구는 없었다. 전반적으로 “사용자 가치 스토리 + 핵심 시나리오 문서화”가 즉시 필요한 후속 과제로 남았다.
7월 14일 멘토링 요약
두 번째 세션에서는 초점을 “AI 에이전트를 기능으로 덧붙이는 수준”이 아니라 “에이전트가 자연스럽게 활동할 수 있는 플랫폼 구조를 먼저 설계”하는 것으로 이동시켰다. 즉, 서비스 내부 데이터(이슈, 커밋, PR, 댓글 활동 로그 등)를 구조화 포맷(내부 JSON/스키마)으로 정규화하여 모델이 해석하기 쉬운 입력을 공급하고, 그 위에 반복적인 업무 흐름(이슈 요약, 변경 영향 인식, 코드 리뷰 후보 선정, 일정 리스크 감지 등)에 에이전트를 삽입하는 파이프라인을 잡아야 한다. HTML 산출물만 던지는 방식은 모델 이해 효율이 낮으므로, “모델 친화적 중간 표현”을 정의하는 것이 품질·안정성 측면에서 장기적으로 유리하다는 인사이트가 공유되었다(업계에서 유사한 포맷 연구가 진행 중이라는 언급 포함). 또한 Jira를 이미 사용하는 조직(크래프톤 등) 사례를 들어 “왜 기존 Jira 대비 이 서비스를 채택해야 하는가”에 대해 (1) 과잉 기능 제거로 인한 접근성, (2) 반복 업무 자동화, (3) 문서·기획·회고 초안 즉시 생성이라는 세 가지 축으로 비교 논리를 문서화할 필요가 지적되었다. 향후 피드백 일정을 수요일→금요일 오전(7월 19일 11시경) 반영 루프로 설정했으며, 이 일정 속에서 시나리오 정의, 데이터 스키마 초안, 에이전트 삽입 포인트 문서화를 단기 목표로 삼아야 한다는 정리가 이루어졌다.
7월 18일 멘토링 요약
세 번째 회의(피드백 세션)에서는 현재 프롬프트 수준에서 미세한 개선 여지가 있지만, 고성능 모델 선택으로 대부분 해소될 사안이라 과도한 프롬프트 엔지니어링을 실무 관점에서는 권하지 않는다는 의견이 제시되었다. 대신 이중 검증(Double-Check) 구조—1차 모델이 생성, 2차 모델이 형식·일관성·누락·사실성(가능한 범위) 점검 후 교정—를 도입해 품질 안정성과 리스크 완화(할루시네이션, 구조 불일치)를 확보하는 전략을 채택하기로 결정했다. 이는 7월 7일과 14일에 제기된 “구조화 데이터 → 시나리오 → 안정적 출력” 기조와 정합성이 있으며, 현재 상태 위에 검증 계층을 추가하여 신뢰성을 높이는 방향이다. 다만 핵심 시나리오 문서, 이벤트 스키마, 경쟁 차별 포인트 비교표, KPI 후보 등은 아직 충분히 문서화되지 않은 상태라, 빠른 시일 내 텍스트 아티팩트로 고정해야 다음 단계(프로토타입 기능 범위 확정, 데모 품질 측정, 팀 내 공통 언어 확보)가 지연되지 않는다는 점이 다시 강조되었다. 결과적으로 “프롬프트 세밀 튜닝 대신 구조화 + 2단계 검증”이라는 장치가 공식 파이프라인 일부로 편입되었고, 남은 과제는 이를 실제 데이터 흐름 및 저장 형식까지 내려 문서화하는 실행 단계다.
진혁이형 포스터 기술적 챌린지 내용
Summary Ai의 프로젝트 및 팀원 피드백 분석 성능 개선
문제 인식: 프로젝트 분석과정에서의 데이터 양이 증가함에따라 속도, 토큰/비용, 응답률 측면에서 성능 저하 초래
해결:
1. 모든 데이터를 보내는 Raw 데이터가 아닌, 자체 알고리즘(중요도 순)과 필터링을 통해 정제된 데이터만 Ai가 받을 수 있게끔 구현
2. 같은 분석에 두개의 Ai를 사용하는 ‘더블체크’를 통해 응답률과 정확성을 확보
권호형 진행장표의 사후 평가 내용
사후 평가
완성도 평가: 8점
이유: 초기에 기획한 기능들이 대부분 반영될뿐만 아니라, 중간에 ‘사용에 직관적이고 회고 기능이 있으면 좋겠다.’ 등의 실제 개발자분들로부터 피드백을 받아 제작되어 목표한 바를 다 이뤘습니다. 또한, 수많은 QA 테스트를 통해 치명적인 버그들을 모두 잡아 완성도가 매우 높다고 생각합니다. 그러나 아직 개선사항은 있습니다.
개선점 및 보완 사항: Ai 모델 사용에 한계가 있어 고품질의 결과를 산출하기 쉽지 않아, 개선하고 싶습니다. 시간관계상 알고리즘 부분의 중요성 판단 한계를 개선하지 못함에 아쉬움이 있습니다. 인프라측면에서 프론트와 백엔드의 서버를 분리하지 못해 보완해야합니다.
느낀점 및 평가: 5주동안 작업한 대비 높은 디테일을 살린 결과물이 나와 굉장히 만족합니다. 뿐만아니라, 적극적인 동료분들과 함께 완주할 수 있어 기쁩니다. 기업의 보편적인 이슈처리 프로세스에 대해 알고 있기 때문에, 실무에서 이슈트레킹 시스템을 마주쳤다면, 능숙하게 사용할 수 있을 것 같습니다.
발표 스크립트, PPT 작성중
모든 알림보기에 삭제버튼 오류 해당 프로젝트 보드로 자동 들어가짐
브렌치 자동 추가시, 키값이 없음. → 커밋만 키값 있으면 됨. 브렌치는 상관없음.
