부스트캠프 문제 해결력 테스트 준비: 요구사항 해석과 논리 설계 연습

부스트캠프 문제 해결력 테스트를 준비할 때는 문제 이름이나 후기의 난이도 표현을 외우기보다, 공식 안내에서 확인되는 평가 목적을 연습 가능한 행동으로 바꾸는 편이 안전합니다. 확인한 웹·모바일 과정 안내는 요구사항 해석, 논리적 해결 설계, CS·프로그래밍 기본기를 다룹니다. 다만 지금 지원하는 기수의 언어, 시간, 도구, 문항 수는 최신 공고와 응시 화면에서 다시 확인해야 합니다. 먼저 Simulate rover movement on a grid로 한 번 풀어 보고, 이 글의 점검 절차로 풀이를 다시 검증하세요.

공식 사실: 부스트캠프 웹·모바일 과정의 공개 안내는 온라인 문제 해결력 테스트에서 CS·프로그래밍 지식, 문제 요구사항 해석, 논리적으로 해결책을 설계하는 능력을 설명합니다. 이번 재확인에서도 해당 페이지에는 2025년 10기 정보가 표시됩니다. 그 안내의 일정·언어·세부 범위는 그 기수의 정보이므로 다음 기수에도 같다고 단정할 수 없습니다. 후보자 보고: 동일 회차의 독립된 후보자 보고는 수집하지 않았습니다. 추론: 문장을 입출력 계약과 제약으로 바꾸고, 작은 반례로 설계를 먼저 검증한 뒤 구현·복잡도·설명을 한 흐름으로 연습한다.

지금 확인할 수 있는 범위와 모르는 범위 (Evidence boundary)

공식 과정 안내가 설명하는 것은 평가 역량의 큰 축이지, 다음 회차의 문제 수나 제한 시간, 모든 지원자에게 적용되는 도구 규칙이 아닙니다. 공고 날짜, 지원 트랙, 안내 페이지가 다르면 그 차이를 표로 적으세요. 후보자 보고: 이번 글은 같은 회차 응시자의 독립된 경험 보고를 수집하지 않았습니다. 추론: 그러므로 특정 난이도·합격선·문항 유형을 사실처럼 단정하지 않고, 요구사항 해석과 논리 설계라는 공식 문구에 직접 대응하는 연습을 제안합니다.

요구사항을 다섯 줄 계약으로 바꾸기 (Input contract)

문제를 받으면 먼저 입력의 단위와 범위, 출력의 의미, 상태 변화, 금지된 동작, 실패 조건을 기록합니다. “가장 가까운 값을 찾는다”라는 문장도 거리가 절댓값인지, 동률을 어느 값으로 깨는지, 입력이 정렬되어 있는지에 따라 풀이가 달라집니다. 한 줄의 모호함을 그냥 넘기지 말고, 샘플만으로 결정되지 않는 조건은 질문하거나 가정을 명시하세요.

예를 들어 격자 이동 문제라면 상태를 (행, 열, 방향)으로 두고, 명령이 한 번 적용될 때 벽을 넘어갈 수 있는지와 경계에 닿았을 때 위치·방향을 어떻게 바꾸는지 적습니다. 이는 실제 부스트캠프 문항이라는 뜻이 아니라 요구사항 해석 연습용 합성 사례입니다. 규칙 표를 만든 후 한 명령씩 적용하면 잘못된 조건 분기를 코드 전에 발견할 수 있습니다.

상태 전이를 고정한 모의 구현 (State transition)

다음은 이 글에서 정한 독립 연습 계약입니다. 3×3 격자, 시작 (1,0,동쪽), 장애물 (1,1)을 사용합니다. F가 막히면 위치와 방향을 그대로 유지하고 다음 명령을 처리합니다. L과 R은 제자리에서 90도 회전하며 북·동·남·서를 0·1·2·3으로 표시합니다. 이 정책은 부스트캠프의 기출 규칙이 아닙니다. 공식 안내가 말하는 요구사항 해석을 연습하기 위해 하나의 모호함을 없앤 예제입니다.

function step([r, c, d], command, rows, cols, blocked) {
  if (command === 'L') return [r, c, (d + 3) % 4];
  if (command === 'R') return [r, c, (d + 1) % 4];
  if (command !== 'F') throw new Error('unknown command');
  const dr = [-1, 0, 1, 0], dc = [0, 1, 0, -1];
  const nr = r + dr[d], nc = c + dc[d];
  if (nr < 0 || nr >= rows || nc < 0 || nc >= cols ||
      blocked.has(`${nr},${nc}`)) return [r, c, d];
  return [nr, nc, d];
}

