방송대 파이썬프로그래밍기초 14강: SDLC와 이벤트 기반 틱택토 설계

방송대 파이썬프로그래밍기초 14강: SDLC와 이벤트 기반 틱택토 설계

틱택토는 규칙이 단순하지만 프로그램으로 옮기려면 게임판의 상태, 입력 사건, 승리 판정, 종료 조건을 빠짐없이 연결해야 한다. 이 글은 아이디어를 곧바로 코드로 옮기지 않고 소프트웨어 개발 생명주기로 요구를 정리한 뒤, 이벤트 기반 게임 루프와 8개 승리선을 구현 가능한 설계로 바꾸는 과정을 추적한다.

“게임을 만든다”는 말만으로는 구현을 시작할 수 없다

사용자와 컴퓨터가 번갈아 O와 X를 놓는다는 설명에는 아직 결정하지 않은 것이 많다. 누가 먼저 시작하는가, 이미 채운 칸을 다시 선택하면 어떻게 하는가, 어느 시점에 승리와 무승부를 검사하는가, 사용자가 게임을 중단하는 방법은 무엇인가를 정해야 한다. 이런 빈틈을 둔 채 코드를 쓰면 함수마다 서로 다른 규칙을 가정하게 된다.

실전 프로젝트의 첫 과제는 코딩이 아니라 관찰 가능한 동작을 요구사항으로 고정하는 일이다. 입력, 상태 변화, 출력, 종료라는 네 축으로 문장을 바꾸면 모호함을 줄일 수 있다.

설계 질문	틱택토에서 정할 내용	확인 가능한 결과
무엇을 입력받는가?	사용자의 행·열 좌표 또는 종료 신호 00	허용된 입력인지 판정
어떤 상태가 바뀌는가?	3×3 게임판의 한 빈칸	선택 위치에 O 또는 X 기록
무엇을 출력하는가?	매 차례의 현재 게임판과 종료 메시지	사용자가 진행 상황을 확인
언제 끝나는가?	승리, 빈칸 없음, 사용자 종료 요청	게임 루프에서 이탈

설계 핵심: 기능 요구사항은 “게임이 된다”가 아니라 입력 조건, 상태 변화, 출력 결과와 종료 조건을 검사할 수 있는 문장으로 적는다.

SDLC는 계획부터 유지보수까지 개발을 하나의 흐름으로 묶는다

소프트웨어 개발 생명주기(SDLC)는 개발 계획을 세우는 시점부터 프로그램을 사용하고 수정하는 시점까지의 전체 과정을 체계화한 틀이다. 큰 소프트웨어는 인력과 시간이 많이 들기 때문에, 처음 예상한 결과를 안정적으로 만들려면 단계별 산출물과 검토 기준이 필요하다.

단계	핵심 질문	틱택토에 적용한 산출물
계획	비용·기간·자원을 어떻게 투입할까?	텍스트 기반 1인용 게임이라는 범위
분석	어떤 기능·비기능 요구가 필요한가?	규칙, 입력 방식, 종료 신호, 출력 조건
설계	구조·데이터·인터페이스를 어떻게 나눌까?	게임판, 승리선, 턴 처리, 판정 함수
구현	어떤 언어와 코딩 규칙으로 작성할까?	파이썬 함수와 반복문으로 작성한 코드
테스트·통합	예상 결과와 같고 오류가 없는가?	8개 승리, 무승부, 중복 좌표, 종료 입력 검사
유지보수	오류·새 요구·환경 변화에 어떻게 대응할까?	입력 규칙 수정, 난이도 개선, 표시 방식 변경

단계를 한 번 통과하면 영원히 돌아오지 않는다고 이해하면 곤란하다. 테스트에서 대각선 승리 판정이 빠졌다면 설계의 승리선 정의로 되돌아가 수정해야 한다. 유지보수에서 새 요구가 생기면 분석과 설계를 다시 검토한다. 생명주기의 가치는 순서를 외우는 데 있지 않고, 문제가 발견됐을 때 어느 결정으로 돌아가야 하는지 알려 주는 데 있다.

배치 프로그램과 게임은 실행을 움직이는 원인이 다르다

