삼성전자 코딩테스트 준비: SW 역량테스트의 구현·디버깅 연습
Quick Overview
삼성전자 코딩테스트 준비를 위해 긴 구현 문제를 고르기 전에, 한 턴의 상태를 언제 읽고 언제 바꾸는지 설명해 보세요. 문제의 규칙을 함수로 나누고, 처음 어긋난 상태를 찾으며, 마지막 출력 형식까지 확인하는 연습이 필요합니다. 풀이 개수와 함께 같은 버그를 다시 찾고 고칠 수 있는 기록이 준비 상태를 더 구체적으로 보여줍니다.
삼성전자 코딩테스트 준비를 위해 긴 구현 문제를 고르기 전에, 한 턴의 상태를 언제 읽고 언제 바꾸는지 설명해 보세요. 문제의 규칙을 함수로 나누고, 처음 어긋난 상태를 찾으며, 마지막 출력 형식까지 확인하는 연습이 필요합니다. 풀이 개수와 함께 같은 버그를 다시 찾고 고칠 수 있는 기록이 준비 상태를 더 구체적으로 보여줍니다.

확인 범위: 2026년 10월 7일에 SWEA 공식 SW 역량테스트 안내와 두 독립된 2025년 하반기 삼성전자 DS 후보자 후기를 읽었습니다. 현재 지원 회차의 독립 보고 두 개는 확보하지 못했습니다. 따라서 이 글은 공식 학습 환경과 구현·디버깅 연습에 집중하며, 지금 받는 모든 초대장의 문항 수, IDE나 합격선을 확정하지 않습니다. 아래 격자는 원본 연습으로 삼성 기출이 아닙니다.
입력 해석과 테스트를 함께 연습하려면 PracHub의 긴 코딩 문제 준비 가이드를 참고할 수 있습니다. 그 페이지의 회사별 평가 조건을 삼성에 적용하는 것은 아닙니다. 여기서는 삼성 공식 학습 안내를 출발점으로, 상태를 단계별로 확인하는 별도 연습을 만듭니다.
공식 학습 안내와 이번 응시 안내를 분리하세요
공식 플랫폼 사실: SW Expert Academy의 역량테스트 안내는 문제 이해부터 코딩까지의 종합적인 문제해결 역량을 설명하며, 4시간 검정과 C/C++, Java, Python을 안내합니다. 같은 페이지에서 모의검정 예시와 해설로 이동할 수 있습니다. 이는 읽은 페이지의 안내이고, 모든 채용 경로의 현행 초대장을 대신하는 문서는 아닙니다.
본인의 초대장에서 전형명, 법인·부문, 날짜와 평가 유형을 먼저 확인하세요. “삼성 코테”라는 검색어 아래에는 다른 시기, 다른 부문과 다른 목적의 평가가 섞일 수 있습니다. 공식 학습 페이지의 숫자만 기억하기보다 자신의 응시 안내에 같은 조건이 있는지 대조하는 일이 우선입니다.
SWEA의 공식 모의검정 예시는 격자를 직사각형 지역으로 나누어 인구 조건을 최적화하는 문제를 제시합니다. 이 예시가 다음 시험의 유형 목록을 확정하는 것은 아닙니다. 공개 예시의 제한, 출력과 해설을 읽고, 어떤 상태와 선택을 표현해야 하는지 분석하는 연습에 사용하세요. 아래 원본 분배 문제는 그 예시를 복제하지 않습니다.
| 기록의 종류 | 확인한 범위 | 남겨야 할 구분 |
|---|---|---|
| 공식 SWEA 안내 | 학습 가이드, 공개 모의 예시, 페이지에 표시된 언어와 검정 설명 | 이번 채용 초대장과 일치하는지 별도 확인 |
| 2025 하반기 DS 후기 | 해당 작성자의 과거 응시와 디버깅 경험 | 다른 부문·현재 회차에 일반화하지 않기 |
| 본인의 초대장 | 실제 응시 날짜, 장소 또는 접속 경로, 언어·도구·제출 지시 | 확인 전에는 미확인으로 남기기 |
| 이 글의 원본 연습 | 동시 분배 규칙, 로컬 실행과 작은 기준선 비교 | 실제 기출·난이도·합격 예측과 분리 |
표를 채울 때 모르는 항목에 후기의 숫자를 대신 넣지 않습니다. IDE 버전, 허용 참고 자료나 출력 템플릿이 없다면 확인할 질문으로 남기세요. 접근이 가능한 연습 화면에서 조작을 익힐 수는 있지만, 그것이 실제 초대장의 모든 옵션을 재현한다고 말하려면 추가 증거가 필요합니다.
과거 후보자 보고에서는 실패 위치를 읽으세요
후보자 보고: 오리 5리의 2025년 10월 5일 글은 9월 28일 DS 응시와 4시간 진행을 기록하고, 한 문제를 구현했지만 시간 초과를 고치지 못했다고 설명합니다. IDE와 제출 형태에 관한 기억도 적었습니다. 2025 하반기 후기. 이는 작성자의 그 회차 경험입니다.
별도 후보자 보고: CSE STUDY BLOG의 같은 2025 하반기 DS 글도 9월 28일 응시와 4시간·두 문제를 언급합니다. 작성자는 특정 테스트에서 오류가 나 그림으로 상태를 추적했고, 숨은 경계 사례를 충분히 만들지 못했다고 회고합니다. DS SW개발 후기.
두 기록은 같은 과거 모집 시기를 읽는 데 도움이 되지만 현재 시험을 확인한 보고는 아닙니다. 작성자가 추측한 합격 기준은 공식 기준으로 사용하지 않습니다. 특히 “한 문제면 된다” 같은 문장은 해결한 문제의 판정, 숨은 테스트와 모집 조건을 확인하지 않고 준비 목표로 삼을 수 없습니다.
편집적 추론: 이 후기에서 가져올 수 있는 연습 질문은 “예제가 일부만 맞을 때 최초 실패 상태를 찾는가?”와 “시간 초과를 정확성 오류와 나눠 검사하는가?”입니다. 특정 알고리즘만 외우면 충분하다는 결론은 아닙니다. 원본 문제를 작게 설계해 두 관찰을 직접 남기는 방법으로 이어가세요.
원본 동시 분배 문제의 상태를 정의하세요
직사각형 격자의 각 칸에 음이 아닌 정수가 있고, 막힌 칸은 None으로 표시합니다. 한 턴에서 각 열린 칸은 시작 시점 값의 // 5를 상하좌우의 열린 이웃 각각에 보냅니다. 보낸 총량을 자신에게서 빼고 들어온 양을 더합니다. 격자 밖이나 막힌 칸에는 보내지 않습니다. 모든 칸의 분배는 동시에 일어납니다.
연습 계약은 행과 열 각각 1–50, 시작 값 0..10^6, 턴 수 0..1000입니다. 직사각형 유효 격자를 입력으로 주며, 이 핵심 함수는 외부 입력 파서를 포함하지 않습니다. 막힌 칸이 있을 때는 끝까지 막힌 상태를 유지합니다. 반올림이나 소수 계산이 아닌 정수 나눗셈을 사용한다는 점도 계약에 포함합니다.
이 문제의 핵심 단어는 “시작 시점”입니다. 위쪽 칸에서 받은 값을 같은 턴에 다시 분배하면 다른 문제를 풀게 됩니다. 변수 이름을 old와 new로 나누고, share를 어느 배열에서 읽어야 하는지 먼저 적어보세요. 위치를 나누는 것보다 읽기 시점을 나누는 것이 더 중요한 설계 판단입니다.
[[10,0],[0,0]]에서 왼쪽 위는 이웃 두 곳에 각각 2를 보내고 6을 남깁니다. 첫 상태는 [[6,2],[2,0]]입니다. 다음 턴에는 왼쪽 위의 시작 값 6에서 각각 1을 보내므로 [[4,3],[3,0]]이 됩니다. 받은 값을 해당 턴 안에서 다시 분배하지 않는 과정을 손으로 확인하세요.
| 턴 | 격자 상태 | 확인할 이유 |
|---|---|---|
| 0 | [[10,0],[0,0]] | 원본 입력을 변경하지 않고 보관 |
| 1 | [[6,2],[2,0]] | 이웃 수 2와 분배량 2를 분리 |
| 2 | [[4,3],[3,0]] | 이전 턴 결과를 새 읽기 상태로 사용 |
읽기 배열과 쓰기 배열을 분리해 구현하세요
다음 함수는 한 턴의 새 배열을 만든 뒤, 이전 배열에서만 분배량을 읽습니다. 막힌 칸은 새 배열에도 None으로 남깁니다. 이웃 목록을 먼저 구해 보낼 곳의 개수와 실제로 보낸 양이 같도록 합니다. 각 칸의 잔량과 유입량은 새 배열에만 더합니다.
def step(old):
rows, cols = len(old), len(old[0])
new = [[None if v is None else 0 for v in row] for row in old]
for r in range(rows):
for c in range(cols):
if old[r][c] is None:
continue
neighbors = [(nr, nc) for nr, nc in
[(r-1,c), (r+1,c), (r,c-1), (r,c+1)]
if 0 <= nr < rows and 0 <= nc < cols
and old[nr][nc] is not None]
share = old[r][c] // 5
new[r][c] += old[r][c] - share * len(neighbors)
for nr, nc in neighbors:
new[nr][nc] += share
return new
def simulate(grid, turns):
state = [row[:] for row in grid]
trace = [[row[:] for row in state]]
for _ in range(turns):
state = step(state)
trace.append([row[:] for row in state])
return trace
한 턴의 시간은 O(RC)입니다. 각 칸에서 네 방향만 살피기 때문입니다. T턴을 계산하면 O(TRC), 다음 상태만 보관하면 추가 메모리는 O(RC)입니다. 다만 원본 simulate 함수는 학습용 추적을 위해 모든 턴을 저장하므로 메모리가 O(TRC)입니다. 상태 계산과 디버그 기록의 비용을 구분해야 합니다.
큰 입력에서 전체 기록이 필요 없다면 현재와 다음 배열만 교체하세요. 오류를 찾는 작은 입력에서만 전체 추적을 켜는 구조가 가능합니다. 이를 바꿀 때는 기록이 사라져도 계산 결과가 같은지 확인합니다. 이 글은 원격 평가 환경의 제한 시간을 측정하지 않았으므로 이 복잡도가 특정 채점기를 통과한다고 보장하지 않습니다.
배열의 행이 서로 독립적인지도 확인해야 한 칸의 변경이 다른 행까지 번지는 오류를 찾을 수 있습니다. 각 행을 별도로 만들어야 서로 다른 행의 값 변경이 연결되지 않습니다. Python에서 같은 행 객체를 여러 번 반복해 격자를 만들면 한 칸을 바꿀 때 다른 행도 바뀔 수 있습니다. 상태 규칙을 올바르게 적었더라도 저장 구조가 그 규칙을 지키는지 작은 행 변경으로 검사하세요.
총합 보존만으로 정답을 확정할 수 없습니다
모든 분배가 열린 칸 사이에서 이루어지므로 열린 칸의 총합은 보존되어야 합니다. 음수 값이 없어야 하고, 막힌 칸은 그대로여야 하며, 이전 배열도 변경되지 않아야 합니다. 이런 불변식은 여러 오류를 빨리 찾는 데 도움이 됩니다. 하지만 필요조건을 만족하는 것과 각 칸의 정답이 맞는 것은 다릅니다.
원본 반례 [[50,0],[0,0]]의 한 턴 정답은 [[30,10],[10,0]]입니다. 같은 배열을 행 순서대로 읽고 즉시 갱신하는 잘못된 구현은 [[34,6],[6,4]]를 만들었습니다. 두 결과 모두 총합은 50입니다. 첫 칸이 만든 값을 뒤 칸이 다시 사용하면서 턴의 의미가 달라졌습니다.
따라서 총합 검사와 전체 상태 비교를 함께 합니다. 순회 방향을 바꾸어도 동시 갱신 문제의 결과는 같아야 합니다. 정방향과 역방향 구현이 다른 결과를 내면 입력 순서가 규칙에 섞였는지 살펴보세요. 이것은 실제 삼성 출제 유형을 예측하는 규칙이 아니라 이 원본 동시 분배 계약의 검사 방법입니다.
독립 기준선은 열린 칸 쌍의 맨해튼 거리가 1인지 검사하고, 각 쌍에 대한 이동량을 변화량 장부에 기록합니다. 본 구현의 네 방향 목록을 그대로 복사하지 않습니다. 기준선은 느리지만 작은 격자에서 이해하기 쉽습니다. 공간과 시간의 상한이 다르므로 대형 입력을 그 기준선으로 검증하려고 하지 않습니다.
로컬에서는 2×2 값 0–5의 모든 조합과 막힌 칸·한 줄·한 칸 사례, 총 1,300개 격자를 각각 세 턴 비교했습니다. 세 턴씩 총 3,900번의 상태 비교에서 독립 기준선과 일치했고 총합과 음수 조건을 확인했습니다. 앞의 잘못된 동시 갱신 반례는 별도로 실행했습니다. 이 영역의 확인을 모든 확장 규칙에 대한 증명으로 표현하지 않습니다.

