개념 이해

대학 축제를 준비하는 학생회가 생수 240병을 받았습니다. 운영 부스는 6곳이고, 모든 부스에 같은 수량을 배정해야 합니다. 이 문제는 짧은 나눗셈 하나로 끝납니다. \(240 \div 6 = 40\), 부스당 40병입니다.

그런데 “축제 전체를 준비하라”는 과제는 전혀 다릅니다. 장소 예약, 부스 모집, 안전 관리, 홍보, 물품 구매, 예산 정산이 서로 얽혀 있어서 어디서부터 손대야 할지조차 막막합니다. 문제가 어려운 이유는 계산이 복잡해서가 아니라, 한꺼번에 다루기에 너무 크고 뒤엉켜 있기 때문입니다.

이 문제를 해결하는 데 필요한 사고는 다음과 같이 정리할 수 있습니다.

복잡한 문제를 해결 가능한 작은 단위로 나누고(문제 분해), 그 안에서 반복되는 해결 구조를 찾아 다시 사용한다(패턴 인식).

이 두 가지 사고는 컴퓨터가 있든 없든, 프로그래밍을 하든 안 하든 통하는 보편적인 문제 해결 방법입니다. 컴퓨팅 사고를 제안한 Wing (2006)은 이를 전공자만이 아니라 누구에게나 필요한 사고 역량이라고 설명했습니다. 그래서 비전공자를 위한 교양수업에서도 문제 분해와 패턴 인식을 가장 먼저 배웁니다.

flowchart LR
    A["복잡한 문제"] --> B["작은 문제로 분해"]
    B --> C["순서와 관계 확인"]
    C --> D["공통 패턴 발견"]
    D --> E["해결 규칙 재사용"]
    E --> F["새로운 문제에 적용"]

    style A fill:#fee2e2,stroke:#dc2626,stroke-width:2px
    style B fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style D fill:#ede9fe,stroke:#7c3aed,stroke-width:2px
    style F fill:#dcfce7,stroke:#16a34a,stroke-width:2px

그림 2-1. 문제 분해와 패턴 인식을 이용한 문제 해결 흐름

왜 복잡한 문제는 한 번에 풀기 어려울까?

사람이 한 번에 또렷하게 다룰 수 있는 정보의 양에는 한계가 있습니다. 축제 준비처럼 서로 영향을 주고받는 항목이 수십 개인 문제를 통째로 붙들면, 머릿속에서 항목들이 뒤엉켜 무엇부터 결정해야 하는지 판단하기 어렵습니다.

큰 덩어리를 작은 문제로 나누면 세 가지가 좋아집니다.

  • 각 부분을 따로 이해하고 검증할 수 있습니다.
  • 여러 사람이 부분을 나눠 맡거나, 순서를 정해 하나씩 처리할 수 있습니다.
  • 한 부분에서 문제가 생겨도 그 부분만 고치면 됩니다.

flowchart LR
    subgraph 큰 문제를 통째로
      X["축제 준비 전체<br/>(무엇부터?)"]
    end
    subgraph 작은 문제로 나눈 뒤
      Y1["장소·일정"]
      Y2["부스 운영"]
      Y3["안전 관리"]
      Y4["홍보"]
      Y5["물품·예산"]
    end
    X -.분해.-> Y1
    X -.분해.-> Y2
    X -.분해.-> Y3
    X -.분해.-> Y4
    X -.분해.-> Y5

    style X fill:#fee2e2,stroke:#dc2626,stroke-width:2px
    style Y1 fill:#dbeafe,stroke:#2563eb
    style Y2 fill:#dbeafe,stroke:#2563eb
    style Y3 fill:#fee2e2,stroke:#dc2626
    style Y4 fill:#ede9fe,stroke:#7c3aed
    style Y5 fill:#dcfce7,stroke:#16a34a

그림 2-2. 대학 축제 준비 문제의 분해

다만 나누는 데에는 순서가 있습니다. 무엇을 해결할지 정하기 전에 나누면 엉뚱한 조각이 만들어집니다. 그래서 분해의 출발점은 “문제가 정확히 무엇인가”를 분명히 하는 일입니다.

문제와 해결책을 구분하기

