← 개발 로그 목록

LearningCollector: 자동 모드에서 신규 아이템만 처리하도록 개선

/ 7분 분량 / 개발 로그
#개발#프로젝트

이번 커밋은 'LearningCollector' 프로젝트의 자동 모드 동작 방식을 개선하여, 이미 처리 중이거나 보류된 아이템은 건너뛰고 오직 새로 수집된 아이템만 처리하도록 수정했습니다. 이로써 불필요한 중복 처리를 방지하고 시스템의 효율성을 높였습니다.

LearningCollector: 자동 모드에서 신규 아이템만 처리하도록 개선

이번 커밋은 'LearningCollector' 프로젝트의 자동 모드 동작 방식을 개선하여, 이미 처리 중이거나 보류된 아이템은 건너뛰고 오직 새로 수집된 아이템만 처리하도록 수정했습니다. 이로써 불필요한 중복 처리를 방지하고 시스템의 효율성을 높였습니다.

요약

이번 커밋에서는 core/orchestrator.py 파일을 수정하여 자동 모드(cron)에서 신규로 수집된 JSON 데이터만 처리하도록 변경했습니다. 기존에는 보류(pending) 상태의 아이템도 처리 대상에 포함될 수 있었으나, 이제는 사용자 의도에 따라 명시적으로 처리하지 않는 이상 보류 아이템은 자동 모드에서 건너뛰게 됩니다. 이 변경은 2026년 1월 31일에 적용되었으며, Git 커밋 해시는 b673c3fd2ff2fb2726dff18e643216e2440f13d2 입니다.

배경 및 목적

'LearningCollector' 프로젝트는 다양한 소스로부터 정보를 수집하고 이를 자동으로 처리하는 것을 목표로 합니다. 특히 자동 모드(cron job)를 통해 주기적으로 새로운 데이터를 처리하도록 설계되었는데, 기존에는 수집된 데이터 중 '보류(pending)' 상태인 아이템도 자동 모드에서 처리될 수 있는 여지가 있었습니다.

이러한 상황은 다음과 같은 문제를 야기할 수 있습니다.

  • 불필요한 재처리: 사용자가 의도적으로 보류한 아이템을 자동 모드에서 다시 처리하는 것은 비효율적입니다.
  • 예측 불가능한 동작: 자동 모드의 동작이 사용자의 명시적인 보류 의사를 무시하고 진행될 수 있어 혼란을 줄 수 있습니다.

따라서 이번 작업의 목적은 자동 모드가 오직 새롭게 수집된 (newly collected) 아이템에만 집중하도록 하여, 사용자 의도를 존중하고 시스템의 안정성과 효율성을 높이는 것입니다. 보류된 아이템의 처리는 오직 대화형(interactive) 모드에서만 이루어지도록 명확히 구분하고자 했습니다.

구현 내용

이번 변경은 core/orchestrator.py 파일의 일부 로직 수정으로 이루어졌습니다.

변경 파일:

  • core/orchestrator.py

코드 변경 규모:

  • 총 추가 라인 수: N/A (정확한 라인 수 정보 부재)
  • 총 삭제 라인 수: N/A (정확한 라인 수 정보 부재)
  • (참고: 제공된 데이터에 정확한 추가/삭제 라인 수 및 상세 diff가 없어 구체적인 라인 수를 명시하기 어렵습니다. 실제 코드 변경은 해당 파일 내의 조건문 로직 수정일 것으로 추정됩니다.)

핵심 코드 설명:

이번 변경의 핵심은 자동 모드(cron)에서 아이템을 처리할 때, 해당 아이템이 'new' 상태인지 'pending' 상태인지를 구분하여 'new' 아이템만 선택적으로 처리하도록 로직을 수정한 것입니다.

예를 들어, 기존 코드에서는 다음과 유사한 방식으로 아이템을 처리했을 수 있습니다.

# 기존 코드 (가정)
for item in collected_items:
    if item.status in ["new", "pending"]: # pending 아이템도 처리 대상
        process(item)

이번 변경 후에는 다음과 같이 'new' 아이템만 처리하도록 변경되었을 것입니다.

# 수정된 코드 (가정)
for item in collected_items:
    if item.status == "new": # 오직 'new' 아이템만 처리
        process(item)

이러한 변경을 통해 자동 모드는 새로 수집된 데이터에만 집중하게 됩니다.

기술적 의사결정

이번 변경에서 특별한 새로운 라이브러리나 프레임워크의 도입은 없었으며, 기존 Python 로직의 개선을 통해 이루어졌습니다.

선택: 기존 Python 로직을 활용하여 조건문 수정

이유:

  • 단순함: 현재 프로젝트의 구조에서 복잡한 변경 없이 기존 로직을 수정하는 것이 가장 빠르고 효율적이었습니다.
  • 명확성: 'new'와 'pending' 상태를 명확히 구분하여 코드의 가독성을 높이고, 자동 모드의 동작을 더욱 명확하게 만들 수 있었습니다.

다른 대안:

  • 상태 플래그 추가: 'pending' 상태에 대한 별도의 플래그를 추가하여 관리하는 방안도 고려할 수 있었으나, 이는 코드 복잡성을 증가시킬 수 있습니다.
  • 별도 큐 사용: 'pending' 아이템을 별도의 큐로 분리하여 관리하는 방법도 있었지만, 현재 프로젝트 규모에서는 과도한 설계일 수 있습니다.

장단점 분석:

  • 장점:
    • 구현이 간단하고 빠르게 적용 가능합니다.
    • 자동 모드의 동작을 더욱 예측 가능하고 명확하게 만듭니다.
    • 코드 유지보수성을 향상시킵니다.
  • 단점:
    • 'pending' 상태 아이템 처리가 자동 모드에서 완전히 배제되므로, 사용자가 대화형 모드를 사용해야만 'pending' 상태를 관리할 수 있습니다. (이는 설계 의도에 부합하므로 큰 단점으로 보기 어렵습니다.)

배운 점 및 개선점

이번 작업을 통해 'LearningCollector' 프로젝트의 자동 모드 동작 방식을 명확히 하고, 사용자 의도를 더 잘 반영하는 방법에 대해 다시 한번 고민할 수 있었습니다.

배운 점:

  • 자동화된 프로세스에서는 각 상태(new, pending 등)를 명확하게 정의하고, 각 모드(자동 vs 대화형)에서의 동작 규칙을 명확히 하는 것이 중요하다는 것을 배웠습니다.
  • 작은 코드 변경이라도 시스템 전체의 예측 가능성과 안정성에 큰 영향을 미칠 수 있음을 확인했습니다.

개선점 및 다음 단계 계획:

  • 보류 아이템 처리 로직 명확화: 대화형 모드에서 'pending' 아이템을 처리하는 로직을 더욱 견고하게 만들 필요가 있습니다. 현재는 보류된 아이템을 어떻게 다시 처리할 것인지에 대한 명확한 사용자 인터페이스나 안내가 필요할 수 있습니다.
  • 상태 변경 플로우 문서화: 'new' -> 'processing' -> 'completed' / 'failed' 및 'pending' 상태로의 전환 등에 대한 플로우를 명확하게 문서화하여 팀원들이 쉽게 이해할 수 있도록 해야 합니다.
  • 테스트 강화: 자동 모드와 대화형 모드에서의 다양한 상태 전환에 대한 테스트 케이스를 추가하여, 향후 유사한 변경 시 발생할 수 있는 문제를 사전에 방지해야 합니다.

참고 자료