일반적인 배치 프로그램은 준비된 데이터 파일을 정해진 처리 절차에 따라 가공하고 결과 파일을 만든다. 입력과 처리 순서를 어느 정도 예상할 수 있다. 반면 게임은 사용자가 버튼이나 좌표를 언제 입력할지, 종료를 요청할지 미리 정할 수 없다. 프로그램이 다음 사건을 기다렸다가 그 종류에 맞는 코드를 실행해야 한다.

비교 기준	배치 프로그램	이벤트 기반 프로그램
실행의 출발점	미리 준비된 데이터와 처리 순서	사용자 동작이나 외부 사건
흐름 예측	처리 단계가 비교적 고정됨	다음 이벤트의 종류·시점이 달라짐
주요 구조	입력 → 처리 → 출력	이벤트 감지 → 처리 → 상태·화면 갱신
틱택토와의 관계	완성된 대국 기록 일괄 분석	매 차례 좌표 입력과 종료 요청에 반응

이벤트(event)는 프로그램이 감지하고 처리할 수 있는 사용자 동작이나 사건이다. 이벤트 기반 프로그래밍(EDP)은 입력장치, 타이머, 다른 프로그램 등에서 발생하는 이벤트를 중심으로 실행을 조직한다. 실행 흐름을 미리 한 줄로 예측하기 어려운 환경에 적합하다.

이벤트 큐와 핸들러는 발생 시점과 처리 시점을 분리한다

사건이 발생했다고 즉시 임의의 코드가 실행되는 것은 아니다. 이벤트 발생 장치가 사건을 만들면 이벤트 유형과 필요한 정보가 이벤트 큐에 저장된다. 이벤트 루프는 큐에서 이벤트를 가져오고, 이벤트가 있는지 확인한 뒤 유형에 맞는 이벤트 핸들러에 전달한다. 핸들러는 해당 사건에 반응하는 실행 코드다.

1. 생성: 좌표 입력, 버튼 클릭, 타이머 완료처럼 사건이 발생한다.
2. 저장: 이벤트를 큐에 넣어 발생 순서를 보존한다.
3. 가져오기: 이벤트 루프가 처리할 이벤트를 큐에서 꺼낸다.
4. 검사·전달: 유형과 조건을 확인해 알맞은 핸들러로 보낸다.
5. 처리: 핸들러가 게임판이나 프로그램 상태를 바꾼다.

반복:
    이벤트 = 큐에서 가져오기
    이벤트가 있으면:
        유형과 유효성을 검사
        알맞은 핸들러에 전달
        프로그램 상태를 갱신

큐와 핸들러를 구분하면 같은 입력이라도 처리 책임을 분리할 수 있다. 예를 들어 00은 종료 핸들러가, 유효한 좌표는 착수 핸들러가 처리한다. 큐는 사건을 보관하는 구조이고 핸들러는 사건에 대응하는 행동이므로 둘을 같은 것으로 보면 안 된다.

게임 루프는 상태를 바꾸고 보여 주는 순서를 반복한다

게임은 초기화 후 이벤트 검사 → 이벤트 처리 → 게임 상태 업데이트 → 화면 생성 → 화면 업데이트를 반복한다. 틱택토의 텍스트 화면에서는 화면 생성과 업데이트가 현재 게임판 출력으로 나타난다. 승리·무승부·종료 요청이 확인되면 루프를 빠져나간다.

게임판과 플레이어를 초기화한다
게임이 끝날 때까지 반복한다
    현재 게임판을 출력한다
    다음 플레이어의 이벤트를 받는다
    이벤트가 종료 요청이면 반복을 끝낸다
    좌표가 유효하면 게임판을 갱신한다
    현재 플레이어의 승리를 검사한다
    빈칸이 없으면 무승부로 끝낸다
    다음 플레이어로 교대한다

순서가 바뀌면 오류가 생긴다. 착수 전에 승리를 검사하면 방금 둔 수가 반영되지 않고, 승리보다 먼저 다음 플레이어로 바꾸면 승자를 잘못 출력할 수 있다. 또 유효하지 않은 좌표인데도 턴을 넘기면 실제 착수 없이 플레이어만 바뀐다. 상태를 바꾸는 지점과 판정하는 지점을 한 흐름에서 함께 확인해야 한다.

