개발 slecs

반복 생성 패턴을 구조적으로 분류하기

목차

지난주 brainstorm 시스템에서 흥미로운 문제를 마주쳤다. 사용자들이 아이디어를 생성할 때 같은 패턴의 제안이 자꾸 반복되는데, 그걸 처리하는 방식이 아쉬웠다. 단순히 코드 로직으로 "이건 반복이다/다르다"를 판단하고 있었는데, 실제론 시스템이 과거에 내린 의사결정의 맥락을 기억하지 못하고 있었던 게 근본 문제였다.

처음엔 당연히 코드로 해결했는데…

반복 생성을 막자고 하면, 보통은 다음처럼 풀었다:

# Before: 코드 레벨의 휴리스틱
if current_idea == last_idea:
    return "이미 본 아이디어입니다"

if similarity(current_idea, prev_ideas) > 0.85:
    return "비슷한 아이디어가 있습니다"

간단하고 직관적이다. 하지만 여기엔 숨은 문제가 있었다.

사용자 입장에서는 "왜 이 아이디어는 안 돼?"라는 의문이 남는다. 마지막 세션에서 본 아이디어일 수도, 2주 전에 검토했던 거일 수도 있다. 아무 맥락도 없으면 그냥 거절인 거다. 게다가 코드 로직만 보강하려면 계속 if 와 휴리스틱을 추가해야 한다. 그 결과는 스파게티 코드.

결정이력을 구조의 일부로 만들기

그래서 이번엔 과거 결정(decision history)을 명시적으로 컨텍스트로 주입하기로 했다. brainstorm 각 세션이 시작될 때, 이전 세션들에서 "이미 제안됐던 아이디어", "검토됐던 패턴", "각각 어떤 이유로 거절된 건지"를 다 불러온다. 그리고 핵심은 반복 판단을 "code_change"(알고리즘 수정)가 아니라 "structural"(분류 체계)로 분류한 것이다.

즉:

# After: 구조적 분류 기반
class BrainstormSession:
    def __init__(self, user_id):
        self.history_context = load_past_decisions(user_id)  # ← 결정이력
        self.structural_categories = {
            "seen_before": [],
            "variant_of_known": [],
            "new_direction": []
        }

    def classify_idea(self, idea):
        # 코드로 판단하지 않고, 과거 결정맥락과 비교해 분류
        category = self.history_context.find_closest_match(idea)
        return {
            "status": category,
            "reason": self.history_context.explain(category),
            "previous_context": self.history_context.get_context(category)
        }

사용자는 이제 "아, 이건 3주 전 세션에서 비슷하게 제안된 거고, 그때 시간이 없어서 보류된 거네" 같은 정보까지 받는다. 단순한 거절이 아니라 학습의 일부가 된다.

왜 "구조적" 선택이 중요했나

이렇게 설계를 바꾼 이유는 두 가지다.

첫째, 확장성. 코드 로직에는 한계가 있다. 새로운 휴리스틱이 필요하면 매번 함수를 수정해야 하고, 테스트도 늘어난다. 반면 분류 체계를 데이터로 구조화하면, 새로운 카테고리를 추가하는 건 설정 변경 수준이다. 코드 배포가 필요 없다.

둘째, 팀 커뮤니케이션. 코드에 박힌 로직은 다른 팀원이 "왜 이렇게 했나?"를 파악하기 어렵다. 하지만 "structural 분류는 이 네 가지 카테고리로 나뉜다"라고 문서화하면, 제품 팀과 데이터팀 모두가 한 언어로 대화할 수 있다. 후에 "이 분류가 사용자 반응을 반영 못 하는 것 같다"는 피드백이 와도, 분류 정의를 조정하는 것만으로 대응할 수 있다.

과거 결정이력을 "주입"한다는 것

학습경로(learning path)를 살린다는 건 정말 이것이다. 매 세션마다 "우리가 과거에 뭘 시도했고, 어떤 결론에 도달했는지"를 새로 상기하는 것. 마치 팀 회의에서 "지난주에 이 주제로 논의했는데…"라고 컨텍스트를 깔고 시작하는 것처럼.

이렇게 하면 반복이 줄어든다. 단순히 "같은 아이디어 차단"이 아니라, 사용자 본인이 이미 본 맥락을 알게 되므로, 자연스럽게 새로운 방향을 탐색하게 된다. 시스템이 강제하는 게 아니라, 사용자가 "아, 이미 이 방향은 나왔네"라고 스스로 깨닫는 거다.

코드 한 줄보다 구조 하나

이번 작업을 통해 다시 한 번 확인한 것: 특정 비즈니스 로직을 반복 처리해야 할 땐, 코드를 수정하기보다 분류 구조를 명확히 하는 게 먼저다. 코드는 그 구조를 구현하는 수단일 뿐이다.

회고할 때마다 이런 실수를 한다. "어, 또 예외 케이스가 생겼네?" 하면서 코드에 if 를 하나 더 붙이는 거. 하지만 정말 문제인 건 대부분 "분류 체계가 불완전했다"는 거다. 구조를 다시 그려놓고 보면, 코드는 놀랍도록 깔끔해진다.

다음엔 비슷한 상황에서 좀 더 일찍 "코드인가, 구조인가"를 판단하는 게 목표.

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

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

이어보기

댓글 0

첫 댓글 달아줘.