바닐라코딩 부트캠프 16주차 후기 - "개인 프로젝트 시작"

안녕하세요,

저는 고시원 방 한 칸에 살며, 한창 개인 프로젝트를 진행하고 있습니다.

개인 프로젝트를 하면서 "열심히 하고 있다"는 말에 선뜻 대답할 수 없겠다는 생각이 들었습니다.
'열심히'라는 말이 참 추상적이고도 상대적인 단어더라고요.
한 달 전의 나와 비교하면 분명 지금 더 열심히 살고 있다고 말할 수 있을 것 같은데,
또 다른 누군가의 "열심히"와 나를 나란히 놓고 보면,
‘과연 내가 정말 노력하고 있는 게 맞나?’ 라는 의심도 아닌 확신이 들었습니다.

그래서 상대적인 ‘열심히’를 '절대적인 ‘노력’으로 바꾸고자, 스스로 마음을 다잡게 된 것 같아요.

며칠간 절대적인 노력이란 뭘까 고민했는데,
그 절대라는 공간 안에는 결국 나 혼자뿐이더라고요.

비교할 사람도 나,
평가할 사람도 나,
열심히 하려는 사람도 나.

이 절대라는 공간 안에서는, 남과 나를 비교하는 것이 아니라 어제의 나와, 방금 전의 나와 비교하게 되고,
평가도 남이 해주는 게 아니라 "정말 열심히 했다고 내가 나에게 말할 수 있을까?"를 스스로 묻게 되는 구조인 것 같습니다.

‘열심히’라는 기준조차도 온전히 "나"라는 걸, 그걸 조금씩 깨닫게 되면서
"나 스스로 부끄럽지 않게 살자"는 다짐을 하게 되었습니다.

어제의 나를 부끄러워하지 않도록,
불과 몇 분 전의 나조차 부끄럽지 않도록.

 

"개인 프로젝트를 진행하면서..."

제 프로젝트 아이디어는 게임 보이 에뮬레이터, 게임 파일 실행기입니다.

아이디어 선정하는데 이번에도 어김없이 거름같은 아이디어를 내고 컷 당했지만 결국 이 아이디어가 다행히 생존했어요.
(너무 좋은 아이디어여서 생존한 것보다는, 거름 같은 아이디어들 사이에서 그나마 ‘그냥 아이디어’ 정도여서 살아남은 게 아닐까 싶어요…)

아이디어를 선정하고 나서 POC를 진행하는데, 아니 글쎄 게임 파일을 실행시켜주는 멋진 오픈소스 라이브러리가 이미 있지 않겠습니까...
정말 간단하게 API만 호출하면 게임이 실행되고, 세이브도 되고, 심지어 키 매핑까지 다 되어 있는 거예요.

근데 이걸 그냥 가져다 쓰는 건 개인 프로젝트에서 내가 얻을 수 있는 게 너무 적을 것 같았어요.
그래서 '이왕 하는 거 메모리부터 CPU까지 내가 직접 구현해보자!' 라는… 지금 생각하면 근자감 그 자체인 마음으로 패기롭게 시작하게 됐습니다.

그 패기도 잠시...
게임기기 중 게임보이가 가장 구조가 단순한 하드웨어 중 하나인데도, 구현이 어려웠어요.

우선 CPU 명령어 세트를 구현하는데, 8비트 연산 하나하나가 전부 수작업이고, 플래그 레지스터 하나 잘못 처리하면 게임이 아예 안 돌아가고... (테트리스로 테스트 파일 돌리면서 20개쯤 하다가 안되겠어서 결국 256개 다 긁어온...)
가산기 구현하면서 진수 연산에 익숙하지 않다 보니, 0xFF 넘는 순간 carry 처리에서 삽질하고, half-carry는 또 도대체 이걸 왜 체크하는지 감도 안 잡히고..

그래도 버릴 수는 없으니까, Game Boy CPU 명령어 매뉴얼이랑 blargg 테스트 ROM  하루 종일 파면서 
테스트 하나하나 통과시킬 때마다 콘솔에 하나하나 씩 통과 된거 보면서 기뻐하고.... 

