📌 [알고리즘 회고] 구현 주도형 사고에서 설계 주도형 사고로의 전환
알고리즘 문제를 풀다 보면, 머릿속에 떠오르는 자료구조를 일단 선언해 두고 로직을 끼워 맞추려는 습관이 있습니다. 특히 백준에서 단편적인 알고리즘을 풀 때와 달리, 소프트웨어 마에스트로(SoMa)나 기업 코테처럼 요구사항이 복잡한 시뮬레이션 문제에서는 이러한 '구현 주도형 사고'가 뼈아픈 패착이 되곤 합니다.
오늘은 복잡한 문제를 만났을 때 꼬이지 않고 가장 효율적으로 정답에 도달하기 위한 '알고리즘 설계 및 구현 템플릿'을 정립하고 회고해 봅니다.
💡 As-Is: 구현 주도형 사고의 함정
과거의 저는 문제를 읽자마자 e = [[E]*S, [E]*B, ...] 처럼 데이터 저장 공간부터 만들려 했습니다.
- 문제점: 로직의 '생명주기(Lifecycle)'를 고민하기 전에 데이터 구조를 픽스해버리면, 이후 추가되는 복잡한 조건(예: 특정 개체의 일시적인 기억 유지)을 처리하기 위해 거대한 2차원 배열을 도입하는 등 코드가 데이터 구조에 갇혀 불필요하게 무거워지는 현상이 발생합니다.
🚀 To-Be: 설계 주도형 사고 프로세스 정립
코딩 테스트 고수들의 접근법을 분석하여, 철저히 규칙과 생명주기를 먼저 정의하는 프로세스를 세웠습니다.
1. 설계 단계 (Design)
자료구조를 떠올리는 것은 무조건 3단계 이후로 미룹니다.
1. 추상화: 복잡한 문제 지문에서 핵심 행동(Action) 규칙만 뽑아냅니다.
2. 생명주기 설계: 데이터가 유지되어야 하는 스코프(전체 라운드 vs 단일 매칭 루프)를 정의하여 글로벌 상태를 최소화합니다.
3. 자료구조 선택: 비로소 로직을 담을 그릇을 정합니다. (예: 2차원 공간이 필요해 보여도, 1차원 리스트 셔플 후 인덱스를 수학적으로 치환하여 으로 최적화)
4. 예외 처리 구상: 경계값(Edge Cases) 방어 로직을 미리 세웁니다.
5. 모듈화: 핵심 기능을 독립적인 함수로 쪼갭니다.
2. 구현 단계 (Implementation)
설계가 끝났다면 타이핑은 철저히 하향식 뼈대 구축 -> 상향식 조립으로 진행합니다.
solution,play_game,update등 스켈레톤(껍데기) 코드를 먼저 작성해 길을 잃지 않게 세팅합니다.- 메인 루프를 짜기 전, 가장 작은 단위의 부품(함수)부터 구현하고 테스트하여 버그를 사전에 차단합니다.
- 조립이 끝나면 반드시 손으로 변수를 추적하는 Dry Run을 거칩니다.
🎯 마치며
"규칙과 생명주기를 먼저 완벽히 정의하고, 그 로직을 가장 가볍게 담을 수 있는 자료구조를 나중에 선택한다."
이 패러다임의 전환은 단순히 코드를 빨리 짜는 것을 넘어, 유지보수가 용이하고 테스트 가능한 클린 코드(Clean Code)를 작성하는 밑거름이 될 것입니다. 앞으로의 모든 코딩 테스트 훈련은 이 SOP를 기반으로 진행할 예정입니다.
