만들기 전에 설계하기
한 줄 코드도 쓰기 전에 실제 프로젝트를 조각으로 쪼개기
⏱ 예상 ~7분
01 · 읽기
초보자가 새 프로젝트를 할 때 흔히 하는 가장 큰 실수는 터미널을 열고 바로 코드를 쓰기 시작하는 거예요.
프로 개발자는 반대로 해요. 먼저 설계해요. 계획이 거칠고 나중에 바뀔지라도요. 설계는 Claude에게 만들어 달라고 부탁하기 전에 무엇을 만들고 있는지 를 생각하는 거예요.
AI 와 일할 때 이게 더 중요해요. 명확한 계획은 훨씬 더 좋은 Claude Code 출력을 만들어요. '게임 만들어 줘' 는 일반적인 결과를 가져와요. '게임 방을 관리하고, 대기 중인 플레이어를 매칭하고, 수를 검증하는 서버를 만들어 줘' 는 정확히 원하는 걸 가져와요.
핵심 정리
- 코딩 전에 설계해요. 거친 계획이라도 도움이 돼요
- 명확한 계획은 더 나은 AI 생성 코드를 만들어요
- 프로젝트를 레이어로 쪼개요: 서버, 클라이언트, 통신
- 온라인 매치메이킹이 있는 실시간 멀티플레이어 tic-tac-toe 게임을 만들어요
02 · 읽기
우리가 만들 건 실시간 멀티플레이어 tic-tac-toe 게임 이에요. 낯선 두 사람이 같은 URL 을 방문하면 매칭되어 실시간으로 게임을 해요. 한 플레이어가 한 수를 두면 다른 플레이어 화면에 바로 나타나요.
완성된 게임은 세 레이어로 이뤄져요. 서버 는 권위자예요. 보드를 관리하고, 규칙을 집행하고, 플레이어를 매칭하고, 승리를 감지해요. 서버는 항상 옳아요. 서버가 모든 수를 검증하기 때문에 플레이어가 부정행위를 할 수 없어요.
클라이언트 는 인터페이스예요. 플레이어가 브라우저에서 보는 HTML 페이지예요. 보드를 보여주고, 클릭을 받고, 서버 업데이트를 표시해요.
Communication 은 다리예요. 클라이언트와 서버 사이를 흐르는 WebSocket 이벤트예요. 플레이어가 cell 을 클릭하면 클라이언트가 'make-move' 이벤트를 보내요. 서버가 검증하면 두 플레이어에게 'move-made' 를 보내요.
핵심 정리
- 서버가 모든 게임 상태를 관리해요. 클라이언트를 절대 믿지 마요
- 클라이언트는 UI 를 보여주고 사용자 동작을 받아요
- WebSocket 이벤트가 둘 사이의 통신 레이어예요
- 서버가 모든 수를 검증해서 부정행위를 막아요
03 · 단계별 설명
모든 실시간 앱의 세 레이어와 각 레이어가 우리 tic-tac-toe 게임에서 무엇을 하는지 살펴봐요.
1. 서버: 심판
보드 (3x3 칸) 를 관리하고, 누구 차례인지 추적하고, 수를 검증 (cell 이 비었나? 네 차례인가?) 하고, 승리와 무승부를 감지하고, 대기 중인 플레이어를 게임 방으로 매칭해요.
2. 클라이언트: 화면
3x3 게임 보드를 클릭 가능한 cell 로 표시해요. 상태 메시지 ('상대 기다리는 중...', '여러분 차례', '이겼어요!') 를 보여줘요. 플레이어가 클릭하면 이벤트를 보내요. 서버가 변경 사항을 보내면 보드를 업데이트해요.
3. Communication: 이벤트
클라이언트와 서버 사이의 계약이에요. 플레이어가 'Find Game' 을 누르면 클라이언트가 'find-game' 을 emit 해요. 서버가 두 플레이어를 매칭하면 둘에게 'game-start' 를 emit 해요. 플레이어가 cell 을 클릭하면 클라이언트가 'make-move' 를 emit 해요. 서버가 검증하면 둘에게 'move-made' 를 emit 해요. 게임이 끝나면 서버가 'game-over' 를 emit 해요.
4. 매치메이킹: 로비
서버에 대기 queue 가 있어요. 'Find Game' 을 누르면 queue 에 들어가요. 두 번째 플레이어가 들어오면 서버가 둘을 방에 매칭하고, X 와 O 를 무작위로 배정하고, 게임을 시작해요.
5. Disconnect 처리: 깔끔한 정리
플레이어가 게임 중에 브라우저를 닫으면 서버가 disconnect 를 감지하고 상대에게 알려요. 큐에서 disconnect 되면 서버가 그들을 제거해요. 좀비 게임도 없고, 갇힌 플레이어도 없어요.
04 · 코드 예제
두 플레이어와 서버 사이의 이벤트 흐름이에요. 잘 봐 둬요. 앞으로 7 개 레슨에서 구현할 청사진이에요.
이벤트 흐름: 매칭부터 게임 종료까지
Player A Server Player B
| | |
|--- find-game ---->| |
|<--- waiting ------| |
| |<--- find-game -----|
|<-- game-start ----|--- game-start ---->|
| (you are X) | (you are O) |
| | |
|--- make-move ---->| | (A clicks cell 4)
|<-- move-made -----|--- move-made ----->| (server: valid!)
| | |
| |<--- make-move -----| (B clicks cell 0)
|<-- move-made -----|--- move-made ----->| (server: valid!)
| | |
| ...more moves... |
| | |
|<-- game-over -----|--- game-over ----->| (X wins!)
| (you won!) | (you lost) |
모든 동작이 서버를 거치는 걸 보세요. 플레이어 A 는 플레이어 B 와 직접 말하지 않아요. 서버가 수를 받고, 검증하고, 두 플레이어에게 결과를 브로드캐스트해요. 어떤 멀티플레이어 게임이든 이게 표준 구조예요.
05 · 체크리스트
코딩하기 전에 계획을 이해했는지 확인해요. 편안하게 느껴지는 개념마다 체크해요.
- 서버가 모든 게임 상태를 가지고 있어요. 보드, 누구 차례, 누가 X 와 O 인지
- 클라이언트는 이벤트 ('make-move' 같은) 만 보내고 서버가 시키는 걸 표시해요
- 매치메이킹이 대기 중인 두 플레이어를 게임 방에 짝지어요
- 각 수는 플레이어에게 보이기 전에 서버가 검증해요
- 플레이어가 disconnect 되면 서버가 정리하고 상대에게 알려요
06 · 퀴즈
왜 서버가 수를 검증해야 하고, 클라이언트를 믿으면 안 될까요?
- 서버 검증이 클라이언트보다 빨라요
- 클라이언트는 게임 상태에 접근할 수 없어요
- 플레이어가 클라이언트 코드를 수정해서 부정행위를 할 수 있어요. 서버가 유일하게 믿을 수 있는 권위자예요
- WebSocket 이 서버 측 검증을 요구해요
⚠ 전체 인터랙티브 경험에는 JavaScript가 필요해요. JavaScript를 켜고 새로 고침해 주세요.
※ 이 사이트는 독립 운영되는 교육 프로젝트로, Anthropic의 공식 제품이 아니에요. Claude™ 는 Anthropic, PBC 의 상표예요.