A-5: 문제를 푸는 방법

안녕하세요, 홍순구 튜터입니다. 벌써 다섯 번째 시간이네요. 지난 시간(A-4)에 우리는 프로그램이 흐르는 세 가지 길(순차·선택·반복)을 배우고, 작은 프로그램 한 편을 순서도로 그리고 의사코드로 적었어요. 그리고 마지막에 표를 만들어 값을 한 줄씩 손으로 따라가 봤죠. "인기글 개수: 3"이 정말 나오는지 두 눈으로 확인하면서요. 그때 제가 "이 손으로 따라가기가 다음 시간의 주인공"이라고 약속했어요. 무한 루프를 짚으면서 "틀린 곳을 찾는 디버깅의 출발점"이라고도 했고요. 그리고 큰 문제를 작게 쪼개는 분해, 핵심만 남기는 추상화, 푸는 절차인 알고리즘도 오늘 함께 만난다고 예고했죠.

오늘 그 약속들을 한꺼번에 지킵니다. 지금까지 우리는 프로그래밍의 재료(A-3 변수·연산)와 흐름(A-4 조건·반복)을 모두 손에 넣었어요. 그런데 막상 "이 문제를 풀어 보세요" 하면 막막하죠. 재료와 흐름을 안다고 문제가 저절로 풀리는 건 아니거든요. 그 사이를 잇는 게 바로 오늘 배울 문제를 푸는 사고예요.

좋은 소식 먼저 말씀드릴게요. 오늘도 코드는 한 줄도 안 칩니다. 대신 큰 문제를 작게 쪼개고, 반복되는 모양을 찾고, 핵심만 남겨서, 푸는 절차를 짜는 네 가지 생각 도구를 배워요. 그 도구로 만든 절차를 순서도와 의사코드로 그리고, 손으로 따라가 정말 맞는지 확인하고, 틀렸으면 어디가 틀렸는지 찾아냅니다. 어렵게 들려도 괜찮아요. 사실 여러분은 일상에서 이미 이렇게 생각하고 있어요. 오늘은 그 익숙한 생각에 이름을 붙여 줄 뿐이에요.

   오늘의 여정 — 문제를 푸는 방법

   ① 큰 문제를 작게 쪼개기 — 분해
   ② 반복되는 모양 찾기 — 패턴 인식
   ③ 핵심만 남기기 — 추상화
   ④ 문제를 푸는 절차 — 알고리즘
   ⑤ 순서도와 의사코드를 오가며 — 가장 큰 수 찾기
   ⑥ 손으로 값을 따라가기 — trace
   ⑦ 같은 문제, 다른 해법 — 효율의 직관
   ⑧ 틀린 곳 찾기 — 디버깅 사고

①에서 ④까지가 문제를 정리하는 네 가지 생각 도구예요. ⑤에서 그 정리한 문제를 순서도와 의사코드로 그리고, ⑥에서 손으로 따라가 검증합니다. ⑦에서 같은 문제의 다른 해법을 견줘 보고, ⑧에서 틀린 곳을 찾아내며 마무리해요.

💡 오늘 수업의 핵심 — "문제를 푸는 데에도 방법이 있다 — 큰 문제를 작게 쪼개고(분해), 반복되는 모양을 찾고(패턴 인식), 핵심만 남겨(추상화), 푸는 절차를 짜는 것(알고리즘)이다. 그 절차를 순서도와 의사코드로 그린 뒤 손으로 따라가(trace) 정말 맞는지 확인하고, 틀렸으면 어디서 어긋났는지 짚어 고치는 것이 디버깅이다"

🎯 학습 목표

• 큰 문제를 분해하고, 반복되는 패턴을 찾고, 핵심만 남기는 추상화로 문제를 다룰 수 있는 크기로 정리합니다.
• 문제를 푸는 절차인 알고리즘을 순서도와 의사코드로 그리고, 손으로 따라가기(trace)로 그 절차가 정말 맞는지 검증합니다.
• 같은 문제에 여러 해법이 있고 효율이 다름을 직관으로 이해하고, 틀린 절차를 trace로 짚어 고치는 디버깅의 첫걸음을 뗍니다.

Step 1: "큰 문제를 작게 — 분해"

큰 문제를 만나면 누구나 막막해요. "반 전체 시험 평균을 구하세요" 같은 말을 들으면, 어디서부터 손을 대야 할지 모르겠죠. 그런데 이런 막막함을 푸는 첫 번째 도구가 있어요. 바로 분해예요. 큰 문제를 다룰 수 있는 작은 조각으로 쪼개는 거예요.

