DEVLOG JOURNAL

스파르타 부트캠프:그간의 여정 [시작부터 출시까지의 과정 2/2]

EVANJ — Fri, 10 Jul 2026 01:53:58 +0900

부트 캠프 시작부터 여러 미션들을 수행하고 수료식을 거쳐,
스팀에 게임을 출시하기까지의 여정을 돌이켜보니

여섯 달이 조금 넘는 시간 동안,

무려 26주 동안 매주 치열하게 고민했고,

총 183일이라는 매일의 노력이 쌓여있었습니다.

밤낮없이 모니터 불빛을 나누며 함께 고생했던 다섯 명의 팀원들. 그리고
항상 등불처럼 가이드해주신 튜터님들과 매니저님들에게 마음 깊이 그리고 잔잔한 감사를 남깁니다.

11 주차

3D 심화 프로젝트_팀 프로젝트 : PROTOTYPE

2025년 11월 28일 ~ 12월 05일

내가 선택한 L님의 게임 기획 내용은 이런 구성을 담고 있다.

프로젝트 가제 : 오늘은 잠들 수 있을까?
플레이어는 잠을 방해하는 다양한 소음과 환경 요소를 제한 시간 안에 해결하고, 피로도가 한계에 도달하지 않도록 7일 동안 버티는 3D 타임 어택 액션·퍼즐 게임이다.

아파트 맵 구조

아파트 맵 구현 및 플레이어 조작 개발 중 모습

다른 두 명의 수강생도 기획 아이디어가 재밌어 보여서 선택했다고 했다. 다른 팀들과 다르게 한 명의 인력이 부족했지만,개발에 전혀 지장이 없었다. 팀원들은 그 공백을 충분히 커버할 수 있는 능력자들이었기 때문이었다. 역할 분배는 빠르게 이루어졌고, 기획 세부 논의도 계속 이루어졌다. 빠르게 그리고 비전공자로서 기획을 한 것이기 때문에 디테일들은 개발하면서 구체화했어야 했다.

아파트 방 모듈 더미매쉬

나는 게임 맵 모듈을 만들고 모습을 공유하면서 개발했고, 그 모듈 매쉬를 S님에게 전달했다. 그리고 S님은 랜덤 배치 및 스폰 기능을 구현했다. 나는 플레이어 기능 구현을 맡았고 실습 해본 부분들이어서 금새 구현했다.

레그돌 피격시 물리 처리 작업

다만 문제는 새로운 기능을 다루는 것이었다. 이웃 NPC를 공격하면 NPC들은 Ragdoll화 되어 쓰러지는 연출이 목표였다. Ragdoll화가 되면서 물리처리가 되는데, 초반에는 시원시원하게 쓰러지는 모션 연출이 아쉬웠다. 하루 종일 자연스러운 물리처리를 연출하려고 매진했다. 결국 구현을 해내었다. 그러면서 UI와 플레이 루프를 맡아준 AL님이 대부분의 기능을 구현해서 핵심 구조를 개발했다.

11 주차

PROTOTYPE : 프로젝트 발표회

2025년 12월 05일 금요일

최종적으로 플레이한 한 소감으로는 매 플레이 마다 랜덤하게 여러 이웃들이 곳곳에서 소음을 내고, 그 이웃들을 찾아 망치로 제압하며 우스꽝스럽게 날아가는 NPC가 나름의 재미를 만들었다고 생각했다.

발표회에서 프로젝트를 소개하고 튜터님들의 평가를 들었다. 팀원들이 느낀 그 재미가 분명히 핵심으로 유저에게 전달이 된다고 하셨다. 하지만 일관적인 플레이 구조로 금방 지루해져서 다양한 방법과 퍼즐요소 추가로 입체적인 기획이 필요하다고 피드백을 받았다. 반면 프로토타입 개발 미션인 만큼 최소한의 리소스로 핵심 목표를 구현해서 효율적인 작업 방식에 튜터님의 좋은 평가를 받았다. 게다가 이번 프로젝트 미션에서 우수 작품으로 선정되어 기뻣다.

발표회 이후 Zoom에서 진행한 우수 팀 투표 중 모습

발표회를 마치고 바로 최종 프로젝트를 위한 팀 빌딩을 하는 시간을 가졌다. 어떤 팀은 흩어져서 새로운 팀으로 합류하거나, 어떤 팀은 그대로 유지했다. 우리 팀에서는 AL님은 최종 프로젝트에 함께 하지 못하게 되었고 다른 두 명의 팀원이 새롭게 합류하게 되었다.

12 주차

실전 프로젝트 : 방향성의 재정립

2025년 12월 08일 ~ 12월 12일

해당 첫 주의 월요일은 기획·개발 팀장 워크숍 시간과 앞서 수료한 기수의 선배님이 Zoom을 통해 출시 경험을 공유해주었다.

이 시간이 꽤나 크게 의미있었다. 얼마나 더 멀리 봐야 하는지 그 시야의 기준을 더 높게 잡을 수 있도록 도움이 되었다.

Trello에서 업무 카드를 만들어 공유했던 모습

이번 프로젝트는 최종 작업물이기에, 좀 더 심사숙고하며 개발을 해야했다. 그래서 튜터님들이 추천한 Trello 업무 공유 앱을 사용했다. Trello에서 실시간으로 서로의 업무를 확인할 수 있고, 앞으로 업무를 해야할 것은 카드로 미리 작성해두고 다음 작업을 고민하는 작업자가 가져가는 방식으로 규칙을 정했다.

피그마에서 회의한 전체 모습

그리고 Figma에서 기획회의를 매일 했다. 추가적으로 기획이 필요하면 브레인스토밍을 Figma에서 진행했다. 또 게임에 추가되는 여러가지의 데이터들은 Google Sheet에 기록해서 파악 및 관리하기 수월하게 했다. Google Sheet에는 아이템, NPC, SFX, Dialogue, UI, Prompt 등 기록해서 유용하게 활용했다. NPC의 대사와 UI의 텍스트를 번역하는데 큰 역할을 했다.

데이터를 모두 구글 시트에서 정리 및 공유하는 모습

실전 프로젝트의 첫 째주는 R&D기간으로, 필요한 기능들을 미리 학습하고 탐색하는 시간이었다. 이후 4주 뒤 진행될 중간 발표까지 MVP(Minimum Viable Product)를 개발하는 것을 목표였기 때문에, 구체적이고 실행 가능한 기획서가 필요했다.

하지만 프로젝트 초반에는 기획 방향성이 명확하게 잡히지 않아 개발 범위가 계속 흔들렸다. 그 결과 리소스가 점점 늘어나고 구현 난이도는 높아졌지만, 정작 게임의 핵심 재미가 충분히 검증되지 않는 문제가 발생했다. 돌이켜보면 이는 개인의 문제라기보다, 짧은 학습 기간 이후 곧바로 실전 프로젝트에서 핵심 기획을 구체화해야 했던 상황적 한계에 가까웠다. 마치 요리의 기본기를 막 익힌 사람이 곧바로 전체 코스 요리의 레시피를 설계해야 하는 상황처럼, 아이디어를 실제 개발 가능한 구조로 정리하는 과정에서 시행착오가 많을 수밖에 없었다. 그래서 나는 기획을 한 사람의 역할로만 두기보다, 팀원 모두가 게임의 핵심 재미와 구현 가능성을 함께 검토해야 한다고 판단했다. 이후 회의를 주도하며 아이디어를 다시 정리하고, 개발 범위와 핵심 플레이 경험을 좁혀가는 방향으로 논의를 진행했다.

피그마에서 수많은 회의의 흔적

팀원들 모두 장르와 핵심 재미 그리고 정체성이 불분명하다는 점을 공통적으로 짚었다. 이웃을 조용히 시키는 방법을 구상하면서 텍스트로 구현하면 비주얼 노벨 장르로 보이거나, 퍼즐성을 강조하면 프로토타입에서 구현한 액션성이 희미해지는 이슈가 있었다.

그렇다고 무작정 이웃들을 찾아가 공격하는 건 자연스러운 맥락이 형성되지 않았다. 수업이 끝나고도 다들 기획 아이디어를 수집했고 다음날 서로 고안해낸 아이디어들을 펼쳐놓고 회의를 했다. 그러다 아파트 컨셉을 버리고 교도소로 바꿔보는 건 어떤지 제안을 했다. 다른 팀원들도 흔쾌히 동의했다. 그리고 U님은 최근 인기있었던 '이상현상'장르를 접목해보는 건 어떤지 제안을 했었다. 그 아이디어를 듣고 팀원들은 빠르게 동의하고 I님은 QTE를 접목해보자며 계속해서 재미있는 아이디어들이 핑퐁효과처럼 빠르게 쏟아졌다. 그리고 교도소 컨셉으로 더미 맵을 만들어 보며 레벨 디자인을 함께 진행했다. 감방 갯수는 25개에서 16개로 줄었고, 11자 모양으로 설계되었었다. 2층으로 이어지는 계단 모양은 Y자에서 ㄷ자로 바꿔가며 다양하게 시도를 했다.

적절한 테마를 갖추고 함께 아이디어 물꼬를 트니 기획은 구성은 점점 구체화되어 갔다.

여러 의논을 거쳐 시도해본 계단 모형들

필자 : "레지던트 이블에서 대표 기능인 '상세보기'를 구현해서 죄수가 위험한 무기를 찾도록 하면 퍼즐성을 추가해서 입체적인인 재미를 유도할 수 있을 것 같다.", "성경 책을 열면 죄수가 숨겨둔 무기가 나오는 연출이 재밌을 것 같다."
Y님 : "QTE 이벤트를 접목하면 액션성이 더 강조될 것 같다.", "폭동 게이지 시스템을 적용하면 선택에 대한 패널티를 얻어 더 신중한 플레이를 유도해보는 것을 어떨까 싶다."
U님 : "죄수를 처벌해야 할 패턴 중 바닥을 파내어 도망가려는 죄수 패턴이 재미있을 것 같다.", "플레이어가 감방 안으로 진입할 때 습격하면 플레이에 긴장감을 더 할 수 있을 것 같다."
S님 : "벽돌이 색이 살짝 다르게 생겨서 빼내어 봤을 때, 금지 물품이 있는 패턴을 추가하면 좋을 것 같다.", "죄수 별로 맷집 정도를 다르게 주면 입체적인 플레이에 한 요소로 작용할 것 같다."
L님 : "칫솔을 갈아서 뾰족하게 만든 흉기 아이템으로 접목하면 내러티브한 아이템이 될 수 있을 것 같다.", "죄수 특징이 다르게 유형별로 만들면 다양한 재미를 뽑아낼 수 있을 것 같다."

상세보기 기능을 구현한 원리 (U님 작업)

팀원들의 적극적인 참여로 프로젝트 작업이 시작을 할 수 있을 정도까지 구성을 갖추게 되었다.

13 주차

실전 프로젝트 : MVP 기획 구성

2025년 12월 15일~ 12월 19일

기획이 어느정도 틀이 잡히고 3주가 남은 시점에서 명료한 MVP 구조를 개발하기 위해, 플레이가 되는 상태까지 작업이 빠르게 진행되어야 했다. 우선 각자 현재까지의 기획을 바탕으로 역할분배를 했다.

캐릭터 조작 및 충돌 개발 중인 모습

나는 이번에도 캐릭터와 맵 파트를 담당했다. 맵은 초기 교도소 구조로 더미 맵을 제작했고, S님에게 전달해 스폰 시스템에 적용하도록 해야 했다. 그리고 플레이어 조작은 기존의 단순한 Input System에서 FSM(Finite State Machine) 시스템으로 재구성했다. 이번 작업은 역시나 스파르타 팀에서 제공된 'Unity 게임 개발 심화' 강의가 아주 크게 도움이 되었다. 실전에 사용되는 기능 구현이 자세하게 가이드를 해주었다. 덕분에 플레이어 캐릭터의 상태별로 전환 조건을 깔끔하게 추가할 수 있었다. 그리고 그밖에 작업들을 학습하며 개발을 했다.

초기 교도소 더미 맵 내부 모습

죄수 더미 캐릭터 추가
죄수 피격시 Ragdoll으로 전환되어 물리처리 연출
플레이어 애니메이터에서 'Blend Tree'로 다양한 방향전환에 따른 애니메이션을 연결
플레이어 Raycast로 활용한 상호작용 기능으로 '문 여닫이' 구현
플레이어의 무기 제작 및 공격 기능 구현
오디오 믹서 세팅으로 SFX와 BGM 제어 및 출력

14 주차

실전 프로젝트 : MVP 기능 구현

2025년 12월 22일~ 12월 26일

레지던트 이블을 참고해서 개발한 상세보기 기능 (U님 작업 내역)

이제 중간발표를 2주를 앞두고 있던 시점이었다. 플레이가 가능한 상태를 구현하기 위해 각자가 작업한 Scene에서 개발한 기능들을 합쳐야 했다. 이 과정에서 수 많은 이슈들이 쏟아져나왔다. 이때부터 끝없는 이슈와의 전쟁이 시작되었던 것이다. 그리고 게임을 진행하기 위해 오브젝트와 상호작용 기능이 우선적으로 작업이 되었어야 했다. 그래서 성격 책과 쓰레기통 아이템을 만들어 U님에게 전달해 '상세보기' 기능을 완성했다. 이 외에 주인공의 캐릭터 모델 베이스를 만들어 적용하고, 중간 발표 이후에 죄수, NPC 캐릭터의 바리에이션을 제작하려고 계획했다. 이제 본격적으로 리소스 제작을 진행했다. 더미 매쉬로만 재미를 검증하는데 무리가 있었기 때문이다. 감방의 모듈에 배치될 침대, 책상, 의자, 변기, 세면대, 환풍구, 쓰레기통을 기본 가구 요소로 계획했다. 그 가구들 중 쓰레기통과 변기, 베개, 환풍구, 성경책을 상호작용한 아이템으로 우선 제작했다. 그래도 해당 주 막바지에는 플레이를 해볼 수 있었다. 하지만 게임 페이즈 연결되는 시점과 위치에 대해 여러 문제가 발생해 당혹스러운 상황이 벌어졌다. 이에 대해 팀원들은 다시 의논을 했고, 게임 맵의 재설계와 플레이 플로우 재정립이 필요했다. 이러한 결론에 따라 팀원들 모두 이부분에 대한 대책 아이디어를 준비해오기로 했다.

MVP 기능 개발 중인 모습

15 주차

실전 프로젝트 : MVP 막바지 작업

2025년 12월 29일~ 2026년 01월 01일

지난 주에 확인된 게임 플로우 이슈를 보완할 대책 회의를 했다. 교도소 맵 구성은 감방이 모여있는 플레이 공간 그리고 이어져 있는 복도와 중간에 사무실로 들어가는 문이 있는 구조였다. 여기서 복도가 문제였는데, 게임 페이즈의 시작과 끝을 어디에서 작동되게 할지 의견이 분분했다. 그래서 게임 페이즈를 명확하게 구분할 지점과 그에 따른 합리적이고 효율적인 맵의 재설계가 필요했다. 우선 팀원들의 의견을 모아서 해결책을 강구했다.

초기 교도소 더미 맵의 모습

U님은 교도소 공간과 사무실 사이에 복도가 페이즈 연결점을 혼란을 주어, 복도를 제거해서 두 공간을 바로 연결해야 한다고 제안했다.
Y님은 감옥을 위로 층을 올리는 구조보다 지하로 내리는 구조가 리소스 절약과 던전 느낌을 살릴 수 있을 것 같다고 제안했다.
S님은 감방을 순찰하고 다시 못 들어가게 하는 규칙을 적용하면 다른 부작용들이 뒤따라와 이 규칙에 대해 더 고민해봐야 한다고 짚어주었다.
L님은 죄수들을 네가지로 특징별로 분류해 체력/스폰되는 이상현상 아이템을 컨셉에 맞게 구성해보자고 의견을 내놓았다.

나는 교도소 감방 배치가 좀더 효율적이고 입체적인 동선을 위해 육각형 모양의 교도소 맵을 디자인했고, 층마다 6개의 감방을 배치했다. 최종적으로 교도소 건물의 구조는 지상 1층에 교도관 사무실, 지하 1층에 6개소, 지하 2층에 6개소로 구성되었다.

육각형 형태의 새롭게 디자인된 맵 도안

변경된 교도소 맵의 컨셉아트

그렇게 MVP 기획은 아래와 같이 제작되었다.

[브레인스토밍 중 선택된 이벤트 성 이상현상 컨텐츠]
✓ 낙서하는 죄수
✓ 소리 지르는 죄수
✓ 악마를 숭배하는 염소
✓ 비키니를 입은 근육질 죄수
✓ 문을 열면 도망가버리는 탈주형 죄수
✓ 감방 안 물건들을 수색하기 위해 상세보기 도중 놀래키는 죄수

폭동 이벤트
무고한 죄수를 때리면 폭동게이지가 증가함
✓ 감방에 들어가면 급습하는 죄수
✓ 죄수는 순응형과 반항형 두가지로 랜덤 행동 패턴이 부여된다.
순응형은 플레이어 공격에 순순히 당하지만, 반항형은 플레이어에게 반격하는 패턴을 나타낸다.

상호작용 가능 사물	상호작용 기능	이상현상 요소
침대 위에 베개	베개를 들어 올려 배게 밑을 살펴보기	베개 밑 망치
휴지통	휴지통을 상세보기로 쓰레기 아래를 수색	휴지통 밑바닥에 칼
변기	변기 시트를 올려서 탐색	변기 커버 아래에 금지 물품
환풍구	환풍구를 떼어내어 안쪽 확인	환풍기 안쪽에 간수복

MVP 개발한 감방 모습

MVP 더미 맵 구조 전경

MVP 교도소 감방 내부 모습

죄수 유형	죄수 컨셉별 전용 사물	죄수 컨셉별 전용 이상현상 요소
멸치형(Skinny)	성경 책, 바닥 타일	성경책에 공간을 파내어 숨긴 송곳 바닥 타일 아래 구덩이 그리고 금지물품
근육질형(Muscular)	덤벨, 무게 원판	덤벨에 끼워진 너클 원판 밑에 금지물품
갱형(Gang)	철장, 포스터	탈출을 시도한 흔적의 휘어진 철장 포스터 뒤에 파인 벽 그리고 금지 물품
지능형(Smart)	화분, 벽에 벽돌	화분 아래 금지 물품 벽돌 안쪽에 금지물품

죄수 캐릭터 초기 컨셉 원화

실전 프로젝트 : 중간 발표회

2026년 01월 02일

이렇게 컨텐츠가 명확히 구체화되고 구현할 수 있어서 중간 발표회에서 게임을 시연 및 소개를 할 수 있었다.

이후 튜터님들에게 피드백을 받을 수 있었다.

MVP의 기능 구현이 적절하게 개발되어 아주 효율적인 작업을 한 것에 긍정적으로 평가됨.
협업이 상당히 잘 이루어졌으며, 모두가 적극적으로 의견을 내고 구현까지 이루어내서 칭찬할 만한 부분이다.
EventBus 기능을 잘 사용하였고 그 기능의 장점을 적절히 활용했다.
죄수의 로직 구조가 확정성 까지 염두해두어 잘 잡혀있었다.
기획적으로 설계도 잘 갖추고 있어 최종 결과물이 기대가 된다.

메타 파일 코드가 꼬이는 이슈가 발생해서 플레이에 지장이 가는 부분이 있었다.
EventBus 기능이 필요 이상으로 비대해 보여, 도메인 별로 분리가 필요해 보인다.
애니메이션 처리에서 직접 접근이 많고 문자열로 작업해서 오타 발생과 같은 이슈에 취약하므로 보완이 필요해 보인다.
개인 방식 코드과 팀 방식 코드가 혼용되어 과도기적인 상태로 보인다. 이 부분은 추후 수정이 필요하다.
기능 구현은 되었지만 재미는 실질적으로 표현되지 못했다.
게임 플레이에서 여러 피드백이 부족해서 목표 의식이 불분명한 문제가 있다.

발표회 이후, 최종 발표회까지의 목표와 피드백을 어떻게 적용할지에 대해 팀원들과 함께 고민을 해야 했다.

우선 팀원 개개인이 느낀 부분을 토대로 피드백을 공유했다. 전체적으로 의견들을 정리하자면 다음과 같다.

반복적이고 단조로운 게임 플레이 방식 개선이 필요
플레이어의 행동에 대한 피드백과 목표 수행 안내가 부족해 UI를 추가 고려
시간 제한으로 프레이의 긴장감과 집중 유도의 효과를 충분히 활용하지 못해 개선이 필요
해학적인 재미가 표현되지 않고 있어서 컨텐츠 기획이 필요
튜토리얼 단계가 필요

튜터님들과 공통점이 많은 피드백이 모였다. 피드백 반영을 위해 아이디어 수집을 하고 다음주에 다시 회의하기로 했다.

다음주 회의를 위해서 팀원들은 다음과 같은 내용을 고민하기로 했다.

