[크래프톤정글/WIL] 1주차 회고: 컴퓨팅 사고와 완전 탐색, 아이디어의 범람과 코딩 구현력의 벽

코딩이 어려운 사람·2026년 10월 22일

WIL

목록 보기

1/8

소주제

1주차 학습 개요와 기술 스택: Python 기반 컴퓨팅 사고와 완전 탐색
내가 직면했던 현실과 한계: 아이디어의 범람과 코딩 구현력의 벽
핵심 기술 개념과 코드 분석: 재귀 호출 스택(Call Stack)과 시간복잡도(Big-O)
알고리즘 트러블슈팅: 단순 중첩 루프의 한계와 기저 조건(Base Case) 설계
협업과 소통의 성찰: 말이 아닌 작동하는 코드(Working Code)의 설득력
실행 가능한 액션 플랜: 빈 파일에서 시작하는 손근육 훈련
1주차 핵심 엔지니어링 Q&A 3선

1. 1주차 학습 개요와 기술 스택: Python 기반 컴퓨팅 사고와 완전 탐색

크래프톤 정글의 1주차는 프로그래밍 언어의 문법 숙달을 넘어, 복잡한 현실의 문제를 컴퓨터가 이해하고 연산할 수 있는 논리적 단위로 분해하는 컴퓨팅 사고(Computational Thinking)의 기초를 닦는 단계였습니다. Python 언어를 도구로 삼아 수학적 귀납법, 완전 탐색(Brute-force), 재귀(Recursion), 기본 정렬 알고리즘을 학습했습니다.

[컴퓨팅 사고와 문제 해결 파이프라인]

현실의 복잡한 요구사항
        │
        ▼ 1. 문제 추상화 (핵심 변수 및 조건 도출)
수학적 모델링 / 상태 공간 정의
        │
        ▼ 2. 시간복잡도 분석 (N의 크기에 따른 알고리즘 선택)
알고리즘 설계 (완전 탐색, 재귀, 정렬)
        │
        ▼ 3. 실제 코딩 구현 (Base Case 및 루프 제어)
작동 가능한 코드 (Working Code) & 테스트 통과

2. 내가 직면했던 현실과 한계: 아이디어의 범람과 코딩 구현력의 벽

"의견은 많이 냈지만 코딩 구현의 측면에서는 거의 못했다"

정글에 입소하여 첫 팀을 배정받고 마주한 첫 주차의 현실은 냉혹했습니다. 문제 분석 시간이나 팀 토론 시간에는 누구보다 적극적으로 가설을 세우고, "이 문제는 이렇게 접근하면 풀릴 것 같다", "이 방향으로 분기해야 한다"며 수많은 아이디어를 쏟아냈습니다.

하지만 토론을 마치고 빈 에디터를 띄워 혼자 코드를 타이핑하기 시작했을 때 커다란 벽에 부딪혔습니다. 머릿속에 맴도는 논리를 문법적으로 무결한 코드로 표현해 내지 못했고, 사소한 인덱스 에러(IndexError)나 조건문 실수로 인해 한두 시간씩 허비하기 일쑤였습니다. 결국 팀 단위로 문제를 해결하는 과정에서 정작 동작하는 코드로 기여하지 못했고, '말만 앞서고 실제 구현력이 뒷받침되지 못하는 사람'이라는 깊은 자괴감과 부끄러움을 겪었습니다.

3. 핵심 기술 개념과 코드 분석: 재귀 호출 스택(Call Stack)과 시간복잡도(Big-O)

3.1 재귀 호출의 물리적 본질과 스택 프레임

재귀(Recursion)는 단순한 함수 호출 반복이 아닙니다. 운영체제와 하드웨어 관점에서 함수가 호출될 때마다 CPU 스택 메모리에 활성화 레코드(스택 프레임: 지역 변수, 매개변수, 복귀 주소)가 아래 방향으로 누적되는 물리적 메모리 점유 과정입니다.

[재귀 호출 시 스택 프레임 누적 및 역순 반환 흐름]

호출 단계 (Push):
main() ──► factorial(3) ──► factorial(2) ──► factorial(1) [기저 조건 도달!]
                             (Stack Depth = 3)

반환 단계 (Pop & Compute):
factorial(1) = 1 반환 ──► factorial(2) = 2 * 1 = 2 ──► factorial(3) = 3 * 2 = 6 ──► main()

기저 조건(Base Case)의 필수성: 기저 조건이 누락되거나 도달할 수 없는 조건식으로 구성되면 스택 프레임이 무한히 쌓여 Python의 RecursionError: maximum recursion depth exceeded 또는 시스템 레벨의 Stack Overflow 예외를 발생시킵니다.
분할 정복(Divide and Conquer): 큰 문제를 동일한 형태의 더 작은 하위 문제로 분할하고, 기저 조건의 해를 바탕으로 원래 문제의 해를 합성하는 논리적 패턴을 확립했습니다.

3.2 시간복잡도(Big-O)의 수학적 의미

$O(1)$ : 입력 크기와 무관한 즉각적 메모리 오프셋 참조.
$O(N)$ : 입력 데이터 전체를 1회 순회하는 선형 탐색.
$O(N^2)$ : 이중 중첩 루프로 모든 쌍을 전수 조사하는 완전 탐색. $N = 10,000$ 일 때 연산 횟수가 $10^8$ (1억 번)에 달하여 통상 1초 제한을 초과합니다.

