몽키D버깅’s 개발일지

1. 7주를 끝까지 완주한 나에게

7주라는 시간이 아주 길다고 말하기는 어렵지만, 매주 꾸준히 문제를 풀고 기록하고 회고하는 과정은 생각보다 쉽지 않았습니다. 처음에는 “이번에는 끝까지 할 수 있을까?”라는 의심도 있었고, 알고리즘 문제를 볼 때마다 막막함이 먼저 들기도 했습니다.

그래도 결국 7주를 끝까지 완주했습니다.
중간에 속도가 느려진 날도 있었고, 문제 하나에 오래 막혀서 답답했던 날도 있었지만, 포기하지 않고 다시 돌아와서 문제를 붙잡았다는 점이 가장 의미 있었습니다.

이번 챌린지는 단순히 코딩테스트 문제를 몇 개 더 푼 경험이 아니라, 꾸준히 공부하는 루틴을 만드는 훈련에 가까웠습니다. 그래서 완주한 지금의 저에게 가장 먼저 해주고 싶은 말은 이것입니다.

“완벽하지 않아도 끝까지 해낸 것만으로 충분히 잘했다.”

2. 시작할 때와 비교해 가장 달라진 점

처음에는 문제를 보면 바로 “어떤 알고리즘을 써야 하지?”부터 생각했습니다. DFS인지, BFS인지, 정렬인지, 완전탐색인지부터 맞히려고 했고, 알고리즘 이름을 떠올리지 못하면 풀이 자체가 막히는 경우가 많았습니다.

하지만 7주 동안 문제를 풀면서 조금씩 접근 방식이 달라졌습니다.

이제는 먼저 문제를 작은 단위로 나누어 봅니다.

• 입력 크기가 어느 정도인지
• 모든 경우를 확인해도 되는지
• 반복되는 상태가 있는지
• 좌표 이동이 필요한지
• 방문 처리가 필요한지
• 단순 구현으로 해결 가능한지

이런 식으로 문제를 분해하고 나니, 무조건 어려운 알고리즘을 떠올리기보다 현재 문제에 필요한 최소한의 방법을 찾는 데 집중하게 되었습니다.

가장 뿌듯했던 순간은 예전에는 막막하게 느껴졌던 DFS/BFS 유형을 다시 풀었을 때였습니다. 처음에는 2차원 배열에서 방향을 이동하고, 방문 체크를 하고, 조건을 분기하는 것만으로도 헷갈렸습니다. 그런데 반복해서 풀다 보니 어느 순간 dx, dy, visited, queue 또는 재귀 구조가 자연스럽게 떠올랐습니다.

그 순간 “아, 그래도 내가 조금씩 늘고 있구나”라는 생각이 들었습니다.

3. 중간에 그만두고 싶었던 고비

솔직히 중간에 그만두고 싶었던 순간도 있었습니다. 특히 문제를 풀었는데 계속 틀리거나, 풀이를 봐도 바로 이해되지 않을 때가 가장 힘들었습니다. 하루하루 해야 할 일도 있는데 코딩테스트 공부까지 이어가려니 부담이 생기기도 했습니다.

그때 저에게 도움이 되었던 방법은 목표를 낮추는 것이었습니다.

“오늘 반드시 어려운 문제를 풀어야 한다”가 아니라,
“오늘은 한 문제라도 다시 보고, 왜 틀렸는지만 정리하자”로 기준을 낮췄습니다.

또 하나 도움이 되었던 것은 디버깅 루틴이었습니다. 문제를 풀다가 값이 예상과 다르게 나오면 무작정 코드를 갈아엎기보다, 필요한 위치에 출력문을 넣어 현재 상태를 확인했습니다. 제출 전에는 디버깅 출력을 쉽게 끌 수 있도록 관리하면서, 어디서 로직이 꼬였는지 빠르게 찾으려고 했습니다.

작은 루틴이 생기니 문제를 틀렸을 때도 덜 무너졌습니다.
틀린 문제를 “나는 못한다”의 증거로 받아들이기보다, “아직 확인하지 못한 조건이 있다”는 식으로 바라보게 되었습니다.

4. 앞으로의 코테 학습 계획

7주 챌린지는 끝났지만, 코딩테스트 공부는 여기서 멈추지 않으려고 합니다. 앞으로는 문제 수를 무작정 늘리기보다, 제가 자주 약해지는 유형을 중심으로 반복 학습할 계획입니다.