명령 F,L,F,R,F를 적용하면 상태는 (1,0,1) → (1,0,1) → (1,0,0) → (0,0,0) → (0,0,1) → (0,1,1)입니다. 첫 F는 장애물 때문에 실패하지만 프로그램 전체를 끝내지 않습니다. 회전 뒤의 F가 새 방향을 사용한다는 점도 추적에서 드러납니다. “벽이면 종료”를 구현했다면 첫 명령 뒤의 상태까지만 나오므로, 최종 좌표만 보기 전에 최초로 달라지는 명령을 찾을 수 있습니다.

계약을 바꾸는 후속 연습은 한 가지만 택합니다. 이동 실패 시 남은 명령을 중단하도록 바꾸면 최종 결과가 어디에서 달라지는지 설명하세요. 이때 방향 배열이나 해시 구조를 교체할 이유는 없습니다. 바뀐 요구사항과 영향을 받는 반환·반복 제어만 연결하면 됩니다. JavaScript 예시는 과거 웹 풀스택 트랙과 같은 언어로 설명한 학습 코드이며, 다음 기수의 허용 언어나 실행 환경을 확인했다는 뜻은 아닙니다.

풀이 선택은 제약과 증명으로 정당화 (Constraint analysis)

모든 경우를 열거해도 되는지 먼저 계산합니다. 입력 크기 n이 작으면 O(n²) 후보가 가능할 수 있지만, n이 커지면 정렬·해시·그래프 탐색·동적 계획법처럼 구조를 이용해야 할 수 있습니다. 단지 익숙한 알고리즘 이름을 붙이지 말고, 최악 입력에서 수행 횟수와 메모리를 추정하세요.

정렬을 쓴다면 원래 순서가 필요한지, 해시를 쓰면 중복과 순서가 어떻게 되는지, 그래프를 만들면 도달 불가 상태를 어떻게 표시할지 말합니다. 구현 뒤에는 복잡도를 다시 계산하고, “매 단계에서 어떤 후보를 버려도 정답을 잃지 않는가?”라는 문장으로 선택의 근거를 설명하세요.

작은 반례로 논리 설계를 시험하기 (Counterexamples)

샘플과 정상 크기 사례 외에 빈 입력, 최소 크기, 중복, 동률, 최대 경계, 답이 없는 경우를 의도적으로 만듭니다. 각 케이스는 코드 줄을 실행하기 전에 기대 결과를 써 둡니다. 특히 조건문이 >인지 >=인지, 인덱스가 0부터인지 1부터인지, 마지막 원소를 루프가 처리하는지 테스트로 분리하세요.

격자 이동 합성 사례라면 시작점이 모서리인 경우, 한 칸짜리 격자, 이동을 한 번도 하지 않는 경우, 벽 바로 앞에서 반복 이동하는 경우가 좋은 경계입니다. 일반적인 정답 예시보다 규칙이 흔들리는 지점에서 반례가 더 큰 가치를 냅니다.

구현 순서와 시간 관리 (Implementation)

실제 제한 시간이 공지되면 그 시간에 맞춰 연습을 조정하세요. 그 전까지는 연습 세션을 읽기·계약 작성, 알고리즘 선택, 구현, 반례 확인, 설명의 다섯 구간으로 나눕니다. 막히면 새 아이디어를 계속 덧붙이기보다 현재 가정, 실패한 테스트, 가능한 단순한 대안을 소리 내어 정리합니다.

코드 작성 전에 입력 파싱과 반환 형식을 확인합니다. 이후 핵심 루프를 구현하고, 작은 직접 추적으로 상태를 검증한 다음 최대 제약에서 복잡도를 점검합니다. 테스트가 실패하면 전체 코드를 다시 쓰기보다 가장 먼저 달라진 상태 변수를 찾으세요. 이렇게 하면 디버깅이 추측이 아니라 관찰 가능한 절차가 됩니다.

CS와 코딩을 따로 외우지 않기 (CS fundamentals)

자료구조·알고리즘 설명을 실제 풀이의 선택으로 연결합니다. 큐를 골랐다면 FIFO가 필요한 이유, 해시를 썼다면 키 충돌과 중복 처리를 어떻게 다루는지, 재귀라면 종료 조건과 호출 깊이가 무엇인지 설명해 보세요. 공식 안내의 평가 역량을 이런 관찰 가능한 결과물로 바꾸면 “공부했다”가 아니라 “조건을 해석하고 선택을 검증했다”는 증거가 남습니다.

