Source: Dev.to

소개

소프트웨어 팀에서 가장 큰 문제 중 하나는 코드를 작성하지 않는 것이 아닙니다. 코드는 결국 작성되고, 리팩터링되고, 테스트되고, 배포됩니다. 대부분의 경우 진짜 도전 과제는 다음과 같습니다.

“왜 이런 결정을 내렸을까?”

개발자가 프로젝트에 합류하면, 저장소만 보고는 작업을 이해할 수 없습니다. 코드는 볼 수 있지만, 그 뒤에 숨은 이야기는 알 수 없습니다. 왜 서비스를 이렇게 나눴을까? 왜 인터페이스가 이렇게 이상하게 설계됐을까? 왜 특정 테스트가 그 가장자리 케이스를 검사할까? 왜 어떤 파일은 모두가 건드리기 두려워하게 되었을까? 이러한 질문에 대한 답은 보통 코드 자체가 아니라 팀의 역사에 있습니다.

그 역사는 여러 도구에 흩어져 있습니다.

• Jira 이슈
• GitHub Pull Request
• 리뷰 코멘트
• 커밋 메시지
• 브랜치 이름
• 인시던트 기록
• 릴리즈 노트
• 때때로 Slack/Teams 대화

그래서 새로운 개발자는 보통 다음과 같은 과정을 거칩니다.

코드 보기 → 이해되지 않는 부분 찾기 → Jira 검색 → PR 검색 → Slack 검색 → 기존 개발자에게 질문 → 반복

이것이 바로 팀 메모리 손실이며, 이 손실은 시간을 낭비하고 오류를 유발하며 사람들을 지치게 합니다.

---

섹션 1: 팀 메모리가 답해야 할 질문들

잘 구조화된 팀 메모리 시스템이 구축되면, 다음과 같은 질문에 답할 수 있어야 합니다.

• 누가 이 파일을 가장 많이 변경했나요?
• 마지막으로 이 파일을 건드린 사람은 누구인가요?
• 어떤 커밋이 이 이슈를 해결했나요?
• 어떤 PR에서 이 변경이 논의됐나요?
• 지난 90일 동안 이 컴포넌트가 왜 이렇게 자주 바뀌었나요?
• 이 버그가 이전에 발생한 적이 있나요?
• 새로운 개발자가 인증 모듈을 배우기 위해 읽어야 할 이슈와 PR은 무엇인가요?
• 새로운 PR에 가장 적합한 리뷰어는 누구인가요?
• 어떤 파일이 기술적 위험을 안고 있나요?
• 어느 컴포넌트가 한 사람에게 지나치게 의존하고 있나요?

이 질문들의 공통점은 답이 단일 레코드에 있지 않다는 것입니다. 답은 관계 속에 숨겨져 있습니다.

예를 들어 “누가 인증 모듈을 가장 잘 아는가?” 라는 질문에 답하려면 단순히 커밋 수만 세는 것으로는 부족합니다. 다음을 모두 고려해야 합니다.

• 인증 파일에 커밋한 사람
• 인증 PR을 리뷰한 사람
• 인증 이슈에 코멘트한 사람
• 인증 버그를 수정한 사람
• 최근에 활발히 활동한 사람
• 큰 규모의 변경을 만든 사람
• 되돌리기 혹은 인시던트 기록이 있는 파일

즉, 팀 메모리는 본질적으로 관계 문제입니다.

---

섹션 2: 왜 LLM‑Free 아키텍처인가?

LLM은 강력하지만, 모든 문제의 핵심에 LLM을 두는 것이 항상 옳은 것은 아닙니다. 팀 메모리와 같은 시스템에 필요한 핵심 요구사항은 다음과 같습니다.

• 정확성
• 감사 가능성
• 재현 가능성
• 낮은 비용
• 장기 유지 보수성
• 권한 및 프라이버시 제어
• 증거 기반 응답 생성

덧붙여 개인적인 이야기를 하자면, 저는 Dev.to에 AI‑free 생활에 관한 연재를 쓰고 있지만 이번에는 AI 없이 소프트웨어 엔지니어링 측면을 다루고 싶었습니다. 솔직히 이 글을 쓰게 된 동기는 반복적인 작업에서 스스로를 벗어나고, 여러분에게 생각할 거리를 제공하기 위함이기도 합니다. LLM 없이도 충분히 유용하고, 기술적으로 깔끔하며, 유지 보수 가능한 시스템을 만들 수 있습니다.

더 직접적으로 말하자면, 우리는 이제 조금 지쳤습니다. 끊임없는 AI, 끊임없는 에이전트, 끊임없는 RAG, 끊임없는 프롬프트. 물론 이 주제들은 가치가 있지만, 때때로 오래된 방식의 견고한 엔지니어링을 보고 싶을 때가 있습니다. 이 글은 바로 그런 동기로 작성되었습니다.

