[Tool] 이클립스에서 설정하고자 하는 폰트가 안보일 때..

코딩 테스트를 위해서 이클립스를 켜고 간단하게나마 내가 보기 좋은 쪽으로 설정을 하려다보니 글씨체가 맘에 안들었다.. 어제도 대충 만져보긴 했지만 귀찮기도 해서 걍 넘어갈까 했는데 아무래도 계속 맘에 걸리고 눈에 걸려서 결국 설정하기로 했다..

우선 꼭 언급해야될 부분이 있는데 이건 아주 기본적인 설정..?? 이라고 하기도 좀 그렇긴한데.. 무튼 개발에 있어서 아주 중요한 부분은 아니다.. 근데 시간이 지나면 계속 까먹어서 이클립스 설치 후에 내가 사용하던 폰트가 왜 없지..?? 이전에는 어떻게 했었지..?? 라는 생각을 자주 해서 정리를 해두려고 함이 주 목적이다..

내가 주로 사용하는 폰트는.. Courier New 이다.. 별다른 이유는 없고, 이 글자체가 한글을 쓰건 영문을 쓰건 눈에 잘 들어오기 때문에 사용하는 폰트다.. 솔직히 다른 좋은게 있어도 그거 찾아서 또 설정하는 것도 귀찮고 말이지.. ㅡㅡ..

기본적으로 설치한 이클립스에서 폰트 설정을 하면 해당 폰트가 없다.. 그럼 어떻게 하느냐..?? 탐색기를 켜서 C 드라이브로 간다.. C 드라이브를 가서 아래 그림처럼 Windows > Fonts 경로를 간다.. 그럼 그곳에서 자신이 원하는 폰트를 찾아보시란.. 이클립스에 노출이 안된 폰트는 뿌옇게 되어 있을 것이다.. 그게 활성화가 안되어 있단 의미로 보면 되는데 마우스 우측 클릭해서 맨 하단에 존재하는 표시를 눌러주면 활성화가 된다.. 짜잔..!!!

그렇게 한 상태에서 이클립스로 가보자.. 이클립스 가면 기본적인 폰트 설정하는 곳은 대부분 알것이라고 생각하고 자세히는 설명안하고 아래 이미지 한방으로 정리한다..

이클립스 상단 메뉴 Windows > Preferences > General > Appearance 를 가서 설정을 하면 된다.. 위 그림에 보면 Courier New 폰트가 보이는가..?? 저렇게 설정하고서 딱!! 보면 소스가 자신이 원하는 것처럼 바뀌어 있을 것이다.. ㅎㅎ..

이게 진짜 단순한건데 이클립스를 허구헌날 깔고 지우고 이러는게 아니다보니 순간 순간 잊는다.. 이제는 잊지 말아야지.. 후훗..

[JAVA] Baekjoon 입/출력 받아보기..

어제 알고스팟을 통해서 코딩 테스트를 간간히 하려고 한다는 글을 올렸다.. 근데 죄송스럽게도 하루만에 결정을 바꿔야 될 듯 하다.. 알고스팟 자체를 머리에서 삭제하지는 않을 것이다.. 다만 이러한 결정을 한 이유는 다름이 아니구 오늘도 시간이 되는 시점에 2차 문제를 시도하였다..

그런데 확인해보니 이건.. 좀 머랄까.. 내가 생각하는 문법에 관련된 조금 심풀한 코딩 테스트가 아니라 너무 깊히 생각해야되고, 기본 코딩 이외에 너무 복합적으로 생각해야 되는 듯 했다.. 그래서 그런 결정을 했다..

그리하여 찾아서 오게 된 곳이 BaekJoon Onlin Judge 다.. 사이트를 둘러보니 기본적인 패턴은 알고스팟과 거의 비슷하다.. 누가 누구의 규칙을 옮겨온것인지는 모르겠으나 무튼 해당 사이트에서 문제를 풀어보면 될 듯 하다.. 오늘은 초심중에 초심인 Hello World! 출력을 해봤다..

포스팅 패턴은 문제와 정답으로 인정된 소스코드와 하단에 정답이라고 명시해준 결과 페이지를 같이 올리려고 한다..

문제
Hello World!를 출력하시오.

1 2 3 4 5 6 7 8