“축제 입장 줄이 길다”는 관찰된 현상입니다. “입구를 하나 더 만들자”는 해결책입니다. 두 문장 사이에는 정작 해결해야 할 문제가 빠져 있습니다.

구분 예시 확인할 내용
현상 축제 시작 직전에 입장 줄이 길다 몇 명이 언제 기다리는가?
원인 추정 입구 수가 부족한 것 같다 실제로 입구 수가 가장 큰 원인인가?
문제 평균 대기시간을 줄여야 한다 현재값과 목표값은 얼마인가?
해결책 입구를 추가한다 원인을 해결하며 제약조건을 지키는가?

해결책을 먼저 정해 버리면 실제 원인을 놓치기 쉽습니다. 만약 병목이 입구 수가 아니라 학생증 확인이나 안전검사 속도라면, 출입구만 늘려도 전체 대기시간은 거의 줄지 않습니다. 문제가 무엇인지 규정하는 일이 해결책을 고르는 일보다 먼저입니다.

문제를 측정 가능한 문장으로 바꾸기

“축제 입장을 편리하게 만들자”는 좋은 뜻이지만, 해결되었는지 확인할 수 없습니다. 범위와 기준을 넣으면 해결 가능한 문제가 됩니다.

축제 개막 전후 1시간 동안 학생증 확인·안전검사·손목띠 배부 시간을 측정하여 가장 오래 걸리는 단계를 찾고, 기존 출입 공간과 안전요원 안에서 평균 입장 대기시간을 20분에서 8분 이하로 줄인다.

이 한 문장에는 현재 상태, 목표 상태, 필요한 자료, 지켜야 할 제약조건이 모두 들어 있습니다.

요소 대학 축제 사례
현재 상태 평균 입장 대기시간 20분
목표 상태 평균 입장 대기시간 8분 이하
필요한 자료 학생증 확인·안전검사·손목띠 배부의 시작·종료 시각
만들어야 할 결과 가장 느린 단계와 개선안
제약조건 기존 출입 공간과 안전요원만 사용

문제를 이렇게 표현하고 나면 무엇을 조사하고 어떤 결과를 만들어야 하는지가 보이기 시작합니다. 이제 문제를 나눌 준비가 되었습니다.

문제 분해

문제 분해(Decomposition)는 복잡한 문제를 이해하고 해결하기 쉬운 작은 문제로 나누고, 그 결과를 다시 연결하는 사고 과정입니다.

문제 분해는 복잡한 문제를 해결 가능한 작은 문제로 나누고, 각 부분을 해결한 뒤 다시 결합해 원래 문제의 답을 얻는 사고이다.

핵심은 조각을 많이 만드는 데 있지 않습니다. 각 부분이 무엇을 해결하고 서로 어떻게 연결되는지를 밝히는 데 있습니다. Computing At School의 교사 지침은 문제 분해를 “문제를 구성요소로 나누어 각각을 이해·해결·개발·평가하는 사고”로 설명합니다. CAS 가이드, 8쪽

목표와 조건을 먼저 정한다

“대학 축제를 준비한다”만으로는 해결할 문제가 불분명합니다. 다음처럼 구체화합니다.

참가 부스 30곳이 운영되는 대학 축제를 정해진 예산 안에서 준비하고, 부스 참가 신청과 당일 운영 여부를 관리한다.

이 문장에는 목표뿐 아니라 부스 수·예산·관리 범위라는 조건이 들어 있습니다. (부스 30곳은 수업용 가정입니다.) 조건이 분명해야 어떤 하위 문제가 필요한지 정할 수 있습니다.

스스로 묻는 질문

  • 무엇이 완료되면 문제가 해결된 것인가?
  • 사용할 수 있는 시간과 자원은 무엇인가?
  • 반드시 지켜야 하는 조건은 무엇인가?

하위 문제로 나눈다

대학 축제 준비를 기능에 따라 나누면 다음과 같습니다.

하위 문제 필요한 정보(입력) 만들어야 할 결과(출력)
부스 참가 신청 관리 신청 동아리 정보, 모집 부스 수 참가 부스 명단
일정·장소 결정 축제 가능 시간, 공간 조건 확정 일정과 장소
예산 관리 가용 예산, 예상 비용 지출 계획
프로그램 구성 축제 목적, 방문객 특성 공연·행사 진행 순서
당일 운영 확인 확정 부스 명단 부스 운영 기록