공개 페이지에서 확인한 범위와 개인 학습 계획을 섞지 마세요. 공개 자료에 특정 언어가 적혀 있어도 그 내용이 과거 기수라면 현재 사용 가능 언어라고 말할 수 없습니다. 최신 공고가 게시되면 그때 언어와 시험 도구를 확인하고 연습 환경도 맞춥니다.

모의 연습 결과물 (Practice evidence)

매 세션 뒤에 입력 계약, 선택한 알고리즘, 복잡도, 가장 중요한 반례, 수정 이유를 한 페이지에 남깁니다. 다음 세션에서는 같은 문제를 다시 풀기 전에 왜 이전 풀이가 맞는지 설명하고, 조건 하나를 바꿔도 풀이가 유지되는지 검증합니다. 정답을 한 번 맞힌 기록보다 설계 근거와 실패 케이스가 누적된 노트가 약점을 더 정확히 보여 줍니다.

요구사항 추적표를 실제 풀이로 옮기기 (Requirement trace)

합성 격자 예시를 더 구체화해 봅시다. 명령이 L, R, F라면 각 명령의 의미를 표로 만들고, F가 장애물 앞에서 실패할 때 위치를 유지하는지 프로그램을 종료하는지 적습니다. 모의 답안을 시작하기 전에 상태를 (행, 열, 방향)으로 정의하고, 범위 밖 입력이나 장애물에 대한 정책이 주어졌는지 확인합니다.

정책이 문제에 주어져 있으면 임의로 바꾸지 않습니다. 질문할 기회가 없다면 가정을 분명히 남기고, 그 가정이 입력 제약과 모순되지 않는지 검증합니다. 표의 각 행이 코드의 분기와 연결되면 요구사항 하나가 빠졌는지 찾기 쉽습니다. 이 예시는 실제 부스트캠프 문항이 아니라 해석 연습용 합성 사례입니다.

모의 풀이에서 실패 원인을 분류하기 (Failure categories)

한 문제를 틀렸을 때 정답 코드만 복사하면 같은 실수가 다른 문제에서 반복됩니다. 오답을 요구사항 오독, 알고리즘 선택, 상태 전이, 자료형·인덱스, 테스트 부족으로 나눠 기록합니다. 방향 회전에서 부호를 반대로 썼다면 알고리즘이 아니라 상태 전이 오류입니다. 분류가 정확해야 다음 연습이 문제 수 늘리기 대신 원인 교정으로 바뀝니다.

풀이 검토에는 가장 작은 반례, 최대 입력의 비용, 가정을 바꾸었을 때 영향을 받는 함수를 남깁니다. 이 질문은 정확성·효율성·설계 적응을 각각 확인합니다. 점수나 합격선은 공식 자료에 없으므로 임의의 숫자를 만들지 말고, 확인 가능한 산출물로 진전을 추적하세요.

연습 루틴을 지원 트랙에 맞추기 (Track selection)

공식 안내가 트랙별 언어나 지식 범위를 구분한다면 본인의 지원 공고와 일치하는 항목만 계획에 반영합니다. 다른 트랙의 라이브러리나 언어에 시간을 쓰기 전에 실제 적용 여부를 확인하세요. 기수가 바뀌면 공개 페이지도 업데이트될 수 있으므로 PDF 메모만 보지 말고 원본 링크와 확인 날짜를 기록합니다.

하루 연습은 요구사항 요약, 핵심 함수 구현, 최소 반례 자동화, 짧은 설명의 한 루프로 구성할 수 있습니다. 다음 날에는 이전 답을 보기 전에 같은 불변식과 실패 테스트를 재구성합니다. 이 루틴은 학습용 단위이며 공식 시험 시간이 아닙니다.

준비 흐름을 한눈에 보기 (Workflow)

질문으로 연습하고 최신 안내로 조정 (Practice questions)

아래 공식 페이지를 다시 확인한 뒤, 발표된 조건에 맞춰 모의 세션을 조정하세요. 연습 질문은 지원 프로그램의 기출이나 합격을 보장하지 않습니다.

Sources and Further Reading

• 부스트캠프 웹·모바일 메인 페이지 — 공개 과정과 확인 시점 보완.

• 부스트캠프 웹·모바일 과정 안내

• 부스트캠프 웹·모바일 프로그램

자료 범위: 공식 출처는 공개된 과정·모집 안내를 뒷받침합니다. 후보자 보고는 수집되지 않았고 실습 상황은 교육용 합성 예시입니다. 기수별 일정과 응시 규칙은 최신 공고와 본인에게 전달된 안내로 확인하세요.