Creative Developer

[Vincent]

크리에이티브 프로그래머 독후감

연구자들은 창의성과 사망률 사이의 병적인 연관성으로 인해 공포 관리 이론(terror management theory)이라고 하는, 듣기만 해도 무서운 이론을 깊이 연구하려는 동기를 갖게 되었습니다.

크리에이티브 프로그래머에서는 제한적인 환경에 있을 때 창의적인 방법으로 주어진 문제를 풀어나간다고 한다.

주로 과거의 게임들을 예제로 많이 드는데, 과거의 게임들은 게임팩이나 RAM의 용량이 무척 적었기 때문에 지금처럼 CQRS니, Auto Scale이니 그런 메모리가 풍부한 환경에서 서비스의 품질과 유지보수에 신경을 쓰는 게 아니라 정말로, 메모리를 극한까지 사용하는 환경에서 괜찮은 품질의 제품을 생산해야 했는데, 그래서 과거의 게임 명작들을 소개하고 있다.

제한된 용량 속에서 플레이어가 게임이 느리고 방해된다, 게임 연출이 단순하다 라는 소리를 듣지 않기 위해 메모리 최적화를 하면서 멋진 연출을 해야했던 ‘당연한’ 노력들이 있었고, 그래서 지금 시대에 컴퓨터 사양이 올라간 만큼 AAA게임만 만드는 것이 아니라 픽셀 아트 라는 분야가 만들어 질 수 있었다고 한다.

원숭이 섬의 비밀 - 나무위키 (namu.wiki) 을 개발한 개발팀의 사례를 소개하기도 하고, PICO-8 Fantasy Console (lexaloffle.com) 같은 lua 기반 가상 컴퓨터를 소개하기도 한다.

이 PICO-8은 초초초경량 가상 컴퓨터로서, 브라우저에서까지 실행가능한 게임을 만들 수 있다고 한다. 기본적으로 유료이고, 영어 레퍼런스가 풍부하다고 한다.

---

그렇다면 .NET 개발자로서 창의적인 방법은 무엇인가.

창의적인 방법이란 에디슨 같은 천재를 일컫는 것이 아니라 사회적으로 인정받았을 때 창의적인 활동으로 인정받는다고 한다.

IT 소프트웨어 세상에서 흔한 방법론 중 하나이지만, 내가 속한 집단에서는 최초의 도입이었고 wow point 라고 생각될 수 있던 방법이라면, 그 집단에서는 내가 창의적인 프로그래머가 될 수 있다는 것이다.

나는 WPF의 MVVM 패턴 역시 이런 것이라고 생각이 들었다.

WPF를 개발하면서 MVVM에 대한 자료를 누구나 접하고, MS에서 권장하는 방식이며, 그걸 했을 때 좋다는 사실은 누구나 알지만 쉽게 적용하지 못한다.

하지만 이 책을 보면서 MVVM 이라는 것이 제한 적인 환경이라고 가정을 한다면, 이 제약은 우리에게 집단에서의 창의적인 방법과 성장을 가져다 줄 것이고 여기가 회사라면, 커리어로 인정받을 수 있을 것이다.

나는 초보들에게 MVVM을 훈련하는 단계에서는 Zero Code Behind 를 권장하라고 한다. MVVM을 수행해서 도달하고자 하는 궁극적인 목표는 이미 나와있다.

바로 유지보수의 효율화를 위해서다.

MVVM은 유지보수를 빼면 시체라고 할 수 있다. 그런데 그 유지보수 기법이 OOP의 확장 개념이라고 할 정도로 많이 닮아있고, 캡슐화로서 그것을 표현하게 된다.

Code Behind에서 Event를 사용하지 않기 위한 기법으로 Converter, Behavior, Attached Property 같은 개념들이 그러할 것이다.

또한 MVVM을 하면서 함께 하면 좋은 개념들은 IoC Container, View Locator, ViewModel Factory Method, Service 같은 개념들일텐데, 사실 Windows Application만 개발해오고 Web 개발을 전혀 해보지 않은 개발자라면 이 개념들을 이해하기 어렵고 왜 필요한지도 알 수 없다.

나도 Web개발은 안해봤으나, Web Service를 구성하는 Container들을 개발하면서 Web의 방법론들을 많이 따랐기 때문에 이해했다.

Windows Application은 내 PC에서 동작하기 때문에 HDD, SSD, CPU, RAM이 모두 나의 것이다.

하지만 Web Application은 Server라는 제한적인 환경에서 다수의 유저가 활동하는 것을 고려해야하기 때문에 데스크톱 응용프로그램에 비해 제한적인 환경이었고, 그 때문에 문제해결 방법인, Container Orchestration 같은 Scaling 기법들이 등장했을 것이다.

무중단 배포라고 불리는 Zero-downtime Deployment 역시 같은 맥락에서 제한된 환경에서 User Experience를 나쁘지 않게 하기 위해서 나온 기법들일 것이다.

Go 같은 언어에서도 Green Thread 개념으로 CPU Core가 제한한 환경에서도 Multi Threading(Go-Routine)을 효과적으로 가능케하는 기법도 그래서 등장했을 것이다. 일부러 람다식같은 요즘은 일반적인 개념들을 빼고 적은 키워드로 개발에만 집중한다는 컨셉이 극도로 가볍고 효율화 된 언어를 만든 것 같다. (나의 Go에 대한 지나친 환상일수도…실제로는 Gohper들도 그렇게 생각할지는 모르겠다.)

다시 본론으로 돌아와서 WPF를 Zero Code Behind로 개발해본다는 제한적인 환경은 훈련하는 사람에게 창의적인 방법을 가져와 줄 것이고, 사실 그 창의적인 방법은 이미 개발업계에서 일반적인 해결 방법일 것이다.

일반적인 이론을 받아들인 개발자는 매우 중요하다 사용하는 언어가 일반적으로 IT 소프트웨어 업계에서 통용되는 단어들일 것이다. 마치 도메인 주도 설계의 Ubiquitous Language 처럼.

그런 일반적인 단어들이 쌓이고 쌓여서 Knowledge-base가 될 것이고 특정 분야에 창의적인 개발자가 되려면 콩심은데 콩나고 팥심은데 팥나듯, 그런 기반 지식들이 많아야 창의적인 아이디어가 샘 솟을 것이고 더 높은 레벨로 도약할 수 있을 것이다.

아직 반 밖에 못봤지만 이전에 본 것과 이후에 볼 것들도 Slog로 저장해야겠다.

[jamesnet214]

@Vincent 좋은 글 작성해주셔서 감사합니다. 잘 읽었습니다!