브레인스토밍 모듈에 방어·성장 처방과 저장소 라우팅 구조를 도입한 이유

최근에 자동화 도구의 제안을 체계적으로 분류하고 라우팅하는 구조를 brainstorm.py에 추가했다. 단순해 보이지만, 이 작은 설계가 팀의 의사결정 과정에 꽤 유의미한 영향을 준다고 생각한다.

자동화 도구는 결국 "제안자"다

브레인스토밍 모듈의 역할을 생각해보면, 이건 팀을 위한 조력자다. 코드 리뷰에서 놓친 개선점, 기술 부채, 성능 최적화 기회, 새로운 기능 아이디어 — 이런 것들을 지속적으로 발굴하고 제시한다. 처음엔 이 제안들이 그냥 나열되곤 했다. 우선순위 없이, 성격도 제각각으로.

문제는 이렇게 뒤섞여 있으면, 팀이 그 제안을 소비하기가 어렵다는 것이다. "지금 이 제안을 반영해야 하나?" "다른 제안과 비교하면 상대적 가치가 뭔가?" 이런 질문에 쉽게 답할 수 없었다. 그래서 제안들을 일관된 프레임으로 분류하기로 했다.

방어와 성장: 두 가지 처방의 의도

처방 카탈로그에 "방어(defensive)"와 "성장(growth)" 두 가지 트랙을 만들었다.

이 구분이 무엇보다 중요한 이유는, 팀의 의사결정 맥락이 다르기 때문이다. 방어 처방은 "지금 안 하면 문제가 커질 것 같은가?"를 묻는 거고, 성장 처방은 "우리의 다음 단계에서 필요한가?"를 묻는 거다. 같은 우선순위 프로세스로 평가하기엔 성격이 너무 다르다.

타겟 저장소 라우팅: 영향 범위를 명시하기

코드 변경이 발생하면, 그것이 어느 저장소(bot 또는 site)를 대상으로 하는지를 라우팅하도록 했다. 같은 제안이라도:
- bot 타겟: 자동화 로직, 백그라운드 처리, 시스템 간 통신 관련
- site 타겟: 사용자 인터페이스, 클라이언트 동작, 직접 노출되는 부분

이 구분이 없으면, 제안을 받은 팀원이 "이게 어디에 영향을 미치는 거지?"를 매번 판단해야 한다. 작은 인지 부하지만, 매일 이런 제안들이 쌓이면 결국 추적 비용이 된다. 라우팅을 미리 정해두면, 담당자가 명확해지고, 영향 범위 예측도 수월해진다.

자동화 도구와 팀의 협력 방식을 설계한다는 것

이번 작업을 하면서 느낀 건, "자동화 도구를 만드는 것" = "팀과의 커뮤니케이션 프로토콜을 설계하는 것"이라는 점이다. 도구가 어떤 제안을 하든, 그것을 팀이 이해하고 실행 가능한 형태로 받아들일 수 있어야 한다.

처방 카탈로그의 이원화와 타겟 라우팅은 이런 인터페이스 설계의 작은 사례다. 제안을 "무엇인가(방어/성장)"와 "어디인가(bot/site)"로 구조화함으로써:

• 팀원이 제안을 빠르게 분류할 수 있다.
• 우선순위 의사결정이 더 구체화된다.
• 관련된 담당자를 쉽게 찾을 수 있다.
• 자동화 도구가 "무분별하게 제안하는 기계"가 아니라 "팀의 맥락을 이해하는 조력자"로 보인다.

복잡한 시스템을 여러 저장소에서 운영하면서도, 자동화의 편의성과 팀의 명확한 이해 사이의 균형을 맞추는 게 항상 쉽진 않다. 이번 설계가 그 균형을 조금 더 잘 맞출 수 있게 해주지 않을까 싶다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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