이것은 가능한 분해안 중 하나입니다. 상황과 목적에 따라 다른 분해도 얼마든지 가능합니다.

아직 큰 부분은 다시 나눕니다. 예를 들어 부스 참가 신청 관리는 이렇게 더 잘게 분해할 수 있습니다.

flowchart TD
    R["부스 참가 신청 관리"]
    R --> S1["1. 동아리 신청 정보를 받는다"]
    R --> S2["2. 필수 정보 누락을 확인한다"]
    R --> S3["3. 중복 신청을 확인한다"]
    R --> S4["4. 모집 수에 따라 참가·대기를 결정한다"]
    R --> S5["5. 부스 선정 결과를 안내한다"]

    style R fill:#fef3c7,stroke:#d97706,stroke-width:2px
    style S1 fill:#dbeafe,stroke:#2563eb
    style S4 fill:#dcfce7,stroke:#16a34a

그림 2-3. 부스 참가 신청 관리의 세부 분해

이렇게 각 부분의 처리 순서와 조건까지 정하면 다음 단계인 알고리즘 설계로 자연스럽게 이어집니다. 다만 문제 분해를 단순한 “시간 순서 나열”과 같은 것으로 여기지는 않습니다. 분해의 목적은 순서를 적는 것이 아니라, 각 부분이 무엇을 입력받아 무엇을 만들어 내는지 밝히는 것입니다.

같은 수준으로 나눕니다. 다음 분해는 크기가 서로 맞지 않습니다.

  • 일정·장소 관리 · 참가 신청 관리 · 예산 관리 · 포스터 제목을 파란색으로 변경

앞의 세 항목은 큰 기능이고 마지막 항목은 세부 작업입니다. 같은 단계에는 비슷한 크기의 문제를 놓아야 합니다. 포스터 제목 색상은 “홍보물 제작” 아래의 더 작은 문제로 배치합니다.

부분 사이의 관계를 확인한다

나눈 하위 문제가 모두 독립적인 것은 아닙니다. 앞 작업의 결과가 있어야 다음 작업을 시작할 수 있는 경우가 많습니다.

  • 참가 부스가 정해져야 부스용 물품 수량을 확정할 수 있습니다.
  • 장소와 시간이 정해져야 축제 최종 안내문을 보낼 수 있습니다.
  • 참가 부스 명단이 있어야 당일 운영 여부를 확인할 수 있습니다.

그래서 “누가 무엇을 하는가”뿐 아니라 어떤 결과가 다음 작업에 필요한가를 함께 확인해야 합니다. 이 관계에는 두 가지 유형이 있습니다.

순차 관계 — 앞 결과가 있어야 다음을 시작

flowchart LR
    A["부스 신청 접수"] --> B["참가 부스 확정"]
    B --> C["부스 위치 배정"]
    C --> D["전기·안전시설 배치"]
    D --> E["최종 안내"]

    style A fill:#eff6ff,stroke:#2563eb
    style E fill:#dcfce7,stroke:#16a34a

그림 2-4. 축제 준비 업무의 순차 관계

병렬 관계 — 동시에 진행 가능

flowchart TD
    A["장소·일정 확정"] --> B["홍보물 제작"]
    A --> C["필요 물품 계산"]
    A --> D["안전계획 작성"]
    B --> E["행사 준비 최종 점검"]
    C --> E
    D --> E

    style A fill:#fef3c7,stroke:#d97706
    style B fill:#dbeafe,stroke:#2563eb
    style C fill:#dcfce7,stroke:#16a34a
    style D fill:#fee2e2,stroke:#dc2626
    style E fill:#ede9fe,stroke:#7c3aed,stroke-width:2px

그림 2-5. 축제 준비 업무의 병렬 관계

장소가 확정된 뒤에는 홍보물 제작·물품 계산·안전계획을 서로 다른 팀이 동시에 진행할 수 있습니다. 병렬로 처리하면 전체 시간이 줄지만, 마지막에 결과를 어떤 형식으로 합칠지 미리 정해야 합니다.

