AI 에이전트가 자주 하는 비효율 중 하나는 이미 조직이 겪은 문제를 처음 보는 문제처럼 다시 푸는 것이다. 과거에 비슷한 장애가 있었고, 비슷한 설계 결정을 했고, 비슷한 테스트 실패가 있었는데도 에이전트는 현재 코드와 현재 이슈만 보고 새로 추론한다.
이 문제를 줄이려면 Jira의 과거 이슈를 조직 기억으로 활용해야 한다. 핵심 인터페이스는 /jira similar다.
조직 기억은 문서보다 이슈에 많다
문서에는 최종 결론이 남는다. 하지만 Jira Issue에는 과정이 남는다.
- 왜 이 기능을 만들었는지
- 어떤 대안을 버렸는지
- 어떤 테스트가 실패했는지
- 어떤 운영 문제가 있었는지
- 누가 어떤 결정을 했는지
- 후속 이슈가 무엇이었는지
AI 에이전트에게는 이 과정이 중요하다. 최종 코드만 보면 왜 그렇게 설계됐는지 알기 어렵다. 과거 Jira Issue를 보면 당시의 제약과 결정 근거를 알 수 있다.
/jira similar PROJ-123
/jira similar는 현재 이슈와 유사한 과거 이슈를 찾아야 한다.
/jira similar PROJ-123
검색 기준은 단순 키워드만으로는 부족하다. 다음 정보를 함께 사용해야 한다.
- summary
- description
- labels
- components
- linked issues
- 최근 comments의 핵심 키워드
- 관련 파일 경로
- 에러 메시지
출력은 단순 목록이 아니라 작업에 도움이 되는 요약이어야 한다.
## Similar Issues
### PROJ-87 — Slack webhook timeout handling
Status: Done
Resolution: Added 5s timeout and masked webhook URL
Useful Notes:
- 4xx should not retry
- Slack webhook URL must be redacted in logs
### PROJ-102 — Alert duplicate prevention
Status: Done
Resolution: Added deduplication key
Useful Notes:
- Retry can create duplicate notifications
- Use alert_id as idempotency key
### Recommendation
Before implementing PROJ-123, check whether existing deduplication helper can be reused.
이 출력이 있으면 에이전트는 바로 더 나은 출발점에서 시작한다.
해결된 이슈를 우선하라
유사 이슈 검색에서 가장 먼저 봐야 할 것은 해결된 이슈다. Done, Resolved, Closed 상태의 이슈는 실제로 어떤 방식이 채택됐는지 보여준다.
반대로 진행 중이거나 취소된 이슈는 주의해서 봐야 한다. 특히 Won't Do, Duplicate, Rejected 이슈는 잘못된 접근을 피하는 데 유용하다.
검색 결과에는 상태와 resolution을 반드시 표시해야 한다.
Status: Done
Resolution: Fixed
또는:
Status: Closed
Resolution: Won't Do
Reason: Retry at application layer caused duplicate notifications
실패한 결정도 조직 기억이다.
결정 사항만 따로 검색하기
Jira comment가 많아지면 전체 이슈를 읽는 것도 부담이다. 그래서 decision comment만 검색하는 기능이 있으면 좋다.
/jira decisions "retry policy"
/jira decisions "rate limit"
/jira decisions "webhook timeout"
출력은 다음처럼 정리할 수 있다.
## Past Decisions: retry policy
### PROJ-102
Decision: Retry only 5xx and network errors.
Reason: 4xx retry caused unnecessary traffic and duplicate alert risk.
### PROJ-141
Decision: Use exponential backoff with max 3 attempts.
Reason: Fixed interval retries amplified temporary outage traffic.
이 기능은 에이전트가 팀의 과거 정책을 따르게 만드는 데 도움이 된다.
유사 이슈 검색은 완벽하지 않다
검색 결과를 맹신하면 안 된다. 과거 이슈가 현재 문제와 비슷해 보여도 조건이 다를 수 있다.
- 서비스가 달라졌을 수 있다.
- 인프라가 바뀌었을 수 있다.
- 과거 결정이 지금은 더 이상 유효하지 않을 수 있다.
- 당시 임시방편이 현재 표준처럼 보일 수 있다.
그래서 /jira similar의 출력은 “정답”이 아니라 “참고할 조직 기억”이어야 한다. 에이전트는 과거 이슈를 참고하되, 현재 코드와 요구사항에 맞는지 다시 검증해야 한다.
이슈 검색과 코드 검색을 연결하기
가장 좋은 흐름은 Jira 검색과 코드 검색을 연결하는 것이다.
예를 들어 과거 이슈에서 deduplication helper가 언급됐다면, 에이전트는 현재 repo에서 해당 helper를 찾아야 한다.
/jira similar PROJ-123
→ PROJ-102에서 deduplication helper 언급
→ 코드베이스에서 helper 검색
→ 재사용 가능 여부 판단
이렇게 하면 조직 기억이 실제 코드 변경으로 연결된다.
검색 결과를 현재 이슈에 남기기
중요한 유사 이슈는 현재 Jira Issue에 comment로 남겨야 한다.
## Related Past Issues
### PROJ-102 — Alert duplicate prevention
Relevant because retry may create duplicate notifications.
Decision reused:
- Use alert_id as idempotency key
### PROJ-87 — Slack webhook timeout handling
Relevant because webhook URL redaction policy was already decided.
Decision reused:
- Mask webhook URL in logs
이 comment는 다음 에이전트와 리뷰어에게 유용하다. “왜 이 접근을 선택했는지”를 과거 결정과 연결할 수 있기 때문이다.
결론
AI 에이전트가 매번 처음부터 추론하게 두면 조직은 같은 문제를 반복해서 푼다. Jira에는 이미 많은 조직 기억이 있다. 유사 이슈, 과거 결정, 실패 로그, 해결 패턴을 에이전트가 활용할 수 있어야 한다.
/jira similar는 단순 검색 기능이 아니다. 현재 작업을 과거의 맥락과 연결하는 인터페이스다.
좋은 에이전트는 현재 코드만 읽지 않는다. 조직이 과거에 무엇을 배웠는지도 읽는다.