왜 팀 메모리에 LLM‑Free인가?

LLM 중심 접근 방식에는 여러 위험이 따릅니다.

2.1 환각(Hallucination) 위험

LLM은 실제 시스템에 존재하지 않는 관계를 만들어 낼 수 있습니다. 잘못된 PR을 가리키거나, 잘못된 사람을 전문가로 제시하거나, 과거 버그 수정을 오해하면 심각한 시간 손실이 발생합니다. 팀 메모리에서는 답이 “추정”이 아니라 증거와 함께 제시돼야 합니다.

2.2 감사 가능성 문제

시스템이 “이 파일은 위험하다”고 말한다면, 왜 그런지 설명할 수 있어야 합니다.

src/auth/token_service.py는 지난 90일 동안 18번 변경되었습니다.
그 중 5번은 버그 수정과 연결됩니다.
4명의 서로 다른 개발자가 파일을 건드렸습니다.
마지막 두 PR에서 레이스 컨디션이 논의되었습니다.
테스트 파일은 동일한 비율로 업데이트되지 않았습니다.

이와 같은 답변은 논쟁의 여지가 없고, 검증 가능하며, 개선할 수 있습니다. LLM이 “위험해 보인다”고 말하는 것과는 차원이 다릅니다.

2.3 비용 및 지연

다음과 같은 질문은 LLM이 필요하지 않습니다.

• 어떤 커밋이 이 이슈를 해결했나요?
• 누가 마지막으로 이 파일을 건드렸나요?
• 이 PR이 변경한 파일은 무엇인가요?

이들은 순수 데이터 조회이며, SQL이나 그래프 탐색으로 즉시 해결됩니다.

2.4 재현 가능성

팀 메모리에서는 같은 데이터에 대해 같은 질문을 하면 언제나 같은 답이 나와야 합니다. LLM 기반 시스템은 매번 다른 답을 줄 수 있어, 감사와 디버깅에 전혀 어울리지 않습니다.

---

섹션 3: 핵심 아키텍처

시스템의 기반은 메모리 스토어입니다. 이 스토어는 다음을 보관합니다.

• Git 커밋 로그
• Jira 이슈 및 코멘트
• GitHub PR, 리뷰, 리뷰 코멘트
• 파일 경로 및 컴포넌트 정보
• 개발자 정체성

이 위에 에이전트들이 메모리 스토어를 조회하고, 점수를 매기며, 설명 가능한 출력을 생성합니다.

기본 흐름

Jira / GitHub / Git
    ↓
Ingestion Layer
    ↓
Memory Store (relational + graph)
    ↓
Agents (ContextAgent, ExpertiseAgent, RiskAgent, ...)
    ↓
Explainable Output (CLI / API / Bot)

핵심 원칙: 모든 것은 관계다

PROJ-1247 이슈
  → PR #382와 연결
  → 커밋 f00ba47, b91c0de에 의해 해결
  → src/auth/token_service.py를 변경
  → Mehmet Turac, Ayşe Demir가 기여
  → Burak Kaya가 리뷰

이 정보를 통해 새로운 개발자는 이제 무작위로 검색할 필요가 없습니다.

---

섹션 4: 클래식 멀티‑에이전트 로직

여기서 “에이전트”라는 단어는 LLM 에이전트 의미가 아니라 특정 작업을 수행하는 작은 서비스를 뜻합니다. 메모리를 조회하고, 규칙 기반 결정을 내리며, 증거 기반 출력을 생성합니다. 즉, 봇이 프롬프트를 실행하는 것이 아니라 전통적인 소프트웨어 컴포넌트입니다.

• ContextAgent – 이슈, PR, 파일에 대한 컨텍스트를 추출
• ExpertiseAgent – 파일이나 컴포넌트에 가장 지식이 풍부한 사람을 계산
• RiskAgent – 높은 churn, 버그 수정, 기여자 분산 등 신호를 기반으로 위험 파일 탐색
• ReviewRoutingAgent – 새로운 PR에 적합한 리뷰어 후보 제안
• OnboardingAgent – 특정 컴포넌트에 신규 개발자가 읽어야 할 가장 가치 있는 이슈와 PR 목록 제공
• HygieneAgent – 메모리 스토어의 데이터 품질 문제 보고

각 에이전트는 점수화와 규칙 기반 로직을 사용합니다.

---

섹션 5: 데이터 모델

첫 번째 버전에 필요한 최소 엔터티 집합은 다음과 같습니다.

Developer
Repository
Issue
Commit
File
PullRequest
Review
IssueComment

이 모델만으로도 강력한 메모리 시스템을 구축할 수 있습니다.

Developer

개발자는 여러 시스템에서 서로 다른 정체성으로 나타날 수 있습니다.

• Git author email
• GitHub username