브레인스토밍 시스템에 SEO 실행 타입을 추가한 이유

brainstorm.py에 SEO 실행 유형을 추가했다. 이게 뭐 별 것 아닌 거 아닐까 싶을 수 있는데, 의외로 여기에 팀 리딩 관점에서 고민할 게 많다.

배경: 새로운 결정 실행 패턴의 등장

이 프로젝트의 브레인스토밍 시스템은 원래 여러 대안 중에서 최선의 선택지를 추천하는 용도였다. 근데 운영하면서 요청이 들어왔다. "이제 SEO 관련된 의사결정도 이 시스템에서 처리하고 싶어. 근데 SEO 관련 결정은 실행하는 방식이 지금까지와 달라."

처음엔 "그럼 별도 모듈 하나 더 만들까?" 싶었는데, 곰곰 생각해보니 이건 시스템 아키텍처 관점에서 중요한 갈림길이었다. 지금부터의 선택이 앞으로 팀이 얼마나 쉽게 새 기능을 추가할 수 있을지가 결정되는 순간이었거든.

실행 방식: 타입 기반 확장

결정은 단순했다. 기존 결정들과 별도 처리하기보다, 같은 구조 안에서 실행 타입(execution type)을 구분하는 방식을 선택했다.

구체적으로는 type=seo를 추가해서, SEO 관련 결정이 들어오면 그에 맞는 실행 흐름을 타는 식으로 했다.

회고: 타입 시스템으로 설계한 이유

팀 리딩 관점에서 이 선택을 정당화하려면 몇 가지를 생각해야 했다.

첫째, 코드 응집도. SEO 결정만 따로 모듈로 떨어져 나가면 어떻게 될까? 브레인스토밍 로직과 SEO 실행 로직이 두 군데 산재된다. 나중에 유지보수할 때 누군가는 brainstorm.py에서 뭔가 수정하고, 누군가는 seo_module.py에서 수정한다. 코드 리뷰도 복잡해진다. 반면 타입으로 구분하면 "결정을 실행하는 방식"이라는 개념이 한 곳에 모인다.

둘째, 다음 요청에 대한 대비. "SEO 결정도 처리해달라"는 요청이 여기서 끝날까? 아마 아닐 것 같다. "마케팅 결정도", "운영 결정도" 이런 식으로 계속 들어올 거다. 타입 시스템이 있으면 그때마다 "새로운 type을 추가하는" 패턴으로 일관성 있게 처리할 수 있다.

셋째, 팀원들의 온보딩. 새로운 팀원이 왔을 때 "이 시스템에 새로운 결정 유형을 추가하려면?"이라고 물으면, 답변이 간단하다. "type을 정의하고 처리 로직을 추가해." 만약 산재된 구조라면? "어, 여기도 있고 저기도 있고..." 이 정도면 혼란이다.

# 기존 (권장하지 않는 방식)
if decision_source == 'seo':
    # brainstorm.py 밖의 다른 곳에서 처리
    handle_seo_decision()

# 개선된 방식 (타입 기반)
def execute_decision(decision, execution_type='default'):
    if execution_type == 'seo':
        # seo-specific 처리
        pass
    elif execution_type == 'default':
        # 기본 처리
        pass

팀 입장에서의 우선순위

이런 결정을 할 때 내가 고민하는 부분은 다음과 같다:

• 당장의 비용 vs 미래의 이득: 지금 타입 시스템을 깔끔하게 만드는 데 시간을 좀 더 들이는 게 나을까, 아니면 일단 동작하는 코드부터 만들 것이 나을까? 팀의 업무 로드와 일정을 함께 고려해야 한다.
• 코드 일관성: 다른 부분에서도 비슷한 확장이 필요한가? 그렇다면 전사적으로 일관된 패턴을 써야 한다.
• 문서화와 커뮤니케이션: 새로운 팀원이나 코드 리뷰어가 "왜 이렇게 했는가"를 이해할 수 있도록 설명할 책임.

이번 경우엔 세 가지가 모두 정렬됐다. 현재 로드가 감당할 수 있는 선에서, 미래 요청에 대비할 수 있는 구조가, 팀 전체에 좋은 선례를 남길 수 있다고 판단했다.

🛒 이 글과 어울리는 추천 상품

• 사무의자 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.