우선 DFS/BFS, 완전탐색, 시뮬레이션, 정렬, 자료구조 유형을 꾸준히 복습하려고 합니다. 특히 한 번 풀었던 문제를 다시 풀 때, 예전 풀이를 그대로 외우는 것이 아니라 “왜 이 방식이 가능한지”를 설명할 수 있는지를 기준으로 삼으려고 합니다.

앞으로의 학습 계획은 다음과 같습니다.

1. 일주일에 최소 3회 이상 문제 풀이 유지하기
2. 틀린 문제는 북마크하거나 따로 기록하기
3. 다시 풀 때는 풀이를 보기 전에 접근 방법부터 직접 정리하기
4. 자주 틀리는 조건문, 인덱스 범위, 방문 처리 실수를 체크리스트화하기
5. 쉬운 문제라도 풀이 과정을 말로 설명하는 연습하기

코딩테스트는 단기간에 실력이 확 늘기보다는, 틀린 문제를 다시 마주하는 과정에서 조금씩 실력이 쌓이는 것 같습니다. 그래서 앞으로도 급하게 많은 문제를 푸는 것보다, 꾸준히 다시 풀 수 있는 루틴을 만드는 데 집중하려고 합니다.

5. 코드트리에 바라는 점과 운영진에게 하고 싶은 말

코드트리 챌린지를 하면서 좋았던 점은 학습 흐름을 계속 이어갈 수 있도록 동기부여가 된다는 점이었습니다. 혼자 공부하면 하루 이틀 미루다가 흐름이 끊기기 쉬운데, 챌린지라는 구조가 있으니 다시 돌아와서 문제를 풀게 되었습니다.

또한 문제를 풀고 끝나는 것이 아니라, 블로그 회고를 작성하면서 내가 무엇을 어려워했고 어떤 방식으로 극복했는지 정리할 수 있었습니다. 이 과정이 단순한 문제 풀이보다 더 오래 남는 학습이 되었다고 느꼈습니다.

운영진분들께는 7주 동안 꾸준히 학습할 수 있는 계기를 만들어주셔서 감사하다는 말을 전하고 싶습니다. 앞으로도 학습자가 자신의 약점을 더 쉽게 확인할 수 있도록 유형별 성장 리포트나 오답 복습 루틴을 더 세분화해서 제공해주면 좋을 것 같습니다.

6. AI 시대에도 알고리즘을 공부해야 하는 이유

요즘은 AI가 코드를 빠르게 작성해주고, 모르는 문법이나 구현 방식도 쉽게 알려줍니다. 그래서 “이제 알고리즘 공부가 꼭 필요할까?”라는 생각을 할 수도 있습니다.

하지만 7주 동안 공부하면서 느낀 점은, AI가 코드를 도와줄 수는 있어도 문제를 이해하고 판단하는 힘까지 대신해주지는 않는다는 것입니다.

알고리즘 공부는 단순히 코딩테스트를 통과하기 위한 공부만은 아니라고 생각합니다. 문제를 작은 단위로 나누고, 조건을 빠뜨리지 않고, 시간 복잡도를 고려하고, 예외 상황을 점검하는 훈련입니다. 이 능력은 실제 개발에서도 그대로 이어집니다.

AI가 제안한 코드가 맞는지 검증하려면 결국 개발자가 문제의 구조를 이해하고 있어야 합니다.
AI의 도움을 잘 활용하기 위해서라도, 기본기가 더 중요해졌다고 느낍니다.

그래서 앞으로도 알고리즘 공부를 완전히 놓지 않으려고 합니다. 빠르게 정답만 맞히는 공부가 아니라, 문제를 읽고 구조화하고 검증하는 힘을 기르는 공부로 이어가겠습니다.

7. 마무리

이번 7주 챌린지는 저에게 “꾸준함도 실력이다”라는 것을 알려준 시간이었습니다. 매번 완벽하게 풀지는 못했지만, 막히면 다시 보고, 틀리면 고치고, 어려우면 기록하면서 끝까지 완주했습니다.

앞으로도 코딩테스트 공부를 할 때 이번 7주의 경험을 기억하려고 합니다.
중요한 것은 한 번에 잘하는 것이 아니라, 포기하지 않고 다시 돌아오는 것이라고 생각합니다.

7주 동안 달려온 나에게 다시 한 번 말해주고 싶습니다.

“끝까지 해냈으니, 다음 단계도 충분히 해낼 수 있다.”