게임의 명확한 핵심 재미 선정
플레이어가 감방을 점검하고 이상 현상을 발견하며 문제를 해결하는 과정을 재미있게 구체화하여 기획
튜토리얼과 목표 안내를 위한 UI 디자인 기획
반복 플레이의 단조로움을 해결할 수 있는 방안
플레이어 행동에 대한 즉각적인 피드백 개선 방안
플레이의 몰입감을 위한 시간 제한, 전투, 폭동 게이지, HP, 엔딩 조건 등의 정리 방안

16 주차

실전 프로젝트 : 게임 컨텐츠 기획

2026년 01월 05일~ 01월 09일

최종 결과물에 반영될 실질적 기획 회의를 중간발표회에서 얻은 피드백을 바탕으로 진행했다.

[L님의 의견]
게임의 핵심을 이상 징후를 관찰하고, 올바른 조치를 통해 교도소의 위협을 통제하는 재미로 명확하게 만들어야 한다.
날짜별 난이도·상호작용·감방 변화를 단계적으로 늘리고 즉각적인 피드백을 제공해, 반복감과 억울함 없이 7일 동안 긴장감의 유지되도록 설계가 필요하다.

[Y님의 의견]
튜토리얼과 단계별 컨텐츠 해감을 통해 플레이 규칙을 자연스럽게 익히고, 날짜가 지날 수록 감방·죄수·이상현상 변화를 늘려 반복감을 줄여볼 수 있다. 관찰과 판단, 물건 압수, 죄수 제압이 명확한 피드백으로 이어지도록 구성해서, 이상 징후를 찾아 올바르게 처리하는 재미를 핵심으로 제시하고 싶다.

[U님의 의견]
모든 방을 반복 점검하는 대신, 제한된 정보와 위험 속에서 어느 방을 더 조사하고 이상 여부를 결정할지 플레이어가 스스로 판단하게 만드는 장치 기획이 필요해 보인다.

[S님의 의견]
게임의 핵심을 단순한 이상현상 찾기가 아니라, 제한된 정보 속에서 죄수를 의심하고 제압할지 망설이는 딜레마와 불안감을 설계해야 한다. 공포나 코믹 등 하나의 서브 장르를 분명히 정하고, 매 감방을 지날 때, 혹은 날짜마다 새로운 경험을 주도록 기획이 필요하다.

피그마에서 회의를 위해 자료와 의견을 모아놓은 모습

방향성은 모두가 충분히 인지했다고 생각했다. 하지만 실질적이고 구체적인 컨텐츠 내용 기획이 필요했다. 나는 7일 동안 매번 다른 미션을 수행하는 플레이 방식을 제안했다. 매 플레이마다 1번 미션부터 6번 미션까지 랜덤으로 정해지고, 각 미션을 수행해야만 날짜가 쌓인다. 그리고 마지막 7번째 미션은 항상 클라이맥스 7번 미션으로 고정되며, 일곱 번의 미션을 성공하면 게임을 클리어할 수 있도록 플로우를 설계했다. 각 미션 구성은 다음과 같이 기획해 보았다.

"시끄럽게 떠드는 수감자를 조용히 시켜라!"
: 노래를 부르는 죄수, 침대에 웅크려 혼자 중얼거리는 죄수, 고함을 지르며 철장을 때리는 죄수, 벽에 망치질을 하는 죄수, 데드리프트를 하며 운동을 하는 죄수, 울부짖는 죄수 이렇게 총 6명의 죄수를 찾아서 진압해야 한다.
"죄수들이 숨긴 위험한 무기를 찾아라!"
: 칼이나 뾰족한 물건, 망치 등 흉기를 감방 안에 숨겨두어 다양한 방법으로 7가지의 무기를 찾아야 한다.
압수한 무기는 UI에 계산되어 표시된다.
"이상 행동을 하는 죄수를 처벌해라!"
: 근육 비키니, 염소, 반항하여 공격하는 죄수, 탈주하는 죄수, 땅을 파는 죄수, 벽을 파는 죄수를 총 6명을 진압해야 한다.
"실종된 죄수를 찾아라!"
: 이 미션 중에는 선임 교도관도 함께 순찰을 돈다. 하지만 선임 교도관으로 변장한 죄수들이 두 명이 있다.
그 두 명을 구분해서 처벌해야 한다. 틀린 그림 찾기 방식을 접목한 미션이다. 세명의 선임 교도관 모습에서 어색한 특징을 관찰하여 가짜를 찾아내야 한다.
"모든 죄수의 물건들을 수색해 금지 물품을 압수해라!"
: 감방안을 탐색해 죄수들이 몰래 숨긴 금지 물품들을 12개 모두 압수해야 한다. 환풍구, 쓰레기통, 벽돌 뒤 와 같은 배경 오브젝트 요소에 상호작용해서 수색할 수 있다. 물건을 탐색하기 위해 상세보기를 하면 랜덤 확률로 QTE 시스템이 발동되며 플레이어를 기습하는 이벤트가 발생한다.
"탈출하려던 흔적을 발견! 범인을 찾아라!"
: 죄수들에게 뇌물을 주며, 범인을 목격한 증언을 토대로 범인을 찾아야 한다.
텍스트 대화 형식으로 진행되며, 외형 특징에 차이를 두어 힌트를 얻을 수 있도록 한다.
"폭동을 일으키며 탈출하려는 죄수들을 모두 제압해라!"
: 12명의 죄수들이 탈출을 시도하고 플레이어를 공격하기 위해 따라온다. 플레이어는 모든 죄수를 처벌해야 한다.
각 죄수 유형별로 체력과 공격력에 차이를 주어서 레벨 디자인을 설계한다.

QTE 예시 레퍼런스

매번 달라지는 미션으로 단조로운 플레이 방식을 타파할 수 있었고, 중간 중간 퍼즐요소를 가미해 입체적인 플레이를 유도할 수 있다. 그리고 이벤트성 캐릭터의 등장과 QTE 시스템으로 몰입감과 긴장감을 이끌어낼 수 있었다. 이러한 구성은 프로토 타입부터 쌓여온 아이디어들을 최대한 활용한 방안이었다.

미션이 표기되는 화이트 보드

이 아이디어 제안에 모두가 찬성을 해주었고, 팀원들과 함께 이 플레이 방식으로 구성을 수정하며 발전시키기 시작했다.

중간 발표회때까지는 지상 1층 사무실 공간에 있는 화이트보드에 미션의 상태와 폭동게이지를 표시하도록 했지만, 매번 미션이 달라짐에 따라 현재 미션과 결과값이 UI로 보여주어야 했다. 게임 플로우가 재구성되면서 폭동 게이지 기능은 삭제되었다. 그래서 최종적으로 타이머와 HP, 현재 미션 성공으로 쌓인 날짜, 미션 안내와 상태 그리고 대사를 보여주는 프롬프트가 새롭게 추가되었다.

교도관 캐릭터 3종 컨셉아트와 캐릭터 모델

모두가 변경된 기획안을 따라 업무 분배가 이루어졌고, 바로 개발에 착수 할 수 있었다. 이후 모두 기능 구현을 최우선시 하며 작업에 매진했다. 나는 게임 방향성이 확고해졌으니 아트작업을 다루었다. 플레이어 캐릭터의 컨셉 디자인을 하고 모델링을 거쳐, Rigging, Animating 그리고 더미 캐릭터에서 제작한 캐릭터를 교체했다. 또 교도소의 배경도 빠르게 제작해서 감방 모듈 스폰 기능을 담당한 S님에게 전달했다. 이때 프리팹 기능으로 초기 소스를 전달하고 세부 구현은 추후에 하면서 우선순위를 세워 작업을 했다. 프리팹 기능 덕분에 어느 한 쪽 업무가 지연되지 않고 거의 동시에 개발할 수 있었다.

17 주차

실전 프로젝트 : 기능 구현 개발 집중 기간

2026년 01월 12일~ 01월 16일

이상현상 아이템 모델 리소스

3주가 남은 시점부터는 개발 속도를 본격적으로 올릴 수 있었다. 이 한주 동안은 변경된 게임 플로우에 따라 기본 토대를 세우는 작업이 주된 목표였다. 개발을 하면서 하루에 3번 정도 지속적으로 회의를 했다. 팀원들과 항상 소통이 잘 되어서 정말 다행이었다.

L님 작업 ✓ 변경된 기획안 업데이트 및 전체 수정 ✓ 기능 추가에 대한 QA 및 이슈 보고 ✓ 랜덤 미션 세부 기획 작성 ✓ 튜토리얼 플로우 세부 내용 기획 ✓ 캐릭터들의 대사 작성 ✓ BGM/SFX 리소스 추가	Y님 작업 ✓ 변경된 게임 구조에 따른 GameManager 수정 ✓ 다이얼로그 시스템 제작 ✓ 튜토리얼 스테이지 구현 ✓ 미션 6 설계 구현
S님 작업 ✓ 랜덤 미션 발생 로직 구현 ✓ 미션 별 죄수 AI 로직 설계 및 구현 ✓ 이상현상 랜덤 스폰 설계 및 구현 ✓ 조건에 따라 죄수들의 행동 설계	U님 작업 ✓ HUI UI 작업(체력/날짜/미션/타이머) ✓ QTE 이벤트 로직 구현 ✓ 순찰 중 활성화 알림 UI 구현 ✓ 상세보기 기능과 이상현상 오브젝트 연결

나는 최종 결과물에 반영될 아트 리소스 작업에 집중했다.

✓ 교도관 사수와 죄수 캐릭터 제작

✓ 이상현상 오브젝트 리소스 제작

✓ UI에 필요한 2D 리소스 제작

✓ 총 3층으로 구성된 교도소 맵 디자인 및 제작

✓ 플레이어 조작에서 발생하는 이슈 수정

그리고 팀원들의 개발 데이터가 한 브랜치로 머지를 할때 자주 이슈가 발생 하곤 했는데, 이 이슈들은 개발 기간 내내 모두를 괴롭게 했다.

18 주차

실전 프로젝트 : 미션 시스템 구현

2026년 01월 19일~ 01월 23일

이 주간은 미션을 플레이 할 수 있도록 구현하는 것이 목표로 작업을 진행했다.

L님 작업 ✓ 실시간 기능 추가에 따른 QA 및 보고 ✓ 게임 플레이 밸런스 체크 ✓ 레벨 디자인 작업 ✓ 튜토리얼 스테이지 점검 ✓ 엔딩 기획 ✓ 게임 안내 및 피드백 체크 및 QA	Y님 작업 ✓ 미션 4번 프랭크를 찾아라 구현 ✓ 튜토리얼 플레이 플로우 다듬기 및 이슈 수정 ✓ 미션 6번 대화 시스템 이슈 수정 ✓ 저장 기능 이슈 수정
S님 작업 ✓ 죄수 유형별 스폰 기능 이슈 수정 ✓ 죄수 행동 애니메이션 연결 이슈 수정 ✓ 이상현상 스폰 시스템 이슈 수정 ✓ 로직 완성도 끌어올리기	U님 작업 ✓ UI 작동 SFX 추가 ✓ 비키니 죄수 대화 기능 추가 및 비누 스폰 위치 수정 ✓ QTE 이벤트 이슈 수정 ✓ 튜토리얼 무기 획득 가이드 구현 ✓ 이상현상 오브젝트 위치 수정

상세보기와 QTE 개발한 모습

나는 아트 리소스 작업을 막바지에 이르렀다. 특별 죄수인 염소인간과 비키니 죄수를 제작하고 소장 캐릭터를 제작했다. 그리고 사무실도 나쁘지 않게 꾸며내었다. 기존에는 임시로 더미 문서에 상호작용하여 미션을 전달받았는데, 소장 캐릭터를 배치해서 소장에게 정말 미션을 부여받고 보고하는 모양새를 구현했다.

염소와 비키니 죄수 컨셉 아트 및 기획

소장 캐릭터 : Victor Blackwell

19 주차

실전 프로젝트 : 이슈 수정과 마무리 과정

2026년 01월 26일~ 01월 30일

개발 도중 이슈를 수정하는 모습

이제 딱 긴 여정을 지나 딱 한 주가 남았다. 모두가 플레이를 해보며 QA를 진행했고 이슈를 계속 수정했다. 다른 팀들은 유저테스트를 진행했었지만 우리 프로젝트는 아직 버그가 발생해 유저테스트를 진행하기 곤란한 상황이었다. 그래서 유저테스트는 발표 후에 받게 되었다.

거의 완성에 가까운 모습을 갖추고 있는 오피스 전경

준 완성 감방의 내부 모습

준 완성의 교도소 복도 모습

게임을 직접 플레이 여러번 해보니, 생각보다 클리어가 어려워 밸런스 수정을 하게 되었다. 죄수들의 공격력, HP 회복 기준, 공격 범위와 속도 등 수치조절로 난이도를 완만하게 다듬었다.

그리고 함께 발표자료를 준비하고 L님은 게임 내용을 담은 브로셔를 작성했다.

발표 전날에는 밤을 세워서 발표 영상을 편집을 했다.

노션에 게시된 여러 프로젝트의 브로셔

20 주차

발표회 그리고 수료식

2026년 02월 26일~ 01월 04일

마지막 발표회 전날까지 발표 준비를 하다보니 밤을 세웠다. 아무 집중도 할 수 없이 몽롱했다.

그러다 오후 발표시간까지 뜨는 시간이 있어, 잠깐 눈을 붙였다. 분명히 헤드셋을 끼고 있었지만 아무것도 인지하지 못했다. 그러다 눈을 떠보니 오후 3시쯤이었다. 화들짝 놀라 상황을 살펴보니, 이미 우리 팀의 발표회는 지나갔었다. 그렇게 나는 보지 못한 마지막 발표회를 마치게 되었다. 다른 팀원들 말로는 반응이 아주 좋았다고 했다. 하필 마지막 발표회는 Zoom에서 진행하지 않고 Zep 내에서 진행해서 녹화영상도 없었다. 이점이 너무 아쉬웠다.

발표회 공지 포스터

발표회 이후 저녁시간에는 다른 팀들의 게임을 해볼 수 있는 기회가 있었다. 그리고 다음날 화요일에는 외부 손님들과 지난 기수 수강생들을 초대해 게임을 시연할 수 있었다. 이때가 우리 게임의 거의 첫 UT(User Test)였다. 그래서 그동안 아무도 인지하지 못했던 이슈들을 계속해서 발견되었다. 가장 큰 이슈는 Unity 환경에서 플레이할 때는 발생하지 않던 마우스 감도 이슈가 빌드 파일에서 플레이하면 컨트롤이 불가할 정도로 민감도가 높아져서 멀미가 날 지경이었다. 이 이슈는 바로 설정창에 민감도 조절 기능을 추가하고 마우스 민감도의 기본값을 수정 및 고정했다. 이 이슈로 더 많이 유저테스트를 못한 것이 아쉬웠다. 유저 테스트를 하면서 설문조사도 진행했다. 게임을 플레이한 사람들 중 5명이 설문조사를 참여해주었는데, 그 결과 내용을 정리해보았다.

게임을 해본 대부분의 유저들은 게임의 목표와 기본 조작을 이해했으며, 감방 관찰·이상현상 탐색·죄수 진압 구조를 긍정적으로 평가해주었다. 다만 튜토리얼과 정보 전달, UI·행동 피드백, 이상현상의 명확성, 난이도 및 반복감은 추가 개선이 필요한 것으로 나타났다.

유저테스트에서 얻은 의견들

이를 바탕으로 팀원들과 논의해서 수료식 이후 출시까지 함께 추가 개발을 진행하기로 했고, 따로 퍼블리셔를 개설하지 않고 '팀 스파르타' 퍼블리셔에서 무료로 출시하기로 결정했다. 이유는 다음과 같은 현재 상황 때문에 결정하게 되었다.

게임 자체 분량이 매우 짧았고 전체적으로 유료로 판매하기에는 부족한 상품성을 가졌다고 판단했다.
무료로 출시하기로 결정되어서 '팀 스파르타' 퍼블리셔에서 출시하는 것이 더 간편하고 개인 퍼블리셔보다 널리 퍼질 수 있을 것이라고 판단했다. 그리고 해당 기억 퍼블리셔에서 출시하면 무조건 무료로 판매되어서 수익이 없어야 하는 조건이 있었다.
추후 각자 팀원들은 개인의 길을 가게 될 것이고 수익이 나오면 그에 따른 관리도 필요하기에 번거롭다는 의견이 모였다. 유료로 출시하게 된다면 지속적인 관리와 업데이트가 필요하다. 그렇지만 팀원들은 그럴 여력이 부족했다.
첫 작품이기도 하고 연습작으로써의 출시이기 때문에 무료 출시되어야 유료보다 더 널리 퍼질 수 있을 것이라고 생각했다.

팀에서 여러 합리적인 조건과 이유로 무료 배포를 하기로 함께 결정을 했고, 우선 '팀 스파르타'에 빌드 파일을 공유하여 출시를 위한 사전 검수를 해야했다. 나는 가능한 치명적인 이슈만 빠르게 수정하고 가능한 일찍 제출해서 검수를 받고 출시일을 정하자고 했다.

그래야 개인의 시간도 절약이 되기 때문이다. 그렇게 신속하게 출시에 대한 안건이 정리되고, 수료식을 맞이했다.

Zep에서 회의하는 모습

마지막 날 수료식에서 시상식이 발표되었다. 최종 프로젝트에서 튜터님들과 유저테스트에 따른 투표로 이루어진 것으로 보였다.

우리 팀의 프로젝트인'근무 중 이상 무'가 최우수상을 수여받게 되었다. 그동안의 고생과 노력에 위로를 받는 느낌이었다.

그리고 수료증과 매니저님과 튜터님이 보내는 조언 그리고 따뜻한 응원과 수고의 편지가 담긴 '퍼스널 리포트'도 함께 받게 되었다.

출석률 100% 인증 알림창

나는 집이라는 공간에 있었지만, 많은 사람과 만나서 무언갈 배우고 이루는 것이 꽤 색다른 경험이었다. 온라인으로 수업을 하는 건 오프라인과 다르게 단점 분명히 있었지만, 분야 특성에 따른 효율적인 부분도 꽤나 큰 장점으로 다가왔다.

부트캠프 최우수상

21~26 주차

추가 개발과 스팀 출시

2026년 02월 09일~ 03월 21일

수료식 이후 해당 주는 휴식기간을 갖고 이후 2월 9일부터 출시를 위한 추가 개발 작업을 이어갔다. 다른 소통 앱을 찾아봤지만 Zep만한 앱은 없는 것 같았다. 그래서 Zep에서 오후 1시부터 5시까지 소통에 필요한 작업을 진행했고 3월 13일부터는 어느정도 마무리가 되어 Slack으로만 소통하며 작업을 했다. 출시 전까지의 작업은 이렇다.

Github에서 그래프로 나타낸 그동안의 작업 기록

12명의 죄수 캐릭터 모델링 작업

UI 사이즈 변동 및 화면 비율 별 확인
마우스 감도 이슈 수정 및 설정 창에 기능 감도 조절 기능 추가
언어 선택 기능 추가 및 영어 번역
전체적인 게임 플로우 다듬기
죄수 캐릭터 바리에이션 11종 추가
어색한 애니메이션 수정
라이팅 맵 디테일 작업
교도소 외관 배경 다듬기
마지막 7번 미션 난이도 완화
죄수 Hit 판정 이슈 수정
스팀 출시를 위한 포스터와 배너 패키지 리소스 작업
스팀 출시를 위한 트레일러 영상 제작(한국어/영어)

근무 중 이상 무 메인 포스터

스팀 상점 페이지

드디어 3월 21일에 스팀에 출시를 해냈다.

스팀에 출시하는 건 통장 개설하는 것 보다 더 번거로운 과정이 필요했다.

이후 몇몇 BJ들이 플레이를 하기도 했다. 그때 발견되는 이슈들이 있어 추가로 수정을 했었다.

3월 23일

Y님의 일부 발견된 이슈를 수정하고 UI 및 텍스트 가동성을 향상해서 업데이트를 했다.

3월 25일

한 영어권 스트리머가 유튜브에서 라이브로 게임을 플레이하다 '근무 중 이상 무'를 선택해서 실행했는데, 한국어로 나오는 것을 보고, "WTF" 의 리액션과 게임을 종료하는 것을 목격했다. 게임 설정창에 언어 선택 기능을 추가했지만, 외국인 입장에서 설정창까지 진입하는 것이 무리일 수 밖에 없다는 것을 뒤늦게 깨달았다. 그래서 부랴부랴 게임을 실행하면 언어 선택 창이 최초로 실행할 때만 나타나게 만들었다. 이후 영어권 혹은 동남아권 유튜버들이 플레이를 하는 걸 볼 수 있어서 마음이 놓였다.

3월 31일

게임에서 미션을 수행하고 소장에게 가서 임무 보고를 하는 대화 중에도 게임 타이머가 흘러가서 비합리적으로 실패하는 경우가 종종 발생했다. 이후 Y님이 소장 NPC에게 미션 보고를 위해 대화를 시도하면 타이머가 멈추도록 조치를 취했다.