좋은 분해인지 검토한다

나누기만 하고 끝내면 안 됩니다. 다음 기준으로 분해의 품질을 점검합니다.

점검 기준 확인 질문
누락 목표 달성에 필요한 부분이 빠지지 않았는가?
중복 서로 다른 이름으로 같은 일을 다루고 있지 않은가?
크기 각 부분을 한 번에 이해하고 해결·검증할 수 있는가?
결합 부분의 결과를 합치면 원래 목표를 달성하는가?
명확성 각 부분이 주고받는 정보가 분명한가?

예를 들어 “축제 홍보 · 포스터 제작 · SNS 게시”를 같은 단계에 두면 중복이 생깁니다. 포스터와 SNS는 둘 다 홍보 방법이기 때문입니다. 같은 수준에서는 “홍보 대상 분석 · 메시지 작성 · 매체 선택 · 효과 확인”처럼 나누는 편이 낫습니다.

작게 나눌수록 항상 좋은 것은 아닙니다. 지금 이 문제를 해결할 사람이 이해하고 실행·검증할 수 있는 수준까지만 나눕니다. 지나치게 잘게 쪼개면 오히려 전체 그림을 잃습니다.

문제 분해와 역할 분담은 다르다

“A는 발표, B는 자료 조사, C는 디자인”은 역할 분담입니다. 문제 분해를 잘하려면 그 전에 어떤 작업과 결과물, 관계가 필요한지를 먼저 밝혀야 합니다.

역할 분담은 분해 결과를 바탕으로 이루어질 수 있지만, 두 개념은 같지 않습니다. 결정적인 차이는 이것입니다. 혼자 해결하는 문제에도 문제 분해는 필요합니다. 나눌 사람이 없어도, 문제 자체는 나누어야 풀리기 때문입니다.

패턴 인식

패턴 인식(Pattern Recognition)은 여러 사례나 문제에서 공통된 특징·관계·해결 절차를 찾아, 해결 방법을 재사용할 가능성을 발견하는 사고 과정입니다.

패턴 인식은 여러 문제에서 반복되는 구조와 공통점을 찾아, 이미 아는 해결 방법을 새로운 문제에 다시 쓸 수 있게 하는 사고이다.

문제를 잘 나누고 나면, 나눈 부분들 사이에서 “어, 이거 아까 그거랑 똑같네” 하는 지점이 보입니다. 그 반복을 알아채는 것이 패턴 인식입니다.

패턴은 숫자 규칙만이 아니다

패턴이라고 하면 흔히 “2, 4, 6, 8 다음은?” 같은 수열을 떠올립니다. 하지만 문제 해결에서 찾는 패턴은 훨씬 넓습니다. 다음은 이해를 돕기 위한 교육용 분류입니다.

패턴의 종류 찾는 대상 예시
특징의 공통성 대상들이 공유하는 속성 축제 신청서마다 신청자·연락처·신청 항목이 있음
처리 과정의 반복 반복되는 작업 순서 입력받기 → 확인하기 → 결과 알리기
문제 구조의 유사성 같은 방식으로 풀 수 있는 관계 부스 신청·공연 시간 신청·자원봉사 신청의 자격·가능 여부 확인

CAS 가이드도 “데이터에서뿐 아니라 해결 과정과 전략에서도 패턴을 찾으라”고 설명합니다. 우리가 주목할 것은 특히 세 번째, 문제 구조의 유사성입니다.

여러 사례를 같은 기준으로 비교한다

대학 축제 안에서 겉모습이 다른 세 신청 업무를 같은 기준으로 나란히 놓아 봅니다.

공통 처리 부스 참가 신청 공연 시간 신청 자원봉사 신청
요청 확인 동아리와 부스 종류 공연팀과 희망 시간 지원자와 희망 업무
가능 여부 확인 참가 조건과 남은 부스 공연 조건과 빈 시간대 지원 조건과 필요한 인원
결과 기록 참가 확정·대기 공연 시간 확정·대기 근무 배정·대기
결과 안내 부스 선정 결과 공연 시간과 무대 근무 시간과 담당 구역