메모리 맵은 또 ROM, VRAM, WRAM, I/O, OAM 등등 각 메모리 영역이 어떤 주소에 어떻게 연결돼 있는지… 이걸 처음에 몰랐을 땐 그냥 if (addr < 0x8000) 식으로 대충 분기했는데,
나중에 알고 보니 게임보이는 MMU라는 걸로 은근 복잡하게 메모리를 분기하고 있었더라고요. 
(메모리에서 모든 하드웨어 처리를 하고 있어서 메모리가 복잡할 수 밖에 없는 구조...)
인터럽트 구현할 때는  HALT 버그도 있어서, IME가 꺼져 있는 상태에서 인터럽트가 pending이면 HALT에서 깨어나서 인터럽트가 실행되어야 하는데 계속 pending 상태고... 

결국 정말 레고 조립하듯이, 다른 사람 코드 조각 참고하고 닌텐도 개발 문서, reddit, stackoverflow, 깃허브  뒤지면서 어렵게 어렵게 겨우겨우 맞춰냈습니다. 사실 한번 뒤집어 엎기도 했어요

진짜... "코드로 기계를 만드는 느낌" 이라는 게 이런 거구나 싶었어요.
그리고 그런 과정을 거치면서 컴퓨터가 어떻게 작동하는지, 하드웨어가 소프트웨어와 어떻게 소통하는지를 가장 본질적인 수준에서 체감할 수 있었어요.
아직도 갈 길은 멀지만, 이 경험만큼은  오래 남을 것 같다는 생각이 듭니다.

"사용자 입장에서 개발하기"

켄님께서 중간 점검 끝나고 마무리하시면서 "사용자 입장에서 기능을 추가해야 한다"는 말씀을 해주셨는데,
그 순간 문득 개인 프로젝트를 하면서 내가 놓치고 있던 부분이 뭔지 확 와닿았어요.

그동안 저는 개발자 입장에서 이기적으로 코딩을 하고 있었더라고요.
개발자인 내가 편한 UX, 내가 이해하기 쉬운 UI, 내가 구현하기 쉬운 기능 위주로만 구현을 해왔던 거예요.
근데 켄님은 피드백을 주실 때  개발자 관점에서 말씀해주시기 보다 항상 사용자 입장에서 어떤 흐름이 자연스러운지,
어떤 UI가 불편할지 그런 걸 짚어주시더라고요.

그걸 듣다 보니 자연스럽게 기술적인 챌린지도 따라왔어요.
예전엔 그냥 로직만 동작하면 됐는데, 이제는 "사용자 입장에서는 이게 맞나?"를 계속 고민하게 되니까, 코드도 더 깔끔하게 짜야 하고, 기능도 더 신중하게 설계해야 하더라고요.

그러면서 프로젝트를 단순히 기술 구현 과제로만 보는 게 아니라,
‘사용자 경험을 만드는 일’이라는 관점으로 점점 전환되는 게 느껴졌어요.

그래서 이번 중간 점검은 단순히 코드를 점검받는 시간이 아니라,
개발자로서 내가 어떤 마인드로 프로젝트에 임하고 있었는지 돌아보게 되는 시간이었고,
결국 사용자 입장을 고려한다는 건 개발자 마인드셋을 다듬는 일이기도 하구나, 싶어서 오히려 좋았습니다.

 

그리고 저를 위해 적는 교훈 메세지가 있다면 중간 발표 때 두뇌풀가동하지 않기 입니다. 저번 모의 면접 때도 받았던 피드백인데요, 
중간 점검하면서 머리가 새하얘지면서 제가 자꾸 두뇌풀가동 + 변명  + 모르면서 나불나불... + 허세 + 과장하기 등등...
이것저것 나쁜 습관이란 습관은 다 가지고 있더라구요 면접 자리였다면 정말 최악일 것 같은... 그래도 이렇게 제 스스로를 깨닫고 고칠 수 있는 기회가 있었다는게 다행인 것 같습니다. 하루 빨리 이런 모습을 다 치워버려야겠다는 생각이 드는 하루였습니다. 


마지막으로 저의 화려한 에러 로그를 보여드리며 마무리하도록 하겠습니다!

읽어주셔서 감사합니다.