조나단 블로우에 대한 소개
조나단 블로우는 컴퓨터사이언스 명문 UC 버클리 출신으로
AAA 게임업계에서 잠깐동안 일하다 인디게임업계로 들어온 인물
그가 AAA게임업계에서 참여한 대표적인 작업물로는 <둠>을 포팅한 것 등이 있다
그러다 2008년 시간 되감기를 소재로 한 수채화 풍 그래픽의 퍼즐 플랫포머 <브레이드>를 히트시켜
엑스박스 라이브 아케이드같은 디지털 유통망을 통해 배급되는
인디 게임 시대를 개척한 선봉장 중 한명으로 평가받으며
게임 <브레이드>는 상업적 성공 외에도
게임만이 보여줄 수 있는 독창적인 스토리텔링 기법인 게임 메커닉과 서사의 절묘한 융합과 충격적인 반전으로
엄청난 호평을 받은 바 있음
그 인연으로 인디게임 개발자들의 제작기를 조명하는 다큐멘터리 영화 <인디게임 더 무비>에도 출연한 바 있고
이후 그는 차기작 <더 위트니스>를 발표해 다시한번 상업적/비평적 성공을 거둠,
수많은 아이디어들과 기믹이 상당히 알차게 가득차있는 그 게임의 밀도와
글자 하나 없는 비언어적인 방식으로 플레이어를 학습시켜서
마지막 장소까지 진행시키고 과제를 해결하게 만드는 놀라운 미학은
이후 많은 게임 개발자들에게 영감을 주었음
<더 위트니스>이후 조나단 블로우는 기존에 C++로 게임 제작을 진행해왔던 경험을 복기하면서
그러한 언어는 게임 제작에 특화된 언어가 아니라는 생각을 가지게 되어
직접 C와 같이 저수준으로 메모리를 제어하고 빠른 컴파일 타임을 가지면서도
리플렉션같은 기능을 가지며, 본인이 직접 구상한 방식대로 프로그램이 구조화되도록 하는 이상을 담아
Jai라는 자체 제작 프로그래밍 언어와 컴파일러 및 IDE도 제작한 그는 대담한 엔지니어이기도 함
------------------------------------------------------------
채팅: 코드가 제 기능을 하고 있고 앞으로도 안 바꿀 거면, 그걸 리팩터링하는 건 시간 낭비일까요?
음... 그건 좀 복잡한 문제야.
근데 시스템이 점점 비대해지는 이유 중 하나가,
계속 뭔가를 수정하면서 새로운 제약이 생기기 때문이거든.
그럼 그 안에 있는, 네가 리팩터링 안 한 코드 조각 하나가
불필요하게 많은 제약을 만들고 있을 수도 있고,
아니면 그 코드가 무슨 제약을 갖고 있는지 명확하지 않을 수도 있어.
그러면 그게 전체 코드에 안 좋은 영향을 미치지.
일반적으로 말하자면,
내가 지금 하는 것처럼 데이터 구조 자체를 리팩터링하는 일은
지루하고 귀찮아 보여도, 프로그래밍에서 제일 강력한 무기 중 하나야.
진짜로. 이건 내가 시간이 지나면서 배운 거야.
정적 타입이 강한 언어는
Lua 같은 동적 언어가 못하는 걸 할 수 있게 해줘.
코드를 리팩터링해서 프로그램을 깨뜨려도,
컴파일 에러들을 고치면 프로그램이 다시 작동한다는 걸 확신할 수 있거든.
이건 동적 언어에선 안 돼.
근데 그게 진짜 말도 안 되게 강력한 기법이야.
우리가 지금 하는 건 되게 재미없는 잡일처럼 보이지만,
이걸 이용해서 지금 '가능한 모든 프로그램 공간' 안에서 한 지점에서 다른 지점으로 안전하게 이동하는 거야.
모든 걸 박살내지 않고 말이지.
나도 이걸 제대로 배우는 데 오래 걸렸어.
효율적으로 하려면 정말 어렵거든.
괜히 한 달씩 쏟아붓지 않으려면 말이지.
채팅: 그럼 그렇게 큰 리팩터링 작업을 오래 끌지 않고 해내려면 어떤 팁이 있을까요?
음… 일단 계속 전진하고 있는지 확인해야 해.
그리고… 내가 얼마나 작업을 해내고 있는지 스스로 기준을 높게 잡는 게 중요해.
사실 많은 프로그래머들이 실제론 거의 작업 안 하고 있으면서
자기들은 열심히 일하고 있다고 착각하거든.
나는 지금 단순한 리네이밍 같은 걸 하고 있지만,
그게 정확한 방향성을 가지고 진행되고 있는 거고,
구체적인 마일스톤이 머릿속에 있어.
지금 목표는, 백엔드에서 옛날 데이터 세그먼트를 따로 처리하고 있는 지저분한 코드를 없애는 거야.
하루 끝날 때까지 그 목표를 못 이루면,
나는 실망하고,
‘이게 잘못된 선택이었나?’, ‘되돌려야 하나?’ 하는 생각을 하기 시작해.
그래서 그런 마일스톤이 있으면 그걸 달성했는지 안 했는지 확실히 알 수 있어.
내가 프로그래머로 일하던 초기 시절, 첫 게임 회사에 다닐 때는
이런 오버홀 작업 하나 하는 데 최소 일주일은 걸렸을 거야, 어쩌면 그 이상.
근데 지금은 하루 안에 하고 있어.
이건 꽤 큰 작업이고, 그땐 아마 이틀 이상 걸렸을 수도 있어.
이런 작업은 하면 할수록 더 잘하게 돼.
진짜 멋진 트릭 하나 보여줄까?
프로그래밍 언어 관련된 또 다른 웃긴 트릭이야.
여기 c라는 변수가 있어. 문자열 붙이는 변수고 바깥 스코프에 정의돼 있지.
이걸 relocations 같은 다른 변수로 완전히 바꾸고 싶어
근데 말이지, 정말 전부 다 바꿨는지 확신하려면 어떻게 해야 할까?
c는 짧은 변수명이라 놓치기 쉽고, 지금 여긴 코드량이 엄청 많거든.
물론 검색해서 바꿀 수도 있는데, 사람은 자기 실수를 잘 못 알아채는 경우가 많잖아.
그래서 이렇게 해.
그 코드를 하나의 스코프로 감싸.
그리고 c라는 이름으로 새로운 변수를 하나 정의해.
예를 들어 float 타입으로 로컬 c를 하나 만들면,
그 블록 안의 함수들은 c를 그 타입이라고 생각하니까,
그걸 기존 방식대로 쓰면 전부 타입이 안 맞아서 컴파일 에러가 나.
이제 c가 사용된 모든 부분이 다 드러나지.
그 상태로 전부 수정한 다음에,
마지막에 그 float c 선언을 지우면 돼.
진짜 유용해. 잠깐 후에 보면
(잠시후...)
첫 번째 에러가 965번째 줄에서 나와.
그건 이 블록 안에서는 더 이상 c가 안 쓰인다는 뜻이지.
매크로 안에서 몰래 쓰이는 경우가 있나 걱정했는데,
그런 것도 아니었다는 걸 확인할 수 있었어.
이건 파이썬이나 자바스크립트 같은 언어에선 못 하는 매우 유용한 테크닉임
정적 타입이 강한 언어에서만 가능한 방식이지
그래, 파이썬에서 타입 세이프티가 없다는 건 진짜 큰 문제야.
오늘 내가 한 이런 단순하지만 귀찮은 리팩터링 작업들 있잖아,
이런 거 파이썬에서 하면 훨씬 더 무서울 거야.
왜냐면 "이거 방금 뭔가 망가뜨린 거 아냐?" 하고 불안해지거든.
오늘만 해도 최소 열 번은
"이게 뭐 망가졌는지 아닌지 모르겠네" 같은 상황이 있었을 거야.
근데 C++에선 "아니, 이거 안 망가졌어" 하고 확신할 수 있지.
완전히 다르지. 진짜 달라.
그리고 리팩터링에 대해서 또 다른 얘기가 있는데,
리팩터링이라는 단어 자체가 수학에서 빌려온 개념이야.
근데 내가 오랫동안 이해 못 했던 부분이 하나 있어.
학교 다닐 때 선생님들이 그렇게 나쁘진 않았고, 꽤 괜찮았던 편인데도
그 부분을 명확하게 설명해준 사람은 없었어.
예를 들면, 수학이나 물리 문제 풀 때
방정식을 서로 조합해서 답을 구하잖아.
하나의 식을 변형해서 어떤 변수에 대해 푼 다음에,
그걸 다른 식에 대입하는 식으로.
근데 내가 자주 겪던 문제는
그걸 반복해서 하다 보면 그냥 계속 왔다 갔다만 하게 되고
진전이 없는 경우가 많았다는 거야.
근데 나중에 깨달은 건,
뭐 내가 그냥 멍청해서 몰랐던 걸 수도 있지만..
아니면 선생님들이 진짜 그 개념을 몰랐던 걸 수도 있는데,
그 핵심은 이거야.
각각의 방정식은 하나의 제약 조건이야.
그리고 문제를 풀기 위해선
자유도보다 제약 조건이 더 많아야 한다는 거지.
그리고 방정식을 조합하는 이유는
그 제약 조건들을 줄여가면서
문제를 해결 가능한 상태로 만들기 위한 거야.
그걸 의도적으로 할 때만
진짜로 앞으로 나아가고 있는 거야.
근데 그냥 아무 생각 없이
이거 저거 대입하고 치환하고 막 하다 보면
그냥 끝도 없는 치환의 미로에 빠져서
아무 데도 도달하지 못하게 돼.
나도 초등학교 다닐 때 그런 식으로 자주 헤맸어.
그래서 하고 싶은 말은,
코드 리팩터링도 그거랑 비슷하다는 거야.
목표가 뚜렷하지 않으면
이리저리 구조 바꿔보다가
"이게 좀 나은 것 같네?", "아니 이게 더 낫나?"
하면서 계속 왔다 갔다만 하게 되고,
결국 진짜 진전은 없는 상태가 되는 거지.
--------------------------------------------------------------
중간에 블로우가 썼던 로컬 변수로 컴파일 에러를 일으키는 팁은
그렇게 유용하진 않을수도 있어여ㅋㅋ
이양반 워낙 OOP 언어 + 기성 IDE 회의론자라
막짤 뭔데 ㅋㅋㅋㅋ
돈방석 위에 앉은 인디게임 개발자와 그렇지 못한 인디게임 개발자... 조나단 블로우 최근작이 망했거든ㅋㅋ
일부러 망가뜨리기 권법!
게임 디자인(=기획)이 픽스될수록, 프로그래밍이 더 좋아지는 이유인 듯 모든 기획을 픽스할 필요는 없지만, 픽스될 수록 설계 단계가 좋아지는 것 같아 기획이 정해져 있으면(=제약 조건) 훨씬 편한 경우가 많았음
게임 디자이너(=기획) 입장에서는, 픽스된 부분과 말랑말랑한 부분을 잘 제시해줘야 하는듯 프로그래머 입장에서는, 회의 때 제약 조건 여부를 기획자에게 잘 물어봐야 하고 혼자 1인 개발할 때는 훨씬 유연하게 대처할 수 있지만, 픽스된 부분을 정하고 가지 않으면 본문에서 얘기한 "계속 왔다 갔다 하지만 진전은 없는 상태"에 빠지게 쉬웠던 거 같음
결론은 좋은 글이네
중간에 스코프 따서 변수 리네임하는건 20세기에나 하던거 아니냨ㅋㅋㅋㅋㅋㅋㅋㅋ
이제 여기도 존불 시리즈 올리는거임? ㅋㅋㅋ
어허 여기엔 진짜 멋있는 엔지니어 존 센세만 올릴거에여!
존슨 버스터가 여기까지...
조불호 선생의 확장주의적 행보
리팩토링하는 팁도 번역해서 "올려줘"
지금은 걍 비쥬얼 스튜디오 컨트롤 rr 컨트롤 h로 원턴킬 내는데
왤캐 유익함 제약조건 얘기가 퍼즐게임 생각나네. 인디갤에서 봤던 바바이즈유 연구 글이랑… - dc App