LearningCollector: 불필요한 프롬트 생성 로직 제거 및 저장 방식 개선
이번 커밋은 DraftSaver에서 프롬트(frontmatter) 생성을 제거하고 Gemini API의 출력을 직접 저장하도록 변경하여, 저장되는 마크다운 파일의 불필요한 헤더 생성을 막고 데이터 저장 방식을 단순화하는 데 중점을 두었습니다.
LearningCollector: 불필요한 프롬트 생성 로직 제거 및 저장 방식 개선
이번 커밋은 DraftSaver에서 프롬트(frontmatter) 생성을 제거하고 Gemini API의 출력을 직접 저장하도록 변경하여, 저장되는 마크다운 파일의 불필요한 헤더 생성을 막고 데이터 저장 방식을 단순화하는 데 중점을 두었습니다.
요약
이번 커밋은 DraftSaver 클래스에서 _add_frontmatter() 메서드를 완전히 제거하고, Gemini API의 출력물을 수정 없이 직접 저장하도록 변경했습니다. 또한, datetime 임포트 문을 수정하고 gemini_draft_generator.py 파일의 주석을 업데이트하여 코드의 명확성을 높였습니다. 이 변경은 저장된 드래프트 마크다운 파일 상단에 프롬트 블록이 생성되던 문제를 해결합니다. 이제 DraftSaver는 Gemini 출력을 그대로 저장하며, BlogAPIClient가 H1 제목과 첫 문단에서 메타데이터를 추출하는 방식으로 변경되었습니다. 작업은 2026년 1월 28일에 이루어졌습니다.
배경 및 목적
기존에는 DraftSaver가 Gemini API로부터 받은 내용을 저장하기 전에 _add_frontmatter() 메서드를 통해 자동으로 프롬트(YAML 형식의 메타데이터 블록)를 생성하여 파일 상단에 추가했습니다. 하지만 이 과정에서 의도치 않게 불필요한 프롬트가 생성되거나, 추후 메타데이터 추출 로직(예: BlogAPIClient에서 H1 제목과 첫 문단에서 추출)과 충돌하는 경우가 발생했습니다.
이러한 문제를 해결하기 위해, DraftSaver가 더 이상 프롬트를 생성하지 않고 Gemini API의 원본 출력을 그대로 저장하도록 변경하는 것이 이번 작업의 주된 목적입니다. 대신, 메타데이터 추출은 BlogAPIClient와 같은 다른 컴포넌트에서 담당하도록 역할을 분리하여, 각 컴포넌트의 책임과 역할을 명확히 하고 데이터 처리의 유연성을 높이고자 했습니다.
구현 내용
주요 변경사항은 DraftSaver 클래스에서 프롬트 관련 로직을 제거하는 것이었습니다.
policies/storage/draft_saver.py:_add_frontmatter()메서드를 완전히 삭제했습니다.save()메서드에서 Gemini API로부터 받은gemini_output을 직접self.draft_file.write()를 사용하여 저장하도록 변경했습니다. 더 이상 프롬트 생성을 위한 별도의 처리 과정이 없습니다.
core/gemini_draft_generator.py:from datetime import datetime으로 import 문을 수정했습니다. (이전 커밋 또는 다른 변경사항에서 관련 임포트 오류가 있었을 것으로 추정됩니다.)- 코드의 명확성을 높이기 위해 관련 주석을 업데이트했습니다.
변경된 파일 목록:
core/gemini_draft_generator.pypolicies/storage/draft_saver.py
코드 라인 수 변경:
정확한 라인 수 변경은 제공되지 않았으나, _add_frontmatter() 메서드 삭제 및 관련 로직 변경으로 인해 policies/storage/draft_saver.py 파일에서 상당수의 라인이 줄어들었을 것으로 예상됩니다.
핵심 코드 설명 (DraftSaver.save() 메서드 관련):
# 기존 방식 (가상)
# def save(self, gemini_output: str):
# frontmatter = self._add_frontmatter(gemini_output)
# self.draft_file.write(frontmatter)
# 변경 후 방식
def save(self, gemini_output: str):
# Gemini API 출력을 수정 없이 직접 저장
self.draft_file.write(gemini_output)
기술적 의사결정
이번 작업에서는 Gemini API의 출력물을 저장하는 방식에 대한 몇 가지 기술적 의사결정이 이루어졌습니다.
프롬트(Frontmatter) 생성 로직 제거:
DraftSaver에서 프롬트 생성을 담당하던_add_frontmatter()메서드를 완전히 제거했습니다.- 이유: 프롬트 생성을
DraftSaver의 책임으로 두는 것이 불필요한 중복 로직을 만들고, 메타데이터 추출 방식(H1, 첫 문단)과의 통합을 복잡하게 만들었기 때문입니다. 또한, Gemini API의 출력물을 그대로 저장하는 것이 더 단순하고 예측 가능한 동작을 제공합니다. - 다른 대안:
- 기존대로
DraftSaver에서 프롬트를 생성하되,BlogAPIClient의 메타데이터 추출 로직을 프롬트와 호환되도록 수정. - 프롬트 생성 로직을 별도의 유틸리티 함수로 분리하여
BlogAPIClient에서 필요시 호출.
- 기존대로
- 장단점 분석:
- 선택된 방식 (프롬트 생성 제거):
- 장점:
DraftSaver의 책임이 명확해지고,BlogAPIClient의 메타데이터 추출 방식이 단순해짐. Gemini API의 원본 데이터를 보존하기 용이함. - 단점:
BlogAPIClient에서 메타데이터를 추출하는 로직이 더 중요해지며, 해당 로직의 견고성이 요구됨.
- 장점:
- 대안 1 (호환 로직 수정):
- 장점: 기존의 프롬트 기반 메타데이터 추출 방식과의 호환성을 유지할 수 있음.
- 단점:
BlogAPIClient의 로직이 복잡해지고, 프롬트 형식 변경에 민감해질 수 있음.
- 대안 2 (별도 유틸리티):
- 장점: 프롬트 생성 로직의 재사용성을 높일 수 있음.
- 단점: 여전히
DraftSaver와BlogAPIClient간의 의존성 및 책임 분배 문제가 완전히 해결되지 않음.
- 선택된 방식 (프롬트 생성 제거):
- 이유: 프롬트 생성을
datetime임포트 문 수정:from datetime import datetime으로 수정되었습니다.- 이유: 코드에서
datetime객체를 사용할 때 필요한 정확한 임포트 문법을 따르기 위함입니다. 이전에는datetime클래스 자체를 직접 임포트하지 않았을 가능성이 있습니다.
- 이유: 코드에서
배운 점 및 개선점
이번 작업을 통해 두 가지 주요한 점을 배울 수 있었습니다.
- 책임 분리의 중요성:
DraftSaver와BlogAPIClient간의 역할을 명확히 분리함으로써, 각 컴포넌트가 자신의 핵심 기능에 집중할 수 있게 되었습니다.DraftSaver는 "저장"에,BlogAPIClient는 "메타데이터 추출"에 집중하도록 하는 것이 전체 시스템의 유지보수성과 확장성을 높이는 데 기여합니다. - 단순함의 가치: 불필요한 중간 단계를 제거하고 Gemini API의 출력을 직접 저장하는 방식은 코드베이스를 더 단순하고 이해하기 쉽게 만듭니다. 이는 버그 발생 가능성을 줄이고, 새로운 개발자가 프로젝트에 쉽게 적응할 수 있도록 돕습니다.
앞으로 개선할 점:
BlogAPIClient의 메타데이터 추출 로직이 H1 제목과 첫 문단에만 의존하고 있는데, 이 로직의 견고성을 더 강화해야 합니다. 예를 들어, 예상치 못한 형식의 제목이나 첫 문장이 나타날 경우에 대한 예외 처리나 대체 로직을 고려해야 합니다.- Gemini API의 출력물에 대한 보다 세밀한 검증 로직을 추가하여, 저장되는 데이터의 품질을 높이는 방안을 모색할 수 있습니다.
다음 단계 계획:
BlogAPIClient의 메타데이터 추출 로직에 대한 단위 테스트를 강화합니다.- 프로젝트 내 다른 컴포넌트에서
DraftSaver의 변경사항을 사용하는 데 문제가 없는지 통합 테스트를 진행합니다. - Gemini API 출력물의 유효성 검증을 위한 새로운 정책 또는 도구를 도입하는 것을 고려합니다.
참고 자료
- (없음 - 제공된 커밋 데이터에 명시된 참고 자료가 없습니다.)