https://www.codetree.ai/ko

알고리즘 문제를 풀다 보면 2차원 맵을 탐색하는 문제가 자주 등장합니다.
대표적으로 미로 찾기, 연결된 영역 개수 세기, 바이러스 확산, 사람 이동 시뮬레이션, 격자 위 최단 거리 문제 등이 있습니다.

이때 가장 많이 사용하는 알고리즘이 DFS와 BFS입니다.
처음에는 둘 다 “상하좌우로 이동하면서 맵을 탐색하는 알고리즘”처럼 보이지만, 실제 문제를 풀다 보면 두 알고리즘의 목적과 사용 상황이 다르다는 것을 알 수 있습니다.

이번 글에서는 코드트리 문제를 풀면서 정리한 DFS와 BFS의 차이, 방문 처리의 중요성, 그리고 여러 대상이 매 턴 이동할 때 동시 이동과 순차 이동을 구분하는 방법을 정리해보겠습니다.

코드트리 문제는 아래 링크에서 직접 풀어볼 수 있습니다.

https://www.codetree.ai/ko

1. DFS와 BFS를 쉽게 이해하기

DFS는 한 방향으로 갈 수 있는 곳까지 깊게 들어간 뒤, 더 이상 갈 곳이 없으면 다시 되돌아오는 방식입니다.

예를 들어 2차원 맵에서 현재 위치를 기준으로 상하좌우 이동이 가능하다고 하면, DFS는 하나의 방향을 선택한 뒤 계속 안쪽으로 들어갑니다. 그러다가 더 이상 이동할 수 없으면 이전 위치로 돌아와 다른 방향을 탐색합니다.

반면 BFS는 현재 위치에서 가까운 칸부터 차례대로 넓게 탐색하는 방식입니다.

시작점에서 거리가 1인 칸을 먼저 확인하고, 그다음 거리가 2인 칸, 그다음 거리가 3인 칸을 확인합니다. 그래서 BFS는 최단 거리나 최소 이동 횟수를 구하는 문제에 자주 사용됩니다.

개인적으로는 다음 기준으로 먼저 생각하면 문제 접근이 쉬웠습니다.

• 연결된 영역 전체를 확인해야 한다면 DFS
• 몇 번 만에 도착하는지, 몇 턴 후 퍼지는지 구해야 한다면 BFS

2. 2차원 맵 순회 기본 구조

2차원 맵 문제에서는 보통 dx, dy 배열을 만들어 상하좌우 이동을 처리합니다.

dx = [-1, 1, 0, 0]
dy = [0, 0, -1, 1]

def in_range(x, y):
    return 0 <= x < n and 0 <= y < m

여기서 x는 행, y는 열로 두고 끝까지 일관성 있게 사용하는 것이 중요합니다.

3. DFS 핵심 로직

DFS는 재귀를 사용하면 간단하게 구현할 수 있습니다.

def dfs(x, y):
    visited[x][y] = True

    for i in range(4):
        nx = x + dx[i]
        ny = y + dy[i]

        if not in_range(nx, ny):
            continue

        if visited[nx][ny]:
            continue

        if board[nx][ny] == 0:
            continue

        dfs(nx, ny)

DFS에서는 현재 칸에 들어온 순간 방문 처리를 하고, 상하좌우를 확인하면서 이동 가능한 칸이면 다시 DFS를 호출합니다.

이 방식은 연결된 영역을 모두 탐색할 때 유용합니다.
예를 들어 1로 연결된 영역의 개수를 세거나, 특정 영역의 크기를 구하는 문제에서 자주 사용됩니다.

4. BFS 핵심 로직

BFS는 큐를 사용합니다.

from collections import deque

def bfs(x, y):
    q = deque()
    q.append((x, y))
    visited[x][y] = True

    while q:
        x, y = q.popleft()

        for i in range(4):
            nx = x + dx[i]
            ny = y + dy[i]

            if not in_range(nx, ny):
                continue

            if visited[nx][ny]:
                continue

            if board[nx][ny] == 0:
                continue

            visited[nx][ny] = True
            q.append((nx, ny))

BFS는 시작점에서 가까운 칸부터 순서대로 탐색합니다.
따라서 미로에서 목적지까지의 최단 거리, 바이러스가 몇 초 후 퍼지는지, 불이 몇 턴 후 도달하는지 같은 문제에 적합합니다.

5. 방문 처리가 중요한 이유

