📌 [알고리즘 회고] 스켈레톤 코드 완성 후, 도대체 뭐부터 짜야 할까? (Bottom-Up 조립의 정량적 기준)

코딩 테스트에서 복잡한 시뮬레이션 문제를 풀기 위해 '설계 주도형 사고(SOP)'를 도입하여 5개의 스켈레톤(뼈대) 코드를 분리하는 데 성공했습니다.
하지만 빈 껍데기뿐인 함수들을 마주하고 나니 새로운 고민이 생겼습니다.

"상향식(Bottom-Up)으로 가장 작은 조각부터 조립하라는데... 도대체 어떤 함수가 '가장 작고 만만한' 함수인지 단번에 어떻게 알지?"

오늘은 막연하게 "논리가 명확한 것부터 짠다"는 인간의 주관적인 감각을, 컴퓨터가 이해하는 객관적이고 정량적인 소프트웨어 공학 지표로 번역하여 '구현 우선순위'를 정하는 방법을 회고해 봅니다.

---

🤖 컴퓨터가 '만만한 함수'를 찾는 4가지 정량적 지표

컴파일러나 코드 분석 도구가 함수의 복잡도를 채점할 때 사용하는 기준을 우리의 코딩 테스트 전략에 그대로 적용해 보았습니다. 점수가 낮을수록(단순할수록) 1순위로 구현해야 할 타겟이 됩니다.

1. 의존성 (Dependencies / Out-degree = 0)

• 인간의 언어: "다른 함수 신경 안 쓰고 이것만 집중해서 짜면 되는 것"
• 컴퓨터의 언어: 함수 호출 그래프(Call Graph)를 그렸을 때, 외부의 다른 커스텀 함수를 단 하나도 부르지 않는 리프 노드(Leaf Node)인가?
• 적용: 내가 만든 다른 함수를 호출한다면 우선순위에서 배제합니다.

2. 순수 함수 여부 (Pure Function & Side Effects)

• 인간의 언어: "원본 데이터를 망가뜨릴 걱정 없이 안전한 것"
• 컴퓨터의 언어: 원본 배열을 훼손(pop, append 등)하거나 전역 상태를 변경하지 않고, 주어진 입력값만으로 독립적인 결괏값(return)만 뱉어내는가?
• 적용: 부수 효과(Side Effect)가 없는 순수 함수일수록 먼저 구현하여 사이드 이펙트 버그를 예방합니다.

3. 순환 복잡도 (Cyclomatic Complexity)

• 인간의 언어: "경우의 수가 적고 흐름이 뻔한 것"
• 컴퓨터의 언어: 함수 내부에 분기문(if/else)이나 반복문(for/while)이 몇 개인가? 시간 복잡도가 $O(1)$인가, 아니면 $O(N)$ 이상인가?
• 적용: 제어문의 뎁스(Depth)가 얕고 $O(1)$로 끝나는 연산을 최우선으로 둡니다.

4. 파라미터와 반환값의 단순성 (Arity)

• 인간의 언어: "들어오고 나가는 데이터가 단순한 것"
• 컴퓨터의 언어: 매개변수의 개수가 적고, 주고받는 타입이 복잡한 2차원 배열 객체가 아닌 단순 원시 타입(정수, 불리언 등)인가?

---

🎯 실전 적용: 이기적 유전자 시뮬레이션

위의 4가지 지표를 제가 짠 스켈레톤 코드에 적용하여 구현 우선순위(티어)를 매겨보았습니다.

• solution, play_game: 외부 함수를 호출하므로 일단 대기. (의존성 발생)
• update_populations: 의존성은 없지만, 거대한 2차원 배열을 순회하며 요소를 삭제/추가하므로 $O(N)$의 복잡도와 부수 효과가 발생함. (후순위)
• match: 의존성은 없지만, 원본 리스트를 shuffle하고 pop으로 훼손시킴. (중순위)
• get_species & action_by_entity 🏆 (1순위 당첨!)
  • 의존성 0 (다른 함수 호출 안 함)
  • 순수 함수 (입력값만으로 계산하여 반환, 사이드 이펙트 없음)
  • 복잡도 $O(1)$ (단순 빼기 연산 및 if문)
  • 단순한 입출력 (정수형 데이터)

💡 마치며

코딩 테스트에서 뼈대를 세우고 나면 마음이 급해져 메인 로직(solution)부터 손을 대거나, 가장 복잡한 배열 조작 함수부터 건드리다가 멘탈이 나가는 경우가 많았습니다.

하지만 "의존성이 없는 $O(1)$의 순수 함수부터 조립한다"는 명확한 엔지니어링 기준을 세우고 나니, 구현의 시작점에서의 망설임이 완전히 사라졌습니다. 이제 1순위로 선정된 get_species 함수부터 가벼운 마음으로 살을 붙여보려 합니다.