세 업무는 대상이 다르지만 요청을 받고 → 조건을 확인하고 → 결과를 기록·안내하는 구조를 똑같이 공유합니다. (이 표는 특정 축제의 실제 운영 규정이 아니라 수업용 비교 모델입니다.) 이 공통 구조를 한 번 정리해 두면, 축제 안에서 새로운 신청 업무가 생겨도 처음부터 다시 설계하지 않아도 됩니다.

공통점과 차이점을 함께 찾는다

패턴을 찾았다고 모든 업무를 똑같이 처리할 수 있는 것은 아닙니다. 공통 구조 아래에는 저마다의 차이가 있습니다.

  • 부스 참가 신청에는 모집 수와 대기 동아리가 있습니다.
  • 공연 시간 신청에는 공연 길이와 시간대 중복이 있습니다.
  • 자원봉사 신청에는 업무별 필요 인원과 근무 가능 시간이 있습니다.

그래서 패턴을 볼 때는 늘 두 질문을 함께 던집니다.

무엇은 그대로 사용할 수 있는가? 무엇은 이 문제에 맞게 바꾸어야 하는가?

새로운 문제에 적용한다 — 일반화

공통 구조를 새로운 상황에 다시 쓰는 것을 일반화(Generalisation)라고 합니다. 이제 축제의 푸드트럭 참가 신청이라는 새 문제에 위의 “요청 → 확인 → 기록 → 안내” 구조를 적용하면서 다음 차이를 검토합니다.

  • 판매 가능한 음식 종류와 위생서류는 어떻게 확인할까?
  • 전기 사용량이 허용 범위를 넘으면 어떻게 처리할까?
  • 참가 취소가 발생하면 대기 푸드트럭을 어떻게 선정할까?

여기서 패턴 인식은 추상화·알고리즘 설계와 이어집니다. “비슷하다”고 말하는 데서 그치지 않고, 해결 방법 자체를 재사용하는 것이 목적입니다.

발견한 패턴을 검증한다

몇 개의 사례가 비슷하다고 해서 규칙이 늘 성립하는 것은 아닙니다.

  • 사례 몇 개만 보고 “항상 그렇다”고 결론 내리지 않습니다.
  • 그 공통점이 실제 문제 해결에 꼭 필요한 특징인지 확인합니다.
  • 예외 사례를 넣어도 규칙이 작동하는지 확인합니다.

예를 들어 “모든 축제 신청은 선착순으로 승인한다”는 규칙은, 심사나 추첨이 필요한 부스 신청에는 맞지 않습니다. 이때 “요청 → 확인 → 기록 → 안내”라는 공통 구조는 그대로 두고, 선정 규칙만 바꾸면 됩니다. 패턴은 문제를 단순하게 만들어 주지만, 조건을 무시하게 만드는 만능 공식은 아닙니다.

분해와 패턴 인식은 함께 작동한다

두 사고는 짝을 이룹니다. 분해로 문제를 나누면 그 안에서 반복되는 구조가 드러나고, 패턴을 먼저 알아채면 문제를 어떻게 나눌지가 보입니다.

구분 문제 분해 패턴 인식
핵심 질문 어떤 작은 문제로 나눌 수 있는가? 무엇이 비슷하거나 반복되는가?
사고 방향 전체를 부분으로 나누기 여러 부분·사례의 공통 구조 찾기
결과물 하위 문제, 각 부분의 역할과 관계 공통 규칙, 재사용 가능한 해결 방법
주의점 나눈 부분을 다시 연결할 수 있어야 함 차이점과 예외도 확인해야 함

두 개념은 언제나 한 방향으로만 흐르지 않습니다. 패턴을 먼저 발견한 뒤 문제를 다시 나눌 수도 있습니다.

flowchart LR
    A["복잡한 문제"] --> B["문제 분해"]
    B --> C["반복 구조 발견<br/>(패턴 인식)"]
    C --> D["공통 해결 방법 재사용"]
    C -.더 나은 분해로.-> B
    D --> E["추상화 · 알고리즘 설계"]

    style A fill:#fee2e2,stroke:#dc2626
    style B fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style C fill:#ede9fe,stroke:#7c3aed,stroke-width:2px
    style D fill:#dcfce7,stroke:#16a34a
    style E fill:#fef3c7,stroke:#d97706