실패 원인: ‘반복문이 있으니 게임 루프가 완성됐다’고 생각하기 쉽다. 반복 내부에 입력 검사, 상태 변경, 종료 판정, 출력 갱신이 올바른 순서로 연결되어야 실제 게임 루프가 된다.

틱택토의 규칙은 불변 조건과 종료 조건으로 나눈다

틱택토는 두 플레이어가 3×3 판에 번갈아 O와 X를 기록하는 게임이다. 이미 기록된 칸에는 다시 둘 수 없고, 같은 기호가 가로·세로·대각선의 한 줄을 채우면 그 플레이어가 승리한다. 승자가 없는데 빈칸도 없으면 무승부다.

규칙 종류	프로그램이 지켜야 할 조건	검사 시점
턴 불변 조건	사용자와 컴퓨터가 한 번씩 번갈아 둠	유효한 착수가 끝난 뒤
칸 불변 조건	빈칸에만 현재 플레이어 기호를 기록	게임판 갱신 직전
승리 조건	현재 기호가 승리선 하나의 세 칸을 모두 차지	각 착수 직후
무승부 조건	승리선은 없고 빈칸도 없음	승리 검사 직후
사용자 종료	사용자가 00을 입력	좌표 해석 전

승리와 무승부의 순서가 중요하다. 마지막 빈칸을 채운 수가 동시에 승리선을 만들 수 있으므로 먼저 승리를 검사하고, 승리가 아닐 때만 빈칸이 없는지 확인한다. ‘게임판이 가득 찼다’만 보고 곧바로 무승부라고 판정하면 마지막 수의 승리를 놓친다.

게임판은 독립된 아홉 칸을 가진 2차원 리스트로 만든다

게임판은 행과 열 좌표로 접근해야 하므로 3×3 2차원 리스트가 적합하다. 강의에서는 빈칸을 *로 표시한다. 직접 구성한 다음 초기화는 각 행을 별도의 리스트로 만들어 한 칸을 바꿔도 다른 행이 함께 바뀌지 않게 한다.

EMPTY = "*"
board = [[EMPTY for column in range(3)] for row in range(3)]

board[1][2] = "O"

for row in board:
    print(" ".join(row))

출력은 첫째 행 * * *, 둘째 행 * * O, 셋째 행 * * *다. board[행][열]에서 두 인덱스의 범위는 모두 0~2다. 사용자에게 1~3을 입력받는다면 내부 인덱스로 쓰기 전에 각각 1을 빼야 한다.

# 잘못된 초기화: 세 행이 같은 리스트를 가리킨다.
wrong_board = [["*"] * 3] * 3
wrong_board[0][0] = "X"
print(wrong_board)
# [['X', '*', '*'], ['X', '*', '*'], ['X', '*', '*']]

곱셈으로 바깥 리스트를 만들면 같은 안쪽 리스트의 참조가 세 번 반복된다. 그래서 한 칸만 바꾸려 했는데 한 열의 세 칸이 함께 바뀐다. 2차원 리스트에서는 행마다 새 리스트를 만드는 컴프리헨션을 사용해야 한다.

빈칸 검사는 전체 상태를 불리언 하나로 줄인다

게임을 계속할 수 있는지는 아홉 칸 가운데 *가 하나라도 있는지 확인하면 된다. 행 단위 반복과 칸 단위 반복을 결합하면 게임판 전체를 검사할 수 있다.

def has_empty(board):
    for row in board:
        for cell in row:
            if cell == "*":
                return True
    return False

함수는 첫 빈칸을 발견하는 즉시 True를 반환한다. 모든 칸을 확인할 때까지 빈칸을 찾지 못해야 마지막 False에 도달한다. return False를 안쪽 반복문에 넣으면 첫 행만 보고 결론을 내리게 되므로 들여쓰기가 판정 범위를 바꾼다.

판정 핵심: ‘하나라도 존재’는 발견 즉시 참을 반환하고, ‘하나도 없음’은 전체 검사가 끝난 뒤 거짓을 반환한다.

승리 판정은 여덟 개의 좌표 묶음을 같은 규칙으로 검사한다