public class Main { public static void main(String[] args) { // TODO Auto-generated method stub System.out.println("Hello World!"); } }//

위와 같다.. 여기서도 역시나 class 명은 Main 으로 해야됨을 잊지 말도록 하자.. 앞으로는 이곳을 통해서 찬찬히 해보도록 하자.. ㅎㅎ..

[Book] 일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

REST의 개념이 HTTP의 원래의 의도와 개념에 적합하고 상당히 합리적이라고 생각하기 때문에 좋아하는 편이지만 REST의 개념은 꽤 어렵고 실제로 적용할 때는 "어디까지를 리소스로 정의"하고 각 상황별 URL을 어떻게 구성하는 것이 옳은지를 결정하는 것은 꽤나 어렵다. 최근에 RESTful하게 URL을 구성하는 부분에 대해서 고민이 많았던 상황에서 지인의 추천으로 이 책을 읽게 되었다. 이 책은 REST API Design Rulebook의 번역서로 100페이지가 약간 넘는 적은 분량이고 번역도 괜찮은 편이기 때문에 빠르게 읽을 수 있다. 번역이 엉망이었던 RESTful 웹 서비스 - 웹 서비스의 진화이 유일한 REST관련 서적이었던 상황에서 가뭄에 단비같은 서적이라고 할 수 있다.

완전히 REST에 대한 기초를 다루는 책은 아니라고 생각한다. 대신 REST가 어떤 것인지 약간은 알고 있고 RESTful하게 URL을 설계하려고 고민을 해보았다면 REST스럽다는게 어떻게 접근해야 하는 것인지 개념을 잡기에 참 좋은 책이라고 생각한다. 그리고 고민해보는 기준이 될 수 있는 내용을 규칙으로 정의해서 정리해 놓았기 때문에 나중에 참고하기도 좋다. 전부는 아니지만 여러가지 고민하던 문제들을 이 책을 보면서 많이 정리되었고 RESTful URL을 고민하는데 많은 기준점을 가질 수 있게 되었다.(그래도 고민되는 문제들은 많이 있지만.)

다만 약간 아쉬운 점은 이 책에서는 REST 설계에 Web Resource Modeling Language인 WRML을 사용하고 있는데 WRML이라는 걸 이 책에서 처음 보기는 했지만 일반적으로 WRML이 그렇게 보편적인지 잘 모르겠다. 제대로 사용해보지 않아서 판단은 어렵지만 WRML이  REST를 너무 장황하게 만드는듯한 생각이 많이 들었다. 뒤로 갈수록 WRML을 활용하는 방법이 많이 나오는데 차라리 이 지면을 REST URL 설계의 실용적인 예제를 언급하는데 썼으면 훨씬 유용하지 않을까 하는 생각이 들었다. 책을 읽고나서도 WRML을 써봐야지 하는 생각은 별로 들지 않은 관계로....

REST가 유행한 뒤에 REST가 많이 오용되고 있다고 생각하는데 내 입장에서는 사람들이 Fancy URL과 RESTful URL을 제대로 구별하지 않고 있기에 Fancy URL만 적용되면 HTTP 요청을 모두 REST라고 부르는 경향이 생겨버렸다. 과거에 사용하던 http://example.com/board.jsp?boardid=1&pageno=2&search=test 같은 보기 흉한 URL보다 좀더 깔끔한 http://example.com/boards/freeboard/123 같은 Fancy URL만 적용되면 그냥 모두 REST라 부르고 있다.apigee에서 제공하는 이북들도 상당히 괜찮다고 알려져 있지만 아무래도 영문이라 읽는데 부담이 되는 가운데 이 책이 번역되어 나온 것은 사람들이 REST를 제대로 이해하는데 많은 도움이 될 것 같다.

[Talk] 사내 프레임워크 만들지 말자..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

해당 글을 구분을 어디에 둬야할지 참 모호했는데.. 아웃사이더 햄도 어쨌거나 본인의 의견을 담은 사담같은 부분이 있기에 [Talk] 에 두기로 했다.. 그리고 이러한 사담성의 성격을 지닌 글을 갖고 오게 된 이유는 내가 생각하지 못했던 부분에 대한 글이기도 하고 한 번쯤은 이러한 고민을 해보고 생각을 해봐도 좋겠다 싶어서이기도 하다..

누군가 그랬지.. 아는만큼 보인다고.. 그 말이 진리인듯 하다.. 본인이 경험해본만큼 그리고 아는만큼 그에 따른 불편함도 편리함도 그리고 파생되는 효과적인 부분도 다 생각하게 되는 듯 하다.. 그럼 이제 본론으로 들어가보도록 하자..

보통 이런 제목은 안쓰는 편이긴 한데 약간 낚시성(?) 제목을 작성했다.(적당한 제목이 생각 안나기도 해서...) 엄청 많은 회사를 다녀본 것은 아니지만 많은 개발 조직 혹은 회사가 자체 프레임워크나 라이브러리를 가지고 있거나 가지려고 하고 있다. 나는 이러한 시도를 그다지 안좋아하는데 그런 얘기를 해보려고 한다. 어떤 선을 딱 긋기는 어렵지만 보통 사내 프레임워크라 불리는 정도로 포커싱을 해서 얘기해보자.

흐름 자체는 자연스럽다
개발자들은 기본적으로 중복작업 혹은 반복 작업을 별로 좋아하지 않는다. 그래서 여건이 허락하는 내에서는 중복된다고 생각되는 모든 것을 공통화 혹은 자동화해서 제거하게 된다. 이러한 과정은 간단한 리팩토링부터 프로세스 자동화까지 포함되고 리팩토링에서 나아가 업무상 공통이 된다고 생각하는 부분은 별도 라이브러리로 추출하게 되고 더 나아가게 되면 프레임워크를 작성해서 서비스쪽을 개발하는 개발자들은 추상화레벨 위에서 로직개발에만 신경쓰도록 하려는 것은 아주 자연스러운 흐름이다. 실제로 이러한 흐름을 통해서 수많은 오픈소스들이 등장한다고 생각한다.

회사내 프레임워크의 문제
앞에서 자연스러운 흐름이라고 얘기했고 "사내 업무에 특화된 똑같은 작업을 회사차원에서 공통 프레임워크로 작성하면 생산성을 높일 수 있다"라는 유혹(?)은 꽤 달콤해 보이지만 실제로 기대대로 되지 않는다고 본다.(오히려 생산성을 낮추는 효과까지) 내가 본 혹은 들은 프레임워크들은 이 자연스러운 흐름과는 달리 많은 문제점을 가지고 있다.

흐름이 반대로 되어 있다
앞에서 자연스럽다고 한 것은 실제 개발을 하면서 반복되는 부분의 불편함을 느끼고 공통화를 추출해내는 것이다. 경험이 많아지면 작성해 보기 전에도 어느정도 미리 공통화할 부분을 뽑아낼 수 있기는 하다. 이러한 흐름은 자연스러운데 개발업무를 수행하면서 어느정도 공통화를 할 수 있더라도 프레임워크 수준으로 제작하려면 많은 공수가 들어간다. 회사가 해당 프로젝트를 허용해 주지 않는한 업무를 수행하면서 프레임워크 수준으로 개발하기는 좀처럼 쉽지 않다.(각 부분에서 실제 개발을 하면서 필요한걸 공통화하고 라이브러리하는 접근이 훨씬 더 좋다고 본다. 그러면서 시간을 할당해서 좀더 나은 형태로 만들고...)

실제 사내 프레임워크의 제작 과정을 본 적은 없지만 일반적으로는 윗분의 의지로 프레임워크를 만들게 되고 이를 위해서 별도의 조직을 만들어서 프레임워크만 만들게 한다. 시작이 모두 이렇게 되는지는 모르지만 결과적으로는 프레임워크를 만드는 별도의 조직이 구성되게 된다. 여기서 문제가 발생한다고 보는데 서비스 혹은 제품을 개발하는 사람과 프레임워크를 개발하는 사람이 분리되고 프레임워크를 개발하는 쪽에서 이런 부분이 필요할꺼라고 추측해서 개발을 하게 되고 당연히 서비스쪽의 니즈를 다 충족시키기는 어렵다. 실제로 개발하면서 공통화되었으면 하는 부분이 바로바로 프레임워크에 전달되고 적용되기는 무척 어렵고(분리된 조직의 비효율성도 한몫한다) 시간이 지날수록 점점 거리가 멀어지는 것 같다.

실제로 별로 좋지 않다
이런 문제를 빼고서도 경험상 보면 실제로 별로고 자체 프레임워크를 사용하는 쪽에서는 금세 오래된 기술을 사용하고 있다고 느끼게 된다. 회사 조직상 우수한 인력만 모으는 것이 쉽지 않은 탓에 프레임워크를 제작하는 개발자들이 그정도 수준이 되는지 의심스러운 경우도 많아 보인다. 많은 경우는 프레임워크를 만들 수 있기 때문에 만든다기 보다는 프레임워크를 만드는게 업무로 떨어졌기 때문에 만드는 경우도 다소 존재하게 된다. 현재 관심가지는 오픈소스들은 수많은 오픈소스 중에서 인정받은 프로젝트들이므로 당연히 커미터들의 실력도 단연 우수한다. 이런 전세계를 기반으로 한 인력 풀(pool)에 비해 한 회사에서 구성한 인력 풀(pool)의 질이 떨어지는 것은 당연하다고 본다.(개개인이 부족하다는 얘기하곤 좀 다르다.)

설사 아주 우수한 인력으로 만들었다고 하더라도 IT에서 기술의 발전과 흐름의 변화는 아주 빠르기 때문에 만들 당시에는 아주 혁신적이고 좋은 구현체라고 할지라도 금세 뒷쳐지게 마련이다. 오픈소스 프레임워크와 사내 프레임워크를 양쪽 다 아는 입장에서는 시간이 지나면서 사내 프레임워크가 추세를 제대로 따라잡지 못한다면 금세 오래되고 좋지 않은 프레임워크로 생각하게 마련이다. 추세를 따라가는게 쉬운 일이 아니지만 회사가 우수인력을 한 조직에 수년간 계속 유지하는게 쉽지 않기도 하고 기존 레거시를 사용하는 서비스들이 많으므로 쉽게 변경하기 어려운 이유도 있다.

강제 적용
최종적인 문제는 여기서 발생한다고 보는데 이렇게 만들어진 프레임워크를 사내 개발표준으로 강제화해 버린다. 강제화의 정도는 조직마다 다르겠지만 사내의 정치적인 부분이 작용해서 오랜기간 고급인력을 들여서 만든 프로젝트를 아무도 안쓴다면 입장(?)이 곤란해 지므로 모두가 사용하도록 권장(이라면서 사실은 강제)하게 된다. 좋은 프레임워크로 선택하게 하는 것이 아닌 강제화라는 방법을 선택하게 되는 것이다.

사내에서 비슷한 용도의 프로젝트를 2-3개씩 만드는 회사는 없다. 그러므로 선택권은 없어지고 억지로 사용하게 되고 이러한 강제화 프로세스가 완성된다면 제품을 아주 좋게 만들어야할 동기는 사라져버린다. 치명적 버그가 없애고 사용자들이 얘기하는 이슈들을 개선하는 정도로 충분하고 새로운 방식으로 프레임워크를 기반부터 바꾸는 시도는 사용하는 개발자들의 비명이 들릴때까지는 좀처럼 시도하기 어렵다.

그럼 대안은?
그러면 어떻게 해야하는가? 누구나 비슷한 생각을 하겠지만 그냥 오픈소스를 써라.

오픈소스 프레임워크
과거에도 좋았지만 근래에는 오픈소스의 성장세가 아주 크다. 리누스 토발즈가 말한대로 "보고 있는 눈이 충분히 많으면 찾지 못할 버그는 없다."라는 말을 오픈소스들이 제대로 증명해 주고 있다고 본다. 자바 엔터프라이즈라면 Spring, 자바스크립트라면 jQuery 등 충분히 검증받은 걸출한 프로젝트들이 많이 존재한다.

"오픈소스는 무조건 좋다"라고 얘기하고 싶은게 아니라 오픈소스는 계속해서 경쟁하게 되고 경쟁에서 앞선 프로젝트만 살아남게 된다.(경쟁이 무조건 좋은 것은 아니지만 오픈소스에서는 좋은 효과가 난다고 본다.) 많은 사람이 오픈소스 프로젝트에 공헌해서 개선을 하고 있고 더 좋은 해결책이 있는 개발자들은 새로운 프로젝트를 만든다. 새로운 시도가 더 좋은 방법이라면 기존 프로젝트의 인기는 점점 줄어들고 역사속으로 사라진다. 이러한 과정이 계속해서 반복되면서 점점 퀄리티는 좋아지게 된다. 그리고 철저히 사용자 중심이다. 어떤 방법이 좋은가는 반드시 정해진 것은 없다. 여기서의 사용자는 개발자들이지만 제품을 만들어서 내놓고 사용자들이 선택하는 방식이다. 일반적으로 사내에서 진행되는 프레임워크보다 훨씬 사용자 중심적인 구조를 가질 수 밖에 없다. 업무에 특화된 것들이 있다면 이런 오픈소스들 위에 라이브러리처럼 레이어를 올려서 사용할 수 있다. 이 레이어를 프레임워크 의존성이 없게 만든다면 업무에 특화된 공통화에 대한 니즈도 충족시키면서 서비스를 개발하는 쪽의 기술을 제약할 필요도 없고 시대에 뒤떨어졌다는 비판의 부담도 가질 필요 없다. 충분히 이렇게 만들 수 있는 시대이다.

물론 오픈소스가 가지는 제약사항도 있다. 우리가 원하는 기능이 없을 수도 있고(이건 바로 앞에서 얘기한 방법으로 해결할 수 있을 것이다.) 우리에게 중요한 어떤 이슈가 오픈소스 프로젝트에서는 다른 이슈에 우선순위가 밀려서 개선되지 않을 수도 있다. 하지만 이러한 문제는 앞에서 프레임워크 개발팀을 구성했듯이 오픈소스 대응팀같은 걸 만들어서 필요한 부분을 직접 개선해서 오픈소스에 공헌할 수 있다. 이렇게 할 수 있다면 자체적으로 개발해서 운영하는 것보다 훨씬 적은 비용으로 더 좋은 프레임워크를 얻을 수 있다. 오픈소스 생태계도 좋아지고 비용도 줄어드는 말그대로 윈윈이다.

더군다나 자체 프레임워크를 만들면 필연적으로 필요한 문서화나 인력충원에 대한 부담도 오픈소스 프레임워크를 사용하면 엄청나게 줄일 수 있다. 만약 스프링이나 jQuery를 쓴다면 사내에서 문서를 만들필요 없이 이미 시장에 많은 문서들이 나오고 수많은 이슈와 해결책에 대한 글이 구글에서 검색만 하면 찾아낼 수 있게 된다. 사내에만 특화된 부분만 따로 문서화하면 그뿐이다. 인력충원도 새로 뽑아서 새로운 프레임워크의 사용방법 가르쳐주고 하는 과정을 반복할 필요없이 해당 프레임워크의 경험자를 그냥 뽑으면 되고 어쩌면 훨씬 더 잘 아는 사람을 뽑을 수 있을지도 모른다.

수레바퀴는 재발명해도 된다
"이미 있는데 뭐하러 또 만들어!"라고 얘기하고 싶은건 아니다. "수레바퀴를 재발명하지 말라."는 프로그래밍의 오래된 격언이지만 사실 이는 어디까지 추상화하고 그 위에서 개발할 것인가의 문제일 뿐 수레바퀴를 게속 개선할 필요는 있다.(수레바퀴 비유는 여전히 유용하지만 좀 과용되는가 감도 있다.)그리고 수레바퀴를 더 좋은 수레바퀴로 만들려면 지금의 수레바퀴를 어떻게 만들었는지 알아야 하므로 수레바퀴를 재발명하는 시도자체를 말리고 싶진 않다.(오히려 권장하고 싶다.) 그러면서 점점 좋은 수레바퀴가 만들어지는 것이다.

오픈소스로 내놓아라
하지만 수레바퀴를 재발명하려면 많은 노력이 필요하고 혼자나 한 조직내에서만 이뤄내기는 쉽지 않다. 기존의 오픈소스들이 만족스럽지 않아서 사내에서 새로운걸 만들고 싶다면 오픈소스화 해서 세상에 공개해라. 수많은 개발자들의 검증을 받을 수 있고 돈을 안들이고도 소스를 수정해 주는 열정적인 개발자를 만날 수 있을지도 모른다. 그리고 당연히 여러 사람이 모이면 더 좋은 해결책을 찾을 수 있고 사내에서만 개발하는 것보다 여러모로 이점을 가질 수 있다. 오픈소스에서 실제 성능과 기능으로 다른 프레임워크와 경쟁하는 식으로 접근한다면 프레임워크의 질을 좋게 유지할 수도 있고 설사 더 좋은 프레임워크가 나오더라도 손해볼 일은 그다지 없다.(그렇다면 더 좋은 해결책이 있는데 좋지 않은 해결책을 사내에 적용하려 했다는 것이므로..)

덧) 이건 사내 프레임워크에 대한 비판글인지... 오픈소스 찬양글인지... 쓰다보니 모호해진 감이...

My Comment..
요 근래에 아웃사이더 햄의 글을 갖고오거나 혹은 나 스스로 무엇인가 포스팅을 함에 있어서 가장 많은 생각을 해본 것 같다.. 그렇다고 해서 지난 시간 동안 아무 생각없이 무조건 퍼오고 무조건 포스팅 했다는 뜻은 아니다..

나 스스로 오픈소스 오픈 프레임워크를 다양하게 많이 써보진 않았다.. 개발 자체에 관심을 갖은것 자체가 오래되지는 않았기에 말이다.. 그런데 해당 글을 읽다보니 과거에 스프링을 써봤던 경험, 전자정부프레임워크를 써본경험, 회사내 프레임워크를 써봤던 경험을 떠올리면서 볼 수 있었다..

글에 대한 내 결론은 나도 동감한다!!! 이다.. 회사에서 자체 프레임워크라고 해서 개발을 하고 SI 사업으로 발주를 해서 버전을 올리고 하지만 결국 보면, 그 버전업이라는 것 자체가 특정 개발자들이 혹은 기존 프레임워크를 개발했던 회사가 버전업을 시키는 것인데.. 그 개발인력이 개발하는 환경과 생각 자체도 결국에는 오픈소스에서 출발한다는 것이다..

그래서 과거 전자정부프레임워크를 봐도 그렇고 S 사 프레임워크도 그렇고 B 사 프레임워크도 보면 결국에는 스트럿츠나 스프링에 기반을 두고 있는 시스템이다.. 차이가 있다면..?? 기껏해야 명칭이 바뀌었다는거..?? 아니면, 쓰는 패턴을 살짝만 당사에 맞도록 변경했다는 정도이다..

그런 경험을 하면서도 본문과 같은 생각은 못해봤는데.. 그냥 쓰기만 급급했지.. -_-;;; 이번 기회에 한 번더 고민을 하고 곰곰히 생각을 해보게 되었다.. 내가봐도 아니.. 내가 겪어본 과거를 생각해봐도 어차피 비슷비슷한 A, A-1, A-2 스러운 것을 쓰는것보다는 많은 사람이 쓰고, 그로인해서 수많은 피드백을 통해서 수정하고 업데이트 되고 새로운 버전이 출시되고 하는 오픈소스에 무게를 두는것이 좋다고 본다..

물론, 아무리 그래봐야.. 저마다 생각이 틀리기에 또한, 유니크함을 갖고 싶은 무리..?? 단체가 많기에 자신들의 것을 지금 이순간에도 만들고 있겠지.. 꼭, 세상 어디에도 없는 본인들만의 것을 창조한 것처럼 말이지.. ㅎㅎㅎㅎ

[Book] 위대한 게임의 탄생..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

위대한 게임의 탄생 - Michael Thornton Wyman 지음 박일 옮김 지&선(지앤선)

게임 개발자는 아니지만(게임도 많이 하진 않지만...) 책의 제목과 내용이 인상깊어서 기억에 남아있던 책이었는데 이제야 읽어보았다. 이 책은 유명한 게임들의 개발과정에 대한 포스트모템[프로젝트가 끝난 후에 좋은 점, 아쉬운 점을 회고하는 것을 의미한다.]을 담은 책이다. 일반적으로 접하기 어려운 실제 프로젝트의 포스트모템이라는 점에서 이 책이 가지는 의미가 크지만 역자인 박일님이 번역을 세세하게 신경쓴 것을 책을 읽는 내내 느낄 수 있었고 원서에는 없는 국내 게임의 포스트모템도 함께 담겨 있어서 그 의미가 훨씬 커진다. 게임 개발자들에게는 특히 도움이 되겠지만 소프트웨어 개발이라는 점에서 다른 개발과 완전히 다른 것은 아니므로 게임개발이 아니더라도 읽어볼만 하다. 그리고 재미도 있다.

해외에는 Game Developer Magazine에서 게임의 포스트모템을 많이 공유한다고 하는데 이 책도 Game Developer Magazine의 형식을 따라 게임의 간단한 소개뒤에 잘된 점과 잘못된 점을 형식에 맞춰서 정리되어 있기에 편하게 읽을 수 있다. 다만 역자 후기에도 나와있지만 국내 게임의 포스트모템은 형식이 좀 제각각인데 인터뷰형식 보다는 각 게임 개발자들이 글을 적은 내용을 바탕으로 정리되었기 때문인 것으로 보인다. 게임을 많이 하지는 않지만 게임에 어느정도 관심은 있고 IT에서 게임이 가지는 위상도 꽤 크기 때문에 약간 다른 개발직종임에도(나는 주로 웹개발) 흥미롭게 읽을 수 있었고 국내와는 어느정도 다른지 모르겠지만 각 장뒤에 직종별 인터뷰가 수록되어 있어서 게임업계쪽에 관심을 가지는 취업준비생들에게도 흥미로울 것 같다.

위대한 게임의 탄생 2도 출간이 되어 있는데 조만간 2권도 읽어봐야겠다.