오래된 농담이 하나 있어요. "코끼리를 어떻게 먹지?" "한 번에 한 입씩." 통째로 보면 도저히 못 먹을 것 같지만, 한 입 크기로 쪼개면 결국 다 먹을 수 있어요. 문제도 똑같아요. 통째로는 막막해도, 작은 단계로 쪼개면 각 단계는 충분히 풀 만해집니다.

오늘 우리는 문제를 푸는 네 가지 생각 도구를 배우는데, 분해가 그 첫째예요. 차례로 분해·패턴 인식·추상화·알고리즘을 만나게 됩니다. 이 넷은 따로 노는 게 아니라, 문제 하나를 함께 정리하는 한 팀이에요.

"반 평균 구하기"를 분해해 볼게요. 이걸 작은 조각으로 나누면 이렇게 돼요.

   반 평균 구하기

   ① 모든 점수를 더한다  (합계 구하기)
        └─ 첫 점수부터 끝까지 하나씩 합에 더한다
   ② 더한 값을 사람 수로 나눈다  (나누기)

막막했던 "반 평균"이 두 단계로 줄었죠. ①은 또 "하나씩 더하기"로 한 번 더 쪼갤 수 있어요. 이건 A-4에서 배운 반복으로 풀 수 있는 모양이고요. ②는 A-3에서 배운 나누기 연산 하나면 끝나요. 큰 문제가 우리가 이미 아는 작은 조각들로 분해되는 순간, 풀이가 보이기 시작합니다.

이게 분해의 힘이에요. 분해는 새로운 마법이 아니라, "큰 걸 작게 나눠 하나씩 처리한다"는 아주 자연스러운 생각이에요. 큰 청소를 방별로 나누고, 긴 여행을 날짜별로 짜듯이요. 프로그래밍에서 만나는 거의 모든 큰 문제는, 먼저 분해부터 시작합니다.

💡 한 줄 정리

분해는 막막한 큰 문제를 다룰 수 있는 작은 조각으로 쪼개는 것이며, 각 조각이 우리가 이미 아는 흐름(순차·조건·반복)이나 연산으로 풀리는 순간 전체 풀이가 보이기 시작한다.

Step 2: "반복되는 모양 찾기 — 패턴 인식"

문제를 분해하다 보면 신기한 일이 일어나요. "어, 이 조각 아까 그거랑 똑같은데?" 싶은 순간이 와요. 겉보기엔 다른 문제인데 속을 들여다보면 같은 모양인 거죠. 이렇게 반복되는 모양을 알아채는 게 두 번째 도구, 패턴 인식이에요.

예를 들어 볼게요. "1부터 5까지 더하기"와 "1부터 100까지 더하기"는 다른 문제처럼 보이죠. 숫자가 다르니까요. 그런데 푸는 방법은 완전히 똑같아요.

   같은 모양, 다른 숫자

   1 부터 5 까지 더하기    →  1 부터 N 까지 하나씩 더한다
   1 부터 100 까지 더하기  →  1 부터 N 까지 하나씩 더한다
                              └ 숫자만 다르고 푸는 모양은 똑같다

둘 다 "1부터 어떤 수까지 하나씩 더한다"로 똑같아요. 5냐 100이냐는 그저 숫자만 바뀐 거죠. 그래서 5까지 더하는 법을 알면, 100까지든 만까지든 숫자만 바꿔 그대로 풀 수 있어요. 한 번 푼 모양을 재사용하는 거예요.

패턴을 알아보면 좋은 점이 분명해요. 매번 처음부터 새로 고민하지 않아도 되거든요. "이건 전에 본 그 모양이네" 하면, 그 풀이를 가져다 쓰면 끝이에요. 반 평균·동아리 평균·우리 팀 평균이 전부 "모두 더해서 인원으로 나눈다"는 같은 패턴이듯이요. 문제 겉모습은 달라도 속 모양은 같은 경우가 정말 많아요.

이 패턴 인식은 분해와 짝을 이뤄요. 분해로 문제를 작은 조각으로 쪼개 놓으면, 그 조각들 사이에서 "어, 이거 아까 그 모양" 하는 패턴이 눈에 들어오거든요. 그러면 같은 모양은 한 번만 풀어 두고 돌려쓸 수 있어요.

💡 한 줄 정리

패턴 인식은 겉모습이 다른 문제들 속에서 반복되는 같은 모양을 알아채는 것이며, 한 번 푼 모양을 재사용하면 매번 처음부터 고민하지 않아도 된다.

Step 3: "핵심만 남기기 — 추상화"

