이 글은 2026-09-30 하루의 기록이다. 코드는 거의 건드리지 않았다. 하루 내내 SURAS Jira의 에픽 두 개와 그 아래 작업 구성을 다시 짰다. 그 결과를 BATON 로컬 Task DB와 맞췄다.
배경 — 에픽 이름과 하위 작업이 서로 다른 말을 하고 있었다
SURAS-1342 에픽의 이름은 “자동화”였다. 그런데 하위 작업 29건 가운데 절반 이상은 자동화와 관계가 없었다. v1.2 개정 때 만든 정의 산출물 작업 15건이 여기에 들어 있었다. 요구사항·유스케이스·다이어그램을 고쳐 적는 작업들이다.
AI 관련 작업 10건도 같은 에픽에 섞여 있었다. 에픽 이름만 보고는 이 에픽이 무엇을 끝내면 닫히는지 알 수 없었다.
문제
- 에픽을 “무엇을 개선하나” 기준으로 다시 정의하면, AI 작업은 어디로 보내야 하나
- 이미 끝난 정의 작업 15건은 남겨야 하나, 지워야 하나
- Jira에서 지운 작업과 연결된 BATON Task는 어떻게 정리하나
- AI 쪽에 원래 있던 에픽(SURAS-1316)과 새 에픽의 범위가 겹치면 어떻게 하나
결정 1 — 에픽은 “위험도 평가 편의성 개선”으로 바꾸고 AI 작업은 분리한다
SURAS-1342의 이름을 “위험도 평가 편의성 개선”으로 바꿨다. AI·자동화 작업 10건은 새 에픽 SURAS-1600(“위험도 평가 AI·자동화 기능 개발”)으로 옮겼다. 새 에픽의 상위는 AI 서비스 에픽(SURAS-1315)이다.
| 에픽 | 상위 | 하위 작업 |
|---|---|---|
| SURAS-1342 위험도 평가 편의성 개선 | SURAS-1289 위험도 평가 | 19 |
| SURAS-1600 위험도 평가 AI·자동화 기능 개발 | SURAS-1315 AI 서비스 | 10 |
옮긴 뒤 두 에픽의 하위 작업을 합쳐 보니 29건으로, 옮기기 전과 같았다. 이동 API 응답에는 parent가 나오지 않는다. 그래서 JQL로 다시 조회해 실제로 옮겨졌는지 확인했다.
결정 2 — 정의 작업 15건 대신 개선 요소 작업 5건을 둔다
다음 요청은 “정의 단위로 되어 있는 하위 작업을 개선 요소 단위로 바꾸자”였다. 무엇이 개선 요소인지는 이미 정리돼 있었다. 불편 사항 리스트업(SURAS-1353)과 편의성 증대 항목 검토(SURAS-1400, 8/7 회의)의 결론이다. 이 결론을 그대로 작업 단위로 옮겼다.
| 이슈 | 개선 요소 | SP | 근거 |
|---|---|---|---|
| SURAS-1601 | 위험도 평가 전용 시스템 전환 | 5 | 도메인 아이덴티티 확립 |
| SURAS-1602 | SORA·SRM 평가 분리 | 5 | 도메인 아이덴티티 확립 |
| SURAS-1603 | 평가 입력 정보 간소화 | 3 | 평가 절차 간소화 |
| SURAS-1604 | 평가 단계 재구성 | 3 | 평가 절차 간소화 |
| SURAS-1605 | 위험도 평가 승인 절차 추가 | 5 | 승인 절차 추가 |
SURAS 프로젝트는 작업을 만들 때 Story Points가 필수다. 제안값은 영향 범위로 추정했다. 삭제가 있는지, 외부 연동이 걸리는지, 역할이 추가되는지를 봤다. 팀이 나중에 조정할 수 있는 값이라고 설명에 적었다.
기존 정의 작업 15건 처리에는 선택지를 세 가지 냈다. 남겨 두고 relates to로 잇기, 별도 에픽으로 빼기, 중복으로 닫기다. 사용자의 답은 셋 다 아니었다.
“삭제하기 위한 JQL 공유해줘. 내가 삭제할게”
이슈 삭제는 되돌릴 수 없다. 그래서 대상 목록만 JQL로 넘기고, 실제 삭제는 사용자가 직접 했다.
project = SURAS AND key in (SURAS-1549, SURAS-1551, ..., SURAS-1597) ORDER BY key ASC
삭제의 대가는 하나 남는다. SURAS-1592·1593은 요구사항 개정 이력(v1.1.3, v1.2.0)에 참조로 적혀 있다. 이슈가 사라지면 이 참조는 없는 이슈를 가리킨다. 산출물 본문은 멀쩡하고 개정 이력의 링크만 끊긴다. 이 점을 미리 알렸다.
결정 3 — BATON Task는 Jira 삭제를 확인한 뒤에 지운다
BATON에서는 로컬 SQLite Task DB가 정본이고, Jira는 outbox로 내보내는 사본이다. 지운 15건은 BATON Task 15건과 연결돼 있었다.
순서를 이렇게 잡았다.
- Jira에서 15건이 실제로 모두 없어졌는지 조회
- 하위 Task가 없는지 확인
- DB 백업(
state.db.bak4) local_tasks.delete로 삭제 (딸린 댓글·이력·대기 중인 outbox 항목도 함께 삭제)
DB를 직접 DELETE하지 않고 삭제 함수를 썼다. 그래야 outbox에 남은 전송 요청까지 같이 정리된다. 확인 뒤 백업 파일도 지웠다.
결정 4 — [Jira 가져오기]를 누르지 않고 같은 동작을 대상에만 적용한다
새 개선 작업 7건을 BATON으로 불러오려다 두 가지 걸림돌이 드러났다.
- [Jira 가져오기]는 작업 종류 라벨(
task-doc,task-impl등)이 붙은 이슈만 가져온다. 새 작업에는 라벨이 없었다. - 웹 버튼은 라벨이 붙은 SURAS 이슈를 완료된 것까지 모두 가져온다.
그래서 7건(개선 5건과 대시보드 2건)에 task-impl 라벨을 붙였다. 개선 작업은 기능을 바꾸는 일이므로 구현 종류가 맞다고 봤다. 그다음 버튼과 같은 동작(local_tasks.create + link_jira)을 이 7건에만 돌렸다. 7건 모두 synced 상태가 됐다.
목록이 비어 있었기 때문에 Task 번호는 SURAS-T00001부터 다시 매겨졌다. 지난번에 지운 Task와 번호는 같지만 다른 Task다. 나중에 헷갈리지 않게 보고에 이 점을 적었다.
결정 5 — SURAS-1316은 쪼개지 않고 이름만 정리한다
새 에픽 SURAS-1600을 만들고 보니 AI 서비스 아래에 SURAS-1316 “AI 기반 위험도 평가 지원 개발”이 이미 있었다. 이름만 보면 두 에픽의 범위가 겹친다.
그런데 하위 작업 40건을 열어 보니 성격이 달랐다. 1316은 벡터 RAG, 지식 그래프, RAGAS 품질 평가, 쿼리 라우터, LLM 추천 같은 엔진 작업이었다. 1600은 그 엔진을 위험도 평가 화면에 붙이는 작업이다.
선택지는 셋이었다. 작업 흐름별로 에픽 쪼개기, 추천 7건만 1600으로 옮기기, 에픽을 유지하고 이름만 정리하기다. 마지막 안을 골랐다.
- 에픽 이름: “AI 위험도 평가 지원 엔진(RAG·추천) 개발”
- 하위 작업 40건 요약명 앞에 작업 흐름 이름을 붙임
| 작업 흐름 라벨 | 앞에 붙인 이름 | 건수 |
|---|---|---|
| vector-rag / hierarchical-rag | 벡터 RAG / 계층형 RAG | 7 / 3 |
| kg / graph-rag / hybrid-rag | 지식 그래프 / 그래프 RAG / 하이브리드 RAG | 3 / 3 / 3 |
| ragas / query-router | RAG 품질 평가 / 쿼리 라우터 | 8 / 3 |
| llm-recommendation / response | AI 추천 / AI 응답 | 7 / 3 |
“문서 임베딩 파이프라인 구현”이 두 건이었는데, 이제 “벡터 RAG 문서 임베딩 파이프라인 구현”과 “계층형 RAG 문서 임베딩 파이프라인 구현”으로 구분된다. 이 40건도 task-impl 라벨을 붙여 BATON Task(T00008~T00047)로 가져왔다.
의도치 않은 함정
라벨을 로컬에만 붙였다. 40건을 가져올 때 BATON Task에는 기존 작업 흐름 라벨에 task-impl을 더했다. 다음 동기화 때 Jira 쪽 작업 흐름 라벨이 지워지지 않게 하려는 것이었다. 하지만 가져오기는 로컬에서 연결만 하는 동작이라 Jira 이슈에는 라벨이 없었다. 상태를 한 번 바꾸기 전까지는 두 쪽 라벨이 달랐다. 결국 Jira 40건에도 라벨을 직접 붙여 양쪽을 맞췄다.
담당자 일괄 지정이 중간에 멈췄다. 5건 중 2건만 반영되고 3건은 자동 모드 안전 검사가 판정 없이 연속으로 실패했다. 연속 10회가 되면 세션이 강제로 멈추므로 거기서 멈추고 보고했다. BATON Task 쪽은 Jira 5건이 다 끝난 뒤 한 번에 맞추려고 손대지 않았다. 재개 후 Jira가 먼저 반영됐으므로, BATON이 쌓은 재전송 요청은 바로 완료로 처리했다. 같은 담당자 변경을 Jira에 두 번 보내지 않기 위해서다.
곁가지 — SPA 개편 프롬프트
오전에는 SURAS SPA 코드를 읽고 개편 작업용 프롬프트를 짰다. 이 개편이 SURAS-1601·1604의 실제 구현이 될 일이다. “일반 정보”라는 이름이 두 곳에 쓰이고 있었다.
- 데이터 관리 CRUD(
/general-information): 삭제 대상 - 평가 1단계 입력: GRC·ARC 계산에 필요하므로 유지
그래서 aircraft/flight.store는 남기고 CRUD API 의존만 끊도록 범위를 적었다. Stepper 기반 5단계 화면은 IDE형 워크벤치로 바꾼다. Cesium 뷰어는 지금 5개인데, 이를 하나로 합치는 방향도 담았다.
마무리
에픽이 무엇을 하는지는 이름이 아니라 하위 작업이 정한다. 정의 산출물 작업은 “무엇을 적었나”를 기록하고, 개선 요소 작업은 “무엇이 나아지나”를 기록한다. 에픽 이름을 바꿀 때 하위 작업의 단위도 같이 바꾸지 않으면, 에픽은 다시 여러 성격이 섞인 묶음이 된다.
Jira와 로컬 Task DB를 함께 쓸 때는 어느 쪽에 먼저 반영하느냐보다, 어느 쪽이 이미 반영됐는지 확인하는 순서가 더 중요하다.
다음 할 일:
- SURAS-1316과 SURAS-1600이 선후 관계인지 이슈 링크로 명시
- RAG 품질 평가 작업 일부를
task-test로 바꿀지 결정 - SPA 개편 프롬프트로 1단계(데이터 관리 CRUD 제거) 착수