처음 어긋난 턴을 찾는 디버깅 순서를 만드세요
최종 배열 전체를 보고 여러 조건을 한꺼번에 바꾸면 원인을 확인하기 어렵습니다. 정답 기준선과 구현의 첫 다른 턴을 찾고, 그 턴의 첫 다른 칸을 선택하세요. 예를 들어 모서리 칸의 이전 값 50, 이웃 두 곳, 분배량 10과 잔량 30을 먼저 적고 유입량을 대조합니다. 어느 단계에서 값이 달라졌는지 확인하면 수정 범위가 작아집니다.
예를 들어 모서리에서만 다르면 이웃 수와 격자 밖 처리부터 살핍니다. 막힌 칸 근처에서만 다르면 보내는 위치와 잔량 계산에 같은 이웃 정책이 적용되는지 확인합니다. 둘째 턴 이후에만 다르면 이전 상태가 변경되었거나 추적 배열이 같은 객체를 공유하는지 볼 수 있습니다. 관찰과 가능한 원인을 연결하되 결과만 보고 확정하지 않습니다.
반례를 줄일 때는 오류를 유지하는지 매번 확인합니다. 격자 크기, 값과 턴 수를 하나씩 줄이고, 더 작은 입력에서도 같은 단계가 어긋나는지 봅니다. 원인이 소수 처리라고 생각해 임의로 반올림을 붙이지 마세요. 먼저 계약의 정수 나눗셈과 자신의 실제 연산을 비교하는 편이 근거가 있습니다.
수정 뒤에는 최소 반례와 원래 실패 입력을 모두 재실행합니다. 새 구현이 막힌 칸이나 0턴에서 기존 동작을 바꾸지 않았는지도 확인하세요. 보존식이 다시 맞아도 전체 상태 비교가 남아 있습니다. 디버깅 기록은 “통과함”으로 끝내지 말고 어떤 읽기 시점이 바뀌었는지 한 문장으로 남깁니다.
정확성 검사와 실행 환경 확인을 따로 끝내세요
SWEA 공개 예시와 본인에게 허용된 연습 화면을 사용해 진입점, 입력과 출력 형태를 익히세요. 사이트 이름이 같다는 이유로 함수 제출과 표준 입력 제출이 같다고 가정하지 않습니다. 테스트 케이스 번호를 붙이는지, 줄바꿈이 필요한지, 디버그 출력이 남아 있는지 실제 지시와 대조합니다.
과거 후보자의 IDE 기억은 사용할 수 있는 단축키 목록의 보장이 아닙니다. 현재 환경에서 지원되는 도구와 버전을 확인하고, 짧은 프로그램을 저장·실행하는 동작부터 익히세요. 외부 도구, 웹 검색과 AI의 허용 여부도 초대장에 따릅니다. 공개 연습 플랫폼에서 가능한 동작을 실제 평가의 허용 규칙으로 바꾸지 않습니다.
정확한 구현이 느리다면 어떤 작업이 반복되는지 세어봅니다. 이번 핵심은 칸마다 네 이웃을 확인하지만 독립 기준선은 칸 쌍을 검사합니다. 추적 저장, 화면 출력과 디버거도 관찰 시간을 바꿀 수 있습니다. 성능을 측정할 때는 무엇을 포함했는지 적고, 작은 디버그 실행의 시간으로 큰 입력을 예측하지 마세요.
다음 연습을 시작할 때는 이전 실패와 다른 경계를 선택하세요. 한 줄 격자는 상하 방향의 부재를, 막힌 칸은 이동 대상의 제외를, 0턴은 입력 보존을 검사합니다. 한 사례에 모든 조건을 넣기보다 각각의 기대값을 설명할 수 있게 나누면 구현과 환경 중 어디가 문제인지 진단하기 쉽습니다.
아래 PracHub 자료는 격자 상태, 탐색과 변환을 다른 계약으로 연습하기 위한 질문입니다. 일부 상세 내용은 로그인이나 멤버십에 따라 제한될 수 있습니다. 삼성의 다음 시험 문제나 공개 기출 출처라는 의미가 아닙니다.
| PracHub 질문 | 이 글과 연결되는 연습 |
|---|---|
| Infection Spread on a Grid (Cellular Automaton) | 이전 상태와 다음 상태를 분리하기 |
| Grid State After a Given Number of Days of Spoilage Spreading to Neighbors | 지정된 일수와 이웃 확산 경계를 검사하기 |
| In-Place Rectangle Copy Within a 2D Array Using O(1) Extra Memory | 복사 방향과 겹침으로 생기는 변경을 추적하기 |
| Implement flood fill using BFS and DFS | 연결 성분의 방문 상태를 검증하기 |
| Grid Robot Command Simulator | 명령·좌표·방향의 상태 전이를 손 계산하기 |
연습 기록에는 입력, 기대 상태, 실제 상태와 수정 이유를 함께 남기세요. 예를 들어 50의 반례는 총량이 맞아도 동시 갱신이 틀릴 수 있다는 관찰입니다. 막힌 칸을 추가했을 때에는 해당 칸을 이웃 수에서 빼야 한다는 관찰이 따로 필요합니다. 서로 다른 실패를 한 줄의 “구현 실수”로 묶으면 다음 문제에서 무엇을 먼저 확인해야 할지 알기 어렵습니다.
설명 연습에서는 코드 화면을 닫고 한 턴을 말로 재구성해 보세요. 시작 값에서 분배량을 계산하고, 유효한 이웃만 선택하고, 잔량과 유입량을 새 배열에 더한다는 순서를 설명합니다. 그 뒤 자신의 함수에서 각 문장을 담당하는 줄을 찾으세요. 설명과 구현이 다르면 외운 설명을 고칠지 실제 코드를 고칠지 계약을 기준으로 판단해야 합니다.
다음으로 Infection Spread on a Grid (Cellular Automaton)을 열고 현재 턴과 다음 턴의 상태를 표로 적어보세요. 그 문제에서는 감염 규칙이 달라 총합 보존을 그대로 적용할 수 없습니다. 조건을 다시 읽고 최초 다른 턴을 찾는 절차만 옮겨가는 것이 목표입니다. 실제 응시 전에는 이 연습 결과와 별도로 본인 안내의 언어·도구·제출 계약을 마무리하세요.
Comments (0)