세 번째 도구는 추상화예요. 이름이 어려워 보이지만 뜻은 간단해요. 지금 풀려는 문제에 중요한 것만 남기고, 안 중요한 곁가지는 과감히 버리는 거예요. 우리는 일상에서 이미 추상화를 쓰고 있어요. 가장 좋은 예가 지하철 노선도예요.

지하철 노선도를 떠올려 보세요. 실제 거리도, 땅의 모양도, 건물도 전부 지워져 있죠. 역과 역을 잇는 선, 그리고 갈아타는 역만 남아 있어요. 길 찾는 데 필요 없는 건 다 버린 거예요. 그래서 오히려 "어디서 갈아타면 되는지"가 한눈에 보이죠. 진짜 지도보다 노선도가 길 찾기엔 더 쓸모 있는 이유예요. 이게 추상화예요. 핵심만 남기니 문제가 또렷해지는 거죠.

문제 풀이에 적용해 볼게요. "이름들을 가나다순으로 정렬하라"는 문제가 있어요. 민지·재훈·승우를 순서대로 늘어놓는 거죠. 여기서 각 사람에 대해 우리가 아는 정보는 아주 많아요. 나이, 키, 취미, 이름의 뜻, 글자 수… 그런데 정렬에 그게 다 필요할까요?

   이름 정렬 — 무엇이 중요하고 무엇을 버리는가

   버린다:  이름의 뜻 · 글자 수 · 한글인지 영어인지 · 나이 · 키 …
   남긴다:  "두 이름 중 누가 가나다순으로 앞에 오는가" 하나만

정렬에 필요한 건 딱 하나예요. "두 이름 중 누가 앞에 오는가." 나이도 키도 이름의 뜻도, 정렬에는 아무 상관이 없어요. 그래서 다 버리고 "순서 비교" 하나만 남기는 거예요. 곁가지를 버리고 나면 문제가 훨씬 단순해지죠. 복잡한 사람들이 아니라, 그저 "앞뒤를 비교할 수 있는 이름들"만 남으니까요.

여기서 중요한 점이 있어요. 무엇이 핵심이고 무엇이 곁가지인지는 풀려는 문제가 무엇을 묻느냐에 따라 달라져요. 같은 사람이라도, 정렬 문제에선 나이가 곁가지지만 "나이순으로 줄 세우기" 문제에선 나이가 핵심이 되죠. 추상화는 "항상 이건 버려라"가 아니라, "지금 이 문제에 무엇이 중요한가"를 묻는 거예요.

💡 한 줄 정리

추상화는 지금 풀려는 문제에 핵심만 남기고 곁가지를 버려 문제를 또렷하게 만드는 것이며, 무엇이 핵심인지는 문제가 무엇을 묻느냐에 따라 달라진다.

Step 4: "문제를 푸는 절차 — 알고리즘"

분해로 문제를 작게 쪼개고, 패턴으로 익숙한 모양을 찾고, 추상화로 핵심만 남겼어요. 이제 마지막 도구예요. 정리한 문제를 실제로 푸는 절차를 적는 거예요. 그 절차에 붙은 이름이 바로 알고리즘입니다.

알고리즘이라고 하면 뭔가 대단하고 어려운 것 같지만, 실은 여러분이 매일 쓰는 것과 똑같아요. 바로 요리 레시피예요. A-2에서 "프로그램은 명령의 순서, 곧 요리 레시피 같다"고 했던 걸 기억하시죠. 알고리즘이 딱 그거예요. "이 문제를 풀려면 이걸 먼저 하고, 그다음 이걸 하고…" 하는 정해진 순서. 라면 끓이는 절차가 라면 알고리즘이고, 반 평균 구하는 절차가 평균 알고리즘이에요.

그런데 아무 절차나 다 좋은 알고리즘은 아니에요. 좋은 알고리즘에는 세 가지 조건이 있어요.

   좋은 알고리즘의 세 가지 조건

   ① 명확하다    누가 따라 해도 똑같이 — 모호한 말("적당히")이 없다
   ② 끝이 있다    언젠가 반드시 멈춘다 — 무한 루프가 아니다
   ③ 결과를 낸다  원하는 답이 정말로 나온다

하나씩 볼게요. 첫째, 명확해야 해요. "물을 적당히 붓고 맛있게 끓여라"는 좋은 레시피가 아니에요. "적당히"가 사람마다 다르니까요. "물 550ml를 붓고 4분간 끓여라"처럼 누가 봐도 똑같이 따라 할 수 있어야 좋은 절차예요. 컴퓨터는 특히 모호함을 못 견뎌요. A-1에서 "컴퓨터는 시킨 것만 한다"고 했죠. "적당히"를 시키면 컴퓨터는 멈춰 버려요. 무엇이 "적당히"인지 모르니까요.