3×3 틱택토의 승리선은 행 3개, 열 3개, 대각선 2개로 모두 8개다. 여덟 경우를 별도의 if로 흩어 놓기보다 좌표 묶음으로 먼저 정의하면 ‘세 칸이 모두 현재 기호인가?’라는 한 규칙을 반복할 수 있다.

WIN_LINES = [
    [(0, 0), (0, 1), (0, 2)],
    [(1, 0), (1, 1), (1, 2)],
    [(2, 0), (2, 1), (2, 2)],
    [(0, 0), (1, 0), (2, 0)],
    [(0, 1), (1, 1), (2, 1)],
    [(0, 2), (1, 2), (2, 2)],
    [(0, 0), (1, 1), (2, 2)],
    [(0, 2), (1, 1), (2, 0)]
]

def is_winner(board, mark):
    for line in WIN_LINES:
        if all(board[row][column] == mark for row, column in line):
            return True
    return False

예를 들어 [(0, 2), (1, 1), (2, 0)]은 오른쪽 위에서 왼쪽 아래로 내려오는 대각선이다. all은 세 좌표가 모두 현재 기호일 때만 참이 된다. 승리선을 데이터로 분리하면 누락된 방향을 세기 쉽고, 판정 코드는 한 규칙으로 유지된다.

검산할 때는 8개의 승리판뿐 아니라 거의 완성된 반례도 넣어야 한다. 같은 기호가 두 칸뿐인 경우, 서로 다른 기호가 섞인 경우, 빈칸이 포함된 경우가 모두 거짓인지 확인하면 ‘같은 기호 세 개’라는 조건을 정확히 검사할 수 있다.

사용자와 컴퓨터의 선택은 생성 방식만 다르고 검증은 같다

게임 시작 시 먼저 둘 플레이어는 무작위로 선택한다. 사용자와 컴퓨터는 각각 O와 X를 사용하지만 어느 기호가 누구에게 배정되는지는 설계에서 일관되게 고정해야 한다. 사용자는 행·열 좌표를 입력하고, 컴퓨터는 남은 빈칸 가운데 하나를 무작위로 선택한다.

import random

def empty_positions(board):
    positions = []
    for row in range(3):
        for column in range(3):
            if board[row][column] == "*":
                positions.append((row, column))
    return positions

starter = random.choice(["사용자", "컴퓨터"])
computer_move = random.choice(empty_positions(board))

컴퓨터의 좌표를 0~2에서 각각 무작위로 뽑기만 하면 이미 채운 칸이 나올 수 있다. 먼저 빈칸 목록을 만든 뒤 그 목록에서 선택해야 게임 규칙을 보장한다. 사용자 입력도 숫자 범위와 빈칸 여부를 통과한 경우에만 같은 게임판 갱신 함수로 보내는 편이 안전하다.

공통 검증 원칙: 입력의 출처가 사용자든 난수든 게임판을 바꾸기 전에는 좌표 범위와 빈칸 여부를 검사한다. 생성 방법이 다르다고 규칙까지 달라지는 것은 아니다.

한 차례는 입력·검증·갱신·판정·교대의 원자적 흐름이다

틱택토의 한 차례를 작은 상태 전이로 보면 전체 게임 루프를 설계하기 쉽다. 현재 플레이어가 좌표를 만든 뒤 유효성을 확인하고, 성공한 경우에만 기호를 기록한다. 이어서 승리, 빈칸 여부를 검사하고 게임이 계속될 때만 플레이어를 교대한다.

순서	질문	실패했을 때
입력	종료 요청인가, 좌표 선택인가?	종료라면 즉시 루프 이탈
검증	범위 안이며 빈칸인가?	게임판과 턴을 유지하고 다시 입력
갱신	현재 위치에 현재 기호를 기록했는가?	판정 단계로 넘어가지 않음
판정	승리인가, 아니면 빈칸이 없는가?	승리·무승부 메시지 후 종료
교대	게임이 계속되는가?	다음 플레이어로 바꿔 반복

이 흐름은 잘못된 입력에서 특히 중요하다. 이미 채운 칸을 선택한 경우 게임판이 바뀌지 않았으므로 승리 판정이나 턴 교대를 해서는 안 된다. 반대로 유효한 착수 뒤에는 판정을 생략하지 않아야 한다. ‘상태가 실제로 바뀌었는가?’를 교대의 조건으로 두면 두 오류를 함께 막을 수 있다.