그림 2-6. 문제 분해와 패턴 인식의 반복 관계

대학 축제 부스 신청 관리 설계 예시

대학 축제 부스 신청 관리에 문제 분해와 패턴 인식을 적용해 보겠습니다.

제시 조건

  • 모집 가능한 부스는 30곳이다.
  • 동아리 한 곳은 부스를 한 번만 신청할 수 있다.
  • 모집 수를 넘으면 대기 동아리로 등록한다.
  • 취소가 발생하면 신청 순서에 따라 대기 동아리를 승인한다.

문제 분해

부스 신청 관리는 다섯 개의 하위 문제로 나눌 수 있습니다. 각 단계의 출력은 다음 단계에서 사용할 입력이 됩니다.

작은 문제 필요한 정보 할 일 만들어지는 결과
신청 접수 동아리명, 대표자, 연락처, 부스 종류 신청 정보를 정해진 형식으로 기록한다 신청 기록
신청 정보 확인 신청 기록, 필수 항목 목록 누락된 항목과 동일 동아리의 중복 신청을 확인한다 유효 신청 목록, 보완 요청 목록
참가·대기 결정 유효 신청 목록, 모집 부스 수 30곳 신청 순서대로 참가 여부를 정하고 초과 신청을 대기로 분류한다 참가 부스 명단, 순서가 있는 대기 명단
결과 안내 참가·대기 명단, 대표자 연락처 참가·대기 여부와 이후 절차를 안내한다 발송 기록
취소 처리 취소 요청, 참가 명단, 대기 명단 취소 부스를 명단에서 제외하고 첫 번째 대기 동아리를 승인한다 갱신된 참가·대기 명단

이 분해에서는 단순히 일을 시간순으로 나열하지 않았습니다. 각 부분이 하나의 분명한 결과를 만들고, 그 결과가 다음 부분으로 전달되도록 구성했습니다. 예를 들어 신청 정보 검증을 통과하지 않은 신청은 참가·대기 결정에 포함되지 않습니다.

flowchart LR
    A["신청 접수"] --> B["신청 정보 검증"]
    B --> C["참가·대기 결정"]
    C --> D["결과 안내"]
    C --> E["취소 처리"]
    E --> D

    style A fill:#dbeafe,stroke:#2563eb
    style B fill:#fef3c7,stroke:#d97706
    style C fill:#ede9fe,stroke:#7c3aed,stroke-width:2px
    style D fill:#dcfce7,stroke:#16a34a
    style E fill:#fee2e2,stroke:#dc2626

그림 2-7. 부스 신청 처리 단계의 연결 관계

패턴 인식

부스 참가 신청과 같은 축제의 자원봉사 신청을 비교하면 공통 처리 구조와 서로 다른 조건을 함께 확인할 수 있습니다.

확인 항목 부스 참가 신청 자원봉사 신청 판단
요청 접수 동아리와 희망 부스 정보를 받는다 지원자와 희망 업무 정보를 받는다 신청 정보를 받는 구조는 같다
조건 확인 필수 정보, 중복 신청, 남은 부스를 확인한다 필수 정보, 중복 신청, 근무 가능 시간을 확인한다 검증 대상은 다르지만 확인 단계는 같다
승인·대기 모집 부스 수를 기준으로 결정한다 업무별 필요 인원을 기준으로 결정한다 기준값에 따라 승인과 대기를 나누는 구조는 같다
결과 기록·안내 부스 위치와 준비사항을 알린다 근무 시간과 담당 구역을 알린다 안내 내용은 다르지만 기록·안내 절차는 같다

따라서 요청 접수 → 조건 확인 → 승인·대기 결정 → 결과 기록 → 안내는 두 신청 업무에 재사용할 수 있습니다. 다만 부스 신청에서는 부스 수와 부스 종류, 자원봉사 신청에서는 업무별 필요 인원과 근무 가능 시간을 각각 반영해야 합니다.

예외 점검

처음 만든 절차가 실제 상황에서도 작동하려면 예외 처리까지 포함해야 합니다.