둘째, 끝이 있어야 해요. 절차를 따라가다 보면 언젠가는 끝나야죠. 지난 시간에 본 무한 루프가 바로 이 조건을 어긴 거예요. 멈출 줄 모르고 영원히 도는 절차는 좋은 알고리즘이 아니에요. 셋째, 원하는 결과를 내야 해요. 끝까지 잘 돌았는데 엉뚱한 답이 나오면 소용없죠. 반 평균을 구하랬더니 합계만 내놓으면 안 되는 거예요.

이 세 조건을 떠올리면, 절차를 적을 때 스스로 점검할 수 있어요. "이거 모호한 데 없나? 끝나긴 하나? 원하는 답이 나오나?" 오늘 우리가 만들 가장 큰 수 찾기 알고리즘도, 이 세 조건을 만족하는지 보면서 짜 볼 거예요.

💡 한 줄 정리

알고리즘은 문제를 푸는 정해진 절차(요리 레시피와 같다)이며, 좋은 알고리즘은 명확하고(모호함이 없고)·끝이 있고(언젠가 멈추고)·원하는 결과를 내야 한다.

Step 5: "순서도와 의사코드를 오가며 — 가장 큰 수 찾기"

이제 네 가지 도구로 진짜 문제를 풀어 볼게요. 오늘의 주인공 문제는 가장 큰 수 찾기예요. 숫자 몇 개가 주어졌을 때 그중 제일 큰 값을 찾는 거죠. 시험 최고점, 가장 추웠던 날의 기온, 한 주 중 좋아요가 제일 많았던 글… 일상에서 "제일 큰 거 하나 골라내기"는 정말 자주 나와요.

먼저 사람은 이걸 어떻게 풀까요? 수를 죽 훑으면서 "지금까지 본 것 중 제일 큰 것"을 머릿속에 기억해 둬요. 더 큰 게 나오면 기억을 바꾸고, 아니면 그대로 두죠. 다 보고 나면 머릿속에 남은 게 답이에요. 이 생각을 절차로 옮기면 알고리즘이 됩니다.

지난 시간에 약속했죠. "A-5에서는 순서도와 의사코드를 오가며 문제를 푼다"고요. 그 약속대로, 먼저 순서도로 흐름을 그리고 그다음 의사코드로 옮겨 볼게요. 흐름이 갈라지고 되풀이되는 문제는 그림으로 먼저 보면 훨씬 또렷해요.

   가장 큰 수 찾기 — 순서도

   ┌──────────────────┐
   │       시작       │
   └─────────┬────────┘
             │
             ▼
   최댓값 ← 첫 번째 수
     │
     ▼
   ┌─▶ ◇ 아직 안 본 수가 있는가?
   │     ├─ 아니오 ─→ 최댓값 출력 → 끝
   │     └─ 예
   │          ▼
   │        ◇ 지금 수 가 최댓값 보다 큰가?
   │          ├─ 예    ─→ 최댓값 ← 지금 수
   │          └─ 아니오    (그대로 둔다)
   └──────────── 되돌아가 다음 수를 본다

흐름을 따라가 볼게요. 맨 처음 첫 번째 수를 잠정 최댓값으로 둬요. 비교하려면 기준이 하나 있어야 하니, 첫 수를 일단 "잠정 1등"으로 앉히는 거예요. 그다음 남은 수를 하나씩 보면서, 지금 보는 수가 최댓값보다 크면 최댓값을 그 수로 바꿔요. 아니면 그대로 두고요. 더 볼 수가 없으면 최댓값을 출력하고 끝납니다. 위로 되돌아가는 화살표가 보이죠? A-4에서 본 반복의 그 되돌아옴이에요.

이 순서도를 의사코드로 옮기면 이렇게 돼요. 그림으로 본 흐름을 글로 또박또박 적는 거예요.

최댓값 ← 첫 번째 수
나머지 수를 하나씩 보면서 반복
    만약 지금_수 가 최댓값 보다 크면
        최댓값 ← 지금_수
최댓값 출력

나머지 수를 하나씩 보면서 반복은 A-4의 반복을 말로 푼 거예요. 남은 수가 있는 동안 한 개씩 꺼내 보겠다는 뜻이죠. 그 안에서 만약 지금_수 가 최댓값 보다 크면 최댓값을 새 값으로 바꿔요. 들여쓰기를 보면, 반복 안에 조건이 한 단계 더 들어가 있죠. A-4 마지막에 본 "반복 안에 조건" 그 모양 그대로예요.