2차원 맵 탐색에서 가장 중요한 부분 중 하나는 방문 처리입니다.

방문 처리를 하지 않으면 같은 칸을 계속 반복해서 방문할 수 있습니다.
특히 상하좌우 이동이 가능한 문제에서는 현재 칸에서 다음 칸으로 이동한 뒤, 다시 이전 칸으로 돌아오는 상황이 쉽게 발생합니다.

예를 들어 A 칸에서 B 칸으로 이동할 수 있고, B 칸에서 다시 A 칸으로 이동할 수 있다면 방문 처리가 없을 경우 무한 반복이 발생할 수 있습니다.

BFS에서는 보통 큐에 넣는 순간 방문 처리를 하는 것이 안전합니다.

visited[nx][ny] = True
q.append((nx, ny))

만약 큐에서 꺼낼 때 방문 처리하면, 같은 칸이 큐에 여러 번 들어갈 수 있습니다.
그러면 불필요한 연산이 늘어나고, 최단 거리 문제에서는 거리 계산이 꼬일 수 있습니다.

DFS에서도 마찬가지로 함수에 들어온 직후 방문 처리하는 것이 일반적입니다.

def dfs(x, y):
    visited[x][y] = True

제가 자주 했던 실수는 방문 처리를 늦게 하거나, 이동 조건을 확인하기 전에 배열에 접근하는 것이었습니다.
그래서 이제는 다음 순서를 습관처럼 확인하려고 합니다.

if not in_range(nx, ny):
    continue

if visited[nx][ny]:
    continue

if board[nx][ny] == 0:
    continue

이 순서를 지키면 인덱스 에러와 중복 방문 실수를 줄일 수 있습니다.

6. 동시 이동과 순차 이동의 차이

2차원 맵 시뮬레이션 문제에서는 DFS/BFS만큼 중요한 개념이 있습니다.
바로 여러 대상이 매 턴 이동할 때, 동시에 이동하는지 순차적으로 이동하는지입니다.

문제에서 “모든 사람이 한 칸씩 이동한다”, “모든 바이러스가 동시에 퍼진다”, “매 턴마다 전체가 이동한다”처럼 표현되어 있다면 동시 이동일 가능성이 높습니다.

반대로 “번호가 작은 사람부터 이동한다”, “위에서 아래로 차례대로 처리한다”, “입력 순서대로 이동한다”처럼 순서가 명시되어 있다면 순차 이동일 가능성이 높습니다.

7. 동시에 이동하는 경우

동시 이동은 현재 턴의 상태를 기준으로 모든 이동 결과를 계산한 뒤, 마지막에 한 번에 반영하는 방식입니다.

즉, 한 대상이 먼저 이동했다고 해서 그 결과가 같은 턴의 다른 대상에게 바로 영향을 주면 안 됩니다.

next_board = [[0] * m for _ in range(n)]

for x in range(n):
    for y in range(m):
        if board[x][y] == 1:
            nx, ny = move(x, y)
            next_board[nx][ny] = 1

board = next_board

이 방식은 바이러스 확산, 미세먼지 확산, 여러 객체의 동시 이동 문제에서 자주 사용됩니다.

동시 이동 문제에서 기존 board를 바로 수정하면, 같은 턴 안에서 먼저 이동한 결과가 뒤에 처리되는 대상에게 영향을 줄 수 있습니다.
그러면 문제에서 요구한 “동시에 이동”과 다른 결과가 나올 수 있습니다.

⸻

8. 순차적으로 이동하는 경우

순차 이동은 앞에서 이동한 결과가 바로 다음 대상에게 영향을 줍니다.

예를 들어 1번 사람이 먼저 이동하고, 그다음 2번 사람이 이동하는 문제라면 2번 사람은 1번 사람이 이동한 이후의 맵을 기준으로 판단해야 합니다.

for person in people:
    x, y = person
    nx, ny = move(x, y)

    board[x][y] = 0
    board[nx][ny] = 1

순차 이동 문제에서는 반복문의 순서가 중요합니다.
문제에서 번호 순서, 행 순서, 열 순서, 입력 순서 등을 지정했다면 반드시 그 순서대로 처리해야 합니다.

9. 자주 하는 실수 정리

1. x, y 좌표를 헷갈리는 실수

2차원 배열은 보통 board[row][col] 형태로 접근합니다.

board[x][y]