스팀에서 '주목받는 신규 게임' 리스트에 오르기도 했다.

이후 유튜브 바이럴

~2026년 06월23일

3월 29일에 스트리머 '우주하마'가 유튜브 라이브에서 '근무 중 이상 무'게임을 플레이 해주셨다. 이후 게임이 스팀의 '주목받는 신규 게임' 리스트에 오르며 예상보다 많은 관심을 받게 되었다. 4월 8일에는 우주하마 채널에 편집 영상이 업로드되었고, 해당 영상은 32만회 조회수(7월12일 기준)를 기록했다. 이후에도 김도, 짬타수아, 풍월량님 등 인지도 있는 스트리머분들이 게임을 플레이해주셨고, 라이브 채팅 반응을 통해 어떤 부분에서 웃고, 몰입하고 불편함을 느꼈는지 확인할 수 있었다.

4월 8일, 유튜브에서 스트리머 '우주하마'님께서 플레이
( 우주하마 라이브[00:19:00 - 02:11:00], 우주하마 편집영상)

4월 10일, 치치직에서 스트리머 '김도'님께서 플레이

( 김도님 라이브[00:46:00 - 01:26:00], 긴도랜드 편집영상)

4월 16일, Soop에서 스트리머 '짬타수아'님께서 플레이

( 짬타수아님 라이브[00:46:00 - 01:26:00], 짬타수아 편집영상, 장타수아 라이브 녹화영상)

4월 17일, 치치직에서 스트리머 '풍월량'님께서 플레이를 해주셨다.

( 풍월량님 라이브[01:15:00 - 03:44:00] )

네 분의 라이브 채팅 로그 중 실제 '근무 중 이상무' 플레이 구간에서 채팅들을 분석해보았다.

스트리머	분석 구간	채팅 수	참여 계정 수	분당 채팅 수
우주하마	00:19:00 ~ 02:11:00	3,887개	528명	약 34.7개/분
김도	00:46:00 ~ 01:26:00	4,195개	749명	약 105.0개/분
짬타수아	전체 구간	2,943개	149명	약 60.2개/분
풍월량	01:15:00 ~ 03:44:00	22,494개	2,700명	약 151.0개/분
합계	약 5시간 50분	33,519개	4,126명	약 95.8개/분

단순 수치상으로는 풍월량님 방송의 채팅 규모가 가장 컸고, 김도님 방송은 짧은 구간에 비해 채팅 밀도가 높았다. 짬타수아님 방송은 참여 계정 수는 적었지만, 방송인 밈과 게임 상황이 강하게 결합되며 웃음 반응이 많이 발생했다.

반응 유형	채팅 수	전체 대비 비율	해석
웃음 / 밈 반응	7,848개	23.4%	게임이 방송용 리액션을 잘 만들어냄
공포 / 긴장 / 놀람	1,826개	5.4%	갑작스러운 제압, 공격, 수상한 상황에서 반응 발생
수색 / 추리 참여	1,531개	4.6%	시청자가 단서 찾기에 직접 참여
제압 / 블랙코미디	1,152개	3.4%	죄수 제압이 강한 예능 포인트가 됨
실패 / 리트 / 해고 반응	538개	1.6%	실패 상황이 스트레스보다 웃음으로 소비됨
불편 / 개선 신호	486개	1.5%	시간 부족, 난이도, 화면 옵션, 최적화 관련 반응
긍정 / 퀄리티 평가	461개	1.4%	“무료인데 괜찮다”, “잘 만들었다” 계열 반응

가장 큰 비중은 역시 웃음과 밈 반응이었다. 그렇지만 단순히 보는 것 이상으로 수상한 점을 같이 찾고 스트리머에게 알려주는 방식으로 게임에 참여하는 채팅이 많았다.

이러한 라이브 채팅 로그 분석으로 세 가지의 의미있는 평가가 있었다.

첫 번째는 무료 게임치고 퀄리티가 괜찮다는 반응이었다.

“이게 무료?”, “고퀄인데?”, “깔끔하다”, “무료인데 퀄리티가 좋네”, “잘 만들었음”, “게임 재밌다”

무료 게임으로 출시했기 때문에, 유저들은 처음에는 가볍게 접근했다가 실제 플레이를 지켜본 뒤 생각보다 구성이 갖춰져 있다는 반응이 있었다. 특히 UI, 분위기, 미션 구조, 죄수 수색 방식에서 "무료 게임치고 괜찮다."는 평가가 나왔다.

두 번째는 수색과 추리에서 시청자 참여가 발생했다는 점이다.

“포스터 뒤 봐”, “벽도 봐야 해요”, “신발 다른데”, “귀걸이 있다”, “칼!”, “망치!”, “총기 ㄷㄷ”, “프랭크 찾기”, “가짜 프랭크”

근무중 이상무의 핵심 재미는 단순히 죄수를 제압하는 것이 아니라, 제한 시간 안에 방을 수색하고, 이상한 점을 찾아내고, 판단하는 과정에 있다. 실제 채팅에서도 시청자들이 화면을 함께 관찰하며 단서를 찾는 모습을 확인 할 수 있었다.

세 번째는 실패가 예능적인 웃음으로 연결됐다는 점이다.

“해고”, “0일차”, “리트”, “또 해고야”, “3부 시작”, “YOU FIRED”

일반적인 게임에서는 실패가 부정적인 경험이 될 수 있지만, 방송에서는 오히려 리액션을 만드는 장치가 되었다. 특히 미션 실패, 잘못된 제압, 사망, 해고 연출은 시청자들에게 반복적인 웃음 포인트로 소비되었다.

채팅에서 확인한 강점

1. 교도소/죄수/수색/제압이라는 컨셉이 직관적으로 표현되어, 시청자들이 별도의 긴 설명 없이도 게임의 상황을 빠르게 이해했다.

2. 시청자가 함께 참여할 수 있는 구조가 있어서 단서를 찾고, 수상한 죄수를 판단하는 과정에서 채팅 참여가 자연스럽게 발생했다.

3. 해고, 사망, 리트, 잘못된 제압 등의 실패가 웃음 포인트로 작동되어서 예능적인 반응으로 이어질 수 있었다.

4. "무료인데 괜찮다"는 반응처럼 무료가 진입 장벽을 낮췄다. 이는 실제 스팀 유입에도 긍정적으로 작동했을 가능성이 있다.

채팅에서 확인한 개선점

1. 초반 목표 전달을 더 명확히 할 필요가 있다.
일부 채팅에서는 "뭐 하는 게임인지 모르겠다", "뭔겜?" 같은 반응이 있었다. 교도관으로서 무엇을 해야 하는지, 어떤 조건에서 성공과 실패하는지를 더 빠르게 전달할 필요가 있다.

2. 수색 난이도와 제한시간 조절이 필요하다.
"시간 부족", "못 찾겠다", "어렵다" 계열 반응이 반복적으로 등장했다. 특히 초반부는 조금 더 여유를 주거나, 수색 가능한 오브젝트의 피드백을 강화하면 좋았을 것 같다.

3. 화면 옵션과 최적화 개선 필요성이 보였다.

풍월량님 방송에서는 "모션블러", "프레임", "렉", "블러 끄자" 같은 반응이 확인됐다. 모션 블러 기본 OFF, FOV 옵션, 감마/밝기 조절, 카메라 흔들림 옵션이 있었다면 더 좋았을 것 같다.

4. 제압 요소가 강하게 밈화되었다.

죄수 제압은 좋은 웃음 포인트였지만, 동시에 게임이 "그냥 죄수 패는 게임"처럼 오해될 가능성도 있었다. 홍보에서는 수색과 추리 요소를 더 강조할 필요가 있다고 느꼈다.

이 외의 대략 추정된 38명의 스트리머 분들께서 플레이를 해주시고 영상도 올려 주셨다. [ 유튜브 영상 재생목록]

Youtube에서 수집된 '근무 중 이상 무' 플레이 영상 재생목록

스팀 지표로 확인한 출시 이후 성과

유튜브와 스트리머 방송을 통해 예상보다 많은 관심을 받게 되면서, 이후에는 Steamworks에서 제공하는 여러 수치들을 확인해보았다. 단순히 “많이 봤다”는 감각적인 반응이 아니라, 실제로 얼마나 많은 유저가 게임을 받아갔고, 실행했으며, 어느 지역에서 반응이 있었는지 확인하고 싶었다. (2026년 07월 09일 기준)

항목	수치
무료 활성화 수	21,277
실제 플레이 유저 수	1,009
획득 대비 실제 플레이 전환율	약 4.7%
최근 평균 일일 활성 유저	3명
전체 기간 평균 일일 활성 유저	11명
최대 일일 활성 유저	44명
최대 동시 접속자	6명
현재 위시리스트	307개

※ 여기서 '무료 활성화'는 유저가 게임을 무료로 자신의 Steam 계정에 등록한 수를 의미한다. 즉, 21,277명이 게임을 "무료로 받아갔다"는 뜻이다. 다만 이 수치가 실제 플레이를 했다는 의미는 아니다.

플레이 시간 지표

Steamworks에서 확인한 플레이 시간 지표는 다음과 같았다.

최종 평가

라이브 채팅 반응을 종합해보면, 근무 중 이상 무는 방송에서 반응을 만들어내는 데 성공한 게임이었다.

특히 시청자들이 단서를 함께 찾고, 스트리머가 판단하고, 그 결과로 성공하거나 해고당하는 흐름은 방송과 잘 맞았다. 단순히 플레이어 혼자 하는 게임이 아니라, 시청자가 옆에서 함께 수색하고 훈수두는 게임처럼 작동했다는 점이 가장 인상적이었다.

다만 장시간 플레이에서는 반복 수색의 피로, 제한시간 스트레스, 목표 이해 부족, 화면 옵션 문제도 함께 드러났다. 이번 채팅 분석은 단순히 “반응이 좋았다”는 기록을 넘어서, 다음 프로젝트에서 어떤 재미를 강화하고 어떤 불편을 줄여야 하는지 확인할 수 있는 중요한 데이터가 되었다.

2만 명 이상이 라이브러리에 등록했다는 건 분명히 의미 있는 성과이고, 실제 플레이 유저수 1,009명은 더 보수적이고 진정성 있는 수치이다. 공개된 판매 추정 분포에 대입하면, 1,009라는 수치는 1,000~10,000 구간의 가장 초입에 해당한다. 이 분포에서는 100장 미만이 약 47.5%, 100~1000장이 약 28%로 추청되므로, 단순 비교하면 1,000명을 넘긴 것 만으로도 대략 하위 75% 이상은 넘어선 위치라고 볼 수 있다.

정리하면, 근무 중 이상 무의 가장 강한 부분은 이것이었다.
죄수를 제압하는 장면의 웃음보다, 시청자들이 함께 수상한 점을 찾고 판단하는 과정에서 더 큰 재미가 발생했다.
이 경험은 다음 게임을 기획할 때도 중요한 기준이 될 것 같다.

인터뷰

2026년 06월23일

이후 높게 평가되고 있는 성과에 팀 스파르타에서는 인터뷰를 요청해주셨다.모든 팀원들은 흔쾌히 동의했고, 이후 함께 만나서 인터뷰를 준비하며 그동안의 못나누었던 대화를 했었다.나는 큐카드를 만들어서 팀원들에게 기념을 위해서 선물했다.부트캠프의 마지막까지 큰 의미를 남겼다.

인터뷰에서 활용한 큐카드

팀 스파르타에서 촬영해주신 인터뷰 영상

5명의 7조 로고

API와 MCP

EVANJ — Sun, 5 Jul 2026 02:11:40 +0900

API = 프로그램이 다른 프로그램의 기능을 쓰기 위한 요청 창구
MCP = AI가 여러 프로그램, 파일, 데이터, 도구를 공통 방식으로 연결해 쓰기 위한 규격

API는 개별 서비스의 주문 창구, MCP는 AI용 멀티 어댑터/허브로 비유할 수 있다.

API란?

API는 Application Programming Interface의 줄임말이다.

의미는 '어플리케이션간의 소통하기 위해 열어둔 기능 사용 창구'이다.

MDN에서는 API를 소프트웨어가 다른 소프트웨어나 하드웨어와 상호작용할 수 있게 해주는 "기능과 규칙의 집합"으로 설명한다. 즉, 사람이 버튼을 누르는 UI가 아니라, 프로그램이 프로그램에게 요청하는 방식이다.

API는 왜 필요할까?

프로그램이 다른 서비스의 기능이나 데이터를 써야 할 때가 많기 때문이다.

유튜브 댓글 가져오기
구글 로그인 사용하기
날씨 정보 가져오기
카카오 지도 불러오기
결제 처리하기
번역 기능 사용하기
게임 서버에 랭킹 저장하기
AI에게 문장 분석 요청하기

이러한 작업들을 매번 직접 수행할 수 없다.

그래서 각 서비스에서는

"우리 기능을 쓰고 싶으면, 이 주소로 이런 형식의 요청을 보내세요. 그러면 이런 형식으로 답을 드릴게요."

이런 식으로 약속된 창구가 API이다.

API 요청은 보통 이렇게 생겼다.

웹 API는 보통 인터넷 주소처럼 생긴 곳에 요청을 보낸다.

https://api.example.com/comments?videoId=123

이 요청의 의미는 대략 다음과 같다.

api.example.com이라는 서비스에게
comments 기능을 요청하고
videoId가 123인 영상의 댓글을 달라고 한다

그러면 서버는 보통 이런 식의 데이터를 돌려준다.

</> JSON

{
  "videoId": "123",
  "comments": [
    {
      "user": "A",
      "text": "재밌다"
    },
    {
      "user": "B",
      "text": "이 장면 좋다"
    }
  ]
}

이런 JSON 형태는 사람이 읽기에도 비교적 쉽고, 프로그램도 처리하기 쉬워서 API 응답에서 자주 사용된다.

API를 쓸 때 자주 나오는 용어

엔드포인트(Endpoint)

API에서 특정 기능에 접근하는 주소이다.

댓글 가져오기 주소
회원 정보 가져오기 주소
이미지 업로드 주소
결제 요청 주소

이런 각각의 주소가 엔드포인트라고 보면 된다.

요청 Request

내 프로그램이 API에게 보내는 말이다.

이 영상의 댓글을 주세요.
이 사용자의 정보를 주세요.
이 파일을 업로드해 주세요.

응답Response

API가 돌려주는 답이다.

성공했습니다.
데이터는 이것입니다.
권한이 없습니다.
요청한 정보를 찾을 수 없습니다.
서버 오류가 발생했습니다.

파라미터Parameter

요청할 때 함께 보내는 세부 조건이다.

어떤 영상인지
몇 개를 가져올지
어느 날짜 이후 데이터인지
어떤 언어로 번역할지

예를 들어, "댓글을 주세요." 보다 "videoID가 abc123인 영상의 댓글을 100개 주세요."가 더 구체적이다.

여기서 videoID, 100개 같은 조건이 파라미터이다.

API Key

API를 사용할 수 있는 열쇠 같은 값이다.

예를 들어 유튜브 API, 구글 API, OpenAI API 같은 서비스를 사용할 때는 보통 "누가 요청하는지" 확인해야 한다.

그래서 API key를 발급받고 요청에 포함한다.

API Key = 이 사용자가 허가받은 사용자인지 확인하는 열쇠

다만 API Key는 비밀번호와 비슷하게 다뤄야 해서 공개하면 안된다.

MCP란?

MCP는 Model Context Protocol의 줄임말이다.

공식 MCP 문서에서는 MCP를 AI 애플리케이션이 외부 시스템에 연결하기 위한 오픈소스 표준으로 설명한다.

AI 앱은 MCP를 통해 로컬 파일, 데이터베이스 같은 데이터 소스, 검색 엔진이나 계산기 같은 도구, 특수 프롬프트나 워크플로우에 연결될 수 있다.

MCP = AI가 외부 도구를 연결해서 사용할 수 있게 해주는 공통 연결 규칙

MCP를 비유하면 "AI용 USB-C"에 가깝다

공식 MCP 문서에서도 MCP를 AI 애플리케이션을 위한 USB-C 포트에 비유한다. 여러 기기를 각자 다른 케이블로 연결하는 대신, 공통 포트 하나로 연결하듯이, AI도 다양한 도구와 데이터를 공통 방식으로 연결할 수 있게 하려는 개념이다.

예전 방식은 아래와 같았다.

ChatGPT ↔ GitHub 전용 연결
ChatGPT ↔ Google Drive 전용 연결
ChatGPT ↔ Notion 전용 연결
ChatGPT ↔ 로컬 파일 전용 연결
ChatGPT ↔ 데이터베이스 전용 연결

이렇게 각 서비스마다 연결 방식을 따로 만들어야 했다.

MCP 방식은 더 공통화된 구조를 목표로 한다.

AI 앱 ↔ MCP ↔ GitHub
AI 앱 ↔ MCP ↔ Google Drive
AI 앱 ↔ MCP ↔ Notion
AI 앱 ↔ MCP ↔ 로컬 파일
AI 앱 ↔ MCP ↔ 데이터베이스

즉, MCP는 AI와 외부 도구 사이의 표준 어댑터 같은 역할을 한다.

API와 MCP의 가장 큰 차이

API는 보통 개별 서비스의 기능을 호출하는 창구이다.

유튜브 API: 유튜브 데이터 가져오기
구글 드라이브 API: 드라이브 파일 가져오기
깃허브 API: 저장소 정보 가져오기
노션 API: 노션 페이지 만들기

반면 MCP는 AI가 그런 기능들을 공통 방식으로 발견하고 사용할 수 있게 해주는 연결 규격이다.

API = 서비스 하나하나의 창구
MCP = AI가 여러 창구를 연결해서 쓰게 해주는 표준 연결 방식

중요한 점은, MCP가 API를 완전히 대체하는 것은 아니라는 것이다. MCP 서버 안쪽에서 실제로는 GitHub API, Google Drive API, 데이터베이스 쿼리, 파일 시스템 접근 등을 사용할 수 있다. MCP 공식 도구 명세에서도 MCP 서버는 모델이 호출할 수 있는 tools를 노출할 수 있고, 그 도구는 데이터베이스 조회, API 호출, 계산 같은 외부 작업을 수행할 수 있다고 설명한다.

일반 API 사용

내 프로그램
↓
YouTube API
↓
유튜브 댓글 데이터

예를 들어 사용자가 파이썬으로 유튜브 댓글을 가져오려면, 파이썬 코드가 유튜브 API에 직접 요청한다.

MCP 사용

AI 앱
   ↓
MCP Client
   ↓
MCP Server
   ↓
YouTube API / 파일 / DB / GitHub / Notion

이 구조에서는 AI가 직접 모든 API 사용법을 아는 것이 아니라, MCP 서버가 "내가 제공할 수 있는 도구는 이것이다."라고 알려주고, AI는 그 도구를 호출한다.

MCP의 기본 구성 요소

MCP에는 크게 이런 개념들이 있다.

1. MCP Host

AI가 들어있는 프로그램이다.

AI 채팅 앱
AI 코딩 도구
AI IDE
데스크톱 AI 앱

사용자와 직접 대화하는 쪽이라고 보면 된다.

2. MCP Client

Host 안에서 MCP 서버와 통신하는 연결 담당자이다.

비유하자면 통역사이다.

사용자 요청
→ AI가 이해
→ MCP Client가 MCP 규칙에 맞게 서버에 요청

1. MCP Server

외부 기능을 제공하는 쪽이다.

파일 읽기 MCP 서버
GitHub MCP 서버
Google Drive MCP 서버
Notion MCP 서버
데이터베이스 MCP 서버
브라우저 자동화 MCP 서버
계산기 MCP 서버

MCP 서버는 "내가 할 수 있는 기능"을 AI에게 알려준다.

MCP 서버가 제공할 수 있는 것들

공식 MCP 명세에서는 주요 기능을 크게 Resources, Prompts, Tools로 나눈다. Resources는 모델이나 사용자가 참고할 수 있는 데이터, Prompts는 템플릿 메세지나 워크플로우, Tools는 모델이 호출할 수 있는 기능이다.

Resources

AI가 읽을 수 있는 자료이다.

파일
문서
데이터베이스 내용
검색 결과
프로젝트 설정
노트

예를 들어 "이 프로젝트의 README 파일을 읽고 요약해줘." 라고 요청하면 README 파일이 Resource가 될 수 있다.

Tools
AI가 실행할 수 있는 기능이다.

파일 생성하기
이메일 검색하기
캘린더 일정 만들기
데이터베이스 조회하기
터미널 명령 실행하기
이미지 변환하기
GitHub 이슈 만들기

예를 들어 "내 GitHub 저장소에서 열린 이슈를 확인하고 요약해줘."라고 요청하면 이때 GitHub MCP 서버가 list_issues 같은 도구를 제공할 수 있다.

Prompts

자주 쓰는 작업 흐름이나 지시문 템플릿이다.

코드 리뷰용 프롬프트
회의록 요약 프롬프트
버그 리포트 작성 프롬프트
블로그 글 변환 프롬프트