순서도와 의사코드, 둘은 같은 알고리즘을 다르게 보여 줘요. 순서도는 흐름이 어디서 갈라지고 되돌아가는지를 그림으로, 의사코드는 그 흐름을 한 줄 한 줄 글로요. 복잡한 흐름은 순서도로 먼저 그려 보고, 또렷해지면 의사코드로 옮기는 게 편해요. 그런데 이렇게 적어 놓고 보면 한 가지 찜찜한 게 남죠. "이 절차가 정말 맞게 동작할까?" 그걸 확인하는 게 다음 Step이에요.

💡 한 줄 정리

가장 큰 수 찾기는 첫 수를 잠정 최댓값으로 두고 나머지를 하나씩 보며 더 큰 값이 나올 때마다 최댓값을 바꾸는 절차이며, 같은 알고리즘을 순서도(그림)와 의사코드(글)로 오가며 표현할 수 있다.

Step 6: "손으로 값을 따라가기 — trace 본격"

의사코드를 적었으면, 이제 정말 중요한 일이 남았어요. 이 절차가 진짜 맞게 동작하는지 확인하는 거예요. 머릿속으로만 "되겠지" 하면 틀린 걸 놓치기 쉬워요. 그래서 우리는 값을 한 줄씩 손으로 따라가 봐요. 이걸 손으로 따라가기, 또는 trace라고 불러요. A-4 마지막에 살짝 맛본 그거예요. 오늘은 이걸 본격적으로 씁니다.

방법은 간단해요. 변수마다 칸을 만들고, 절차가 한 바퀴 돌 때마다 그 값이 어떻게 변하는지 표에 적는 거예요. 머릿속에서 굴리지 않고 종이에 적으니, 헷갈릴 일도 빠뜨릴 일도 없어요.

수 다섯 개가 차례로 3, 7, 2, 9, 5라고 해볼게요. Step 5의 의사코드를 따라가 볼게요. 첫 수 3을 잠정 최댓값으로 두고, 나머지 7·2·9·5를 하나씩 봅니다.

표를 한 줄씩 읽어 볼게요. 시작할 때 최댓값은 첫 수인 3이에요. 1회차에 7을 보니 3보다 크죠. 그래서 최댓값이 7로 바뀌어요. 2회차 2는 7보다 작으니 그대로 7. 3회차 9는 7보다 크니 9로 바뀌고, 4회차 5는 9보다 작으니 그대로 9예요. 더 볼 수가 없으니 최댓값 9를 출력하고 끝나죠. 우리가 눈으로 봐도 3·7·2·9·5 중 제일 큰 건 9가 맞아요. 절차가 제대로 동작한다는 걸 두 눈으로 확인한 거예요.

이게 trace의 힘이에요. "맞겠지"라는 짐작을 "맞다는 확인"으로 바꿔 줘요. 특히 반복이 돌 때 변수가 어떻게 변하는지는 머릿속으로 쫓기 정말 어려운데, 표로 적으면 한눈에 보여요. 알고리즘을 짰으면 곧바로 trace로 따라가 보는 습관을 들이세요. 이 습관이 다음 Step에서 틀린 곳을 찾는 결정적인 무기가 됩니다.

💡 한 줄 정리

손으로 따라가기(trace)는 변수마다 칸을 만들어 절차가 한 바퀴 돌 때마다 값의 변화를 표에 적는 것이며, "맞겠지"라는 짐작을 "맞다는 확인"으로 바꿔 준다.

Step 7: "같은 문제, 다른 해법 — 효율의 직관"

재밌는 사실 하나를 말씀드릴게요. 같은 문제를 푸는 방법이 꼭 하나만 있는 건 아니에요. 답은 똑같이 나오는데, 거기 도달하는 절차가 여럿일 수 있어요. 그리고 그 절차들은 드는 노력이 서로 달라요. 가장 큰 수 찾기로 두 가지 해법을 견줘 볼게요.

   가장 큰 수 찾기 — 두 가지 해법

   방법 A · 한 번 훑기   수를 한 번씩만 보고 가장 큰 것만 기억한다
                        → 수가 5개면 비교 4번, 100개면 99번
   방법 B · 줄 세우기    모든 수를 크기순으로 정렬한 뒤 맨 끝을 본다
                        → 줄 세우는 데 훨씬 더 많은 비교가 든다

   같은 답(9), 다른 노력 — 가장 큰 하나만 필요하면 A가 낫다