여기서 x를 행, y를 열로 정했다면 끝까지 같은 기준을 유지해야 합니다.
중간에 board[y][x]처럼 바뀌면 디버깅하기 어려운 오류가 발생합니다.

2. 범위 체크 전에 배열에 접근하는 실수

다음 위치가 맵 안에 있는지 확인하기 전에 board[nx][ny]를 조회하면 인덱스 에러가 발생할 수 있습니다.

if not in_range(nx, ny):
    continue

범위 체크는 항상 가장 먼저 하는 것이 안전합니다.

3. BFS에서 방문 처리를 늦게 하는 실수

BFS에서는 큐에 넣을 때 방문 처리를 하는 것이 좋습니다.

visited[nx][ny] = True
q.append((nx, ny))

그래야 같은 칸이 큐에 중복으로 들어가는 문제를 막을 수 있습니다.

4. 동시 이동 문제를 순차 이동처럼 처리하는 실수

동시 이동 문제에서 기존 맵을 바로 수정하면, 한 턴 안에서 이동 결과가 섞일 수 있습니다.

이 경우에는 next_board, temp, next_positions 같은 임시 저장 공간을 사용한 뒤 마지막에 한 번에 반영하는 것이 좋습니다.

10. 정리와 회고

DFS와 BFS는 모두 2차원 맵 탐색에서 자주 사용하는 알고리즘이지만, 목적이 다릅니다.
DFS는 연결된 영역을 깊게 탐색할 때 적합하고, BFS는 가까운 칸부터 탐색하기 때문에 최단 거리나 최소 턴 수를 구할 때 적합합니다.

이번에 코드트리 문제를 풀면서 느낀 점은, 단순히 DFS와 BFS 문법을 외우는 것보다 문제에서 요구하는 탐색 방식과 상태 변화 시점을 정확히 이해하는 것이 더 중요하다는 점입니다.

특히 2차원 맵 문제에서는 방문 처리 하나만 잘못해도 무한 반복이 발생하거나, 같은 칸이 여러 번 큐에 들어가면서 정답이 틀어질 수 있습니다. 또한 여러 대상이 이동하는 시뮬레이션 문제에서는 동시에 이동해야 하는지, 순차적으로 이동해야 하는지를 구분하지 못하면 구현은 맞아 보여도 결과가 달라질 수 있습니다.

앞으로 2차원 맵 문제를 풀 때는 다음 기준을 먼저 확인하려고 합니다.

• 연결된 영역 전체를 탐색하는 문제인가?
• 최단 거리나 최소 이동 횟수를 구하는 문제인가?
• 방문 처리는 언제 해야 하는가?
• 여러 대상이 동시에 움직이는가?
• 이동 결과를 바로 맵에 반영해도 되는가?
• 문제에서 요구한 처리 순서가 있는가?

이 기준을 잡고 문제를 읽으면 DFS를 쓸지 BFS를 쓸지, 그리고 맵 상태를 어떻게 관리해야 할지 훨씬 명확해집니다.
결국 2차원 맵 순회 문제는 알고리즘 선택뿐만 아니라 방문 처리, 좌표 관리, 상태 반영 시점을 꼼꼼히 챙기는 것이 핵심이라고 느꼈습니다.

코딩테스트를 준비하면서 가장 어려웠던 부분은 “내가 무엇을 모르는지”를 정확히 아는 일이었습니다. 문제를 많이 풀고 있다고 생각해도, 막상 비슷한 유형에서 계속 막히면 실력이 늘고 있는지 확신하기 어려웠습니다. 그래서 이번 한 달 동안은 코드트리의 갭체크 결과를 기준으로 제 약점을 다시 확인하고, 부족한 부분을 의식적으로 보완하는 방식으로 학습했습니다.

첫 갭체크와 이번 갭체크 비교

첫 갭체크 때는 문제를 보자마자 “어떤 알고리즘을 써야 하지?”부터 고민하는 경우가 많았습니다. 규칙을 찾으려고 너무 오래 붙잡고 있다 보니, 오히려 간단하게 구현할 수 있는 문제에서도 시간을 많이 사용했습니다. 특히 구현 문제에서 조건이 많아지면 머릿속으로만 흐름을 따라가다가 중간에 꼬이는 경우가 많았습니다.