예외 상황 확인할 내용 처리 방법 바뀌는 결과
동일 동아리가 두 번 신청함 동아리 식별 정보와 기존 신청 기록 새 신청을 중복으로 표시하고 대표자에게 확인한다 유효 신청 목록에서 중복 1건 제외
참가 확정 동아리가 취소함 취소 동아리와 대기 명단의 첫 순서 참가 명단에서 취소 처리 후 첫 대기 동아리를 승인한다 참가·대기 명단과 안내 내용 갱신
대기 동아리가 없는 상태에서 취소함 대기 명단이 비어 있는지 확인 빈 부스로 기록하고 추가 모집 여부를 결정한다 운영 가능 부스 수와 배치도 갱신

이 예시는 문제를 나누는 것에서 끝나지 않습니다. 하위 문제의 연결 관계를 확인하고, 다른 신청 업무에서 반복되는 구조를 찾고, 예외가 발생했을 때 해결 절차를 다시 고치는 과정까지 보여 줍니다.

대학 축제 공연팀 시간 신청 설계 문제

축제 공연팀의 무대 시간을 배정하려고 합니다.

제시 조건

  • 공연 가능 시간은 오후 1시부터 5시까지이다.
  • 공연팀은 희망 시간 두 개와 공연 소요 시간을 제출한다.
  • 같은 시간에 두 팀을 배정할 수 없다.
  • 공연 사이에는 무대 정리를 위한 10분이 필요하다.
  • 배정된 팀이 취소하면 대기팀을 검토한다.

문제 1 — 문제 분해

공연팀 시간 신청 관리를 작은 문제로 나누어 표를 완성합니다. 각 행에는 그 일을 처리하는 데 필요한 정보, 실제로 할 일, 처리 후 만들어지는 결과를 적습니다.

작은 문제 필요한 정보 할 일 만들어지는 결과

표를 완성한 뒤, 작은 문제를 처리할 순서를 화살표로 연결해 한 줄로 작성합니다.

예: 신청 접수 → 신청 정보 확인 → 시간 배정 → 결과 안내

문제 2 — 패턴 인식

완성 예제의 부스 신청 절차와 공연팀 시간 신청 절차를 비교합니다.

  1. 그대로 재사용할 수 있는 처리 단계 세 가지를 찾습니다.
  2. 공연팀 신청에 맞게 바꾸어야 하는 조건 두 가지를 찾습니다.
  3. 두 문제에 공통으로 적용할 수 있는 처리 순서를 한 문장으로 표현합니다.

문제 3 — 예외 점검

다음 상황이 발생하면 어느 하위 문제를 수정해야 하며, 결과가 어떻게 바뀌어야 하는지 설명합니다.

  1. 두 공연팀이 같은 시간을 첫 번째 희망 시간으로 신청했다.
  2. 40분 공연 뒤에 10분의 무대 정리 시간이 확보되지 않았다.
  3. 공연 확정 팀이 취소했지만 대기팀의 공연 시간이 빈 시간보다 길다.

오개념에 대한 정확한 이해

흔한 오해 더 정확한 이해
문제 분해는 일을 여러 사람에게 나누는 것이다 역할 분담 이전에 해결할 문제의 구조를 나누는 것이다
문제는 최대한 잘게 나누면 좋다 이해·실행·검증이 가능한 수준으로 나눈다
패턴 인식은 수열의 다음 숫자를 맞히는 것이다 데이터·대상·처리 과정·해결 전략의 공통성을 찾는 것이다
비슷한 문제는 그대로 복사하면 된다 공통 부분을 재사용하되 조건과 예외를 확인한다
컴퓨팅 사고는 정해진 네 단계를 순서대로 거친다 여러 사고 요소를 필요에 따라 반복·조합한다
컴퓨터를 사용하면 컴퓨팅 사고다 문제를 어떻게 표현하고 해결 절차를 설계했는지가 중요하다

정리

  • 문제 분해는 해결할 부분을 찾는 사고입니다. 복잡성을 줄여 줍니다.
  • 패턴 인식은 다시 사용할 수 있는 해결 구조를 찾는 사고입니다. 노력을 줄여 줍니다.
  • 두 사고 모두 목표·조건·예외를 확인하며 반복적으로 다듬어야 합니다.