설계 검토는 정상 경로보다 경계 상황에서 시작한다

화면에 O와 X가 잘 보인다고 게임 규칙이 완성된 것은 아니다. 다음 경계 상황을 손으로 추적하면 설계 누락을 구현 전에 찾을 수 있다.

1. 첫 착수: 무작위로 정한 시작 플레이어의 기호와 안내 문구가 일치하는가?
2. 중복 좌표: 이미 기록된 칸을 선택했을 때 게임판과 턴이 그대로인가?
3. 양쪽 대각선: 두 대각선 모두 승리 목록에 포함되는가?
4. 마지막 칸 승리: 게임판이 가득 차도 승리를 무승부보다 먼저 판정하는가?
5. 사용자 종료: 00을 좌표로 변환하기 전에 종료 이벤트로 처리하는가?
6. 컴퓨터 착수: 후보를 전체 좌표가 아니라 실제 빈칸에서 고르는가?

각 검사에서 입력, 바뀐 상태, 출력, 다음 제어 흐름을 한 줄씩 적어 보면 테스트 기준이 된다. 이 작업은 SDLC의 분석·설계 결과를 테스트 단계의 예상 결과로 연결하는 과정이기도 하다.

핵심 개념 정리

개발 흐름: 계획·분석·설계·구현·테스트·유지보수는 요구를 코드와 검증 가능한 결과로 바꾸는 연결 과정이다.

이벤트 구조: 사건은 큐에 저장되고 이벤트 루프가 꺼내 검사한 뒤 적절한 핸들러에 전달한다.

게임 루프: 이벤트 처리, 상태 변경, 승리·무승부 판정, 출력 갱신과 플레이어 교대를 종료 전까지 반복한다.

틱택토 상태: 3×3 독립 행 리스트, 빈칸 기호, 현재 플레이어와 8개의 승리선이 핵심 데이터다.

종료 우선순위: 유효한 착수 직후 승리를 먼저 확인하고, 그다음 빈칸이 없으면 무승부로 끝낸다.

최종 사고 순서: 프로젝트 요구를 입력·상태·출력·종료로 분해하고, 상태를 표현할 자료구조와 불변 조건을 정한다. 그다음 한 이벤트가 검증·갱신·판정·교대로 이어지는 순서를 설계한다. 마지막에는 정상 실행만 보지 말고 중복 좌표, 두 대각선, 마지막 칸 승리와 종료 신호 같은 경계 상황으로 전체 흐름을 역검사한다.

예상문제 10선

1. 소프트웨어 개발 생명주기(SDLC)를 사용하는 핵심 목적에 가장 가까운 것은?

① 구현 단계만 빠르게 끝내기 위해서 ② 모든 프로그램을 같은 언어로 작성하기 위해서 ③ 계획부터 유지보수까지 전체 개발 과정을 체계적으로 관리하기 위해서 ④ 테스트 없이 예상 결과를 인정하기 위해서

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ③

• ① 오답: 구현은 생명주기의 한 단계이며 앞뒤의 요구 분석과 검증도 함께 관리한다.
• ② 오답: 언어 선택은 구현 결정 중 하나일 뿐 전체 과정의 목적이 아니다.
• ③ 정답: 자원 계획, 요구, 설계, 구현, 테스트와 이후 변경까지 하나의 흐름으로 관리한다.
• ④ 오답: 예상 결과와 실제 결과를 비교하는 테스트가 생명주기의 중요한 단계다.

2. 배치 프로그램과 이벤트 기반 프로그램의 결정적 차이를 올바르게 설명한 것은?

① 전자는 정해진 데이터·절차가 중심이고 후자는 발생 시점을 예측하기 어려운 사건에 반응한다. ② 전자는 반복을 사용하지 않고 후자만 반복을 사용한다. ③ 전자는 파일을 읽을 수 없고 후자만 파일을 읽는다. ④ 전자는 상태를 저장하지만 후자는 상태를 저장하지 않는다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ①