방법 A는 우리가 Step 5에서 만든 거예요. 수를 한 번씩만 죽 보면서 제일 큰 것만 기억하면 돼요. 수가 100개여도 100번만 보면 끝나죠. 방법 B는 다르게 접근해요. 모든 수를 키 순서로 줄 세운(정렬한) 다음, 맨 끝에 선 가장 큰 수를 보는 거예요. 답은 똑같이 나와요. 그런데 줄을 세우려면 수들을 서로 여러 번 비교하고 순서를 맞바꿔야 해서, 일이 훨씬 많아져요.

여기서 직관 하나가 생겨요. 가장 큰 하나만 필요한데 전부 줄 세우는 건 낭비예요. 반에서 키가 제일 큰 사람 한 명만 찾으면 되는데, 전교생을 키 순서로 다 세울 필요는 없잖아요. 한 명씩 보면서 제일 큰 사람만 기억하면 되죠. 같은 답이라도, 쓸데없이 더 많이 일하는 절차는 그만큼 느려요. 이게 효율의 직관이에요.

그런데 방법 B가 늘 나쁜 건 아니에요. 문제가 "가장 큰 수 하나"가 아니라 "이름을 가나다순으로 전부 보여 줘"라면, 그땐 줄 세우기(정렬)가 반드시 필요해요. 한 번 훑기로는 전체 순서를 만들 수 없으니까요. 결국 문제가 무엇을 원하느냐에 따라 알맞은 해법이 달라져요. 하나만 필요하면 훑기, 전체 순서가 필요하면 정렬. 좋은 프로그래머는 문제를 보고 어떤 절차가 알맞은지 고를 줄 알아요.

참고로, 절차가 얼마나 더 느린지를 정확한 잣대로 재는 도구가 따로 있어요. 흔히 "시간 복잡도"라고 부르는데, 그건 후속 자료구조·알고리즘 과목에서 본격적으로 배워요. 지금은 "쓸데없이 더 많이 일하면 느리다"는 직관 하나만 가져가면 충분합니다.

💡 한 줄 정리

같은 문제도 답에 이르는 절차가 여럿이고 드는 노력이 다르며, "필요한 것보다 더 많이 일하면 느리다"는 직관으로 문제에 알맞은 해법을 고르는 것이 효율적인 사고의 시작이다.

Step 8: "틀린 곳 찾기 — 디버깅 사고"

마지막 Step이에요. 오늘 우리는 절차를 짜고(알고리즘), 손으로 따라가 확인하는(trace) 법을 배웠어요. 그런데 사람이 짠 절차에는 실수가 끼기 마련이에요. 절차가 틀리면 답도 틀리죠. 이 틀린 곳을 찾아 고치는 일을 디버깅이라고 불러요. A-4에서 무한 루프를 보며 "디버깅의 출발점"이라고 했던 그 약속, 오늘 지킵니다.

가장 큰 수 찾기 의사코드를 다시 봐요. 그런데 이번엔 누군가 한 글자를 잘못 적었어요. 어디가 틀렸는지 한눈에 보이나요?

최댓값 ← 첫 번째 수
나머지 수를 하나씩 보면서 반복
    만약 지금_수 가 최댓값 보다 작으면     ← 여기를 잘못 적었다
        최댓값 ← 지금_수
최댓값 출력

보다 크면이어야 할 곳에 보다 작으면이라고 적혀 있어요. 부등호 방향을 거꾸로 쓴 거죠. 딱 한 글자 차이예요. 그런데 이 한 글자가 절차를 완전히 망가뜨려요. 눈으로만 보면 "그럴듯한데?" 싶을 수도 있어요. 그래서 우리에겐 trace가 있는 거예요. 손으로 따라가면 틀린 게 드러납니다. 같은 수 3, 7, 2, 9, 5로 따라가 볼게요.

뭔가 이상하죠? 가장 큰 수를 찾는다면서 최댓값이 3에서 2로 오히려 작아졌어요. 2회차에서 2가 3보다 작은데도 최댓값을 2로 바꿔 버린 거예요. 결국 출력되는 값은 2. 그런데 3·7·2·9·5 중 가장 큰 건 9잖아요. 답이 완전히 틀렸어요. 오히려 가장 작은 수가 나와 버렸죠.

바로 이 순간이 디버깅의 핵심이에요. trace 표에서 "최댓값이 커져야 하는데 작아지는" 그 이상한 줄을 발견하면, "여기서 뭔가 잘못됐다"는 걸 알 수 있어요. 그 줄을 만든 의사코드를 거슬러 보면 보다 작으면이 눈에 들어오죠. 보다 크면으로 고치면 절차가 제대로 돌아와요. 이렇게 trace로 이상한 곳을 짚고, 그 줄을 거슬러 올라가 원인을 고치는 게 디버깅이에요.