즉, 매번 긴 지시문을 쓰지 않아도, 정해둔 작업 형식을 불러와 쓸 수 있게 하는 개념이다.

API만 쓰는 방식

1. Python 코드 작성
2. YouTube API Key 입력
3. videoId 입력
4. 댓글 가져오기
5. CSV 저장
6. ChatGPT에 CSV 업로드
7. 분석 요청

이 방식은 사용자가 API 사용법과 실행법을 어느정도 알아야 한다.

MCP를 쓰는 방식

이론적으로는 이런 식이 가능하다.

사용자: 이 영상의 댓글을 가져와서 반응을 분석해줘.
AI:
1. YouTube MCP 서버의 댓글 가져오기 도구 확인
2. 댓글 데이터 요청
3. 결과를 표로 정리
4. 감정/반응/구간별 분석 수행
5. 필요하면 CSV로 저장

이 방식은 사용자 입장에서 "API를 어떻게 호출해야 하지?"보다 자연어로 요청하는 느낌이 강해진다.
다만 실제 가능 여부는 해당 MCP 서버가 있는지, 권한이 있는지, API. 제한이 있는지에 따라 달라진다.

API와 MCP 비교

구분	API	MCP
핵심 의미	프로그램이 다른 프로그램 기능을 쓰는 창구	AI가 외부 도구·데이터를 연결하는 표준 규격
주 사용자	개발자가 만든 프로그램	AI 앱, AI 에이전트, AI 코딩 도구
예시	YouTube API, GitHub API, Google Maps API	GitHub MCP 서버, 파일 시스템 MCP 서버, DB MCP 서버
목적	특정 서비스 기능 호출	AI가 여러 도구를 공통 방식으로 발견하고 사용
관계	개별 기능 제공	내부에서 API를 감싸서 제공할 수 있음
비유	식당 메뉴판, 주문 창구	AI용 USB-C 허브, 멀티 어댑터

MCP의 중요성

AI가 단순히 말만 잘하는 단계에서, 이제는 실제 작업을 수행하는 도구로 바뀌고 있기 때문이다.

예전 AI는 주로 '질문 → 답변' 이렇게 작동해 왔습니다.

요즘 AI는 점점 이렇게 바뀌고 있다.

'질문 → 자료 검색 → 파일 읽기 → 계산 → 코드 수정 → 문서 작성 → 결과 제출'

이렇게 하기 위해서 AI가 외부 세계와 연결되어야 한다.

파일
이메일
캘린더
코드 저장소
데이터베이스
브라우저
디자인 툴
빌드 시스템

MCP는 이런 연결을 더 표준화하려는 시도이다. 공식 MCP 명세도 LLM 애플리케이션이 외부 데이터 소스와 도구에 통합할 수 있게 하는 오픈 프로토콜이라고 설명한다.

MCP를 연결한다고 해서 AI가 무조건 모든 것을 할 수 있는 것은 아니다.

중요한 제한이 있다.

1. MCP 서버가 실제로 존재해야 함
2. 사용자가 권한을 허용해야 함
3. 연결된 서비스의 API 제한을 따라야 함
4. 보안 설정이 안전해야 함
5. AI가 도구를 잘못 호출할 가능성도 고려해야 함

특히 MCP는 외부 데이터 접근과 코드 실행 경로를 열 수 있기 때문에 보안이 중요하다. 공식 MCP 보안 문서도 MCP 구현에서 고려해야 할 보안 위험과 모범 사례를 별도로 다루고 있으며, MCP 명세 역시 임의 데이터 접근과 코드 실행 경로가 강력한 기능인 만큼 신뢰와 안전 고려가 필요하다고 설명한다.

API는 프로그램끼리 소통하는 창구.
MCP는 AI가 외부 세계와 소통하기 위한 표준 연결 방식.
MCP 서버는 내부적으로 여러 API를 대신 호출해줄 수 있다.

'Protocol'에 대해

EVANJ — Sun, 5 Jul 2026 00:19:27 +0900

"프로토콜(protocol)은 컴퓨터와 컴퓨터 사이, 또는 한 장치와 다른 장치 사이에서
데이터를 원활히 주고받기 위하여 약속한 여러 가지 규 (規約)"

표준국어대사전

IT에서 컴퓨터, 스마트폰, 서버 인터넷 장비들은 서로 데이터를 주고받아야 한다.

그런데 각자 규칙없이 서로 다르게 말하면 소통이 안된다. 그래서 어떤 형식으로 말할지, 어떤 순서로 주고받을지,

문제가 생기면 어떻게 처리할지를 정해둔 규칙이 필요한데, 이것을 프토로콜이라 한다.

프로토콜은 "언어"이자 "절차"다

프로토콜 = 데이터 통신을 위한 언어 + 형식 + 순서 + 규칙

대표적인 프로토콜 예시

HTTP / HTTPS

웹사이트를 볼 때 사용하는 대표적인 프로토콜이다.

HTTP : 웹페이지 데이터를 주고받는 규칙
HTRPS : HTTP에 보안 암호화를 더한 것

웹사이트 주소가 https://로 시작하는 경우가 많다.

이건 브라우저와 서버가 HTTPS 규칙으로 안전하게 통신한다는 뜻이다.

예를 들어 사용자가 특정 사이트에 접속하면 브라우저가 서버에게 이렇게 요청하는 셈이다.

"이 페이지의 데이터를 보내주세요."

서버는 이렇게 응답한다.

"여기 있습니다. 상태는 정상입니다."

이때 자주 보이는 404 Not Found, 500 Server Error 같은 것도 HTTP 규칙 안에서 정해진 응답 코드이다.

TCP

TCP는 데이터를 안전하고 정확하게 보내는 규칙에 가깝다.

큰 파일이나 웹페이지 데이터를 한 번에 통째로 보내는 것이 아니라, 작은 조각으로 나누어 보내는 경우가 많다.

TCP는 이런 것들을 관리한다.

데이터가 순서대로 도착했는지
중간에 빠진 조각은 없는지
빠졌다면 다시 보내야 하는지
상대가 제대로 받았는지

택배로 비유하면, 물건을 여러 상자로 나누어 보냈을 때 1번, 2번, 3번 상자가 모두 도착했는지 확인하는 규칙이 TCP이다.

IP

IP는 데이터를 어디로 보낼지 주소를 정하는 규칙이다.

우리가 집 주소를 써야 택배를 받을 수 있듯이, 인터넷에서도 컴퓨터나 서버에는 주소가 있다. 그게 IP 주소이다.

예를 들면 이런 형식이다.

192.168.0.1

IP는 "이 데이터는 어느 주소로 가야 한다."를 담당한다.

TCP와 IP는 자주 같이 쓰여서 TCP/IP라고 부르는 경우가 많다.

FTP

FTP는 파일을 주고받기 위한 프로토콜이다.

예전에는 서버에 파일을 올리거나 내려받을 때 많이 사용했다.

파일 업로드
파일 다운로드
서버 폴더 접근

이러한 용도로 쓰였지만, 요즘은 보안 문제 때문에 SFTP 같은 더 안전한 방식도 많이 사용한다.

SMTP, POP3, IMAP

이메일과 관련된 프로토콜이다.

SMTP : 이메일을 보내는 규칙
POP3 : 이메일을 내 기기로 가져오는 규칙
IMAP : 서버에 있는 이메일을 여러 기기에서 동기화해서 보는 규칙

예를 들어 스마트폰, PC, 테블릿에서 같은 이메일을 볼 수 있는 건 IMAP 같은 프로토콜 덕분이다.

DNS

DNS는 사람이 읽기 쉬운 웹사이트 주소를 컴퓨터가 이해할 수 있는 주소로 바꿔주는 시스템이다.

사람은 이렇게 입력한다.

google.com

하지만 컴퓨터는 실제로 숫자 주소인 IP 주소를 사용한다.

DNS는 쉽게 말해 인터넷 주소록이다.

"google.com은 어느 서버 주소야?"
"이 IP 주소로 가면 돼."

이런 식으로 연결을 한다.

프로토콜은 하나만 사용되지 않는다

웹사이트에 접속할 때는 하나의 프로토콜만 쓰이는 것이 아니다.

예를 들어 사용자가 브라우저에서 https://example.com 에 접속한다고 하면 여러 프로토콜이 함께 작동한다.

DNS : example.com의 실제 IP 주소를 찾음
IP : 데이터를 그 주소로 보냄
TCP : 데이터가 빠지지 않고 순서대로 가게 함
TLS/SSL : 데이터를 암호화함
HTTPS : 웹페이지 요청과 응답을 처리함

즉, 인터넷 통신은 여러 프로토콜이 역할을 나누어 협업하는 구조이다.

모든 일을 하나의 거대한 규칙으로 처리하면 너무 복잡해지기 때문에, 역할을 나누게 되었고,

그렇기 때문에 각 기술을 따로 개선하거나 교체하기가 용이하다.

프로토콜이 맞지 않는다면

프로토콜이 다르면 서로 이해하지 못한다.

예를 들어 한 사람은 한국어로 말하고, 다른 사람은 스페인어로 말하는데 서로 번역기가 없다면 대화가 어렵다.

이 예시는 컴퓨터도 마찬가지이다.

서버는 HTTP 방식으로 요청을 기다리고 있는데, 클라이언트가 전혀 다른 방식으로 데이터를 보내면 서버는 이해하지 못한다.

그래서 이러한 문제가 생길 수 있다.

사이트 접속 실패
파일 전송 실패
로그인 오류
이메일 수신 실패
서버 응답 없음
보안 연결 실패

프로토콜과 파일 형식의 차이

프로토콜과 파일 형식은 다르다.

파일 형식은 파일 자체의 구조이다.

예를 들어 JPG, PNG, FBX, TXT 등 이러한 파일 형식은 '데이터가 어떤 모양으로 저장되어 있는가'에 대한 규칙이다.

반면 '프로토콜'은 데이터를 주고받는 방식이다.

프로토콜과 API의 차이

프로토콜은 통신의 기본 규칙이다.

API는 특정 서비스나 프로그램을 어떻게 사용할지 정해둔 창구이다.

예를 들면, "유튜브 댓글을 가져오려면 이 주소로 이런 요청을 보내라." 같은 주문이다.

API는 보통 HTTP 같은 프로토콜 위에서 작동한다.

비유를 해서 정리하자면

프로토콜 = 대화하는 기본 방식
API = 특정 서비스에게 요청하는 메뉴판

정리하자면

프로토콜은 통신 규칙이다.

누가
누구에게
어떤 형식으로
무엇을 보내고
어떻게 확인하고
문제가 생기면 어떻게 처리할지
정해둔 규칙

웹사이트 접속: HTTP / HTTPS
데이터 정확한 전달: TCP
인터넷 주소 지정: IP
사이트 주소 찾기: DNS
이메일 보내기: SMTP
파일 전송: FTP / SFTP

옵시디언을 위한 마크다운 기본 규칙

EVANJ — Wed, 1 Jul 2026 01:30:16 +0900

기존에는 노션에서 작업을 기록해왔는데, 옵시디언의 강력한 기능에 매료되어 옵시디언으로 이동하기로 했다.
옵시디언은 마크다운을 기반으로 이루어져 있어, 어디에도 호환이 된다. 그래서 강력한 기록 앱이다.

1. 제목

# 제목 1
## 제목 2
### 제목 3
#### 제목 4
##### 제목 5
###### 제목 6

# 개수로 제목 단계가 정해지며, Obsidian의 아웃라인에서도 이 제목 구조를 기준으로 문서 목차가 잡힌다.

2. 문단과 줄바꿈

첫 번째 문단입니다.

두 번째 문단입니다.

문단을 나누려면 빈 줄을 한 줄 넣어야 한다. 줄만 바꾸면 Markdown에서는 같은 문단으로 처리될 수 있다. Obsidian에서 문단 안 줄바꿈은 줄 끝에 공백 두 칸을 넣거나 Shift+Enter를 사용할 수 있다.

첫 번째 줄  
두 번째 줄

3. 굵게, 기울임, 강조

**굵게**
*기울임*
***굵고 기울임***
~~취소선~~
==형광펜 강조==

Obsidian은 굵게, 기울임, 취소선, 하이라이트 문법을 지원한다.

4. 목록

- 항목 1
- 항목 2
  - 하위 항목
  - 하위 항목

1. 첫 번째
2. 두 번째
3. 세 번째

체크리스트는 이렇게 작성한다.

- [ ] 할 일
- [x] 완료한 일

Obsidian에서는 - [ ]가 미완료 작업, - [x]가 완료 작업으로 표시된다.

5. 인용문

> 이것은 인용문입니다.

여러 줄 인용은 각 줄 앞에 >를 붙이면 된다.

> 첫 번째 줄
> 두 번째 줄

6. 구분선

---

또는

***

문서 안에서 큰 구간을 나눌 때 사용한다.

7. 코드

짧은 코드는 백틱 하나로 감싼다.

`ZBrush`, `3ds Max`, `Substance Painter`

긴 코드는 백틱 세 개로 감싸.

```csharp
void Start()
{
    Debug.Log("Hello");
}
```

Obsidian은 코드 블록에 언어 이름을 붙이면 문법 강조를 적용할 수 있다.

Obsidian에서 특히 중요한 문법

8. 내부 링크

[[Sobek]]
[[Kom Ombo]]
[[Fayum 신학]]

Obsidian의 핵심 문법이다. [[노트 이름]]으로 다른 노트와 연결하고 Obsidian은 내부 링크에 Wikilink 형식과 일반 Markdown 링크 형식을 모두 지원한다. 표시 이름을 바꾸고 싶으면 이렇게 작성하면 된다.

[[Sobek|소베크]]

특정 제목으로 바로 연결하려면:

[[Sobek#왕권 상징]]

특정 문단 블록으로 연결할 수도 있다.

[[Sobek#^crocodile-symbol]]

9. 첨부파일 삽입

이미지나 PDF를 노트 안에 보여주려면 앞에 !를 붙인다.

![[sobek-statue.jpg]]
![[research-paper.pdf]]

이미지 크기를 조절하려면:

![[sobek-statue.jpg|300]]
![[sobek-statue.jpg|300x200]]

Obsidian 전용 Markdown 확장에는 ![[Link]] 형식의 파일 임베드가 포함된다.

10. 외부 링크

[표시할 이름](https://example.com)

예시:

[The Met Museum](https://www.metmuseum.org)

이미지 주소를 외부 링크로 넣을 때:

![이미지 설명](https://example.com/image.jpg)

11. 태그

#고증
#디자인
#Sobek
#작업중
#project/sobek
#research/egypt

태그는 검색과 분류에 좋다. Obsidian은 /를 사용한 중첩 태그를 지원하고, #inbox/to-read 같은 식으로 계층을 만들 수 있다.
태그에는 공백을 넣을 수 없기 때문에 #snake_case, #kebab-case, #camelCase 같은 방식을 쓰는 게 좋다.

12. 콜아웃

중요한 내용, 경고, 팁을 박스처럼 표시하는 문법이다.

> [!tip] 작업 팁
> 유물 레퍼런스는 출처와 시대를 같이 적어두면 좋다.

> [!warning]
> 고증과 판타지 설정을 섞을 때는 실제 근거와 창작 요소를 분리해두기.

접힌 콜아웃도 가능하다.

> [!info]- 접힌 정보
> 클릭하면 열립니다.

Obsidian 콜아웃은 > [!info]처럼 인용문 첫 줄에 타입을 넣어 만들고, +나 -를 붙여 기본 펼침/접힘 상태를 정할 수 있다.

자주 쓰는 타입:

> [!note]
> [!info]
> [!tip]
> [!warning]
> [!danger]
> [!question]
> [!example]
> [!quote]
> [!todo]

13. 표

| 항목 | 설명 | 상태 |
|---|---|---|
| Sobek 왕관 | 태양 원반, 깃털, 뿔 조사 | 진행중 |
| Kom Ombo | 프톨레마이오스 시대 자료 확인 | 완료 |
| Fayum | 중왕국 연결성 조사 | 진행중 |

정렬도 가능하다.

| 왼쪽 정렬 | 가운데 정렬 | 오른쪽 정렬 |
|:---|:---:|---:|
| 내용 | 내용 | 내용 |

Obsidian 표는 |로 열을 나누고, ---로 헤더 구분선을 만드는 방식이다.

14. 주석

이 문장은 보입니다.

%% 이 내용은 편집 화면에서는 보이지만 읽기 화면에서는 보이지 않습니다. %%

초안, 개인 메모, 나중에 수정할 내용 표시할 때 좋다.

15. 각주

Sobek는 고대 이집트의 악어 신으로 숭배되었다.[^1]

[^1]: 여기에 출처나 설명을 적는다.

짧은 각주는 인라인으로도 가능하다.

이 문장에는 각주가 있다.^[짧은 각주 내용]

고급 문법

16. 속성 / Properties

노트 맨 위에 메타데이터를 넣는 방식이다.

---
title: Sobek Armlet Design
type: design-note
status: 진행중
tags:
  - project/sobek
  - design/armlet
created: 2026-07-01
related:
  - "[[Sobek]]"
  - "[[Kom Ombo]]"
---

Obsidian의 속성은 파일 맨 위 YAML 형식으로 저장되고, 이름: 값 구조를 사용해. 값에는 텍스트, 숫자, 체크박스, 날짜, 날짜+시간, 리스트 등을 넣을 수 있다.

---
type: artifact-reference
culture: Ancient Egypt
period: Ptolemaic-Roman
region: Kom Ombo
deity: Sobek
status: 분석중
tags:
  - research/sobek
  - region/kom-ombo
---

17. 수식

$E = mc^2$

블록 수식:

$$
E = mc^2
$$

Obsidian은 MathJax와 LaTeX 표기법으로 수식을 넣을 수 있다.

18. Mermaid 다이어그램

```mermaid
graph TD
Sobek --> Fayum
Sobek --> KomOmbo
Fayum --> MiddleKingdom
KomOmbo --> PtolemaicRoman
```

Obsidian은 mermaid 코드 블록으로 플로우차트, 시퀀스 다이어그램, 타임라인 같은 다이어그램을 넣을 수 있다.

19. 템플릿 기본 양식 작성법

Templater 플러그인을 설치하면 현재 코드를 치환하여 읽기모드로 볼 수 있도록 하는 단축키가 생긴다.

alt + r = "Templater : Replace templates in the active file"

이 단축키로 코드가 잘 작동하는지 확인 할 수 있다. 이전으로 돌리려면 'ctrl + z' Undo 단축키를 사용하면 된다.

1.현재 시간 입력하기

<% tp.file.creation_date("YYYY-MM-DD HH:mm") %>
↓
2026-07-03 01:16

<% tp.file.creation_date("YYYY년-MM월-DD일 a H시:m분") %>
↓
2026년-07월-03일 오전 1시:16분

2. 제목 그대로 따라 작성하기

<% tp.file.title %>

<% tp.file.title.slice(7) %>

()괄호 안에 숫자 만큼 앞에서 뒤로 계산되어 자르고 뒤의 제목만 작성되도록 하는 기능이다.

<% tp.file.title.slice(0,6) %>

(a,b) a부터 b까지만 제목으로 작성하게 만드는 기능이다.

3. 해당 파일의 저장된 폴더 이름 작성

<% tp.file.folder() %>

4.해당 파일의 경로 작성

<% tp.file.path() %>

5. 날짜 작성

<% tp.date.now("YYYY-MM-DD") %>
<% tp.date.tomorrow("YYYY-MM-DD") %>
<% tp.date.yesterday("YYYY-MM-DD") %>

가장 자주 쓰게 될 요약본

# 제목 1
## 제목 2
### 제목 3

**굵게**
*기울임*
==강조==
~~취소선~~

- 목록
  - 하위 목록

1. 번호 목록
2. 번호 목록

- [ ] 할 일
- [x] 완료

[[내부 링크]]
[[노트명|표시 이름]]
[[노트명#제목]]

![[이미지.png]]
![[이미지.png|300]]

#태그
#project/sobek

> 인용문

> [!tip]
> 팁 박스

| 항목 | 설명 |
|---|---|
| 내용 | 내용 |

`짧은 코드`

```csharp
// 긴 코드 블록

%% 숨김 메모 %%

Moon Knight : Netflix Series, Episodes 1-6

EVANJ — Fri, 26 Jun 2026 14:12:20 +0900

※ 본문 내용에는 작품의 스포일러가 포함되어 있습니다.

이집트 역사와 문화에 흥미가 생겨서 이집트 소재로한 작품을 찾다가 알고는 있었지만 보지 못한 '문나이트' 시리즈를 찾았다.
'문나이트' 마블 시리즈는 총 6회로 공개되었고, 주인공은 스티븐 그랜트와 마크 스펙터를 맡은 오스카 아이작 배우이다.
주인공은 해리성 정체감 장애를 앓고 있다는 설정을 갖고 있다. 주인공을 연기한 오스카 아이작은 마치 연기로 차력쇼를 보여주는 듯한 경의로움을 두가지 캐릭터의 연기에서 보여주었다. 말투, 목소리, 행동, 성격 모두 다른 인물로 착각할 정도로 섬세하고 분명히 구분되게 표현했다.

이 작품에서 해리성 정체감 장애 증상을 다른 인물이 한 육체에 들어가 두 명의 인격이 돌아가며 통제권을 갖는 모습으로 연출했다.
스티븐 그랜트는 고대 이집트 역사와 문화의 덕후이며, 칠칠맞은 성격으로 묘사된다. 반면 마크 스펙터는 전투에 능한 거의 인간병기 급의 용병이며, 다혈질적인 성격으로 묘사된다. 그래서 서로 상반된 성격으로 매번 갈등을 빚는다.
시리즈 1화의 호기심 자극과 상상력 유발 그리고 연출과 연기는 최고였다.

이후 '콘수(Khonsu, Chonsu, Khensu, Khons, Chons, Khonshu)'라는 신이 등장하는데,

[콘수는 아문과 무트 사이에서 태어난, 고대 이집트 신화에 등장하는 달의 신이다. 이 신의 이름 뜻은 '여행하다'라는 단어에서 파생되었다.

원래 달의 신은 '도트'였지만 이후 시대가 흐르며 달의 신 지위는 콘수에게로 옮겨졌다.

강력하게 숭배받던 황금기는 고대 이집트의 신왕국 시대(기원전 1550년 ~ 기원전 1096년경)이다.]

콘수가 스티븐과 마크를 '아바타'로 활용해 암무트(Ammut, Ammit, Ammemet)의 계략을 막으려하는 것이 주된 줄거리이다.
이러한 캐릭터 설정은 애니메이션 '유희왕'을 떠올리게 했다. 그러면서 신의 대행자 역할을 했던 '파라오'의 기능적 성격을 표현한 것이 아닌가 싶었다. 여기까지의 설정과 소재는 아주 매력적이어서 다음 시리즈를 보게 만드는 그 이상의 장치로 작동되었다.

그런데, 여기까지가 흥미의 끝이었다. 이후의 설정들과 연출들이 조잡한 부분들이 많았다.
마크와 라일라가 관짝에서 훔쳐온 별자리가 그려진 파피루스 조각을 맞추려고 애를 쓰다가 감을 못잡는 마크가 화를 낸다.
그러자 라일라는 스티븐의 도움을 받자고 조언하고 마크가 스티븐에게 주도권을 준다.
그리고 스티븐이 별자리 조각들을 능숙하게 맞추는 데 그 조각의 모양새가 유치원에서 하는 도형 퍼즐처럼 보여 몰입이 깨졌다.
퍼즐의 조각도 많지 않고 다 맞춰진 조각이 말 그대로 별 모양이어서 유치하게 느껴졌다.

또 다른 영화의 몰입이 떨어지는 부분은 양산형처럼 보이는 규격화된 전투 씬과 암무트의 아바타인 '헤로우'가 지팡이로 마법을 부리는 장면에서 마법 표현이 아주 보라색의 빛으로 연출을 한 부분이다. 전투씬은 너무나도 많이 본 구도나 연출이어서 지루하게 느껴졌다. 뭔가 본 작품을 또 본 것 같은 느낌이 들었다. 그리고 마법을 보라색 CG처리는 놀이동산에서 보는 조명처럼 보여 저렴하고 공산품처럼 느껴졌다. 이러한 나의 소감은 내가 너무나도 많은 작품들을 봐와서 그런 것도 있지만 시대적으로 봤을 때 기존에 하던 방식을 고수해오며 고여버린 결과가 아닐까 싶다. 마블은 몸집이 아주 큰 프렌차이즈이다. 그래서 새로운 시도보다 빠르게 결과를 뽑아내는 것이 그 몸집을 유지할 수 있는 방법이라 정통적인 굴례에서 굴러가는 것 같다. 작품을 감상할 때 나는 작가의 원본 시나리오는 현재 결과물과 많이 달랐을 것 같다는 느낌을 받았다. 좀 더 많은 장치들과 다양한 연출 그리고 내면에서 요동치는 혼란의 드라마를 표현했을 것 같다. 하지만 마블식의 정통적인 색깔로 덮여져 이런 결과물이 되었을 것 같다. 그래서 작가와 감독의 불협화음이 들리는 것 같다. 그래서 그런지 매 시리즈마다 시작되는 마블 인트로 부분이 불쾌하게 느껴졌다. 너무 길고, 존재감을 과시하는 느낌이어서 부담스럽다. 이런 인트로는 작품의 몰입을 해치는 장치라고 생각된다.

마지막 화에서는 감동받은 연출과 우스웠던 장면이 있다.
감동 받은 연출은 피라미드 표면의 계단 층을 문나이트는 달리면서 오르고 헤로우는 뛰어 내려오는 장면이 굉장히 감동적이였다.
서로가 싸우기 위해 양쪽에서 달려오며 중앙에는 커다란 보름달이 비추는데, 원래 피라미드 모양대로면 피라비드 표면이 카메라 장면에서 사선을 그려야 하는데 카메라 앵글을 오른쪽으로 돌리며 촬영해서 피라미드의 계단 층이 무수히 많은 피라미드의 모습으로 보이도록 연출되어 엄청난 아름다움을 표현한다.

반면 우스운 장면은 라일라가 타웨레트의 아바타가 되어 슈퍼슈트를 얻게 되고 헤로우 일당들과 싸우는 장면에서 보게된다.
문나이트가 헤로우에게 당하고 있을 때, 라일라도 헤로우 일당들 고군분투하는 장면이 나온다. 이때, 라일라의 슈퍼수트의 날개가 방패기능으로 쓰이기도 하는데, 악당들이 총을 쏘며 라일라에게 공격을 하는 장면에서 라일라는 날개로 총알들을 막는다. 그런데 총을 쏘고, 총을 막는 장면의 구도가 엄청 우습다. 악당이 너무 가까이서 날개에만 조준하는 모습으로 보이기 때문이다. 기를 쓰고 라일라를 쏠 의지가 없어보여서 보는데 김이 샜다. 오히려 피식 웃어버리고 말았다.

이렇게 완성도가 들쭉날쭉한 퀄리티로 소감이 남겨진다.
그리고 고대 이집트 소재를 활용한 만큼 역사 기반에서 재해석 작업이 들어간 것으로 보이는데,
이 영화를 해설하며 분석 및 강의를 해주시는 '곽민석 소장'님의 리뷰 영상이 '안될과학' 채널에 있다.

'심장아 나대지마'라는 표현도 이집트가 먼저다? 이집트 히어로 문나이트! (한국 유일의 이집트 고고학자 곽민수 소장)

문나이트 속 심판의 저울과 하마누님의 실제 정체는? (한국 유일의 이집트 고고학자 곽민수 소장)

문나이트 속 유물에는 이집트인이 아닌 파라오가 있다?! (한국 유일의 이집트 고고학자 곽민수 소장)

문나이트의 피라미드 속 구조, 실제와 비슷할까? (한국 유일의 이집트 고고학자 곽민수 소장)

역사학자 입장에서 아쉬웠던 문나이트 속 연출 (한국 유일의 이집트 고고학자 곽민수 소장)

이 영상들을 보며 많은 것을 배웠다. 다음으로 이어지는 내용은 곽민수 소장님이 '문나이트' 작품을 보고 고대 이집트 역사와 문화의 고증적 관점으로 풀어낸 강의를에 대한 리뷰이다.

이집트 신화는 현대의 문헌을 바탕으로 재구성한 내용이 많다고 한다. 그렇기 때문에 그 당시의 내용과 다를 수 있고, 지역마다 신화 체계가 모두 다를 수 있다고 한다. 그렇기 때문에 이집트 신화는 주관성이 강한 기록이라고 볼 수 있다. 이러한 특징들 때문에 현대에서는 아주 매력적인 작품으로 다뤄지지 않았나 싶다. 대중들에게 가장 많이 알려진 이집트 신화는 '헬리오폴리스 신학'이다.

이 헬리오폴리스 신학의 소재를 활용한 작품들 중 하나가 바로 '문나이트'이다.

소장님은 이 작품에서 매력적으로 연출과 이야기를 풀어내기도 했지만 많은 고증의 왜곡이 되어 있다고 설명하셨다. 이 설명들이 정말 재미있는 강연처럼 들렸다. 그러면서 나는 작품으로 재해석할 때 주의해야 할 점들을 반면교사로 배울 수 있어서 정말 유익했다.

주인공 스티븐은 고대 이집트 고고학 덕후 캐릭터로 나온다. 주인공이 책에서 이집트 신화의 신들의 관계도를 묘사한 페이지가 장면에 담기는데, 소장님은 그 책 페이지에 담긴 내용이 잘못된 정보임을 짚었다. 책의 내용은 아툼과 슈의 관계를 이어서 부부사이로 묘사하는데, 이는 사실이 아니다. 또 신들의 외형이 실제 문헌과 다르게 표현되어 있다. 소장님이 말씀하신 정보를 빌리면, 슈의 외형이 사자 얼굴을 하고 있는데, 틀린 그림 자료이다. 그리고 슈와 아툼은 부부관계가 아니고 아툼은 슈에게 부모의 존재이다. 슈가 여신으로 묘사되어 있는데, 슈는 심지어 남신이다. 테프누트의 남편이 바로 슈이다. 헬리오폴리스 신학의 대표적인 아홉명의 신을 '에니어드(Ennead)'라고 하는데, 이에 대해 주인공은 앞서 기념품 샵 상사에게 "포스터의 에니어드에 해당하는 신들이 일곱명 밖에 없다. 이건 잘못된 포스터 그림이다."라고 문제점을 지적하는데, 이는 명백한 설정오류라고 소장님은 꼬집으셨다. 고대 이집트 고고학에 상당한 지식을 가지고 있는 캐릭터 설정이 실제 문헌과 다른 책을 보고 있는 장면에서 캐릭터 설정이 깨지는 순간인 것이다.

주인공은 어쩌다 '스카라브'라는 쇠똥구리 모양 팬던트를 가지게 되는데, 이 팬던트를 보면 쇠똥구리 날개면에 이집트 상형문자가 적혀있다. 소장님은 이 문자가 아무런 의미가 없고 상형문자인척 그린 그저 장식이라고 설명했다. 그리고 팬던트의 외형적 특징이 있는데, 쇠똥구리 금조각 아래에 평평한 두께있는 바닥 판 모양 구조가 있다. 보통 이러한 유물은 기록용으로 쓰인다고 하셨다. 그 기록은 바닥 면에 음각으로 기록된다. 그래서 쇠똥구리의 날개 쪽에 글씨를 새기지 않는다고 하셨다. 이로 미루어 볼 대, 유물의 외형만 모티브로 활용하고 그 유물의 기능과 목적성, 특징을 고려하지 않았다는 것으로 유추된다.

암무트는 이 작품에서 최종 빌런으로 나오는 여신이다. 암무트의 이름 뜻은 '죽음을 먹는 자'이고 아주 유명한 유물인 '사자의 서'에서 묘사된다. 이러한 설정은 아주 매력적이다. 하지만 소장님은 의아한 반응이셨다. 암무트의 외형은 머리는 악어, 몸은 인간으로 표현되는데, 악어의 상징성으로는 '소베크'라는 나일강을 상징하는 이집트 신화에서 메이저 급의 신에게 더 적절한 상징물이었다고 하셨다. 그런 악어를 마이너급인 암미트 신에게 부여한 건 상징성의 해석이 일반적이지 않고 인식의 전도된 결과로 볼 수 있다. 심지어 '헤로우'라는 악당 대장 캐릭터가 여러 무리들을 이끌며 암미트를 숭배하는데, 이것도 이질적인 부분이라고 짚으셨다. 원래 암무트는 사후세계로 넘어가기 전 아누비스가 안내해서 데려온 인간을 저울로 죄가 있는지 없는지 판단하고 있다면 암무트가 그의 심장을 먹어버려 존재를 삭제하는 역할로만 기록되어 있다고 하셨다. 그러니까 다른 신들처럼 숭배의 대상은 아니었다고 보는 것이다. 그리고 작중 나오는 박물관의 기둥 벽화에 숭배의 대상이 그려있어야 맞는데, 그렇지 않은 암무트가 그려져 있어서 어색하다고 하셨다. 그렇지만 소장님은 고증과 거리가 있지만 꽤 괜찮은 컨셉이라고 덧붙였다. 그러면서 소장님과 함께한 진행자들은 후속작에서 '소베크'를 포함해서 이집트 신화 속 중요한 신들이 대거 등장할 가능성을 기대한다는 소감을 밝혔다.

일반 대중들은 대부분 놓칠법한 디테일을 짚어주셨다. 작중 악당들을 검문하는 이집트 관계 당국 직원들이 보이는데, 장면에서 흐리게 보이는 해당 기관 차량에 마크가 그려져 있는데, 그 모양새가 실제 이집트 국립 경찰 로고에서 모티브를 따온 것 처럼 비슷하다. 하지만 등장하는 이집트 관계 당국을 'Egyptian Patrol Agency'로 묘사되는데, 실제 이집트에는 없는 기관이다. 이건 꽤나 설득력 있는 디자인으로 보셨다.

하지만 이 외의 많은 부분들이 고증적 오류가 발생했음을 짚어주셨다.

1. 하마의 모습으로 사후세계 배경에서 등장하는 여신인 타와레트는 문헌에서 얼굴은 하마이고 몸은 사자로 표현되었는데, 작중 타웨레트는 손이 사람의 손으로 묘사되었다.

2. 주인공이 알렉산더 대왕의 미라가 보관된 무덤을 발견하는 장면이 있는데, 여기서 무덤의 배경에 있는 각각의 유물들이나 벽화, 조각상 등이 모두 시대가 고대 이집트의 타임라인에서 일관되는 부분이 없었다고 하셨다. 그러면서 알렉산더 대왕의 무덤은 아직까지 발견하지 못했고, 이유는 알렉산드리아 지역에 있다는 기록들은 많지만 그 지역은 실제 대부분이 바다에 잠겨서 조사가 힘들다고 덧붙여 알려주셨다. 그리고 작중에서 알렉산더 대왕의 관에는 바닥부분에 평평한 면에 문자가 기록되어 있는데, 그 문자가 마케도니아 어가 쓰여져 있다고 한다. 그런데 그 당시 마케도니아어가 있긴 했지만, 기록으로 쓰이지 않았고 구어로만 전해졌으며, 마케도니아의 문서는 고대 그리스어로 쓰여졌었다고 한다. 작중에 사용된 마케도니아어는 20세기 유고슬라비아의 마케도니아가 형성되면서 독자적으로 성립된 언어라고 설명하셨다. 그래서 마케도니아어를 언급하기에는 시대가 아주 달라서 부적절한 설정이고, 실제 알렉산더 대왕이 부장된 고대 이집트 식 양식의 관에는 고대 그리이어를 적지는 않았을 것이라고 하셨다. 차라리 고대 그리스어를 다른 석판에 분리된 형태로 기록하는 것이 더 자연스러울 수 있다고 설명하셨다.

3. 작중에 나오는 아바타들은 신들을 소환하기 위해 신들의 모습으로 만들어진 작은 조각상을 바닥에 던져 깨뜨리는데, 사실 이 조각상은 샤브티(Shabti) 혹은 우샤브티라고 하는 미라형 소상으로 고대 이집트의 부장 인형이다. 이 샤브티라는 이름의 뜻은 '대답하는 자' 즉, 주인의 하인을 칭하는 의미를 담고 있다. 이 소상은 왕족이나 귀족들이 부장할 때 많은 양을 함께 넣는데, 사후 세계에서 직접 노동을 하지 않고 하인들을 데려가서 일을 대신 해주고 생활에 필요한 것들을 갖추며 잘 살길 바라는 의미로 사용되는 유물이다. 그래서 해당 물건의 용도와 의미가 맥락상 잘못된 설정이다.

4. 작중 사후세계에서 거대한 구조물이 있다. 그 중 정말 드나들 수 있게 만든 문이 거대하게 있는데, 이 부분도 실제와 다른 부분이다. 피라미드에는 층이 한겹 한겹 들어간 모양의 막힌 벽이 있는데, 이것을 가짜문이라고 한다. 용도는 이승과 저승을 연결해 영혼이 드나드는 문이다. 그러니까 영혼이 드나들 수 있는 문은 실제 막힌 형태로 설계를 하는 것이었다. 그리고 그 문을 중심으로 양쪽에 두명의 석상이 있는데, 모두 아테프(오시리스가 쓰고 있는 왕관)를 쓰고 있다. 그래서 소장님은 네명 모두 오시리스로 유추하셨다.
고증 오류인 부분은 오시리스가 들고 있는 헤카와 네카카의 모양이 실제와 다르고 양 팔은 X자로 교차한 모양이어야 한다. 하지만 실제 오시리스가 네명이 나란히 배치된 구조물이 라메세움 유적지(람세스 2세의 장례 신전)에 있다.

이러한 양상을 볼 때, 이집트 컨셉을 표현하기 위해 논리 구조 없이 아무거나 가져와 전문성없이 조립했다는 일면이다.

전반적으로 고증과 다르거나 설정이 충돌하고 오류가 나는 부분은 이해한다고 소감을 말하셨다. 하지만 영화에서 고대 이집트를 소재로 기획했지만 고대 이집트 역사와 문화에 존중하는 태도는 아주 적절치 못하고 유감이라고 솔직한 비평을 하셨다.

총 세 가지의 장면들이 있는데, 첫번째 사례는 주인공 스티븐이 알렉산더 대왕 무덤을 발견하고 관을 열어 알렉산더 미라의 입 안쪽에 유물을 얻기 위해 턱을 부수는 장면이다. 스티븐은 앞서 고대 이집트 역사 덕후로서 많은 고고학에 애정과 관심을 보여주었던 캐릭터였다. 그러한 인물이 미라의 턱을 부수는 행동을 한 것은 절대적으로 설정 오류라고 꼬집었다. 고고학자들은 유물을 발굴할 때 손상을 전제로 작업을 하기 때문에, 발굴 작업 전 그대로의 보존 상태를 사진과 글로 충분히 증거를 남긴다. 그리고 최대한 훼손되지 않도록 조심하는데, 스티븐은 그런 과정도 없으며 망설임도 없이 미라의 턱을 파괴했다. 이러한 행동은 아주 무례하고 야만적인 것이라고 비판했다. 만약 외국인이 세종대왕님의 미라에 그런 행동을 한다면 화내지 않을 한국인은 없을 것이라며 적절한 비유로 비판의 타당함을 설명했다. 또 그러한 연출하는 작품의 관계자 또한 그 장면이 아주 비윤리적이라는 것을 분명하게 인지해야 한다고 훈계하셨다. 두번째 사례는 스티븐과 라일라가 미라를 만드는 방에서 적을 피해 숨는 장면이 있는데, 재단 아래 놓인 피에 적셔진 카푸노스 단지로 잔인하고 소름끼치는 공포를 연출한 부분에 대해 비판했다. 미라를 만드는 과정은 고대 이집트인들에게 목숨만큼 소중한 신성한 의식으로 여겨졌다. 미라를 만들지 않는 것은 있을 수 없는 일이고, 죽음보다 더 끔찍한 일처럼 생각했다. 그래서 그만큼 정교하며 많은 인력과 자본력을 투입하는데 이런 의식을 야만적이고 잔인한 모습처럼 연출하는 건 고대 이집트의 역사를 모욕하는 것이기 때문에 무례하다고 볼 수 있는 것이다. 현대의 장례의식에 비유하면 얼마나 타 문화에 무지하고 무례한지 느껴진다.

세번째 사례는 콘수와 암미트가 피라미드 옆에서 격하게 싸우면서 피라미드가 파괴되는 장면이다. 콘수와 암미트는 이집트 신화의 신들이고 피라미드는 태양신 사상과 오시리스 사후세계 신화가 건축으로 형상화된 신앙적 매개체이다. 그런 신성한 건축물을 싸우다 부수는 모습이 터무니없는 설정의 오류인 것이다.

이러한 모습에서 미국의 영화산업이 인종이나 인권 관련해서 윤리의식을 강하게 주장하는 반면, 타 국가의 문화재나 고고학에 관련해서는 모순된 행보를 보면 그런 윤리 감각에 유감스럽다며 씁쓸함을 표현했다. 특히 실제로 곽민수 소장님이 직접 겪은 경험으로는, 서양 국가 사람들이 문화재를 무례하게 다루는 것은 과거의 제국 주의 시대의 관성처럼 보인다며 반추하셨다. 고대 이집트를 소재로 활용하는 만큼 겉 껍데기으로만 소재로 사용하지 않고 고대 이집트의 문화와 역사에 대한 존중을 가졌으면 한다고 솔직한 바람을 전하셨다.

소장님의 불쾌한 장면을 사례로 보며 설명을 들으니, 이 작품의 특정 연출 장면들이 불편한 감정을 주고 비윤리적임이 느껴지고 합당함을 깨달았다. 그런데 필자는 소장님이 짚어 주기 전까지 그 작품을 보면서 불편함을 느끼지 못했는데, 왜 느끼지 못했던 것인지 고민해보았다. 우선 미라의 턱을 제껴서 여는 장면은 영화 '미이라'의 장면 일부를 떠올리게 되었고, 그 장면은 마치 해골이나 좀비의 턱이 부숴지는 모습으로 비쳐져 문화재를 훼손하고 있다는 사실을 망각하게 되어서 그런 것이 아닌가 싶다.
같은 이유로, 신들이 싸우는 장면에서 피라미드가 파손되는 모습은 괴수가 싸우는 모습('고질라'나 '킹콩')처럼 보여서 싸움의 화려함과 웅장함을 연출하려는 의도가 관객에게 작용되어 다른 생각이 떠오르지 않았던 것 같다.
이렇게 보면 디즈니의 행보는 과거의 내가 꿈꾸게 해주고 즐겁게 관람하던 것과 너무 다르게 가고 있어서 안타까우면서도 유감이다.
소장님은 고대 이집트의 역사를 소재로 다룬 작품 중 논란된 사례 하나를 언급했다. 그건 영화 '클레오파트라'(유니버셜 픽처스에서 제작중/미개봉)의 캐스팅 문제이다. 그 영화의 클레오파트라 역을 맡은 배우는 원더 우먼으로 유명한 '갤 가돗' 배우인데, 이 배우의국적이 이스라엘이다. 이집트인들은 이 캐스팅이 용납할 수 없어 분노했다. 왜냐하면 이스라엘(유대인)과 이집트(팔레스타인)는 네 번이나 전쟁을 벌였을 정도로 앙숙이기 때문이다. 이러한 상황을 봤을 때 국가와 문화 그리고 역사를 고려하지 않았음을 보여주는 사례이다.

작품을 어떻게 멋지고 아름답게 그리고 관객들의 흥미를 끌지만 생각하면, 결국 예술적이거나 산업적이거나 어느 쪽에서도 큰 성과를 해내지 못하는 것 같다. 그래서 미감도 중요하지만 예술의 논리를 세우는 것도 매우 중요하다. 그렇기에 역사 공부에 많은 노력과 시간을 투자해야 한다고 생각한다. 소장님의 해설로 여러 관점에서 배우고 깨닫게 되어서 소장님의 활동이 아주 값지고 유익하고 감사함을 갖고 있다.

스파르타 부트캠프:그간의 여정 [시작부터 출시까지의 과정 1/2]

EVANJ — Thu, 25 Jun 2026 13:43:46 +0900

코딩을 배워서 게임 개발에 직접적으로 들어가고 싶은 향학열이 있어, 이번 부트캠프에 참여하게 되었다.

다른 부트캠프들을 많이 탐색해보면서 가장 짧고 굵게 커리큘럼이 구성된 스파르타 부트캠프가 가장 끌렸다.

짧았지만 프로그래머로 배우고 작업해보면서 꽤나 많이 성장할 수 있었고

개발자로서 시작점으로 괜찮았다.
그동안의 여정을 정리해보았다.

Unity 12기 합격

스파르타 내일배움캠프에서 게임 개발 부트캠프

2025년 08월 20일 ~ 09월 26일

스파르타 부트캠프 합격 메세지

부트캠프로부터 최종 합격이 되었다.

그리고 9월 15일부터 일주간 사전캠프를 진행했다.

나는 개인 일정이 미리 정해져 있어서 참석하지 못했다. 그래서 미리 알았더라면 좋을 것 같다.

스파르타 클럽에서는 사전에 미리 기본기를 배울 수 있도록 온라인 강의를 제공해주었다.

"게임 개발이 처음이어도 쉽게 배우는 모바일 게임 개발"

이 강의에서는 "빗물 받는 르탄이", "풍선을 지켜라", "고양이 밥주기", "카드 뒤집기"의

내용으로 간단한 게임을 직접 만들어보는실무 위주의 내용을 담고 있다.

빗물 받는 르탄이 / 풍선을 지켜라 / 고양이 밥주기 / 카드 뒤집기

그리고 'TeamSparta' 노션에서는 기본적인 코딩 문법과 C# 기초 학습 자료를 정리해서 함께 제공해준다.

게임 개발 부트캠프 시작

2025년 09월 22일 월요일

부트캠프트는 Zep에서 온라인으로 참여하는 방식이다.

Zep 온라인으로 수업을 참여하는 모습

이런 수업은 처음 경험해봐서 꽤나 신선했다.

오히려 프로그래밍 수업에 최적화된 환경이라고 생각한다.

시간과 에너지를 절약할 수 있는 것이 아주 큰 장점이다.

Zep에서 멘토님의 방으로 찾아가 상담을 받는 모습

Zep에서는 큰 장점 중 하나가 지정된 구역에서는 그 구역 안에 있는 유저들만 서로 소통할 수 있는 것이다.

학습 중 질문이 생기면 언제든 멘토님께 찾아가 조언과 가이드를 받을 수 있었다.

스파르타 팀에서는 공지 및 안내를 'Notion'으로 공유했다.이미 노션의 존재를 알고 있었지만 적극적으로 사용해본적이 없어서 처음에는 낯설고 불편했다.하지만 사용하면 할 수록 아주 편리한 기록 및 공유 앱이라는 것을 깨달았다.그래서 현재도 아주 애용하고 있다.

1 주차

'카드 뒤집기' Unity 게임 개발 실습_ 팀 프로젝트

2025년 09월 22일 ~ 09월 26일

OT에 참석해서 앞으로의 커리큘럼 참여 방법들을 안내 받았다. 그리고 새로운 사람들과 팀을 구성해서 첫번째 프로젝트를 개발했다. 그건 사전 강의에서 제공된 '카드 뒤집기' 게임을 제작하는 것이었다.

이때 가장 큰 난관은 팀으로 함께 개발을 하는 것었다. 튜터님들은 팀 프로젝트에서 가장 중요한 '버전 관리 도구'를 사용하는 방법을 알려주었다. 버전 관리 플랫폼(호스팅 서비스)인 'Github'를 제일 먼저 배웠다. 그리고 클라이언트 및 인터페이스(작업 도구)인 'Github Desktop(GUI)'와 'Fork' 그리고 'Terminal(CLI)' 를 배우게 되었다.

Github desktop은 가장 직관적인 GUI로 구성되어 있어 초반에 사용하기 편리했다. 하지만 혼동이 올 수 있는 잠재적 위험요소가 있어 실무에서는 'Git Terminal'이나 'Fork'를 사용하는 편이다. 특히 'Fork'는 시각적으로 브랜치를 보여주며 'Push'와 'Pull'이 분리되어 있어 편리하다.

첫번째 팀 : 6조 노션

내배캠_TIL250926[팀 프로젝트 (완료)]

개발하는 내내 여러 오류들이 발생해서 많이 힘들었다. 더군다나 기초 학습이 충분히 되어있지 않아 따라가는 것이 버거웠다.

그래도 꾸역꾸역 했었다. 첫 프로젝트에서 많은 것들을 배웠다. 비록 첫 프로젝트 발표회에서 우수 팀으로 선정되지 못했지만 그래도 충분히 의미가 있었다.

2 주차

C# 기초 문법 학습_개인 프로젝트

2025년 09월 29일 ~ 10월 03일

부트캠프에서는 매주 미션을 주는데, 해당 주에는 'Text RPT'를 구현하는 미션이었다. 이번 한 주 동안은 기존 맵과는 다른 어두침침한 맵에서 각 스탭별 문제를 풀고 튜터님께 검사를 맡은 뒤 계속 스탭을 넘어가며 미션을 수행해야 했다.

각 문제들은 'Text RPG'를 구현하는 문제들이었고 '변수와 타입', '연산자와 조건문', '메서드', '반복문' 등을 다루며 프로그래밍에 기초적인 공부를 할 수 있었다.

각 스탭별 문제마다 각자 역량에 맞게 'Basic', 'Standard', 'Challenge' 중 골라서 문제를 풀 수 있었는데, 필자는 기본기도 배우러 온 입장이기 때문에 Basic으로 선택했다. 다른 몇몇의 수강생들은 거의 스탭과 스탭 사이를 뛰어다니는 듯 해서, 내심 초조한 마음으로 문제를 풀었다. 나는 우선 제공된 'C# 문법 종합반' 강의를 보며 스스로 기초 학습을 갈고 닦는 시간으로 보냈다. 그리고 문제를 풀어갔다.

'Text RPG'는 그래픽 없이 오직 텍스트 출력과 키보드 입력만으로 플레이할 수 있는 콘솔 기반 연습용 프로젝트이다. 미션을 수행하다 '아스키(ASCII) 아트'를 알게되었고 이 코드는 사막과 같던 콘솔창에 조금이나마 생동감을 불어넣을 수 있는 방법이었다.

'Text RPG'는 기본적으로 Console.WriteLine() 으로 상황을 보여주고, Console.ReadLine() 이나 Console.ReadKey() 로 입력을 받도록 한다. 'while 문'으로 무한루프를 작동시켜 코드가 반복해서 화면에 띄워서 '게임 화면'처럼 보이게 구현하는 방식이다.

마치 옛날 컴퓨터 버전을 사용했던 초기 시절로 돌아가 경험해보는 것 같았다.

이 과정을 통해 '객체 지향(OPP)'를 이해하는데 큰 도움이 되었다.

4·5 주차

C# 심화 문법 학습_팀 프로젝트

2025년 10월 13일 ~ 10월 21일

3주차는 추석으로 휴식을 취하고,4주차에는 개인 프로젝트로 진행했던 'Text RPG'를 팀원들과 함께 작업하는 미션이 주어졌다.

여기서 나에게 가장 핵심 활동은 첫째주에서 어려워했던 Github Tool을 더 잘 활용해보는 것이었다. 두번째로 사용해보니 조금 더 익숙했었다. 팀원들과 함께 어떻게 하면 더 재미를 구현할 수 있을까 논의를 했었다. 방법을 모색하던 중 콘솔 창에서도 이미지를 출력해낼 수 있는 방법을 찾았다. 그건 'SixLabors.ImageSharp' 패키지 기능이다. 이 패키지를 설치하면 콘솔창에서 ANSI 컬러 출력 기능이 활성화된다. 'AsciiArt.cs'에서 이미지를 불러와 크기를 줄이고 각 픽셀의 RGB 값을 콘솔 배경으로 출력을 하고, 'asciiWidth', 'cellWidth', 'aspectFix' 값을 조정해 이미지 크기와 비율을 개선했다. 이 패키지 기능 덕분에 여러 팀들 중 유일하게 이미지를 출력해서 몰입갑을 강화한 프로젝트를 구현할 수 있었다. 그래서 내가 속한 10조가 우수 프로젝트로 투표받았다. 부트캠프에서 성과를 성취하면 Zep에서 포인트를 지급한다. 이 포인트로 특별한 아바타 의상이나 효과를 이용할 수 있다. 나름 성취욕을 자극하는 시스템이었다.

5·6 주차

유니티 입문 학습_개인 프로젝트

2025년 10월 22일 ~ 10월 28일

5주차부터는 유니티 엔진에서 게임을 구현하는 학습이 진행됐다.

팀스파르타에서 제공된 'unity 게임 개발 입문' 강의를 수강하며 Unity에서 세 가지 게임을 개발해 볼 수 있었다.

Unity 설치부터 기본적인 조작법
'Tappy Plane' 클릭으로 위 아래로 이동하며 장애물을 피하는 게임
'The Stack' 화면을 클릭해 움직이는 블록을 아래 블록 위에 맞춰 높이 쌓아 올리는 게임
'Top Down Shooting' 2D 화면에서 캐릭터를 조작해 몬스터의 공격을 피해 대적하는 게임

이런 실습 과정을 통해 Unity 설치와 프로젝트 생성, 인터페이스 조작, 스프라이트와 애니메이션 설정 등을 익혔다. 캐릭터의 이동, 점프 그리고 충돌 처리 같은 기본 조작 로직을 배웠다. 이후 장애물 생성, 점수 시스템, 게임의 재시작과 게임 오버 그리고 빌드까지 게임 개발의 전체 흐름을 훑어볼 수 있었다. 그리고 함께 주어진 실습 미션도 있었는데 '스파르타 메타버스' 만들기었다.

강의 내용을 따라 만든 게임들을 한 유니티 프로젝트에서 구현해서 기본 게임을 만들고 그 안에서 미니게임으로 실행 할 수 있도록 구현하는 것이 목표였다. 이를 위해 새롭게 나만의 게임 배경과 캐릭터를 만들었고 그 맵에서 NPC와 미니게임 연결 구역을 만들어야 했다. 이 주간은 강의도 수강하고 미션도 수행하느라 정말 힘들었다.

6·7 주차

2D 프로젝트 실습_팀 프로젝트

2025년 10월 29일 ~ 11월 05일

이번 실습 프로젝트는 Unity에서 2D게임을 개발하는 것이 과제였다.

하지만 기존의 인지도가 높은 게임 세 가지 중에서 골라서 최대한 따라 만들어보는 것이 조건이 있었다.

그 세 가지 게임은 'Fire & Water', '쿠키런', '궁수의 전설'이었다. 그 중 팀원끼리 의논을 하고 한 가지를 선택해 일주일 동안 제작해야 했다. 그때 팀원들과 의논 했을 때, '궁수의 전설'은 너무 어려워 보였고 '쿠키런'은 너무 무난해 보였다고 의견이 모였었다. 그래서 최종적으로 'Fire & Water'를 선택하게 되었다.

주요 학습 내용은 플레이어 조작, 점프와 이동, 충돌 처리, 카메라, UI, 아이템, 씬 전환, 점수 시스템, 빌드와 배포 등이었다.

각자 파트를 나누어 역할 배분을 나누었는데, 나는 UI, 튜토리얼, 불 캐릭터 애니메이션, 맵 빌드, 이미지와 음원 리소스를 제작했다.

이 프로젝트를 할 때, 두 명의 컴공과 출신이 있어서 많이 배우게 되었다.

필자는 주어진 학습 자료에서만 허우적거리는 느낌이었는데, 먼저 앞서가는 우등생들의 모습에 여러 질문들을 하게되고, 작업한 결과물을 보니 자극도 받고 모범적인 부분들을 따라하게 되었다. 덕분에 여러 힌트들을 찾게되면서 많은 성장이 있었다.

또 프로젝트를 개발하면서 기능 구현뿐 아니라 테스트, 오류 해결, 코드 구조화, 확장 기능 설계까지 함께 다루어서 시야가 넓어졌었다. 한 수강생의 와이어프레임을 설계하는 것이 가장 인상 깊었는데, 이후 와이어프레임을 스스로 설계하는데 큰 도움이 되었다.

아마 이 미션 이후부터는 잠이 많이 줄었었던 것 같다. 정말 페인처럼 지내왔었다.

7·8 주차

유니티 숙련 학습_개인 프로젝트

2025년 11월 06일 ~ 11월 13일

다시 혼자서 새롭게 제공된 'Unity 게임 개발 숙련'강의를 청취하면서 미션을 수행해야 했다. 이번 미션은 'Unity 3D 던전 탐험 프로젝트'를 개발하는 것이었다. 3D가 2D보다 더 익숙했지만 제목만 보면 뭔가 엄청 부담스러웠다. 하지만 강의 내용이 정말 친절하고 자세하게 가이드 해주셔서 어려울 수 있었지만 정말 재밌게 수강했던 학습 주제였다. 밤과 낮을 구현하고, 인벤토리를 구현하고 아이템을 사용, 데미지 처리를 배울 수 있었다. 무엇보다 가장 몰입이 되었던 부분은 적을 생성하고 AI 네비게이션을 구현한 내용이었다. 생각보다 단순한 로직이지만 이 내용을 기초로 발전 시킬 수 있을 것 같아 큰 배움이었다. 강의대로 한번 동작 구현을 해보고 직접 새로운 프로젝트에서 나만의 방식대로 미션을 수행을 했었다.

주요 구현 내용은 WASD 이동과 점프. 'Rigidbody'를 활용한 물리 처리, 체력바 UI, Raycast를 이용한 오브젝트 조사, 점프대 구현, 아이템 데이터 관리, 아이템 사용 효과 등이었다. 이번에는 추가 도전 기능에서 몇몇 기능을 구현할 수 있었다. UI, 3인칭 시점, 장비 장착, 상호작용 오브젝트 표시, 플랫폼 발사기를 구현했었다.

8·9 주차

유니티 숙련 실습_팀 프로젝트

2025년 11월 14일 ~ 11월 21일

다시 팀 프로젝트로 미션이 주어졌다. 나는 아직 숙련되지 않았지만 숙련 프로젝트를 수행해야 했다. 이번에도 전 팀 프로젝트처럼 세가지 게임 중 한가지를 선택해서 예시의 게임처럼 구조를 잡고 주요 기능만 따라 구현하는 것이 주된 목표였다. 선택지는 'Subway Surfers' 러닝 장르, 'Portal / The Witness' 퍼즐 및 장애물 건너기 장르, 'Valheim / ARK' 크래프트 및 서바이벌 장르로 구성되어 있었다. 나는 개인적으로 러닝 장르 외의 두 가지 장르는 막연하고 하드코어하게 느껴졌다. 무엇보다도 강의에 없는 기능들이 포함되어 있어서 부담스럽게 느껴졌다. 하지만 다른 팀원들은 '크래프트 및 서바이벌' 장르로 투표를 했다. 그래서 세 번째 장르로 의견이 좁혀져 선택이 되었다. 3D 프로젝트이다 보니 무료 에셋을 이용하여 게임 구조를 빠르게 만들어야 했다. 첫 날 팀원들과 게임 컨셉을 기획하고 게임 플레이 루프를 구체화했다. 그리고 역할분배를 의논했는데, 나는 이전 팀 프로젝트 작업을 하면서 캐릭터를 꼭 한번 작업해보고 싶었기 때문에 캐릭터 조작을 적극적으로 나서서 담당했다. 이번 프로젝트에서는 다른 팀원을 도와주기도 해서 직접 구현한 기능들이 많았다. 게임 플레이 루프 기획을 도맡아 와이어프레임도 직접 짜보았다. 지난 2D 프로젝트 때 함께 했던 다른 모범 수강생 덕분이다.

플레이어 조작은 Input System과 Rigidbody를 활용해 이동, 점프, 시점 회전을 구현했다.

기본 조작 'WASD'으로 이동하고 마우스로 카메라를 조작할 수 있도록 했다.

그리고 조금 헤맸던 부분은 'Esc'키로 설정창이나 인벤토리창을 열었을 때 카메라는 움직이지 않게 고정해야 했던 작업이었다.

문제는 카메라 회전이 'PlayerController.cs'의 LateUpdate()에서 계속 실행되고 있었기 때문이었다.

private void LateUpdate()
{
    if (canLook)
    {
        CameraLook();
    }
}

UI 창이 열렸는지 여부와 카메라 조작 가능 여부가 제대로 연결되지 않아서 다음과 같은 처리가 필요했다.

마우스 커서 잠금 해제
카메라 회전 정지
UI 닫을 때 다시 커서 잠금
카메라 회전 재개

그래서 PlayerController에 canLook 변수를 두고, 인벤토리나 설정창을 열 때 이 값을 false로 변경해서 카메라 회전을 막았다.

void ToggleCursor()
{
    bool toggle = Cursor.lockState == CursorLockMode.Locked;

    Cursor.lockState = toggle ? CursorLockMode.None : CursorLockMode.Locked;
    canLook = !toggle;
}

그리고 카메라 회전은 canLook이 true일 때만 실행되도록 했다.

private void LateUpdate()
{
    if (canLook)
    {
        CameraLook();
    }
}

이러한 이슈들을 해결하고, 또 다시 발생하는 여러 트러블 슈팅을 겪으며 머리는 아팠지만 성장했었다.

Navigation Bake 오류로 몬스터들이 특정 부분에서 뒤엉키는 이슈 발생

캐릭터의 상태 값들은 체력, 허기, 스태미나로 구성했고 물을 마시고, 음식을 먹으며 여러 상태값을 회복할 수 있는 기능을 구현했다.

그리고 좀비를 사냥하기 위해 FPS 기능을 구현했다. 상호작용 기능처럼 Raycast를 쏘는 방식으로 구현했다. 이 밖에 좀비의 애니메이션 연결과 피격시 데미지 연산 그리고 이펙트 출력, Unity 맵 에디터로 지형 편집 및 배경 제작, 낮과 밤 기능으로 스테이지 별 구분 기능, 무기 교체 기능, 좀비 바리에이션 3종 추가, 플레이어 안전지대 조성 및 NPC 추가, 강아지 NPC의 적이 기지로 침입하면 짖게 하는 경보 시스템 구현 이렇게 많은 도전을 할 수 있는 프로젝트였다.

스카이박스 셰이더 작업 전/후 비교

유니티 맵 빌더로 조성한 지형 맵

그래서 2D 프로젝트 개발보다 더 시간이 촉박하게 느껴졌었다. 게임은 어느정도 구현이 되었지만 아쉽게도 처음과 끝을 분명하게 마무리하지 못했다. 욕심도 컸고 새로운 기능들을 학습하느라 엔딩까지는 구현하지 못했다. 하지만 발표회에서 수강생들의 투표를 받아 우수 작품으로 뽑히게 되었다.

이번 프로젝트는 지난주에 강의를 따라 실습했던 경험이 아주 실질적으로 도움이 되었다. 이럴 때 꾹꾹 눌러 담아 알차게 기획된 커리큘럼이 정말 대단하다고 느낀다. 그렇지만 너무 바쁜 일정으로 거의 밤샘 작업으로 이어져서 너무 피곤했다. 3D 프로젝트 미션 수행을 하면서 TIL 작성도 미루게 되었고 결국 이후 부터는 TIL을 작성하지 못했다.

10 주차

유니티 심화 학습_개인 프로젝트

2025년 11월 24 일 ~ 11월 28일

이번에도 기존 팀에서 새롭게 팀으로 구성되고 새로운 미션을 받았다. 그런데 이번에도 2주차 미션처럼 그 어두침침한 맵으로 이동해서 스탭별로 과제를 수행해야 했다. 하지만 숙련도 별 과제 내용은 달랐다.

ATM 시스템 구현하기 ★
Unity 인벤토리 구현하기 ★ ★
3D 방치형 RPG 구현하기 ★ ★ ★ ★

나는 이번에도 기본기 학습을 위한 선택을 했다. 그건 'ATM 시스템 구현하기' 미션이었다. 별이 하나로 적혀있었지만 내게 결코 만만하지는 않았다. Unity UI와 C# 스크립트를 활용해서 간단한 ATM 시스템을 구현하는 과제였다. 그리고 사용자의 이름, 현금, 통장 잔액 정보를 관리하고, 입금·출금·저장·불러오기 기능을 직접 구현하는 것이 핵심이었다. 구현 과정에서 UI 화면 전환, 버튼 이벤트 연결, 데이터 관리, 예외 처리를 연습하고 익히는데 최적의 과제 내용이였다고 생각했었다. 현재 금액 정보가 유지될 수 있도록 저장 및 불러오기 기능을 구현하면서 Json 방식을 처음으로 실습해 볼 수 있었다.

11 주차

3D 심화 프로젝트_팀 프로젝트

2025년 11월 28일 ~ 12월 05일

이번 주 팀 프로젝트는 지난 주에 배정된 팀원들과 함께하는 줄 알았지만 개인과제만 하고 흩어져버렸다.

이유는 이번 프로젝트는 최종 프로젝트의 'Prototype'을 만드는 것이 미션이었다. 그래서 이번 조 편성은 특별하게 진행되었다.

지난 5주차까지는 함께 공통 개발 과정을 진행하다 6주차부터 기획자 과정을 지원받아 기획자 전용 커리큘럼으로 분리되는 과정이 있었다. 5주 동안 기획자들은 실전 프로젝트를 위한 기획자 수업을 받고 기획서를 작성을 했다. 그리고 11월 28일에 각 기획자들의 기획서를 공유받고 Zep에서 부스를 조성한 맵에서 기획자들에게 직접 찾아가 게임 기획 설명을 들을 수 있었다. 최종 프로젝트에 반영이 될 기획서를 고르려하니 선택이 너무 어려웠다. 모든 기획서를 살펴본 결과, 데이터 테이블이 작성되어 있고 세부적인 계획이 다른 기획서들에 비해 좀 더 갖춰져 있던 게임 기획서를 선택했다. 그리고 저녁 시간이 가까워진 시간 쯤에 빠르게 조 편성이 되었다. 그렇게 네 명이서 프로토 타입 프로젝트를 개발하게 되었다.

예술의 논리

EVANJ — Wed, 24 Jun 2026 21:58:43 +0900

예술의 논리에 대해 흥미를 갖고 탐색한 배경

투썸플레이스 회사의 심볼 디자인에서 논리를 분석한 영상을 보게 되었다. [영상링크]
이때, 내가 만드는 건 논리가 있는지 의심이 되었다.
그리곤 이 ‘논리’가 왜 중요한지 깨닫게 되었고, 그 깨달음에 딸려오는 수 궁금증과 질문을 GPT을 활용해 학습을 시작했다.

예술의 논리는 다음 문장으로 정의할 수 있다.

’내가 전달하려는 의미와 감정을, 왜 이런 소재·형태·순서·연출로 표현했는지를 연결해 주는 인과관계.’

즉, 작품의 모든 선택이 서로 같은 방향을 바라보게 만드는 표현의 설계도에 가깝다.

투썸의 심벌 디자인 논란 사례에서 중요한 교훈을 얻을 수 있다.
’작가에게 논리가 있다는 것과, 관객이 그 논리를 따라갈 수 있다는 것은 별개의 문제다.’
예술의 로직은 내부적으로만 완벽해서는 안 된다. 관객이 작품을 보며 의미를 어느 정도 역추적할 수 있는 단서가 필요하다.

예술은 완전히 정의하기 어렵지만, 이렇게도 정의할 수 있다.

”예술은 인간이 경험한 감정·생각·감각·질문을, 다른 사람이 경험할 수 있는 형태로 바꾸는 형태이다.”

예술의 기본구조

표현하려는 무엇인가 = 인간의 경험
감정 / 기억 / 관점 / 문제의식 / 상상 / 설명이 어려운 감각
그것을 담는 형식 = 표현 형식으로 변환
그림의 색과 구도 / 캐릭터의 실루엣과 재질 / 음악의 음정과 리듬 /
글의 문장과 사건 / 영화의 장면과 편집 / 조각의 형태와 공간
그것을 경험하는 사람 = 타인의 새로운 경험
작품은 관객이 보거나 듣거나 읽으면서 비로소 작동한다.

예술과 단순한 표현의 차이

아이가 울거나, 화난 사람이 소리를 지르는 것도 감정표현이다. 하지만 보통 그것을 곧바로 예술이라 하지 않는다. 예술에는 감정을 그대로 배출하는 것에서 한 단계 더 나아가, 그것을 선택하고 조직하는 과정이 있기 때문이다.

예를 들어 슬프다고 단순히 우는 것은 감정 표현이지만,

● 비어 있는 의자를 보여주고
● 주변의 생활 흔적은 그대로 남겨두며
● 인물은 등장시키지 않고
● 방 안의 시계 소리만 강조한다면

상실이라는 감정이 관객에게 전달되도록 감정을 구조화 한 것이다.
감정 자체보다, 감정을 전달하기 위해 무엇을 남기고 무엇을 제거했는지가 예술의 영역에 가깝다.

예술은 메세지를 전달하는 것인가?

부분적으로 맞지만, 예술이 반드시 명확한 교훈이나 주장을 가져야 하는 것은 아니다.

● 어떤 주장을 전달한다.
● 특정 감정을 체험하게 한다.
● 익숙한 대상을 낯설게 보게 한다.
● 답하기 어려운 질문을 던진다.
● 말로 표현하기 어려운 것을 감각적으로 보여준다.
● 존재하지 않는 세계를 잠시 믿게 만든다.

그래서 예술은 “전쟁은 나쁘다.”처럼 명확한 문장을 전달하지 않아도 된다.
”이것이 아름다운지 두려운지 나도 확신할 수 없더. 당신은 어떻게 느끼는가?”
이처럼 질문을 정확하게 경험시키는 것도 예술이 될 수 있다.

예술은 아름다워야 하는가?

반드시 그렇지 않다. 예술에는 아름다움 뿐 아니라 다음과 같은 것도 포함될 수 있다.
불쾌함 / 공포 / 비극 / 추함 / 혼란 / 허무 / 긴장 / 우스꽝스러움
다만 좋은 작품은 그것들이 무작위로 존재하는 것이 아니라, 작품의 의도나 경험을 위해서 기능한다.
예를 들어 캐릭터 얼굴에 흉터가 있다면 단순히 거칠어 보이게 하는 장식일 수 있지만, 흉터의 위치와 방향이 과거의 사건을 암시하고, 그 사건이 현재의 성격과 행동에 영향을 준다는 장치를 의도적으로 마련한 것이라면, 그때 흉터는 단순한 디테일을 넘어 서사를 압축한 형식이 된다.

예술가가 하는 핵심적인 일

예술가는 단순히 무언가를 창조하는 사람이 아니라, 끊임없이 선택하는 사람이라고 볼 수 있다.

● 무엇을 보여줄 것인가?
● 무엇을 감출 것인가?
● 무엇을 크게 만들 것인가?
● 무엇을 반복할 것인가?
● 어떤 재질을 사용할 것인가?
● 관객이 무엇을 먼저 보게 할 것 인가?
● 얼마나 명확하게 말하고 얼마나 모호하게 남길 것인가?

모든 것을 넣는 것은 예술적 판단이 아니다. 오히려 무엇을 제외할지 결정하는 일이 더 중요할 때가 많다.
예술적 완성도는 디테일의 양보다, 선택들이 얼마나 같은 방향으로 연결되어 있는가에 의해 결정된다.

예술에서 독창성이란 무엇인가?

완전히 새로운 소재를 만들어내는 것만 독창성이 아니다. 태양, 죽음, 사랑, 왕, 전사, 동물 신 같은 소재는 수천 년 동안 반복되어 왔다. 중요한 것은 그것을 누구의 관점으로 어떻게 연결하느냐이다.
예를 들어 Sobek을 단순히 “강한 악어 신”으로 표현하면 익숙한 재현에 머물 수 있다.
하지만 이렇게 관점을 정한다면 달라진다.
“인간은 자신을 죽일 수 있는 자연의 힘을 제거하지 못했다. 대신 그 힘을 신으로 만들고, 왕의 편에 세웠다.”

예술을 가장 간단하게 정의하면, 느낀 것을 그대로 쏟아내는 것이 아니라, 다른 사람도 그것을 경험할 수 있도록 형태와 질서를 부여하는 것. 그리고 좋은 예술은 관객에게 단순히 정보를 알려주는 데서 끝나지 않는다. ”작가가 이런 말을 했구나”를 넘어서, “나는 이것을 보며 무엇을 느끼고, 무엇을 생각하게 되었는가?”가 남게 된다. 그래서 예술은 메세지의 전달이면서 동시에 경험의 제작이고, 때로는 질문의 제작이다.

예술 표현의 기본 워크 플로우

Discover → Define → Develop → Deliver

공감 → 정의 → 발상 → 프로토타입 → 테스트

디자인 분야에서는 위 구조 과정을 널리 사용한다. 하지만 실제 창작은 반드시 직선으로 진행되지 않는다.

1. 원초적인 충동을 발견한다.

처음부터 메세지를 멋진 문장으로 만들 필요는 없다. 먼저 자신이 왜 이 작업을 하고 싶은지 찾는다.
● 어떤 장면이 머릿속에 남아 있는가?
● 무엇이 아름답거나 불편한가?
● 무엇에 분노하거나 매혹되는가?
● 어떤 감정을 다른 사람도 경험하게 하고 싶은가?
이것은 아직 메세지가 아니라 창작의 씨앗이다.

2. 주제와 메세지를 분리한다.

‘주제’와 ‘메세지’는 다르다.
(왕권, 죽음, 보호, 자연, 공포, 신성함…)
주제는 작품이 다루는 범위이다.
메세지는 그 주제에 대해 작가가 말하고 싶은 관점이다.
(인간은 자신이 두려워하는 힘을 숭배함으로써 보호의 힘을 전환한다.)
”내 작품은 Sobek에 관한 작품입니다.”는 주제일 뿐이다. “위협적인 자연의 힘이 왕과 백성을 지키는 신성한 권위로 바뀐다.”까지 가야 메세지가 된다.

3. 관객에게 남길 경험을 정한다.

메세지만 정하면 작품이 설명문처럼 될 수 있다. 따라서 감정 목표를 함께 정해야 한다.
예를 들어 Sobek 캐릭터를 본 관객이 다음 순서로 느끼게 할 수 있다.

처음에는 압도된다.
자세히 보면서 약간의 공포를 느낀다.
그 공포가 무질서하지 않고 통제되어 있음을 발견한다.
마지막에는 보호자와 왕의 위엄을 느낀다.
이를 감정 곡선이라고 생각하면 된다.
경외 → 긴장 → 이해 → 신뢰
음악에는 곡의 전개가 되고, 글에서는 사건의 흐름이 되며, 캐릭터 디자인에서는 시선이 이동하는 순서가 된다.

4. 핵심 문장을 만든다.

다음 형식을 사용하면 좋다.
”나는 [대상]을 통해서 [관점]을 표현하고, [감정]을 느낀 뒤 [생각]을 떠올리게 하고 싶다.”
Sobek 예시)
나는 Sobek의 악어성과 왕권을 통해, 두려운 자연의 힘이 인간을 보호하는 신성한 권위로 전환되는 모습을 표현하고 싶다. 관객이 먼저 위압감을 느끼고, 이후 그 힘이 백성을 위한 보호라는 사실을 발견하게 하고 싶다.

5. 의미를 구성 요소로 분해한다.

핵심 문장을 바로 조형으로 옮기지 말고, 먼저 의미를 나눈다.

의미 관객에게 느껴져야 하는 것

악어	원초적 위험, 물속의 포식자
나일강	생명, 범람, 재생
왕권	질서, 통제, 지배
신성함	인간을 초월한 존재
보호	감싸고 막아주는 구조

이 단계가 중요한 이유는, “이집트 느낌이 나는 장식을 많이 붙이는 것”과 “의미 있는 디자인”을 구분해 주기 때문이다.

6. 의미를 형식으로 번역한다.

이것이 예술 로직의 핵심이다.

의미 조형 언어

위압감	넓은 상체, 큰 머리 장식, 낮은 무게 중심
공격성	전방으로 뻗은 턱, 날카로운 실루엣
보호	겹쳐진 비늘, 몸을 감싸는 장갑 구조
왕권	수직축, 좌우대칭, 금, 태양 원반
나일강	반복되는 수평 물결, 청색 파이앙스
오래된 신성함	마모된 석재, 묵직한 덩어리감

음악
불안 → 불협화음, 불규칙한 박자
위엄 → 느린 템포, 낮은 음역, 반복되는 강한 리듬
해방 → 음역 확장, 화음의 해결
상실 → 멜로디의 중단, 빈 공간, 반복되는 잔향

글
불안 → 제한된 정보, 짧은 문장, 불완전한 기억
권위 → 절제된 대사, 느린 행동, 타인의 반응
상실 → 반복되는 사물이나 문장
변화 → 초반과 후반에 같은 장면을 다른 의미로 반복

7. 표현의 규칙을 만든다.

작품의 일관성을 유지하려면 작은 헌법 같은 것을 정한다.

Sobek 디자인이라면 다음과 같은 규칙을 만들 수 있다.
모든 큰 형태는 악어의 신체 구조나 이집트 왕권에서 출발한다. 장식은 보호·왕권·나일강·재생 중 하나의 의미를 가져야 한다. 이유를 설명할 수 없는 장식은 제거한다. 가장 중요한 상징은 머리와 흉부에 부차적 서사는 골반과 팔다리에 배치한다. 상형문자는 정확한 의미가 검증된 경우에만 사용한다.

이런 규칙이 있으면 아이디어가 많아져도 작품이 하나의 세계관 안에서 유지된다.

8. 여러 해답을 만든다.

첫 번째 아이디어를 곧바로 완성하지 않는다. 같은 메세지를 표현하는 방식을 최소한 3개 정도 만든다.

예를 들어 “보호하는 Sobek”이라면 :

악어의 등비늘이 몸을 감싸는 방어구
나일강 물결이 왕을 둘러싸는 의상 도구
Sobek의 턱이 적을 삼키고 착용자를 보호하는 마스크
신들의 권능이 기둥처럼 팔을 지지하는 완갑

이 단계에서는 넓게 탐색하고, 이후 핵심 메세지와 가장 잘 연결되는 안으로 좁힌다. 이는 디자인 과정에서 말하는 발산과 수렴에 해당한다.

9. 관객의 시선 순서를 설계한다.

좋은 작품은 모든 것을 한꺼번에 말하지 않는다.
다음 과 같은 순서를 만든다.
첫 인상 → 핵심 상징 → 세부 발견 → 의미의 재해석 → 여윤
큰 실루엣부터 미세 문양까지 모두 같은 의미를 반복하되, 서로 다른 거리에서 정보를 제공해야 한다.

10. 설명 없이 테스트한다.

작품을 보여 주기 전에 메세지를 설명하지 않는다. 그리고 다음 세 가지만 묻는다.

가장 먼저 무엇을 보였는가?
어떤 감정을 느꼈는가?
이 인물이나 작품이 무엇에 관한 것 같았는가?

관객이 정확한 문장을 맞힐 필요는 없다. 하지만 내가 의도한 것이 ‘신성한 보호자’인데 대부분이 ‘사악한 암살자’라고 읽는다면, 표현 로직 어딘가가 잘 못된 것이다. 중요한 것은 작품을 보고 난 뒤 작가의 설명을 듣고 “아, 그래서 그랬구나”가 되는 거이다. 설명을 들은 뒤에야 “그런 의미였다고?”가 된다면 단서가 부족했을 가능성이 높다.

좋은 예술 로직의 조건

좋은 작품은 세 가지가 연결되어 있다.

의도 → 형식 → 관객의 경험

예를 들면 :
보호를 표현한다. 그래서 비늘이 몸을 감싸는 구조를 사용한다. 관객은 캐릭터가 공격적이면서도 단단하게 보호받고 있다고 느낀다.

반대로 약한 논리는 다음과 같다.
멋있어서 비늘을 넣었고, 공간이 비어서 전갈을 넣었다. 그리고 이집트 같아 보여서 상형문자를 넣었다.

각각은 멋있을 수 있지만 하나의 메세지를 향하지 않기 때문에 작품이 장식의 모음처럼 보이게 된다.

모호함과 논리는 반대가 아니다.

예술은 반드시 하나의 정답만 전달해야 하는 것은 아니다. 논리가 있다는 것은 관객의 해석을 하나로 강제한다는 뜻이 아니라, 여러 해석이 나오더라도 작품의 핵심 범위 밖으로 무작정 흩어지지 않게 하는 것에 가깝다. Sobek 캐릭터를 보고 어떤 사람은 왕을, 어떤 사람은 수호신을, 어떤 사람은 자연의 공포를 먼저 떠올릴 수 있다. 이 셋은 모두 같은 의미망 안에 있으므로 좋은 모호성이다. 하지만 중국 무장, SF 암살자, 아무 의미 없는 이집트 풍 장식으로만 읽힌다면 핵심 단서가 충분하지 않은 것이다.

예술의 논리 설계서 (1)

핵심은, 감동을 직접 디자인하는 것이 아니라, 관객이 감정을 느끼게 될 원인과 과정을 디자인하는 것이다.
슬픔을 표현하려고 단순히 슬픈 표정을 만드는 것이 아니라, 무엇을 읽었고, 어떤 흔적이 남아 있으며, 그것을 관객이 어떤 순서로 발견하게 할지를 설계하는 것이다. 예술의 로직은 바로 그 발견의 구조이다.

“사람 이외의 존재가 예술을 할 수 있는가”의 대한 고찰

“사람 말고도 예술을 할 수 있는가”란 질문에 GPT는 이렇게 답했다.

이 전제는 조건부로 가능하다고 볼 수 있다.
예술의 정의를 “인간이 경험한 감정·생각·감각을 다른 사람이 경험할 수 있는 형태로 바꾸는 행위.”
인간의 주체로 내렸다면, 한 편으로 ‘인간’의 중심에서 관점을 확장하면
”예술은 어떤 주체가 자신의 경험·의도·관점을 감각적인 형태로 조직하고, 그것을 다른 주체가 경험하게 만드는 행위이다.”으로 정의할 수 있다. 그러면 인간이 아닌 존재도 다음 조건을 어느 정도 충족할 경우 예술을 할 수 있다.

1. 선택

여러 가능성 가운데 특정한 형태를 골라야 한다.
색, 소리, 배열, 움직임 등을 우연이 아니라 어느 정도 선택해야 한다.

2. 의도

그 행동이 생존에 필요한 자동 반응만이 아니라, 무언가를 보여주거나 표현하거나 경험시키려는 경향을 가져야 한다.

3. 변형

그대로 복사하는 데서 끝나지 않고, 자신이 감각한 것은 새로운 형태로 바꾸어야 한다.

4. 수용자

그 표현을 보거나 듣고 반응하는 다른 존재가 있어야 한다. 반드시 인간일 필요는 없다.

5. 의미 또는 경험

“이 형태가 왜 이렇게 만들어졌는가?”에 대해 그 주체 나름의 이유가 있어야 한다. 따라서 핵심은 종족이 아니라 ‘주체성’이다.

동물도 예술을 할까?

동물은 색을 배열하거나, 소리를 변주하거나, 춤과 유사한 움직임을 보이기도 한다. 이런 행동은 인간이 보기에 매우 예술적으로 느껴질 수 있다. 여기에는 두 가지 해석이 가능하다.

하나는 동물도 아름다움을 선택하고 상대에게 보여주므로 원초적인 예술 행위를 한다.
다른 하나는 그것은 번식이나 영역 표시를 위한 본능적 행동이며, 인간이 거기에 예술이라는 개념을 투사하는 것이다.

문제는 우리가 동물의 내면을 확인 할 수 없다는 사실에 있다. 그래서 동물의 일부 행동을 예술의 초기 형태 또는 예술과 연속선상에 있는 행동이라고 보는 것이 가장 적절하다. 명확히 예술이 아니라고 단정하기도 어렵고, 인간의 예술과 완전히 같다고 말하기도 어려운 것이다.

자연은 예술가일까?

석양, 동굴, 눈송이, 나뭇결은 인간의 작품보다 아름답게 느껴질 수 있다. 하지만 자연현상 자체에는 일반적으로 표현 의도가 없다고 본다. 그래서 자연은 예술적인 경험을 만들어 낼 수 있지만, 반드시 예술을 ‘행하는 주체’인 것은 아닌 것으로 구분할 수 있다. 파도가 만든 바위는 조각처럼 보일 수 있지만, 파도가 관객에게 메세지를 전달하려고 그 형태를 선택했다고 보기 어렵다. 즉, 아름다운 것과 예술은 같지 않다. 그리고 예술적으로 느껴지는 것과 누군가가 예술을 한 것도 같지 않다.

인공지능은 예술을 하는가?

현재로서 세 가지 입장이 가능하다고 볼 수 있다.

AI는 단지 도구라는 입장
인간이 목적을 정하고, 프롬프트를 쓰고, 결과를 선택하고, 의미를 부여하므로 실제 예술가는 인간이라는 견해이다.
인간과 AI가 공동 창작한다는 입장
AI가 인간이 완전히 예상하지 못한 결과를 만들어내고, 창작 과정에 실질적인 영향을 주기 때문에 공동 창작자로 볼 수 있다는 견해이다. 다만 작품의 목적과 의미를 최종적으로 판단하는 역할은 여전히 인간에게 크게 의존한다.
AI도 독립적인 예술가가 될 수 있다는 입장
AI가 스스로 목표를 세우고
{무엇을 표현할지 결정하며,
결과를 스스로 평가하고,
이전 경험을 통해 표현 방식을 변화 시키고,
다른 존재의 반응을 이해하여 다음 작품에 반영한다면}
독립적인 예술 주체로 인정할 수 있다는 논리를 세울 수 있다.

따라서 현재의 AI는 독립 예술가라기 보다 강력한 생성 도구 또는 공동 창작 시스템에 가깝다고 볼 수 있다.
결과물은 예술이 될 수 있지만, 그것이 곧 AI가 인간과 같은 의미에서 예술을 하고 있다는 뜻은 아니다.
중요한 구분은 ‘예술 작품을 생성할 수 있는가?’와 ‘스스로 예술을 하려는 주체인가?’이다.

외계 생명이나 미래의 비인간 지성은?

자신의 경험을 가지고 있고, 그것을 특정한 형태로 표현하며, 다른 존재의 반응을 의식할 수 있다면 충분히 예술을 할 수 있다. 하지만 그 예술은 우리가 이해하지 못할 수도 있다.

예를 들면 인간에게는 아무 의미 없는 빛의 변화나 냄새의 배열, 전자기 신호의 패턴이 그들에게는 음악이나 시처럼 기능할 수 있다. 따라서 예술을 인간의 회화·음악·문학 형식으로만 한정하면 안된다.
인간에게 익숙하지 않은 감각 체계로 만들어졌다고 해서 예술이 아닌 것은 아니다.

결국 예술의 기준은 무엇인가?

(GPT의 정리)

”예술은 인간만이 사용할 수 있는 형식이 아니라, 경험을 가진 주체가 자신의 내면과 관점을 감각적인 구조로 변환하는 능력이다.”
그래서 인간이 아닌 존재도 예술을 할 가능성이 있다고 할 수 있다. 다만 아름다운 결과를 만들었다는 것만으로는 부족하고, 최소한 다음 세 가지가 필요하다고 본다.

‘선택하는 주체’, ‘표현하려는 방향’, ‘그 표현을 경험하는 상대’

따라서 “인간만 예술을 한다.”기보다는, 현재 우리가 확실히 예술을 한다고 확인 할 수 있는 존재가 인간일 뿐이다.

예술에서 주관성과 객관성

주관성의 역할 : 작품의 출발점

✓ 무엇에 끌리는가
✓ 무엇이 두려운가
✓ 무엇을 아름답다고 느끼는가
✓ 어떤 기억과 감정을 표현하고 싶은가
✓ 같은 대상을 어떤 관점에서 바라보는가

한 작품을 대중이 봤을 때, 사람마다 다르게 바라볼 수 있다. 그 중 어떤 관점을 선택하느냐가 작가의 주관성이다. 주관성이 없으면 작품은 정확할 수 있어도, 누구의 시선인지 드러나지 않을 수 있다. 고증 자료를 그대로 재현한 것만으로는 정보 전달이나 복원에 가까울 수 있고, 거기에 작가의 해석과 선택이 들어갈 때 예술적 방향이 생긴다.

즉, 주관성은 작품에 {개성, 관점, 감정, 문제의식, 해석, 독창성}을 준다.

객관석의 역활 : 관찰 가능한 기준과 검증 가능한 결과

✓ 인체 구조가 설득력 있는가
✓ 실루엣이 한눈에 읽히는 가
✓ 재질이 구분되는가
✓ 시선이 의도한 순서로 이동하는가
✓ 역사적 상징을 잘못 사용하지 않았는가
✓ 캐릭터의 역할이 형태에서 드러나는가
✓ 여러 관객이 비슷한 인상을 받는가
✓ 3D 제작과 애니메이션이 가능한 구조인가

이런 것은 개인 취향만으로 끝나는 문제가 아니고, 관찰, 비교, 테스트를 통해 어느 정도 검증할 수 있다.
객관성은 작품에 다음을 준다.

✓ 전달력
✓ 설득력
✓ 완성도
✓ 일관성
✓ 가독성
✓ 기능성
✓ 고증성

좋은 예술은 주관적이지만 자의적이지 않다.
주관적이다는 것은 작가의 관점이 있다는 뜻이고, 자의적이다는 것은 이유 없이 마음대로 정했다는 뜻이다.
좋은 작품은 대체로 **{개인적인 관점 + 설명 가능한 선택 + 관객이 확인할 수 있는 결과}**의 구조를 가진다.

주관성만 강할 때 생기는 문제는

✓ 작가에게만 의미가 보인다.
✓ 설명을 들어야 이해된다.
✓ 감정은 강하지만 형태가 불분명하다
✓ 상징이 서로 충돌한다.
✓ 기술적 완성도가 낮아 의도가 전달되지 않는다.
✓ “내가 이렇게 느꼈으니 작품도 그렇게 보일 것이다.”라고 착각하게 된다.

객관성만 강할 때 생기는 문제는

✓ 정확하지만 개성이 없다.
✓ 기술 시연처럼 보인다.
✓ 레퍼런스를 충실히 복제하는 데 그친다.
✓ 관객에게 감정적 여운이 남지 않는다.
✓ 안전하고 평균적인 선택만 반복한다.
※ 주관성과 객관성은 같은 순간에 같은 비중으로 쓰이지 않는다.

[초반] 주관성이 앞선다.

✓ 무엇을 표현하고 싶은가
✓ 어떤 감정을 남기고 싶은가
✓ 이 소재를 왜 선택했는가
✓ 나만의 관점은 무엇인가
※ 이 단계에서 객관적 기준만 생각하면 아이디어가 평범해지기 쉽다.

[중간] 객관성으로 구조를 만든다.

✓ 자료 조사
✓ 고증 검토
✓ 형태와 상징의 인과관계
✓ 실루엣과 비례
✓ 기능과 제작 가능성
✓ 시선의 우선순위
※ 주관적인 생각을 타인이 이해할 수 있는 형태로 번역하는 단계이다.

[후반] 객관적으로 테스트한다.

✓ 설명 없이 보여주기
✓ 첫인상 조사하기
✓ 읽히지 않는 부분 확인
✓ 형태 간 충돌 점검
✓ 과도한 디테일 제거
✓ 기술적 오류 수정

[마지막] 다시 주관적으로 결정한다.

모든 피드백을 받아들일 필요는 없다. 객관적인 테스트 결과를 본 뒤에도 작가는 결정해야 한다.
✓ 더 명확하게 만들 것인가
✓ 일부러 모호하게 남길 것인가
✓ 대중성을 선택할 것인가
✓ 개인적 표현을 지킬 것인가
※ 피드백은 판단 자료이지 최종 명령이 아니다.

관객의 주관성도 작품의 일부이다.

작가에게 주관성이 있듯 관객에게도 주관성이 있다. 관객은 자신의 경험, 문화, 지식, 취향을 통해 작품을 본다. 그래서 같은 작품도 서로 다르게 해석될 수 있다. 이것은 실패가 아니다. 다만 해석에는 범위가 있다.
대부분의 관객이 전혀 상관엇는 존재로 인식한다면, 핵심 단서가 부족한지 살펴볼 필요가 있다.
좋은 작품은 해석을 완전히 통제하지 않지만, 해석이 움직일 수 있는 방향은 설계한다.

주관성은 작품의 영혼이고, 객관성은 그 영혼이 타인에게 도달하게 하는 구조이다.
주관성만 있으면 개인적인 감정에 머물 수 있고, 객관성만 있으면 정확하지만 무표정한 결과가 될 수 있다.
예술에서 가장 중요한 것은 둘 중 하나를 선택하는 것이 아니라.
개인적인 진실을, 타인이 경험할 수 있는 형태로 만드는 것 이다.

고증의 중요성

고증은 작품의 설득력과 신뢰도를 높여준다. 역사·문화·신화·복식·도구 같은 요소를 제대로 조사하면, 관객은 그 세계를 더 자연스럽게 믿게 된다. 특히 판타지나 재해석 작품에서도 고증은 상상력을 제한하는 게 아니라, 변형의 기준점이 된다.

고증은 그대로 복사하기 위한 규칙이 아니라, 무엇을 유지하고 무엇을 바꿀지 판단하게 해주는 근거이다.

고증이 부족하면 멋있어 보여도 상징이 충돌하거나, 문화적으로 어색하거나, 세계관이 얕아 보일 수 있다.
반대로 고증을 너무 엄격하게 따르면 창작성이 약해질 수 있으니, 사실을 이해한 뒤 의도적으로 변형하는 것이 가장 좋다.

개인의 심리적 특성

개념 핵심 의미 예시

기질	타고난 정서 반응과 활동 성향	예민함, 활발함, 쉽게 긴장함
성격	상황에 반복적으로 나타나는 생각·감정·행동의 경향	외향적, 신중함, 충동적
인성	타인을 대하는 태도와 도적적·사회적 품성	정직함, 배려, 책임감
인격	한 사람을 독립된 인간으로 이루는 전체적 품위·자율성·도덕적 주체성	타인을 존중하고 자기 행동에 책임짐
가치관	무엇이 중요하고 바람직한지에 대한 기준	안정, 자유, 성공, 가족을 중시함
신념	무엇이 사실이거나 옳다고 믿는 생각	“노력하면 성장할 수 있다.”
태도	특정 대상에 대해 비교적 지속적으로 갖는 평가와 반응	경쟁에 긍정적, 권위에 비판적
정체성	자신을 어떤 사람이라고 이해하는 방식	예술가, 개발자, 가족 구성원으로서의 나
자아개념	자신의 능력과 특징에 대한 인식	“나는 창의적이지만 낯을 가린다.”
자존감	자신이 가치 있는 사람이라는 느낌	실패해도 자신의 가치까지 부정하지 않음
동기·욕구	행동하게 만드는 내부의 이유와 에너지	인정받고 싶음, 성장하고 싶음
김정·기분	현재 경험하는 비교적 일시적인 심리 상태	분노, 기쁨, 며칠간의 우울한 기분
능력·지능	무언가를 이해하거나 수행할 수 있는 역량	언어 능력, 공간 지각, 문제 해결력

논리란?

어떤 주장이나 결론이, 앞의 근거와 규칙을 따라 납득 가능하게 이어지는 관계

누군가의 설명을 듣고, “아, 그래서 그런 거였구나”라고 느끼는 것은 설명 속 연결고리가 자신의 기존 지식이나 상식과 맞물렸기 때문에 느낄 수 있다.

이해된다고 모두 논리적인 것은 아니다.

설명이 익숙한 상식과 연결되면 쉽게 이해할 수 있지만, 그 상식 자체가 틀릴 수도 있다.
예를 들어, ‘성공한 사람은 모두 열심히 노력했다. 그러므로 열심히 노력하면 누구나 반드시 성공한다.’는 익숙하고 그럴듯하게 들리지만, 결론은 근거보다 지나치게 강하다. 이런 것은 이해하기 쉬운 설명일 수는 있지만 엄밀한 논리는 아니다.

상식과 다르더라도 논리적일 수 있다.

처음에는 낯설고 직관에 반하더라도, 근거와 과정이 일관되면 논리적일 수 있다. 과학이나 철학의 많은 이론은 처음 들으면 상식과 충돌하지만, 설명을 따라가면 내부 구조를 이해할 수 있다.

구분하기 좋은 방식

✓ 이해 가능성 : 설명을 알아들을 수 있는가
✓ 그럴듯함 : 상식이나 경험과 잘 맞는가
✓ 일관성 : 설명 안에서 서로 모순되지 않는가
✓ 논리성 : 근거에서 결론이 타당하게 이어지는가
✓ 사실성 : 그 근거가 실제로 맞는가

예술에서는 이렇게 작동할 수 있다.
작품을 처음 볼 때는 감각적으로 느낀다. 설명을 들으면 형태·상징·메세지의 관계를 이해한다.
그 설명이 작품에서 실제로 확인되면 설득력이 생긴다.

세상을 움직이는 것과 설명하는 것은 다르다.

공이 떨어지는 이유는 공이 논리적으로 판단했기 때문이 아니라 중력과 물리적 조건 때문이야. 우리는 그 현상을 관찰한 뒤, ‘질량이 있는 물체에는 중력이 작용한다. 따라서 놓인 물체는 아래로 떨어진다.’ 라는 논리적 구조로 설명한다. 즉, 세상은 원인과 조건에 따라 일어나고, 인간은 그것을 논리로 정리한다.

세상에는 논리만으로 예측하기 어려운 요소도 있다.

✓ 자연법칙과 인과관계 : 물리·화학·생물학적 조건
✓ 확률과 우연 : 날씨, 돌연변이, 사고, 복잡한 사회 현상
✓ 감정과 욕구 : 사랑, 분노, 공포, 인정 욕구
✓ 습관과 무의식 : 이유를 명확히 모르면서 반복하는 행동
✓ 사회적 힘 : 권력, 관습, 문화, 경제적 이해관계
✓ 개인의 선택 : 같은 조건에서도 서로 다르게 행동함

사람은 무엇이 논리적으로 옳은지 알아도 감정, 두려움, 욕망 때문에 반대로 행동할 수 있다.
예를 들어 건강을 위해 일찍 자는 것이 합리적이라는 사실을 알아도, 재미있는 영상을 계속 볼 수 있다. 이 행동에도 심리적 원인은 있지만, 그것이 반드시 합리적인 판단은 아니다.

‘논리적’과 ‘원인이 있다’도 다르다.

어떤 사건에 원인이 있다고 해서 그것이 논리적이거나 합리적인 것은 아니다.
’화가 나서 물건을 던졌다.’에서 ‘분노→충동적 행동’이라는 원인은 있다. 그러나 물건을 던지는 것이 올바르거나 합리적이라는 뜻은 아니다. 그래서 네 가지로 구분할 수 있다.

✓ 인과관계 : 왜 그런 일이 발생했는가
✓ 논리적 관계 : 근거에서 결론이 타당하게 이어지는가
✓ 합리성 : 목적에 비추어 행동이 적절한가
✓ 도덕성 : 그 행동이 옳은가

그렇다면 세상은 비논리적인가?

세상이 완전히 비논리적인 것도 아니다. 많은 현상에는 일정한 규칙과 원인이 있고, 우리는 논리를 통해 그것을 상당 부분 이해할 수 있다. 다만 세상 자체가 항상 인간이 납득할 수 있는 목적과 질서에 따라 움직인다고 보장할 수 없다. 우연히 사고나 부당한 결과처럼 이유는 설명할 수 있어도, “왜 이런 일이 반드시 일어나야 했는가”라는 의미는 존재하지 않을 수도 있다. 결국 이렇게 정리 할 수 있다. 세상은 논리로만 움직이지 않는다. 세상은 법칙, 인과, 확률, 감정, 욕망, 우연이 함께 작용하며, 논리는 그 복잡한 관계를 이해하고 판단하기 위해 인간이 사용하는 방법이다. 그래서 인간이 세상에 속지 않고 더 정확하게 이해하기 위한 가장 중요한 도구 중 하나라고 볼 수 있다.

[후기] 나의 두 번째 교과서 시즌2: 곽민수의 다시 만난 고대문명(이집트)

EVANJ — Tue, 16 Jun 2026 16:27:58 +0900

어쩌다 침착맨 영상에서 자주 곽민수 소장님을 볼 수 있었는데, 재밌게 시청하고 관련 영상으로 파도타기되어 최근에 출판하신 책까지 이어지게 되었다. 곽민수 소장님이 출연하신 영상을 많이 봤었고, 강의해주신 이집트 역사와 문화에 대해 소장님 덕분에 많이 알게 되었다. 그런 지식을 갖으며 흥미를 품고 이 책을 읽기 시작했다.

내가 가장 흥미로웠던 부분은 이집트의 신념이 현대인들과 비교했을때 굉장히 유연하다는 것이다. 다른 종교에서는 아주 많은 갈등을 빚는데, 이집트는 그렇지 않다는 것이 신비롭고 경의롭다. 그런데 고대 이집트인들은 외부 세력을 악으로 인식하는 것은 모순으로 느껴져 이야기가 더욱 매력적이다. 그리고 검은땅(케메트)와 붉은 땅(데슈레트)가 나타내는 상징성이 내가 알고 있는 여러 작품들의 소재 원천인 것처럼 보인다. 굉장히 흥미로운 소재이며 상징이다. 그리고 마아트와 이세페트의 개념도 재밌게 읽었다. 현대인들에게는 논리처럼 보이지 않지만 그 시대의 사람들은 논리로 작용되었을 것 같다.

기존에 토막 지식들이 이 책의 설명으로 조합이 되는 듯한 기분이 들었다. 그래서 책에 빨려들어가게 되었고 난생 처음으로 하루만에 200페이지를 읽어버렸다. 원래 집중도 잘 못하고, 책을 오래 못 읽는 사람이었는데, 이렇게 빠르고 많이 읽은 것은 처음이었다. 그리고 무려 2일 4시간 만에 완독을 해냈다. 그만큼 이집트 역사와 문화 그리고 신화를 흥미롭게 풀어주셨고 가독성이 뛰어나 쉽게 이해하며 읽을 수 있었다. 여태까지 미디어를 통해 접해온 사람으로서 소장님의 이집트를 알리려는 힘과 의지가 많이 느껴졌고, 대단하신 분이라는 것을 보았다.

현재 나는 Sobek를 주제로 3D 게임 캐릭터를 만들고 있는데, 이 책을 보게되어서 고증을 파고들고 예술의 논리의 중요성을 느끼게 되어 다행이고 감사했다. 이 책으로 파생된 관심이 이집트 역사와 문화를 탐색하게 만든다. 그래서 소장님의 이집트 강연까지 티케팅으로 이어졌다. 7월 25일에 현대백화점에서 열리는 강연이 무척 기대되고 많은 정보를 얻을 수 있을 것 같다.

내배캠_TIL251113 [Unity 게임 개발 숙련_개인과제_마감일]

EVANJ — Thu, 13 Nov 2025 16:37:27 +0900

⏰ 일정

9:00~16:00 도전 기능 과제 작업
16:00 과제 마감시간
19:00~21:00 개인 자습

학습 요약

강의 수강 1-1

활동 내용

✔️ 슈퍼 점프 아이템 기능 구현

✔️ 최종 작업 및 제출

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

내일 할 일 (To-do)

내배캠_TIL251112 [Unity 게임 개발 숙련_개인과제(5)]

EVANJ — Wed, 12 Nov 2025 15:40:29 +0900

⏰ 일정

9:00~16:00 필수 기능 과제 작업
16:00~18:00 분반별 특강

학습 요약

강의 수강 1-1

활동 내용

✔️ [3D입문] 1-13 / 자원 채취

✔️ [3D입문] 1-14 / 스테미나 사용하기

✔️ [3D입문] 1-15 / AI 네비게이션

✔️ [3D입문] 1-16 / 적 생성과 로직

✔️ [3D입문] 1-17 / 발걸음 소리와 뮤직 존 생성