• ① 정답: 실행을 움직이는 원인이 미리 정한 처리 순서인지 외부 사건인지 구분한다.
• ② 오답: 배치 처리에도 반복문을 사용할 수 있어 문법 사용 여부가 구분 기준은 아니다.
• ③ 오답: 파일 입출력은 두 방식 모두에서 사용할 수 있다.
• ④ 오답: 이벤트 기반 게임도 게임판과 현재 플레이어 같은 상태를 유지한다.

3. 이벤트 기반 프로그램의 처리 순서로 가장 적절한 것은?

① 핸들러 실행 → 이벤트 생성 → 큐 저장 → 유형 검사 ② 상태 삭제 → 화면 종료 → 이벤트 생성 → 큐 초기화 ③ 큐 확인 → 이벤트 생성 → 발생 장치 제거 → 핸들러 저장 ④ 이벤트 생성 → 큐 저장 → 루프가 가져와 검사 → 핸들러 처리

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ④

• ① 오답: 처리할 사건이 생성·저장되기 전에 핸들러를 실행할 수 없다.
• ② 오답: 프로그램 종료 절차를 사건 처리의 일반 흐름과 혼동했다.
• ③ 오답: 이벤트는 확인 전에 발생·저장되어야 하며 핸들러 자체를 큐에 저장하는 흐름이 아니다.
• ④ 정답: 발생과 저장, 가져오기·검사, 유형에 맞는 처리의 인과관계를 따른다.

4. 틱택토에서 사용자가 이미 O가 있는 칸을 다시 선택했다. 올바른 처리는?

① O를 X로 덮고 컴퓨터 턴으로 바꾼다. ② 게임판과 턴을 유지하고 유효한 좌표를 다시 받는다. ③ 게임판은 그대로 두되 컴퓨터 턴으로 바꾼다. ④ 빈칸 여부와 관계없이 무승부로 종료한다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ②

• ① 오답: 이미 기록된 칸에는 다시 둘 수 없다는 칸 불변 조건을 위반한다.
• ② 정답: 상태가 바뀌지 않았으므로 턴도 넘기지 않고 같은 플레이어가 다시 선택한다.
• ③ 오답: 실제 착수 없이 교대하면 두 플레이어가 번갈아 둔다는 규칙이 깨진다.
• ④ 오답: 중복 좌표는 입력 오류이며 게임판이 가득 찬 무승부 조건과 다르다.

5. 3×3 틱택토에서 확인해야 하는 승리선의 총개수는?

① 6개 ② 7개 ③ 8개 ④ 9개

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ③

• ① 오답: 행 3개와 열 3개만 세고 대각선 2개를 빠뜨린 값이다.
• ② 오답: 두 대각선 가운데 하나만 포함한 계산이다.
• ③ 정답: 가로 3개, 세로 3개, 대각선 2개를 합하면 8개다.
• ④ 오답: 칸의 개수 9를 승리선 개수와 혼동했다.

6. board = [["*"] * 3] * 3으로 만든 게임판에서 board[0][0] = "X"를 실행할 때 생기는 문제는?

① 첫 행의 세 칸이 모두 X로 바뀐다. ② 게임판이 튜플로 변해 수정할 수 없다. ③ 인덱스 0이 범위를 벗어나 오류가 난다. ④ 세 행이 같은 안쪽 리스트를 가리켜 첫 열의 세 칸이 함께 X로 바뀐다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ④

• ① 오답: 같은 행의 모든 열이 아니라 공유된 각 행의 같은 열 위치가 바뀐다.
• ② 오답: 곱셈 결과는 리스트지만 안쪽 리스트 참조가 독립적이지 않다는 것이 문제다.
• ③ 오답: 3×3 리스트에서 인덱스 0은 유효하다.
• ④ 정답: 바깥 곱셈이 같은 행 객체를 반복 참조하므로 한 수정이 세 행에 나타난다.

7. 유효한 착수 직후 게임이 계속되는지 판정하는 올바른 우선순위는?

① 턴 교대 → 무승부 → 승리 ② 승리 확인 → 빈칸 없음 확인 → 계속되면 턴 교대 ③ 빈칸 없음 확인 → 턴 교대 → 승리 확인 ④ 화면 종료 → 좌표 검증 → 승리 확인

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ②