디버깅에서 가장 중요한 마음가짐을 하나 말씀드릴게요. 틀리는 건 부끄러운 게 아니에요. 아무리 뛰어난 개발자도 실수하고, 그래서 매일 디버깅을 해요. 중요한 건 틀리지 않는 게 아니라, 틀렸을 때 차분히 따라가며 찾아내는 능력이에요. 오늘 trace로 한 글자 버그를 잡아낸 그 과정이, 앞으로 여러분이 평생 쓸 디버깅의 첫걸음이에요.

💡 한 줄 정리

디버깅은 틀린 절차를 trace로 따라가 "값이 이상해지는 줄"을 짚고, 그 줄을 거슬러 올라가 원인(예: 부등호 방향)을 고치는 일이며, 틀리는 것은 부끄러운 게 아니라 차분히 찾아 고치면 되는 일상이다.

마무리

다섯 번째 시간, 정말 잘 따라오셨어요. 오늘 우리는 코드 한 줄 없이도, 막막한 문제를 푸는 사고의 도구들을 손에 넣었어요. 큰 문제를 작게 쪼개고(분해), 같은 모양을 찾고(패턴), 핵심만 남기고(추상화), 푸는 절차를 짰죠(알고리즘). 그 절차를 순서도와 의사코드로 그리고, 손으로 따라가 맞는지 확인하고, 틀린 곳까지 찾아냈어요. 지금까지 모은 재료와 흐름이, 오늘 비로소 "문제를 푸는 힘"으로 모였습니다.

오늘 배운 핵심 세 가지

1. 💡 문제를 푸는 데에도 도구가 있다. 큰 문제를 작게 쪼개는 분해, 반복되는 모양을 찾는 패턴 인식, 핵심만 남기는 추상화, 푸는 절차를 짜는 알고리즘. 이 넷으로 막막한 문제를 다룰 수 있는 크기로 정리한다.
2. 💡 절차는 그린 뒤 반드시 따라가 확인한다. 알고리즘을 순서도(그림)와 의사코드(글)로 표현하고, 손으로 따라가기(trace)로 값을 쫓으면 "맞겠지"라는 짐작이 "맞다는 확인"으로 바뀐다.
3. 💡 같은 문제도 해법이 여럿이고, 틀리면 찾아 고치면 된다. 필요한 것보다 더 많이 일하면 느리다는 효율의 직관으로 해법을 고르고, 틀렸을 땐 trace로 이상한 줄을 짚어 원인을 고치는 디버깅으로 바로잡는다.

다음 시간 예고

오늘까지 우리는 모든 사고를 종이 위에서 다뤘어요. 의사코드도, 순서도도, trace도 전부 손으로 그렸죠. 다음 시간(A-6)에는 드디어 종이를 떠나 진짜 컴퓨터로 갑니다. 파일과 폴더가 무엇인지, 코드를 적는 에디터와 명령을 내리는 터미널이 무엇인지 처음 만나고, 설치도 계정도 없이 브라우저만으로 진짜 코드 한 줄을 직접 실행해 봐요. "화면에 글자를 띄우는" 그 한 줄이, 여러분이 짠 절차가 처음으로 살아 움직이는 순간이 될 거예요.

그리고 오늘 우리가 종이에서 손으로 틀린 곳을 찾았다면, 다음 시간엔 컴퓨터가 빨간 줄로 "여기 틀렸어요"라고 알려 주는 에러를 처음 만나요. 빨간 줄은 무서운 게 아니라, 어디를 보라고 알려 주는 친구예요. 오늘 기른 디버깅의 눈에 컴퓨터의 도움까지 더해지는, 설레는 시간이 기다리고 있어요.

과제

오늘도 종이와 연필로 하는 연습이에요. 문제를 푸는 사고는 직접 쪼개 보고, 직접 따라가 봐야 늘어요. 틀려도 좋으니 부담 없이 손을 움직여 보세요. 그게 오늘 배운 모든 것의 핵심입니다.

[기초] 일상의 큰 일 하나를 분해 트리로 그리기

일상에서 손이 많이 가는 일 하나를 골라(예: 생일 파티 준비·일주일 여행 짐 싸기·방 대청소), 그걸 분해 트리로 그려 보세요. 큰 일을 먼저 3~5개의 작은 단계로 나누고, 그중 아직 막막한 단계가 있으면 한 번 더 작게 쪼개면 됩니다. Step 1의 "반 평균 구하기" 트리를 본보기로 삼으세요. 다 그렸으면 스스로 물어보세요. "각 조각이 이제 어떻게 할지 바로 알겠는가?" 그렇다면 잘 분해된 거예요. 정답은 없어요. 같은 일도 사람마다 다르게 쪼갤 수 있습니다.