4. 알고리즘 트러블슈팅: 단순 중첩 루프의 한계와 기저 조건 설계

4.1 문제: 완전 탐색에서의 시간 초과(Time Limit Exceeded)

배열 내에서 특정 합을 만족하는 두 수의 인덱스를 찾는 문제에서 단순한 $O(N^2)$ 이중 루프를 작성했을 때, 대규모 테스트 데이터셋에서 시간 초과가 발생했습니다.

# [개선 전: O(N^2) 비효율적 중첩 루프]
def find_two_sum(nums, target):
    n = len(nums)
    for i in range(n):
        for j in range(i + 1, n):
            if nums[i] + nums[j] == target:
                return [i, j]
    return []

# [개선 후: 해시 테이블을 활용한 O(N) 최적화]
def find_two_sum_optimized(nums, target):
    seen = {}
    for idx, num in enumerate(nums):
        complement = target - num
        if complement in seen:
            return [seen[complement], idx]
        seen[num] = idx
    return []

개선 원리: 매 탐색마다 $O(N)$ 으로 루프를 도는 대신, 해시 테이블(Python 딕셔너리)을 활용하여 보수(Complement)의 존재 여부를 $O(1)$ 에 조회함으로써 전체 시간복잡도를 $O(N)$ 으로 최적화했습니다.

5. 협업과 소통의 성찰: 말이 아닌 작동하는 코드(Working Code)의 설득력

소프트웨어 엔지니어링의 세계에서 화려한 언변이나 추상적인 아이디어는 아무런 동작을 보장하지 않습니다. 컴퓨터는 사람의 말이 아니라 기계어와 소스코드만을 이해하며, 동료 엔지니어가 신뢰하는 것은 '테스트를 통과하고 버그 없이 작동하는 코드(Working Code)'뿐이라는 점을 배웠습니다.

의견을 내는 행위 자체는 긍정적이지만, 그 의견을 실제 코드로 구현하고 입증할 수 있는 '구현 체력'이 결여되어 있다면 팀에 실질적인 가치를 더할 수 없습니다. 1주차의 좌절은 제게 "말하기 전에 먼저 코드로 구현해 보는 엔지니어가 되자"는 강력한 채찍질이 되었습니다.

6. 실행 가능한 액션 플랜: 빈 파일에서 시작하는 손근육 훈련

기본 문제 백지 구현: 하루 최소 3개의 기본 알고리즘(이진 탐색, 팩토리얼 재귀, 퀵 정렬/병합 정렬)을 IDE 자동 완성이나 정답 코드를 보지 않고 빈 파일에서 처음부터 끝까지 혼자 작성하기.
손 코딩과 디버깅 분리: 코드를 작성하기 전 연습장에 변수의 상태 전이와 루프 종료 조건을 손으로 직접 시뮬레이션한 후 타이핑하기.
구현 시간 측정: 알고리즘 아이디어를 떠올린 시점부터 실제 코드로 완성하여 제출하기까지의 시간을 측정하고 점진적으로 단축하기.

7. 1주차 핵심 엔지니어링 Q&A 3선

Q1. 재귀 알고리즘에서 기저 조건(Base Case)이 누락되면 시스템 메모리에서 물리적으로 어떤 현상이 일어나는가?

답변: 기저 조건이 누락되면 함수가 자기 자신을 계속해서 호출하므로, 반환 주소, 매개변수, 지역 변수를 담은 스택 프레임(Stack Frame)이 프로세스의 유저 스택 영역에 무한정 누적됩니다. 스택 영역은 높은 주소에서 낮은 주소로 신장하므로, 결국 허용된 스택 경계를 넘어서거나 힙 영역을 침범하게 되어 운영체제로부터 세그멘테이션 폴트(Segmentation Fault) 또는 언어 런타임의 RecursionError 예외를 유발하고 프로세스가 강제 종료됩니다.

Q2. 시간복잡도 O(N^2) 알고리즘이 N = 100,000 환경에서 실무적으로 실행 불가능한 물리적 이유는?

답변: 현대 CPU는 통상 1초에 약 $10^8$ (1억) 회 내외의 기본 연산을 처리할 수 있습니다. $N = 100,000$ ( $10^5$ )일 때 $O(N^2)$ 알고리즘의 연산 횟수는 $(10^5)^2 = 10^{10}$ (100억) 회에 달합니다. 이는 단순 산술 계산으로도 수십 초 이상의 CPU 시간을 소모하며, 캐시 미스(Cache Miss)와 메모리 I/O 지연까지 감안하면 웹 서버나 실시간 시스템에서 타임아웃을 유발하여 실무 시스템에 적재할 수 없습니다.

Q3. 파이썬의 해시 테이블(dict)이 O(1) 조회를 달성하는 내부 메모리 원리는?

답변: 해시 테이블은 키(Key) 값을 해시 함수(Hash Function)에 통과시켜 정수형 해시 코드를 생성하고, 이를 배열의 버킷(Bucket) 인덱스로 직접 변환합니다. 키의 위치를 찾기 위해 배열 전체를 순회할 필요 없이 계산된 인덱스의 메모리 주소로 $O(1)$ 즉각 점프하여 데이터에 접근하므로 평균적인 조회, 삽입, 삭제 시간복잡도가 $O(1)$ 을 유지합니다.