• ① 오답: 승자를 확인하기 전에 교대하면 승리 메시지의 플레이어를 잘못 정할 수 있다.
• ② 정답: 마지막 칸의 승리를 먼저 보존하고, 승리가 아닐 때 무승부를 판정한 뒤에만 교대한다.
• ③ 오답: 가득 찬 마지막 칸이 승리선을 만든 경우를 무승부로 오판한다.
• ④ 오답: 좌표 검증과 상태 갱신이 착수 후 판정보다 먼저 완료되어야 한다.

8. 컴퓨터의 착수를 무작위로 정하면서 ‘이미 채운 칸에는 두지 않는다’는 규칙을 가장 직접적으로 보장하는 방법은?

① 빈칸 좌표 목록을 만든 뒤 그 목록에서 하나를 무작위 선택한다. ② 0~2의 행과 열을 한 번씩 뽑고 채워진 칸이어도 기록한다. ③ 승리선 목록에서 좌표 하나를 골라 빈칸 검사를 생략한다. ④ 게임판을 세트로 바꾸고 첫 원소를 선택한다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ①

• ① 정답: 선택 후보 자체를 빈칸으로 제한하므로 뽑힌 좌표는 규칙을 만족한다.
• ② 오답: 채워진 칸을 덮어써 칸 불변 조건을 깨뜨릴 수 있다.
• ③ 오답: 승리선 좌표도 이미 채워져 있을 수 있어 별도의 빈칸 검사가 필요하다.
• ④ 오답: 세트 변환은 행·열 구조를 잃고 첫 원소는 무작위 선택도 아니다.

9. 다음 게임판에서 X의 상태에 대한 판정으로 옳은 것은? [["X","*","O"],["*","X","O"],["*","*","X"]]

① 첫 번째 행을 완성해 승리했다. ② 세 번째 열을 완성해 승리했다. ③ 왼쪽 위에서 오른쪽 아래 대각선을 완성해 승리했다. ④ 승리선이 없고 빈칸도 없어 무승부다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ③

• ① 오답: 첫 행은 X·빈칸·O로 서로 다른 상태다.
• ② 오답: 세 번째 열은 O·O·X이므로 X 세 개가 아니다.
• ③ 정답: 좌표 (0,0), (1,1), (2,2)가 모두 X여서 대각선 승리다.
• ④ 오답: 빈칸이 여러 개 남아 있고 X의 승리선도 존재한다.

10. 틱택토 설계를 구현 전에 검토하는 가장 재현 가능한 순서는?

① 화면 모양 결정 → 난수 출력 → 규칙은 실행 후 추가 ② 입력·상태·출력·종료 정의 → 자료구조·불변 조건 설계 → 이벤트 흐름 작성 → 경계 상황 검사 ③ 반복문 작성 → 모든 입력을 유효하다고 가정 → 승리선 하나로 테스트 ④ 게임판 갱신 → 요구사항 작성 → 종료 조건 삭제 → 유지보수 생략

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ②

• ① 오답: 규칙을 늦게 정하면 화면과 상태 처리의 전제가 서로 달라질 수 있다.
• ② 정답: 검증 가능한 요구에서 상태와 흐름을 도출하고 경계 사례로 누락을 찾는다.
• ③ 오답: 입력 오류와 나머지 7개 승리 방향을 놓쳐 설계를 충분히 검증하지 못한다.
• ④ 오답: 구현을 요구보다 먼저 하고 종료·유지보수를 제외해 생명주기 흐름을 거꾸로 적용했다.

참고 자료와 작성 기준

이 글은 해당 차시 강의자료를 바탕으로 학습 목적에 맞게 재구성한 비공식 학습자료입니다. 개념 관계, 예제와 문제 해설은 학습자의 이해를 돕도록 구성하고 검토했습니다.

• 작성·편집: 올에이클래스 학습연구팀
• 주요 근거: 한국방송통신대학교 파이썬프로그래밍기초 14강 ‘실전 프로젝트 2-1’ 강의자료(2026년)
• 보충 자료: 외부 보충 자료를 사용하지 않음
• 편집 원칙: 올에이클래스 편집 정책
• 최종 내용 검토: 2026-09-08