부트캠프 2주 차, C# 기반의 간단한 텍스트 RPG를 만드는 과제가 주어졌다. 솔직히 말해, 마음먹고 만들면 1시간도 채 걸리지 않을 간단한 프로젝트였다.
하지만 이전 포스팅에서도 여러 번 언급했듯, 나에게는 잘 짜인 구조에 대한 아집과 집착, 그리고 하드코딩에 대한 일종의 트라우마가 있었다. 그래서 이 간단한 프로젝트조차 가볍게 끝내고 싶지 않았다. 마침 개인적으로 진행 중인 비주얼 노벨 프로젝트의 구조를 빌려와 적용해보고 싶은 욕심도 생겼다.
첫 번째 시도: 데이터 기반 설계를 향한 과도한 욕심
처음에는 모든 게임 데이터를 Choice, ChoiceResult, Dialogue, Action으로 나누고, 아래와 같이 노드(Node) 기반으로 설계했다.
[
{
"id": "1",
"text": "",
"options": [
{ "text": "1. 상태 보기", "input": "1" },
{ "text": "2. 인벤토리", "input": "2" }
],
"afterText": "원하시는 행동을 입력해주세요.\n>>",
"nextAction": { "type": "ChoiceResult", "id": "1" }
}
]하지만 하루를 꼬박 투자하고 나서야 깨달았다. 이렇게 깊은 계층 구조를 가진 JSON Raw Data를 수동으로 파싱하고 DTO와 매칭시키는 것은 거의 불가능에 가까운 작업이었다. 또한, 모든 데이터 타입을 아우르는 Action을 다른 데이터들과 동일한 계층에 둔 것도 설계상의 실수였다. 결국 6~7시간을 붙잡고 있던 첫 번째 프로젝트(TextRpg1)를 과감히 삭제했다.
방황과 타협: SQLite에서 다시 JSON으로
두 번째 시도(TextRpg2)에서는 차라리 SQLite를 써보자는 생각이 들었다. 그렇게 기본적인 디렉터리 구조까지 만들었지만, 또 다른 고민이 발목을 잡았다.
'이 작은 프로젝트에 데이터베이스를 도입하는 것이 과연 하드코딩보다 나은 선택일까? 오히려 리소스 낭비라는 측면에서 더 나쁜 설계 아닌가?'
결국 이 고민에 몇 시간을 더 허비하며 프로젝트를 진행하지 못했다.
결국 나는 다시 JSON 기반으로 돌아가기로 결정하고 세 번째 프로젝트(TextRpg3)를 생성했다. 다만, 처음의 복잡한 노드 기반 설계는 버리고, GameManager에서 switch 문으로 입력을 받아 각 메서드를 호출하는 방식으로 현실과 타협했다. 골치 아팠던 JSON 직렬화/역직렬화는 Gemini의 도움을 받아 해결했다.
그렇게 아침 7시부터 시작한 작업은 검토 시간까지 포함해 약 1시간 30분 만에 끝났다.
튜터님의 질문: "대체 왜 하드코딩을 피하려고 하죠?"
사실 전날 내내 진도를 나가지 못하는 나를 보며 튜터님은 의아해하셨다. 프로그래밍 경험이 전무한 다른 동기들보다도 진행이 느렸으니 어찌 보면 당연한 일이었다.
그렇게 하루 만에 step2에서 step7까지의 분량을 모두 끝내고 검사를 받으러 가서, 세 번의 프로젝트를 거쳐온 히스토리를 간단히 설명해 드렸다. 그러자 튜터님께서 물으셨다.
"그런데 대체 왜 하드코딩을 안 하고 DDD(Domain Driven Design)를 하려고 해요?"
그것은 나 스스로도 끊임없이 던지던 질문이었다. 좋은 설계란 본질적으로 '확장성'을 위해 존재한다. 하지만 이 과제는 기능과 결과가 완벽히 고정된, 즉 확장성을 전혀 고려할 필요가 없는 프로젝트였다.
튜터님과 잠시 개발 철학과 기술에 대한 이야기를 나누었다. 현업 시절 겪었던 하드코딩에 대한 트라우마, 그리고 개인 프로젝트에 적용하고 있는 현대적인 아키텍처에 대한 내 생각을 말씀드렸다.
그에 대한 튜터님의 생각은 내 철학과 정면으로 충돌했다. 튜터님께서는 게임 개발은 소스 코드와 오브젝트의 결합을 완전히 분리하기 어려워 DI(의존성 주입)가 적합하지 않을 수 있으며, 오히려 싱글톤이나 옵저버 패턴이 더 직관적일 수 있다는 의견을 주셨다. 또한 클라이언트 환경은 대부분 메인 스레드 위주로 동작하므로, 비동기 처리를 위해 UniTask 같은 외부 라이브러리보다 유니티의 내장 기능인 코루틴으로도 충분히 대응 가능하다는 관점이셨다. 심지어 내가 중요하게 생각하던 느슨한 결합(Loose Coupling)조차, 때로는 코드의 흐름을 파악하기 어렵게 만들어 협업 시 리소스를 낭비시킬 수 있다는 시각이었다. 특히 DI에 대한 관점은 확 와닿는 부분이 있었다. 튜터님의 말마따나 게임개발에서 스크립트와 오브젝트를 완벽히 분리할 수는 없다. 그래서 내 DI를 도입한 내 개인 프로젝트에는 오직 오브젝트와 Manager를 중개하기 위한 클래스들이 수없이 많다. 이만큼의 역할분리가 과연 도메인 중점의 설계를 중요시하는 나에게 정말 합리적인것인가, SRP에 지나치게 몰입해서 의미없는 코드와 클래스를 양산하고 있는것은 아닌가 하는 생각이 내 스스로 들었던 적이 꽤 있었기때문이다.
결론적으로, 완벽한 구조보다 '개발 리소스 최적화'가 훨씬 중요할 수 있다는 이야기였다. 어찌 보면 당연한 말이었다. 아무리 잘 쓴 코드와 현대적인 아키텍처도 게임을 더 재밌게 만들어주지는 않는다. 게임 개발의 핵심은 '재미'이며, 그 재미의 프로토타입을 빠르게 확인하고 개선해나가는 개발 환경 조성이 무엇보다 중요하다. 요약하자면, 개발의 주체는 코드가 아닌 '사람'이며, 상황과 목적(TPO)에 맞는 개발 방식이 필요하다는 뜻이었다.
과거 복지 쇼핑몰 개발자로 일하던 시절이 떠올랐다.
"이거 고객사랑 협의된 거라... 내일모레까지 이 페이지랑 기능 개발해 주시고, 디자인은 이렇게 변경해주세요."
운영팀의 '협의'라는 이름의 '통보'가 떨어지면, 급한 커스텀 작업을 위해 하드코딩은 선택이 아닌 필수였다. 처음 인수인계받았던 프로젝트의 JSP 파일들은 하드코딩으로 뒤덮여 2,000~3,000줄을 가볍게 넘겼고, 그 코드에 또 다른 하드코딩을 추가하며 느꼈던 패배감은 아직도 생생하다.
사실 그런 일도 있었다.
내가 원래 있던 쇼핑몰의 전시데이터는 전시구좌 -> 중간테이블 -> 레디스 -> 노출
이런 구조로 이루어져있는데 중간테이블의 업데이트는 10년된 프로시져로 진행됬다.
물론 데이터양자체가 많은것도 있었지만 고작 배너 이미지, 상품 이미지 하나 변경하는데 30분, 2시간, 8시간씩 걸리는 엄청나게 비효율적인 구조였다.
그래서 전임자는 긴급한 데이터 변경요청이 오면 프로시져를 돌린뒤 30분 걸립니다. 1시간 걸립니다. 오늘은안됩니다.
식으로 처리를 했는데 나는 그게 너무 답답해서 내가 직접 프로시져와 중간테이블, 상품데이터의 구조를 확인한뒤 중간테이블을 직접적으로 CRUD로 만졌던 것이다. 결국 인간 API가 되어버린것이었다. 그게 힘들어서 팀장님한테 API 기능화해서 운영팀한테 제공하자고 건의했었지만... 반려당했다. 그리고 퇴사 3일뒤... 후임자가 중간테이블 프로시져를 돌리다가 사이트 전시데이터가 전부 망가져버렸다고 연락이 왔다. 어떻게 해결은 했다고 들었는데... 그 후로 중간테이블은 팀장급만 만지는걸로 변경이 되었다고한다... 어찌보면 이런게 내 트라우마의 원인이 아니었을까... 물론 근본적인 해결책은 프로시져및 데이터구조 업데이트였겠지만 단순한 API건의도 반려당했는데 그게 통과 되었을리가 없다
물론 개발에 정답은 없다. 튜터님의 생각을 무조건적인 정답으로 신봉할 생각도 없다. 하지만 아키텍처와 구조에 대한 집착에 갇혀, 1~2시간이면 끝낼 프로젝트를 10시간 넘게 붙잡고 있었던 것은 명백한 '오답'이었다.
이번 프로젝트는 나의 옹졸했던 개발 철학의 시야를 확실하게 넓혀주었다. 이 자리를 빌려 깊은 깨달음을 주신 튜터님께 다시 한번 감사의 말씀을 전하고 싶다.
사실 이건 튜터님께 드리진 않은 말씀이지만
튜터님께서 대화중 그런 말씀을 하셨었다.
'개발 잘하는 사람들 보면 일단 하드코딩이든 싱글톤이든 써서 버그없이 엄청나게 빠르게 만든다.'
그건 내가 웹개발자로 일할때 제일 잘했던거다.......... ㅋㅋㅋㅋㅋ
팀장님이 개발공수 4주 찍은거 일주일만에 끝내고 2주찍은거 3일만에 끝내고 그런일이 허다했다.
물론 그게 결과적으로 오 얘 일잘하네 더 시켜 막 요구해 더 더 시켜! 이것도 시켜!!! 이것도해줘!!!!!!!
하면서 내게 재앙으로 돌아온다건 나중에 깨달았지만...
물론 게임개발에서도 그런식의 내 개발이 통할지는 모르겠지만...
그래서 그얘기를 듣고 아 내가 조금만 타협하면 난 게임현장가도 잘하겠네라는 생각이 들어서... 조금 패배감이 느껴졌다.
쉽지않구만...