[응용] 반 평균 구하기를 의사코드로 적고 손으로 따라가기

다섯 명의 시험 점수로 반 평균을 구하는 의사코드를 직접 적어 보세요. Step 1에서 본 분해를 떠올리면 됩니다. 먼저 합계를 0으로 두고(합계 ← 0), 다섯 점수를 하나씩 더한 뒤(합계 ← 합계 + 점수), 마지막에 사람 수로 나누면(평균 ← 합계 ÷ 5) 돼요. 다 적었으면 점수 예시(예: 80, 90, 70, 100, 60)로 trace 표를 채워, 합계가 한 줄씩 어떻게 쌓이고 마지막에 평균이 얼마로 나오는지 손으로 확인해 보세요. 표의 칸은 회차·더하는 점수·합계 정도면 충분합니다.

[심화] 일부러 틀린 의사코드의 버그를 trace로 잡아내기

아래는 "가장 작은 수 찾기" 의사코드인데, 한 군데가 틀려 있어요. 수 3, 7, 2, 9, 5로 trace 표를 채워 어떤 값이 출력되는지 확인하고, 어디가 왜 틀렸는지 짚어 고쳐 보세요. (힌트: Step 8에서 했던 것처럼, 최솟값이 이상하게 변하는 줄을 찾으면 됩니다.)

최솟값 ← 첫 번째 수
나머지 수를 하나씩 보면서 반복
    만약 지금_수 가 최솟값 보다 크면
        최솟값 ← 지금_수
최솟값 출력

다 풀었으면 한 걸음 더 가 보세요. 만약 첫 줄을 최솟값 ← 0으로 바꾸면 어떤 문제가 생길까요? 수가 전부 0보다 큰 경우와, 전부 0보다 작은 경우를 각각 떠올려 보면 Step 5의 학생 질문에서 짚었던 함정이 보일 거예요.

생각해볼 주제

정답이 하나로 떨어지지 않는 질문들이에요. 혼자 곰곰이 생각해도 좋고, 같이 공부하는 사람과 이야기 나눠도 좋습니다.

1. 문제를 어디까지 쪼개야 적당할까?

Step 1에서 분해를 배우며 "이제 어떻게 풀지 알겠다 싶을 때까지 쪼갠다"고 했어요. 그런데 그 "적당함"이 늘 분명하진 않죠. 너무 안 쪼개면 여전히 막막하고, 너무 잘게 쪼개면 조각이 너무 많아져 오히려 헷갈려요. 여러분은 무엇을 기준으로 "이만하면 됐다"를 판단할 것 같나요? 요리·청소·여행 준비처럼 익숙한 일을 떠올리며, 자신만의 "적당한 조각 크기" 기준을 정리해 보세요.

2. 같은 답을 내는 두 절차 중, 무엇이 더 좋은 절차일까?

Step 7에서 가장 큰 수 찾기의 두 해법을 봤어요. 답은 같아도 노력이 달랐죠. 그런데 "좋은 절차"의 기준이 빠름 하나뿐일까요? 빨리 도는 절차, 읽고 이해하기 쉬운 절차, 나중에 고치기 쉬운 절차 중 무엇을 더 중요하게 볼지는 상황마다 다를 수 있어요. 빠르지만 알아보기 힘든 절차와, 조금 느려도 한눈에 이해되는 절차가 있다면 여러분은 어느 쪽을 고를 건가요? 그리고 그 선택이 달라지는 상황은 언제일까요?

3. 컴퓨터는 왜 스스로 "이 답은 틀렸어"라고 못 알아챌까?

Step 8에서 우리는 trace로 틀린 곳을 찾았어요. 그런데 가만 보면, 정작 그 틀린 절차를 돌린 컴퓨터는 "최솟값을 구하랬는데 최댓값을 내놓았다"는 걸 전혀 몰라요. 시킨 대로 충실히 2를 출력했을 뿐이죠. 왜 컴퓨터는 자기가 낸 답이 틀렸다는 걸 스스로 알아채지 못할까요? A-1에서 배운 "컴퓨터는 시킨 것만 한다"와 연결해서 생각해 보세요. 그리고 그렇다면 "맞는지 틀린지 판단하는 일"은 누구의 몫일지도요. 이 질문에 답해 보면, 왜 디버깅이 사람의 일인지가 또렷해질 거예요.