이번 갭체크에서는 접근 방식이 조금 달라졌습니다. 무조건 알고리즘적인 규칙을 찾으려 하기보다, 입력 크기와 조건을 먼저 확인하고 하드코딩이나 단순 분기 처리로 해결할 수 있는 부분은 과감하게 간단한 구현으로 대체했습니다. 처음에는 이런 방식이 “너무 단순한 풀이가 아닐까?”라는 생각도 들었지만, 실제로는 제한 조건 안에서 정확하고 빠르게 푸는 것이 더 중요하다는 점을 체감했습니다.

지난 한 달간 코드트리에서 했던 구체적인 노력

지난 한 달 동안은 단순히 문제 수를 늘리는 것보다, 제가 자주 틀리는 유형을 반복해서 확인하는 데 집중했습니다. 특히 구현 문제를 풀 때는 먼저 조건을 작은 단위로 나누고, 예외 케이스를 직접 적어보며 풀이 방향을 정리했습니다.

가장 크게 바꾼 부분은 디버깅 방식입니다. 이전에는 필요한 위치마다 print()를 넣고, 제출 전에 하나씩 주석 처리하는 식으로 디버깅했습니다. 그런데 이 방식은 코드가 길어질수록 관리가 불편했고, 실수로 출력문을 제거하지 않아 제출에서 틀릴 위험도 있었습니다.

그래서 전역에서 디버깅 출력 여부를 관리할 수 있도록 분기 처리를 두었습니다. 예를 들어 디버깅이 필요할 때만 출력되도록 별도의 함수를 만들고, 제출 전에는 해당 옵션만 꺼두는 식으로 관리했습니다. 이렇게 하니 코드 흐름을 확인하기 쉬웠고, 불필요한 출력 실수도 줄일 수 있었습니다.

python DEBUG = False def debug_print(*args): if DEBUG: print(*args)

이 방식은 작은 변화였지만, 문제를 풀 때 꽤 큰 차이를 만들었습니다. 특히 배열 상태, 반복문 진행 과정, 조건 분기 결과를 확인할 때 훨씬 안정적으로 디버깅할 수 있었습니다.

약점이 강점으로 바뀌고 있다고 느낀 순간

처음에는 구현 문제가 가장 막막했습니다. 조건을 보면 어디서부터 시작해야 할지 모르겠고, 규칙을 찾으려고 시간을 쓰다가 결국 풀이가 복잡해지는 경우가 많았습니다. 하지만 한 달 동안 반복하면서 “이 문제는 굳이 복잡한 알고리즘이 아니라 조건대로 차근차근 구현하면 되는 문제”라고 판단하는 순간이 생기기 시작했습니다.

특히 이전 같았으면 규칙을 찾으려고 오래 고민했을 문제에서, 이번에는 조건을 나누고 필요한 부분만 하드코딩으로 처리해 빠르게 통과했을 때 변화가 느껴졌습니다. 단순히 문제 하나를 맞혔다는 것보다, 제 풀이 방식이 조금씩 안정되고 있다는 점이 더 의미 있었습니다.

디버깅에서도 마찬가지였습니다. 예전에는 틀린 이유를 감으로 찾으려고 했다면, 이제는 debug_print()를 통해 중간 상태를 확인하면서 문제의 원인을 좁혀갈 수 있었습니다. 이 과정을 반복하면서 “틀렸을 때 다시 고칠 수 있는 힘”이 생긴 것 같습니다.

코드트리에서 달성할 최종 학습 목표와 다짐

앞으로 코드트리에서 달성하고 싶은 목표는 단순히 많은 문제를 푸는 것이 아니라, 약점 유형을 다시 만나도 흔들리지 않는 풀이 습관을 만드는 것입니다. 특히 구현, 시뮬레이션, 완전탐색처럼 조건을 정확히 이해하고 코드로 옮기는 유형에서 더 안정적인 실력을 갖추고 싶습니다.

이번 갭체크를 통해 느낀 점은, 약점은 한 번에 사라지는 것이 아니라 작은 개선을 반복하면서 점점 줄어든다는 것입니다. 하드코딩으로 단순화할 수 있는 부분은 과감히 단순화하고, 디버깅은 체계적으로 관리하면서 앞으로도 문제 풀이 과정을 더 정돈해 나가려 합니다.

다음 갭체크에서는 “이 유형은 이제 어느 정도 자신 있다”라고 말할 수 있는 영역을 더 늘리는 것이 목표입니다. 코드트리를 통해 제 약점을 계속 확인하고, 부족한 부분을 하나씩 강점으로 바꿔가겠습니다.

https://www.codetree.ai/ko