[작성자:] guygigas

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

"저는 새로운 기술을 습득하는 요령은 '왜'라는 의문을 가져보는 것이라고 생각합니다."

나에게 이 한 줄이 무척이나 큰 의미로 다가온다. 허투루 할 수 있는 말이 아니다. 적어도 어느 정도 기술적으로 궤도에 오른 사람이 할 수 있는 말이라 생각한다. 그것도 저자가 “마치며”의 첫 문장으로 쓴 표현이다. 그 다음으로 쓴 말을 보자.

"그 언어나 기능이 왜 필요했는가 하는 것을 생각하면 이용하는 상황이 쉽게 보일 수 있고, 다른 기술에서는 필요했던 것이 이 기술에서는 어떻게 되는지 생각해볼 수도 있습니다."

전산학을 공부하면서, 실무를 하면서, 자연스럽게 느낄 수 있었던 바로 그것이다. 왜 이 기술이 존재하는지, 왜 이렇게 만들 수밖에 없었던 것인지, 왜 이래야만 했는지. 바로 그러한 것들을 집약한 표현한, 단 하나의 글자가 ‘왜’라고 생각한다.

아무리 좋은 기술이라도, 한 시대를 풍미하는 기술이라도, 누가 봐도 쉽게 쓰였다는 기술이라도, 이 ‘왜’라는 질문에 답할 수 없다면, 애석하게 와닿지도 않고, 그 기술을 쓰고 싶은 생각도 들지 않았다. 나의 의문에 답을 줄 수 있는 기술이어야 이해도 되고 사용하기도 비교적 수월했고 또 그걸로 문제를 해결할 수 있었다. 그렇지 않은 기술은 아무리 봐도 이해가 되지 않았고, 사용하더라도 문제 투성이라 결국엔 안 쓰게 되었더랬다.

그런데 저자가 그 의문이 새 기술을 습득하는 요령이라고 친절히 알려준다. 그래서 그랬나? 이 책은 근래 읽었던 책 중에서 가장 빨리 읽혔고, 쉽게 이해가 갔고, 그래서 내게 딱 알맞을 정도의 길라잡이 역할을 해줬다.

근래 회사에서 주로 Spring Boot / Java로 백엔드 개발을 하다가, 여러 가지 이유로 프런트엔드 개발도 병행하고 있다. 거기서 사용하고 있는 기술이 Node.js와 React.js다. 앞서 리액트 경우에는 굉장히 초심자가 읽기 좋은 책을 접할 수 있어서 즐겁게 보며 궁금했던 점들을 해소할 수 있었다. 초심자가 읽기 좋은 책, 그래서 리액트에 초점이 맞춰져 있기 때문에 그 자체만으로는 도움이 많이 되었지만, 그 근간에 있던 Node.js에 대한 건 상대적으로 빈약할 수밖에 없었다.

그런데 이번에는 Node.js다. 이 방대한 걸 전부 백과사전식으로 나열하며 설명하지 않는다. 어떻게? 마치 업무에 처음 적용해보려는 것같은 느낌의 설명이다. 철저히 업무에 활용하기 위한 방식이다. 그렇기 때문에 소소할지도 모르지만 확실히 꿀팁이 많이 들어 있다. 본인이 써봐서 이해하고 있는 팁들을 알려주기 때문에 같은 패키지들을 확인해보고 싶은 욕구가 생긴다. 심지어 도입해 쓸 만한 것도 많으니 이렇게 유용할 수가 있을까?

게다가 확실히 이해하고 쓴다는 생각이 들 정도로 핵심적인 내용들 위주로 설명하고, 예제도 점진적으로 (필요에 의해 반복하면서) 작성해가면서 차이점을 명확히 알 수 있도록 해준다. 장과 장 사이를 넘어갈 때 부담스럽지가 않다. 그러면서도 이해가 쉽게 쏙쏙 짚어가며 알려 준다. 아주 좋은 방식이다. 그래서 평소보다 술술 잘 읽히는 기술 서적 중 하나라 생각한다. 뭔가 특별하고 대단한 기술을 알려주는 것은 절대 아니다. 실무 도입 시 필히 봐둘만한 형식이랄까?

왜 나에게 이 책이 더 크게 와닿았을까? 그것은 현재 내가 하는 업무와 아주 밀접하게 연결돼 있다. 현재 맡고 있는 프런트엔드 프로젝트는 프런트엔드 전문 개발자가 React.js를 처음 공부하면서 개발했다. 꽤 장기 개발을 했기 때문에 초창기 작업한 코드와 근래 작업한 코드가 스타일도 그렇고 수준도 그렇고 차이가 난다. 그래서 여러 가지 형태로 구현돼 있는데, 천천히 업그레이드를 하다보니 코드 방식이 여러 개 섞여 있는 셈이다.

그걸 중간에 받아서 하려다보니 꽤 애를 먹고 있다. Node.js에 익숙치 않다보니 이런 것들이 왜 필요했던 것인지 기초적인 것들을 제대로 알지 못한 상태에서 오로지 논리적으로 이렇게 되지 않을까 하고 건드리면서 해결해나가고 있는 실정이다. 이미 좋은 샘플이 많이 있으니 복붙 후 수정 스타일로 작업하고 있달까? 그런데 이 책을 읽으니 작업하면서 막연하게 느껴졌던 애매함과 몰이해가 어느 정도 해소되었다고 하면 될 것 같다. 다시 말해, 제대로 몰랐던 걸 제대로 알아가기 위한 기초를 알게 되었달까?

CORS 관련해서도 문제가 생겼고, 이를 해결하기 위해서 작업을 했다는 것만 알고 있었지, 이 책에서 설명하는 정도로 이해하진 못했던 것 같다. 그랬으니 이 문제를 해결하기 위해 회사 동료가 했던 업무가 잘 이해되지 않았는데, 이참에 이해하게 됐다. 그리고 당시 담당 개발자가 했던 말들이 이제야 조금 이해할 수 있게 되었다. 개발에 프록시 서버가 왜 필요했는지, 프로덕션일 때 추가로 데브옵스 개발자가 어떤 설정 작업들을 했었던 것인지 이제 이해가 되기 시작했다.

SPA 추세는 이해했지만, 왜 복잡하게 구성하고 진행이 될 수밖에 없었던 것인지. 패키지를 업그레이드 했다가 문제가 생겨서 롤백하거나, 그 문제를 해결하기 위해 해당 패키지 문서에 서술된 업그레이드 시 해야 하는 업무 내용을 읽고 따라 반영해본다든지. <Routes>, <Link> 등을 사용해서 구성해야 했던 이유들. 회사 개발 환경 이전으로 방식을 바꾼 뒤에 웹브라우저에서 페이지를 열어서 확인하다 리로드 시도했을 때 왜 에러가 발생했던 것인지. 그런 실무에 밀접하게 연결된 내용들을 컬럼을 통해 전달해주는 방식도 마음에 들었다. 그것도 적절한 시간에 적절한 공간에서 말이다.

확실히 난해할 수 있는 표현을 이렇게 깔끔하게 정리해서 알려주는 것도 대단하다고 생각한다. 저자의 능력이기도 하겠지만, 리뷰를 해준 동료의 센스에도 감탄하게 된다. 확실히 대단한 가이드가 적용된 듯한 인상을 받았다. 이렇게 깔끔할 수 있는 건가?

책에서 나에게 가장 의미 있는 장을 몇 개 꼽아보라 한다면 과감히 3장, 4장, 6장, 8장, 이렇게 4개 장을 꼽겠다. 이유는 다음과 같다.

3장 – Node.js와 모듈. CommonJS과 ECMAScript 모듈의 활용 관점에서의 설명과 package.json 관련 설명 (아주 도움이 되었다)
4장 – Node.js에서의 비동기 처리. 동기와 비동기, 이와 관련된 콜백, 프로미스, async/await, AsyncIterator 등을 비교 설명
6장 – 익스프레스를 이용한 Rest Api 서버 웹 서버. 점진적으로 개선해나가는 익스프레스 기반 Rest Api 서버 및 웹 서버의 비교 설명
8장 – 애플리케이션 운용과 개선. 지금 내가 하고 있는 최고 난이도 업무들과 연관

나머지 장들도 확실히 도움이 많이 되었지만, 위 4개의 장들의 설명들은 내게 있어 뿌옇기만 했던 점들이 점점 더 실체를 갖고 나에게 제대로 보이기 시작한 지점들이라 생각한다. 이 내용들을 바탕으로 더 많이 파보면 멀지 않은 미래에 확실히 이해할 수 있게 되지 않을까 행복회로를 돌려본다.

반대로 이 책의 장들 중 공부할 때 고비로 다가온 것들은 무엇일까? 7장과 아이러니 하게도 바로 8장이다. 여기가 가장 고비였다. 이유는 7장의 경우 거의 써보지 않은 패키지나 기술들이 많았고, 테스트 부분이 약한데, 이 부분을 건드리다보니 머릿속이 복잡해져서, 사실 돌려보지 않으면 감이 잘 안 오는 부분들이라 그랬다. 당장 현업을 해야 하다보니 샘플격으로 만들어 돌려볼 시간이 잘 안 나다보니 글로만 이해하려고 해서 좀 그랬나보다. 8장은 성능 튜닝이 흥미로우면서도 많이 겪어보지 못한 상황이다보니 이해가 더뎌서 그랬던 것 같다.

그럼 책에 문제가 있는 거 아닌가, 하고 오해를 할 수도 있겠다. 그런데 그건 진실이 아니다. 내게 어려웠다는 건 내가 그 부분이 굉장히 약하다는 얘기가 되고, 이건 내가 학습을 더 진행해야 하는 부분임을 알게 해준 거라 읽을 당시엔 힘들었어도 진행할 방향을 알게 되어 무척 다행이라 생각한다. 솔직히 전부다 쉽게 이해가 되는 책이라면, 굳이 구해 읽을 필요가 없다. 시간과 돈 낭비다. 약한 부분을 보완해줄 수 있는 책을 찾는 게 훨씬 효과적일 테니까.

마지막으로, 저자가 한 말 중 이 책을 정리발언하는 내용이 있어 인용해보고자 한다.

"이 책에는 '왜'를 알기 위해 간단한 기술의 설명뿐만 아니라, 제가 본 역사와 얻었던 경험, 생각들을 가능한 많이 담았습니다."

그래서, 이 책은 가치가 있다, 바로 저자의 저 한 마디 문장 때문에 말이다.

“한빛미디어 < 나는리뷰어다 > 활동을 위해서 책을 제공받아 작성된 서평입니다.”

회사를 다니는데 하나의 프로젝트를 혼자서 계속 하는 경우는 드물지도 모른다. 보통은 하나의 프로젝트를 여럿이서 나눠 하면서 각자 맡은 부분을 작성하고 있을 거다. 당연히 GIT 같은 형상관리툴도 쓰고, GitHub 같은 걸 통해 코드리뷰도 진행할 것이다. 페어 프로그래밍을 하는 경우도 있을 것이고… 심지어 ChatGPT를 통해 작성된 코드를 참고해서, 아니면 수정해서 사용하는 경우도 있을 것이다.

그렇게 작업을 하다보면, 나의 코드와 남의 코드 사이에 발생하는 괴리감을 느낀다. 명시적인 코딩 컨벤션이 있다면 그 정도는 덜할 텐데, 암시적인 코딩 컨벤션이 존재하고, 그걸 철저히 준수하지 않아서, 이전 코드와 지금 코드 간의 괴리감도 많이 느낄 것이다. 또한 리뷰어의 성향에 따라 철저하게 코딩 컨벤션을 준수하라고 할 수도, 자신의 스타일을 은근슬쩍 강요할 수도, 이도 저도 아니고 알아서 하라고 할 수도 있을 거다.

누군가가 초기에 세팅해둔 툴 덕분에 코드 컨벤션 일부는 강요되므로 준수해나가는 경우도 있을 것이고, 남이야 어떻든 내 코드는 내 스타일대로, 남의 스타일은 맘에 안 들어서, 무시하고 계속 작성해 나갈 수도 있을 것이다. 남의 코드 수준이 자신보다 떨어지는 것 같아, 내 식대로 다 바꿔버리는 경우도 있다. 그러다가 다른 걸 작업하게 되어 작업하던 프로젝트를 다른 사람이 맡아서 또 바꾸고 하다보니, 어느 순간인가 코드 베이스에 여러 스타일이 넘쳐나서 당최 뭐가 어떻게 돌아가는지 알 수가 없는 경우도 생긴다.

이를 테면, 응답값에서 snake case를 쓰고 있었는데 난데없이 camel case를 쓰는 경우도 있었다. 덕분에 호출하는 쪽에서 일괄적으로 응답값을 관리할 수 없어 경우에 맞게 작성하느라 애를 먹기도 하는데, 또 이걸 이어 받아 작업하던 개발자가 이 사정을 제대로 파악하지 못해 수정했다가 버그가 발생하기도 했다.

여러 사람들과 협업하는 것은, 소통 문제도 문제지만, 결국 결과물이 나오는 것도 문제가 많아질 수밖에 없다. 이걸 해결하기 위한 게 표준이다.

가령 우리가 늘상 사용하는 화장실에서 수도꼭지가 표준을 따르지 않는다고 한다면 어떤 일이 생길까? 뭐 기본적인 사용을 할 때는 문제가 되는 줄도 모를 테지만, 어딘가 고장이 나서 고쳐야 하는 상황이 발생하면 문제가 복잡해진다. 맞는 부품을 구하는 것도, 교체하는 방법도, 표준에 벗어나기 때문에 훨씬 더 많은 비용을 지불해야만 한다.

프로그래밍도 마찬가지였다. 정말 상식적이라고 생각하는 부분은 표준을 따를지도 모르겠지만, 실제 작업하는 영역에 들어오면 이 표준이 있냐 없냐에 따라 결과물이 확연히 달라진다.

20년이 넘는 개발을 해오면서 저자가 말하는 실수를 사실 지금도 하고 있다. 안타까운 것은, 어쩌다보니 십수 년째 한 프로젝트를 혼자하는 경우가 너무 많았다는 거다. 그러다보니 이러한 점을 지키는 게 의외로 암묵적으로 진행하고 있었다. 그래서 팀원이 가끔 생길 때마다 이걸 조율하는 게 쉽지가 않았다. 사실 누구나 자신만의 스타일을 갖고 있다보니 자기가 편한대로 개발하고 싶어 했다. 그런 이유로 어느 순간 굉장히 기본적이 굉장히 명확한 부분은 어느 정도 서로 인정하는 표준을 따르게 되는데, 그게 보통은 해당 언어가 보편적으로 따르게 다소 강제하는 부분이라거나, 사용하는 lint 툴의 가이드라인대로 진행하는 거다. 이건 언어 측면의 표준 정도일 뿐이고.

좀더 고차원으로 올라가면, 경험칙만 있다. 몇 년 동안 나보다 고수 개발자들한테 귀동냥으로, 때로는 코드 리뷰를 받으며 깨지고, 또는 작업했던 코드가 버그를 유발해서 그에 대한 반성으로 등 다양한 방면에서 얻은 그 경험칙들이다. 이걸 문자로 남기는 건 제대로 하지 못했는데, 이 책에서 상당히 많이 볼 수 있었다. 아쉬운 점이라면 저자가 비디오 게임 개발자여서, 게다가 C++ 개발자여서, 알려주는 점과 예제 코드가 이해는 되지만, 완전히 와닿지 못하는 점이 있다는 아쉬움은 있다. 하지만 대체적으로는 내가 완전히 수긍하고 또 역으로 배워서 써먹을 점이 많은 부분이 있음을 부정할 순 없다.

제일 와닿는 규칙을 몇 개 나열해보면 아래와 같다.

규칙 01. 최대한 단순하게, 그러나 너무 단순하지 않게
규칙 02. 버그는 전염된다
규칙 03. 좋은 이름은 최고의 문서다
규칙 08. 실행되지 않는 코드는 작동하지 않는다
규칙 13. 산사태를 일으킨 조약돌을 찾으라
규칙 15. 잡초를 뽑으라

그외 규칙은 조금 이해가 되거나 잘 납득할 수 없는 규칙들이다. 틀렸다고 말하고 싶은 게 아니라, 어딘가 나한테는 맞지 않는다거나 공감할만한 경험을 해보지 않은 게 아닐까 싶다.

팀원이 있던 시절, 그 팀원에게 한 얘기가 규칙 01이다. 그 전에 나도 어렴풋이 알고 있었다가 코드 리뷰를 받으면서 리뷰어에게 들은 말이기도 하고, 실제 그렇다는 걸 코드로 증명까지 해봤기 때문에 가장 가치 있는 규칙이다.

내가 리뷰를 하는 날인데, 코드가 무척 장황하게 만들어 왔더랬다. 불필요한 코드도 잔뜩 들어 있고 결론에 이르는 과정이 꽤나 복잡하기도 했던 그런 코드였다. 그래서 간단하게 말한 내용이다.

“코드가 길면 무조건 버그가 있는 겁니다.”

그걸 저렇게 잘 풀어내면 규칙 01. 최대한 단순하게, 그러나 너무 단순하지 않게, 가 된다. 그러면 그 팀원은 어떻게 했을까? 다시 작업해서 딱 필요한 내용만 남기고 정리해 왔다. 결론은? 잘 동작했고, 오히려 단순하게 했기 때문에 코드 상으로만 봐서는 알 수 없는 오류를 잘 파악할 수 있어서 코드 보완이 수월했다. 외부 입력값이 문서나 경험을 벗어나는 값으로 전달 받아서 버그가 발생할 수밖에 없었던 상황이었기 때문이다.

규칙 02. 버그는 전염된다. 이거 부정할 수 있는 사람 있을까? 버그는 무조건 다른 버그를 유발한다. 사용자에게 잘못된 행동을 유발시키든, 화면 처리를 요상하게 하도록 잘못된 코드를 양산시키든, 해당 버그를 가진 코드를 호출해서 내가 잘못된 결론을 내고 엉뚱한 코드를 작성하든, 아무튼 한 번으로는 안 끝는다. 그 여파는 지속되어 최악의 경우 잘못된 데이터를 생성해 DB 데이터까지 요염시킨다. 그러면 그 오염된 데이터 때문에 데이터팀이든, CS팀이든 개발팀 내 다른 팀원이든 그들의 업무를 대폭 늘리게 된다. 그러니 버그는 전염이 맞다.

규칙 03. 좋은 이름은 최고의 문서다. 이걸 부정하는 개발자가 있을까? 일을 하다보면 다소 근시안적인 접근을 하는 개발자, 기획자가 은근 많다. 지금도 변수 이름 하나, 함수 이름 하나 정할 때마다 어려움을 겪곤 한다. 이름 한 번 잘못 정하면 두고두고 그 뜻을 이해하느라 애를 먹는다. 보통은 당장의 그 시점만 고려하는 경우가 많다. 하지만 한 번 쓰고 버릴 코드가 아니라면 이걸 사용하기 시작하는 시점과 이를 중간에 다시 쓰는 시점 등 다양한 시점을 고려해야 하는데, 상상력 부제인 건지, 당장의 문제만 해결하면 된다는 건지, 지금 당장만 통하는 경우만으로 이름을 정한다. 그러면 지금은 의미가 있을지 모르지만, 시간이 지나면 십중팔구 문제를 일으키기 쉽다. 이걸 이해하려면 경험이 쌓여야 하는 것 같다. 아니면 백날 얘기해도 이해하지 못할 게 뻔하니까.

규칙 08. 실행되지 않는 코드는 작동하지 않는다. 와… 이건 뭐 말해 뭐해, 느낌이다. 실행되지 않는 코드를 누가 건드리겠는가? 변화가 있을 때 관련 코드를 건드리고 테스트 하지 않는다면 이건 무조건 문제가 생긴다. 안 쓰는 코드는 버리는 게 맞다. 지금 안 쓰면 나중에도 안 쓸 확률이 매우 높다. 어쩌다가 다시 쓴다? 저자도 git에서 다시 되살리면 되지 않느냐 하는데, 내 경험으로는 그러는 경우는 사실 없다고 봐도 무관할 것 같다. 이걸 되살리는 경우는 지우지 말아야 하는데 지워서 원복하는 경우 말곤 솔직히 못봤다. 삭제됐던 코드가 정상 작동한다고 보장할 수도 없고, 어차피 되살려봐야 이해하고 고쳐야 할 점을 찾는 게 더 비용이 큰 것 같다. 그냥 현재 요구사항에 맞는 내용으로 재작성하는 게 더 빠르더라.

규칙 13. 산사태를 일으킨 조약돌을 찾으라. 지금도 옆에서 그런 모습을 많이 본다. 경력이 많은 이들은 정말 열심히 파고 들어서 증상을 직접적으로 일으키는 점 뿐만 아니라, 이를 유발한 조약돌까지 찾아 근본적인 해결을 하려고 든다. 그런데 대충 경력이 얕거나 경력이 많아도 그렇게까지 하기 귀찮은 사람들은 증상만 해결하고 끝낸다. 그러면 보통은 당장 해당 순간은 넘어가는데 머지 않아 더 큰 문제를 만나 더 큰 비용을 지불하고 해결해야 한다. 그 동안 고객은 회사에 실망하고 이탈하는 데 말이다. 조금만 더 신경쓰면 서로 윈윈했을 텐데 말이다.

규칙 15. 잡초를 뽑으라. 아… 저자는 예제로 주석문 얘기를 했지만, 내가 이 규칙을 읽었을 때 머릿속에 떠오는 건 바로 며칠 전에 회사 동료에게 했던 말이었다. 뭔가를 수정하고 빌드를 진행하고 있었는데, 그 동료가 컴파일이 오래 걸린다고, 레거시 시스템이라 그렇다는 말을 했다. 하지만 나는 그게 왜 그렇게 오래 걸리는 줄 알고 있다. 내가 담당하지 않아서, 당장 다 뒤집을 수 없어서 몇 번 언급만 했었던 것이지만, 역시 일이 커지고 하기 싫은 일이다보니 해결이 안 됐던 부분이었다. 바로 컴파일러가 내뱉는 경고 문구들 때문이었다. 2, 300여 개의 경고문을 출력하느라 컴파일 속도가 느린 것이다. 이걸 한 번 테스트 삼아 정리했고 10개 내외는 정말 없앨 방법이 없어서 남겨뒀었는데, 컴파일 속도가 확연히 달라졌었다. 그래서 이 점을 인지하고 알렸는데, 저자 말처럼 못질하고 싶지 않은 사람이 훨씬 많았던 터였다. 회사 초창기에는 팀장이 경고 무시하지 말고 무조건 해결하라고 했었는데, 지금은… 안타깝다.

공감되는 내용과 더 노력해야 할 내용들을 읽게 되어서 상당히 많은 도움이 되었다. 내가 완전히 공감하지 못하는 부분들에 대해서는 내 나름대로의 방향을 정리하는데 가이드라인으로 사용할 법하다. 내용을 차분히 읽어보면 이야기꾼 면모가 보이는 것 같다. 번역을 깔끔하게, 맛깔나게 잘 하셔서 더 그런 것 같다. 번역투도 아니고, 실제로 저자가 한 말을 잘 이해해서 우리말로 잘 옮겨놓았다. 그래서 품질이 좋다. 그러다보니 저자가 하고자 하는 내용도 잘 이해되는 효과도 있고.

예제 코드를 단발성으로 사용하지 않고, 점진적 개선을 통해 저자가 하고자 하는 내용들을 증명하며 전개해 나가서, 코드를 읽을 수 있는 개발자라면 확실히 도움이 될만한 팁이 많다. 개인적으로는 규칙 19. 평행 재작업 부분이 덜 이해가 되어서, 이 부분을 다시 보면서 파봐야한다. 왜냐하면 이 내용이 현재 내가 겪고 있는 어려움과 직접적으로 연관된 내용이기 때문이다. 낡은 코드, 문제가 되는 코드들을 개선해야 하는데, 건드릴 때마다 문제가 많이 생겨서 애를 많이 먹고 있기 때문이다. 이걸 잘 풀어보면 해결 실마리를 얻을 수 있지 않을까 기대해본다.

뭔가 본인의 개발 틀을 잡고 싶다면 이 책은 강추하고 싶다. 초심자가 이 책에서 얼마나 많은 걸 얻어갈 수 있을진 모르겠지만, 적어도 이런 점이 있다는 걸 인지하고 있으면, 앞으로 개발 업무를 해나갈 때 선임의 말이나 코드를 이해하는 데 많은 도움이 될 거라고 믿는다.

원래 조언처럼 말해주는 건 당시에는 이해하기 어려운 법이다. 내 생각이 너무 강해서 그렇다. 그래서 겪어봐야 아는 것이지만. 결국 이렇게 말할 테니까. “그때 그 말대로 했어야 했는데!”

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

자바를 처음 접한 게 대학 2학년 때였던 것 같다. 아주 핫한 언어였고, C/C++ 언어의 단점을 극복한 언어라면서 홍보도 많이 했었다. 컴파일러 성능을 개선하기 위한 논문이 쏟아졌고, 한 번에 처리할 인자 수를 늘리면서 성능이 대폭 개선됐다는 얘기도 들려왔다.

실제 취직을 해서 웹 프로그래밍을 하게 되었을 때도 핫했던 Servlet/JSP 기술을 도입해서 만들어내느라 바빴다. 그만큼 자바는 산업계에 큰 파장을 일으켰다.

그런데 어느 순간부터 자바가 자바스럽지 않게 되면서, 수많은 산업계의 요구사항이 빗발치면서 자바가 변했다. 그 변화를 따라잡는 게 쉽지 않아졌다. 심지어 선에서 오라클로 주도권이 바뀌기도 했다.

잠깐 한 눈을 팔고 돌아와보니 내가 알던 자바는 완전 구닥다리처럼 변해 있었다. JVM에서 돌아가는 다른 언어를 익히고 나니, 자바 코딩이 너무 힘들어졌다. 스칼라는 객지지향 언어와 함수형 언어의 장점을 혼합한 언어였고, 러닝 커브가 거셌지만, 한 번 익히고 나니 그 간결함과 대폭 줄어든 코드량에 열광했다. 다만, val과 var의 차이점과, 과거 자바스럽게 코딩하던 버릇 때문에 적응이 어려웠다. 하지만 그 지점을 통과하고 나니 val만 쓰는 방식이 너무 편하다. 문제가 발생해도 값을 인식하지 못한 지점에서 바꾸는 상황이 없어지니 디버깅 하기도 수월해졌다.

그런데 회사에서 스칼라를 버리고 자바로 가게 됐다. 그나마 최신 트렌드로 무장한 코틀린으로 가고자 했지만, 자바를 익힌 개발자들의 저항이 거셌다. 결국 현실적인 이유 때문에 코틀린으로 가지 못하고 자바로 회귀했다.

가만 생각해보면, 자바가 과연 문제일까? 자바가 문제가 아니라, 자바식으로 코드를 작성하는 게 부담스럽다. 무엇 때문에? 막대한 코드량 때문이다. 최신 트렌드가 반영된 언어들과 자바로 같은 로직을 작성해보면, 그 양이 현격히 차이가 난다. 그래서 코드를 읽는 게 부담스럽기도 하고 로직이 먼저 보이는 게 아니라, 로직을 짜기 위해 필요한 코드들이 방해했다.

뭔가 해결책이 필요했다. 그것이 자바 8 이후로 전격 도입된 함수형 프로그래밍 지원이었다. 처음에는 그런 코드들도 너무 군더더기가 많다고 생각했는데, 이 책을 읽으면서 이유를 알게 됐다. 바로 하위 호환성 때문이었다는 것. 새로 도입하는 거라면 과감하게, 최신 트렌드처럼, 간결하게 만들어도 됐을 텐데, 하위 호환 가능하도록 만들다보니 어쩔 수 없이 취해야 했던 모양새다.

도입은 했는데, 이걸 내가 제대로 알고 쓰는 게 맞을까? 놓치고 있는 건 얼마나 될까? 사실 이걸 반영하기 위해 상용 IDE가 제안하는 도구들을 활용해서 조금씩 반영하곤 있었다. 하지만 이게 맞는 걸까? 그런 고민으로 부담감이 날로 커지는 가운데, 이 책을 만나게 됐다.

정말 내가 필요로 했던 책이다. 그런데 단순히 개념만 설명하는 책은 아니었다. PART 01 함수형 기초를 읽을 때까지는 매우 고통스러웠다. 익숙하지 않은 전문용어가 많이 나왔다. 기술 용어? 아니다, 수학적 개념을 이해해야 하는 용어들이다. 번역하는 사람 입장에서도 힘들었겠다 싶었다. 지지부진하게 읽다가, 슬슬 속도가 붙기 시작한 지점이 record 설명할 때였다. 그나마 최신 언어에서 실험 중인 기능을 조금 써 봤다. 그러다보니 설명을 이해하는 게 많은 도움이 됐다.

자바 람다에 대해선 피상적으로만 쓰고 있었는데, 확실하게 알게 되었던 건 큰 수확이다. 물론 정말로 잘 이해했고, 잘 활용하려면 기존 코드를 변경하고 비교해가면서 확고히 하는 수밖에 없겠지만, 그냥 모르는 채로 대충 쓰는 것과는 확실히 다르다. 빨리 적용해보고 싶을 지경이다.

함수형 인터페이스 Function, Consumer, Supplier, Predicate 이것들은 알게 모르게 쓰고는 있었는데, 이제야 뭔지 알 것 같다. 역시 연습을 통해 확실하게 익혀둬야겠다.

스트림 역시 마찬가지다. 스칼라에서 쓰던 형태 비슷하게 쓰고 싶어서 쓰기 시작했던 건데, 코드를 정리하기 위해서라도 더 많이 쓰려고 한다. 내가 관리하는 시스템은 성능보다는 명확한 로직과 의도, 유연한 추가나 변경이 더 중요한 시스템이다. 성능이 중요하지 않다기보다는, 지장이 없을 정도면 되고, 오히려 다양한 요구사항을 빠른 시간 안에, 안정적으로 제공해주는 게 더 중요하다. 게다가 권한도 명확해야 하고, 변화에 대한 기록도 분명하게 해줘야 하는 거다보니 더욱 명확하게 파악해야 한다. 그런 면에서 함수형 도입은 분명히 필요하다.

리팩토링을 하려고 하는 코드는 전형적인 과거 자바 스타일 코드들이다. 솔직히 로직이 안 보인다. 너무나 많은 예외 처리들이 존재한다. 좀더 객체지향적으로 구조 개선을 하든가, 한 눈에 보이도록 함수형으로 개선하던가 해야 한다. 그런 면에서는 개인적으로 함수형이 더 나은 것 같다. 객체지향은 좋긴 한데, 뭔가 명확하게 흐름을 파악하기에는 문제가 많은 것 같다. 물론 설계 미스였겠지만.

인상깊은 부분은 스칼라의 try/success/failure를 함수형으로 구현한 부분이었다. 솔직히 왜 나는 이런 부분을 생각하지 않았을까 싶었고, 스칼라가 해당 기능을 JVM에서 돌리기 위해 비슷한 형태로 내부 구현한 게 아닐까 하는 생각마저 들었다. 물론 이게 진실이라고 생각진 않는다. 이 부분은 실제 구현된 부분을 확인해봐야 알 수 있는 내용이겠지만.

제일 많이 쓰고자 하는 건 역시나 Optional이다. 너무 명확해서 뭐라 말하기가 어렵다. 이걸 쓰고 안 쓰고는 확실히 차이가 나는 게, 정신이 아찔할 정도로 if 절을 남발할 수밖에 없는 상황을 반전시킬 수 있는 키 피처 중 하나다. 스트림과 Optional, 이 둘만 적절히 정리해줘도 지금보다는 확실히 낫다.

느긋한 계산법 (지연 평가), 이걸 제대로 몰랐던 건데, 설명을 아주 잘 해준다. 게다가 저자가 다년 간 일하면서 알게 된 주옥같은 가이드나 팁, 경험 공유는 무척이나 값지다. 기술 설명하는 것보다, 이런 내용들이 오히려 저자가 하고 싶었던 내용이 아닌가 싶다.

재귀 부분은 일반적으로 아는 정도로만 알고 있었는데, 새로운 관점을 알게 해줬다. 눈이 번쩍했다.

함수형 디자인 패턴과 자바를 위한 함수형 접근 방식은 한 번만 읽어서는 안 될 내용이다. 이 내용은 여러 번 읽어서 전달하고자 하는 내용을 체화해야 할 것들이다. 단순한 내용도 아니고 쉬운 내용도 아니다. 이것들을 내것으로 만들 수만 있어도 한 번의 빅 점프를 할 수 있다는 생각이 들었다.

저자는 독학으로 개발자가 되었다고 했다. 본인은 전산학을 전공했지만, 솔직히 저자만큼의 지식을 쌓았다는 생각이 들지 않는다. 역시 배움에는 끝이 없고, 읽어야 할 책은 매년 쏟아져 나온다. 그래서 할 일은 전혀 줄지 않았다. 그래서 흥미로운 세계가 바로 프로그래밍이 아닐까?

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

현재 50대 이하의 사람들 중에 비디오 게임을 모르고 자란 사람이 있을까? 한 번도 안 한 사람이 있을 순 있지만, 비디오 게임이라는 게 있는지도 모르고 자란 사람은 없을 거다. 나 역시 어릴 때부터 접해 왔다. 오락실에서부터 PC, 휴대용 게임기, 게임 콘솔, 그러다 지금은 휴대폰까지, 아니다, 스마트TV까지, 거의 모든 엔터테인먼트 기기에서 게임을 즐길 수 있게 됐다.

이런 게임들을 접하면서 사실 항상 궁금했던 건, 저 캐릭터는 어떻게 움직이는 거지? 왜 저런 판단을 내리고 공격하는 걸까? NPC는 정해진 시나리오대로 움직이는 거라 이해하지만, 전투는 그렇지 못할 텐데… 그러다 어느 순간 랜덤한 선택을 해서 정해지지 않은(?) 시나리오로 진행해 다양한 결과를 보여주는 게임까지 나오곤 했다.

그러다 지금은? 크고 나서는 오히려 학창 시절보다 더 게임을 못 즐기게 됐지만, 과거에 비하면 엄청나게 다양한 모습을 한 캐릭터가 나오고, 이제는 훨씬 복잡하면서도 단순 대전도 아니고 스타크래프트 정도에서 촉발돼나온 다양한 형태의 대전 게임도 많이 존재한다. 사실 PvP 형태가 아닌 AI와의 대전 게임도 사람 만큼이나 다양하게 대응하다보니 AI 상대로 게임을 이길 수나 있을지 걱정이 될 정도로 발전했다.

그렇다고는 해도 가장 기초가 되는 방식이 있을 텐데, 게임 분야 일을 하지 않는 관계로 궁금은 하지만 사실 어떻게 하는지는 모르고 있었다. 간혹 궁금해서 찾아보면 이런 쪽을 설명해주는 자료를 찾긴 쉽지 않았고, 배경지식이 짧으니 자료를 판별하는 것도 쉽지 않은 상황이니 사실상 손놓고 있었다고 보면 된다. 이런 지경이면 이쪽 지식은 게임 회사의 핵심 자원이 아닌가 싶어서, 쉽게 찾을 수 없었던 게 아닌가 싶기도 하고…

그런데 근래 AI 관련 산업이 폭발적인 성장을 하면서 오히려 옛날부터 실전 사례로 사용하던 게임AI쪽도 그 영향을 받아 좀더 공개적인 상황이 된 게 아닌가 싶어졌다. 예전보다 게임 산업이 굉장히 많이 커지다보니 참조 가능한 자료로 더 많아졌을 거라 추측할 순 있었지만, 그래도 어느 지점부터 접근해야 할지 난감한 상황이었다. 게임 아카데미 들어가면 좀 더 수월하게 알 수 있지 않을까 싶기도 하지만, 그렇게 도전하긴 어려운 상황이라.

“게임 AI를 위한 탐색 알고리즘 입문”이라는 책을 알게 됐다. 요즘 AI쪽 얘기를 하도 많이 하다보니 피로감도 있지만, 제대로 공부해본 적은 없고, LLM을 파야 하나, 뭐 괜찮은 입문서는 없나, 싶으면서도 수학은 여전히 자신이 없어서 어려운 책은 보기도 싫고, 그러다 이 책을 덜컥 얻어 걸렸다.

차근차근 읽어가면서 오, 읽을만 한데? 하는 자신감을 얻어갈 때쯤 C++와 관련 필드에서 일하지 않다보니 퇴색된 지식 때문에 좀 난감해졌다. 수학, 확률, 이쪽 관련 알고리즘… 흠, 쉬운 게 없지만, 다행스럽게도 저자가 어려운 말은 많이 안 쓴다. 그나마 다행이다. 학술적인 어조로 진행하지도 않는다. 너무 다행스럽다. 제일 좋은 건 그래프를 곁들인 적당한 설명 뒤에 따라나오는 예제 코드와 그 실행 결과다.

지은이의 말에 자신이 대상으로 삼은 사람들을 나열한 내용 중 내가 속한다고 생각되는 부분은 “대결 게임을 개발하고 싶지만 CPU(컴퓨터가 조작하는 플레이어)를 만드는 방법을 모르시는 분”일 거라 생각한다. 당장 개발할 일은 없지만, 죽기 전에 하나쯤 만들어보고 싶은 생각은 있다.

예제 코드를 제공해준다. 사실 이건 정말 중요하다. 물론 직접 타이핑 치는 게 제일 좋은 학습법임을 알고는 있지만, 항상 업무든 집안일이든 시간에 쫓기는 입장에서는 이렇게 타이핑 치는 시간조차도 아쉽기 마련이다. 샘플 코드를 제공해준다면, 아무래도 책으로 설명을 읽기만 하고 눈으로 쫓아가기만 하는 것보다는 실제로 돌려보고 손보기도 하면서 익히는 게 훨씬 도움이 되니까 매우 좋다.

게임 AI의 핵심은 탐색임을 이해할 수 있게 됐다. 그리고 그런 탐색에서 쓸만한 것들을 많이 제안해준다. 그것도 코드와 그 결과와, 심지어 탐색 알고리즘의 비교 분석까지. 이러니 도움이 안 될 수가 없다. 다만 읽으면서 한 가지 아쉬웠던 것은, 실제 사례로 널리 알려진 게임에서 어떤 탐색 알고리즘을 사용했는지, 그 사례를 좀 더 보여줬으면 어땠을까 싶긴 했다. 하지만 그러기엔 책이 다루는 범위와 주제에 안 맞을 수도 있겠단 생각은 들었지만, 그래도 좀 아쉽다. 이 다음 책은 뭘로 해야 하나 고민스럽기도 하고.

나름의 게임 분류법을 통해 그에 적합한 알고리즘 소개까지는 무난하게 간다. 아무래도 가장 기초적인 건 빔 탐색이라 생각되는데, 이를 바탕으로 진행하면서 추가적으로 설명해나가는 알고리즘들이 앞서 언급한 알고리즘의 어떤 면을 개선해줄 수 있는지, 장점과 단점을 적절히 언급해주는 것도 많은 도움이 된다. 머릿속에 정리하려면 시간이 더 필요할 것 같다. 읽으면서 정리하기엔 쏟아져 들어오는 양이 많다.

쭉쭉 읽어가면서 너무 오래 전에 하고 안 한지라 C++ 코드에서 한 번 걸려 넘어지긴 했다. 다시 공부 좀 해야겠다 싶은 생각이 든다.

그러다 몬테카를로 탐색과 라스베가스 탐색의 배경에 대해 알게 된 건 또 다른 수확이다. 이게 도박에서 나온 거고, 저 유명한 몬테카를로라는 이름이 발레단 때문에 알게 됐는데, 도박이 유명한 곳인 줄은 처음 알았다.

백미라고 생각되는 부분이 두 군데 있는데, 그 중 하나는 Thunder 탐색이다. 본인이 이걸 개발하게 된 배경 설명도 좋았고, 내용도 좋았고, 이런 지식을 널리 공유하게 해준 것도 고맙다. 대단한 사람이다. 다른 하나는 7장 더 좋은 탐색을 하는 기법에서 특히 고속화 부분이다. 사실 어떻게 보면 이건 알고리즘보다는 최적화에 더 적합해보이는 부분인데, 다른 관점에서 보면 조금 과하단 생각이 들기도 하다. 하지만 아마 이 내용을 빼기엔 뭔가 허전했을 것 같긴 하다. 게임 AI의 미덕 중 하나는 비용 절감이다. 충분한 메모리와 시간, CPU 파워 등이 있다면 문제될 게 없겠지만, 뭐가 됐든 제한된 리소스 상에서 최적의 결과를 얻어내야 한다. 그러기 위해서는 비트 연산 이해는 필수다.

입문서지만, 한 두 번 읽어서 다 이해할 거라 생각은 들지 않았다. 한 꼭지씩 따서 찬찬히 뜯어보고 충분히 곱씹어 봐야 한다. 확실히 이해해야 적용과 응용이 될 거란 생각이 읽는 내내 떠나지 않았다.

이쪽 분야를 아주 조금은 들여다본 것 같다. 내 궁금증이 더 해소되려면 더 많은 게 필요하겠지만, 도입부로서는 딱 좋다. 게임 AI를 공부하기에 더할 나위 없이 훌륭하다.

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

자바 책 검색을 하면 늘 나오던 그 책이다. 참 오랜 세월을 봐왔지만 읽어본 건 이번이 처음이다. 굳이 피하던 건 아니었고 학교 다닐 때 배운데다 회사에서는 사실 jsp 1.0 나오기 전부터 사용했기에 입문서를 읽을 이유가 사실상 없었다. 하지만 몇 개 기술서가 그렇듯 판올림으로 계속 나온다는 건 이유가 있는 거다. 그래서 궁금했다.

결론부터 말하자면, 자바 기초를 배우고 싶은 이들에게 이 책은 교과서 느낌이다. 백과사전식 나열도 아니고 지식 검증을 위한 재미없는 퀴즈제시도 아니다. 무슨 느씸이라고 해야 할까, 생각을 제대로 해봐야 하는 대학교재다.

설명은 구체적이고 좀 구어체식이라, 글로 이런 문체를 읽는 데 거부감이 있다면 난감할 수 있다. 나도 처음에 전달하는 내용에 비해 글이 많은 데 부담을 느꼈다. 언제부턴가 해야 할 게 많다보니 그론 경향이 강해졌으니. 그런데 어느 정도 적응을 하고 보니 비로소 그 가치가 느껴진다. 이 책 결코 입문서지만 잠깐 읽고 던질 책이 아니다. 교과서로 진득하게 공부하듯 읽고 생각하고 코딩하면서 결과를 확인해봐야 한다. 안 그러면 온라인 핸드북 읽느니만 못한 결과릉 얻게 될 거다.

직업상 웹 관련 백엔드와 일부 프론트엔드 개발을 하다보니 GUI, Swing, 병렬 처리는 솔직히 직접 건드릴 일이 없어 책 내용이 크게 와닿지 않는다. 하지만 그외 부분들의 경우 잊고 있었던 기본에 관해 되뇌일 수 있는 계기가 된 것 같다. 늘상 생각하던 거고 다른 이들에게도 말했지만 뭔가 고급 기술을 써서 문제 해결하는 것보다는 기본적인 것들로 하는 게 훨씬 많다는 것. 그리고 항상 내가 평생 책임질 게 아니라면 다른 이들이 보고 이해하고 수정하고 개선할 수 있는 코드를 작성해야 한다는 것. 그 생각에 지지대를 세워주는 내용으로 가득 차 있다.

7장 상속과 다형성, 8장 인터페이스와 추상 클래스, 11장 자료구조, 12장 람다와 스트림, 18장 동시성 이슈 처리 방법은 분명하게 개념을 세워두는 게 좋다. 물론 다른 장들을 소홀히 보라는 의미는 아니다. 그게 바탕이 되어줘야 언급한 장들을 이해할 수 있다.

예를 들어, 7장에서 상속과 다형성을 설명할 때 Animal 클래스와 이를 상속받은 Dog 클래스를 여러 가지 예시를 들어가면서 설명한 부분과 같이, 신경 써서 전달하고자 하는 내용을 전개하는 방식은, 꽤 긴 호흡을 유지해야 하기에 어려울 수는 있지만, 그 과정을 잘 이해하기만 하면 해당 개념을 머릿속에 넣어두는 데 있어 매우 중요한 역할을 할 수 있다. 아무래도 실질적인 예제와 개념을 잘 일치시켜 얘기하면 입문자 입장에서는 매우 큰 도움이 된다. 단, 처음 읽다보면 헷갈려서 앞으로 갔다왔다를 반복하겠지만, 그건 어찌 보면 당연하다.

게다가 사이사이 들어가 있는 코드들과 퀴즈들은 생각보다 난이도가 있다 보여진다. 쉬워보이는 게 사실 더 어려운 법이고, 뭔가 해결하는 데 코드량이 많다는 건 뭔가 잘못된 방향으로 나아가고 있다는 뜻일 거다.

개인적으로 이 책에서 람다와 스트림, NIO.2를 다시 샐펴볼 수 있어 좋았다. 다른 관점에서 본다면 입문자에게 부담스러울 수도 있다 싶은데, 뭔가 책에서 해보라는 내용을 따라가는 데 거부감을 느낀다면 그럴 수도 있겠다 싶다. 하지만 그런 불편함을 조금 참아내기만 하면 좋은 출발지일 거라 확신한다. 책의 앞에 추천글이나 서평이 그렇게나 많은, 그래서 홍보하는 그 문구가 있는, 그 이유가 있는 법이다.

자바를 제대로 사작하고 싶다면 이 책이 좋은 길라잡이가 될 거다. 조금의 불편함은 버리고 한 번 도전해보라. 거대한 자바의 세계에 들어온 걸 환영한다!

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

이거다! 근래 회사에서 조직 개편이 일어나 원래 3명이서 하던 업무를 혼자 해야 하는 상황이 발생했다. 서버 프로그램과 클라이언트 프로그램을 다 해야 하는 상황인데, 서버 프로그램쪽이야 하던 거라서 큰 문제가 없었지만, 문제는 클라이언트 프로그램이었다.

과거 클라이언트 코드는 리액트의 클래스 컴포넌트를 사용해서 완전히 익숙해져 있던 상황이었는데, 여러 가지 문제도 있고 너무 낡은 버전을 쓰고 있다보니 보안 이슈도 해결이 안 되고, 기술적으로도 낙후될 뿐만 아니라, 점점 비대해지는 코드량을 관리하는 것도 힘들었다.

특히 SPA가 주는 장점(물론 단점도 있겠지만)을 활용하지 못해 발생하는 이슈도 있어서, 이참에 리액트 버전도 올리고, SPA로 만들어서 뭔가 전담 인원이 집중해서 작업할 수 있도록 해왔다.

그런데 이걸 덜컥 혼자 하게 되었다. 최신 기술을 그래도 많이 도입해서 구현한지라, 여기에 익숙지 않은 나로서는 무척 난감한 상황이었다. 그래도 나름 이쪽 업계에서 구르다보니, 기존 클래스 컴포넌트로 된 것도, 수많은 시행착오와 문서를 뒤져서 익힌 상황인지라, 어떻게든 꾸역꾸역 손대고 있었다. 하지만 최신 기술을 많이 사용한 현 클라이언트 프로그램은 관리하기가 쉽지 않아 능률이 너무 떨어졌다.

문제는 최신 기술에 대한 이해도가 떨어지는 것. 이걸 잘 풀어내기 위한 길라잡이가 필요했는데, 이 책을 우연히 접하게 된 것이다. 처음에는 또 기술 나열이랄까, 전형적인 설명투의 기술 서적이겠거니 해서 기대를 하지 않았던 게 사실이다. 게다가 입문서가 아닌가! 많은 부분을 건너뛰게 될 것만 같은 기대(?)가 있었다.

그런데 열어보니 생각했던 그게 아니었다!

무엇보다도 기초에 충실하면서도, 핵심을 찌르는 설명과 전개가 맘에 쏙 들었다. 특히 인상 깊은 몇 가지를 들여다보면, 저자가 저자의 말에서 한 바와 같이,

“나중에 커서 훌륭한 프로그래머가 되어 내가 알고 있는 것을 다른 사람들에게 이해하기 쉽게 가르쳐 주고자 하는 목표가 생겼습니다.”

이 말처럼 입문서지만 그래도 쉽고 필요한 부분만 언급하며 과하지 않은 반복을 사용해 설명해나간다.

분명히 따라해보면 잘 될 코드들을 제안한다. 그러면서 목적에 맞는 적절한 예제를 제공해준다.

특히, 클래스 컴포넌트를 설명하면서도 여러 문제점을 해결한 함수 컴포넌트를 주로 사용하게 하되 알고는 있으라는 식으로 비교해주어 레거시 코드를 보게 되더라도 당황하지 않도록 배려해준다.

덕분에 내 입장에서는 클래스 컴포넌트 방식으로 개발해오다 함수 컴포넌트 방식으로 전환된 현재 클라이언트 프로그램을 분석하고 수정하거나 추가 개발해야 하는 상황에서 무척이나 많은 도움이 된다. 적어도 왜 이렇게 짜야 하는지를 이해할 수 있게 되어서지 싶다.

훅, 이벤트 핸들링, 조건부 렌더링, 합성 vs. 상속, 컨텍스트… 이것들을 대략적으로는 코드를 통해, 그리고 전 직원의 도움으로 조금은 알고 있었지만, 명확하게 머릿속에 그림을 그릴 수 있도록 가이드해줘서 무척이나 도움이 된다.

역설적이게도, 경력이 있을 때, 잘 만들어진 입문서는 어설프게 만들어져 있던 기초를 탄탄하게 만들어준다. 이해가 안 될지 모르겠지만, 잘 만들어진 입문서는 입문자에게 도움이 된다기보다는 오히려 경력자에게 더 도움이 되는 이 역설.

마지막에 덧붙여진 리액트 18 소개는, 나에게 자동으로 현재 프로그램을 어떻게 개선해나가야 할지를 알려줬다.

잘못 이해하거나 과도하게 작성된 부분을 재정립한 지식을 바탕으로 개선하고 이제 리액트 18로 한층 개선된 코드로 만드는 그림을 그려볼 수 있을 것 같다.

입문서는 입문자에게 해당 내용에 흥미를 잃지 않으면서 약도를 제시해주며 궁극적으로 경험자에게 나침반 역할을 해주는 게 좋은 입문서임을 다시 한 번 되새길 수 있는 기회가 됐다.

529 페이지, 양이 많아보여도 안 많아 보이게 만드는 매직.

알고리즘 책을 펼쳐본 게 얼마만인지 기억이 잘 나지 않는다.

분명 작업하면서 참고할 목적으로 학교 다닐 때 대학교수가 만들어 출간한 알고리즘 책을 교제로 봤던 것 같은데, 그 뒤로 몇 권인가 언어를 달리 하면서 알고리즘 책을 사서 봤던 걸로 기억한다.

문제는 처음부터 끝까지 다 읽어내진 못했다. 게을러서였는지 아니면 설명을 읽어보고 이해가 잘 되지 않게 매우 학술적으로 써서 거부감이 있었던 건지도 모르겠다.

근래 공부를 조금씩 하기로 작정한, 그래서 인강으로 파이썬 초급 과정을 보고, 뭔가 확인해보고 싶은 마음에 이 책, 저 책 보다가 발견한 게 이 책이다.

구성은 매우 간단하다. 문법, 기본 자료구조 및 알고리즘, 그리고 이를 응용해 풀 수 있는 문제들. 뭔가 독창적이라거나 학술적인 방식이 아니라, 기본에 충실하면서도 설명과 예제와, 이를 시각적으로 표현하는 그림들과 그 전개 설명, 그리고 이를 바탕으로 하는 알고리즘 풀이 문제들, 그것도 leetcode.com에서 추려낸 문제들. 다시 말해 어중이 떠중이 문제가 아니라 이미 검증이 된 문제들이라는 말이다.

알고리즘 책들이 흔히 저지르는 실수는 정말 간단하다. 너무 학술적으로 접근하는 경향이 있다는 것. 이는 내가 그 알고리즘을 이해하는 데 사실 1도 도움이 되지 않았다.

정말 필요로 하는 것은 명확한 설명과 이를 뒷받침해주는 그림들이다. 그래야 설명과 그림을 매치시켜가면서 단계를 이해할 수 있다. 아무리 알고리즘을 구현한 코드를 들이민다고 한들 머릿속에 그려내지 못하면 그건 이해했다고 할 수 없다. 매번 봐왔지만 아주아주아주 만족스러운 건 보지 못했다. 그런데 이 책은 어느 정도 내 요구사항을 만족시켜줬다. 비록 간간히 그림 속에 오타가 있어서 내가 잘못 이해한 건지, 그림이 잘못된 건지 확인하느라 끙끙댄 것만 뺀다면.

파이썬의 기초를 설명하면서 초급 과정에 나오지 않았던 내용들을 이해하는 데 좀 힘들었다. 언제나처럼 코드만 바라봐선 이해하기 힘들다. 결국 타이핑을 하든지 예제 코드를 받아서 돌려보든지, 실제로 돌려봐야 감이 오게 마련이다. 약간 안타까운 건, 이건 뭐지? 하는 코드도 조금은 들어 있었다는 거. 내가 이해를 못한 건지, 코드에 버그가 있었던 건지는 모르겠다. 많은 시간을 투자해서 다 검토해보진 못했으니까.

그래도 많은 부분은 파이썬에 대한 내 지식의 틀을 잡는 데 도움이 됐다.

이제 핵심 자료구조. 오, 이건 이렇습니다, 로 끝나지 않았다. 최소한 이게 왜 필요한지 개연성을 가지고 꼬리에 꼬리를 물면서 전개한다. 왜 이런 걸 만들어냈는지 소소하게라도 언급해서 좋다.

기본 알고리즘으로 알려주는 것들. 정렬, 그래프, 문자열 검색. 업무 특성 상 그래프는 제외하더라도 정렬과 문자열 검색은 정말 토 나올 정도로 자주 쓴다. 그러니 익히는 건 당연하다.

자, 문제들. 이게 문제다. 너무 많다. 단기간에 하기에는 매우 벅차다. 그래서 목표를 세워야겠다. 일주일에 2, 3개 정도 시도해보기. 전적으로 시간을 할애할 순 없으니, 차근차근 접근해야겠다. 그래도 맛보기 정도는 접근해봐야하니, 제일 처음으로 만나는 재귀를 봤다.

그렇다. 왜 재귀인가? 재귀하면 사람의 사고방식에 근접한 대신, 시스템 관점에서는 자원을 많이 써서, 잘못하면 스택 오버플로를 발생시킨다는 그 내용이 제일 먼저 떠오른다. 그래서 가급적 풀어서 구현하느라 애먹었던 게 한 두 번이 아니다. 요즘은 컴파일러들 성능이 좋아서 재귀적으로 작성해도 풀어서 성능을 최적화한다고 들었다. 그래서 뭐, 왠만하면 읽기 좋게 작성하는 게, 후임 개발자들한테도 도움이 될지 모르겠다.

앞서 말했던 메모리 이슈를 여기서도 빼먹지 않고 설명한다. 역시 기본에 충실하다. 코드 예제도 보여주면서 동시에 그림도 있다. 친절히 전개 순서도 알려준다. 이런 건 너무 좋다. 눈으로 차분히 따라가보면 조금씩 머릿속에 자리를 잡아간다, 그 개념들이.

이제 첫 번째 문제를 만났다. 홍수 채우기? 어떤 문제인지 설명하고 그 문제를 풀기 위한 의사코드를 제공한다. psuedo code를 의사코드로 변역했다. 뭐 원 발음대로 쓰기도 하고 유사코드라고도 하고, 아주 다양하게 불린다. 아무튼 이걸로 틀을 잡아줬다. 처음엔 이게 뭔가 싶지만, 나중에 계속 반복하다보면, 머릿속에 보통 이런 식으로 틀이 잡히더라. 그러니 익숙해지는 게 좋다.

해결코드를 보여주고 그로 인해 전개되는 걸 역시나 그림으로 설명해준다. 이런 게 너무 좋다. 답으로 코드만 보여주고 돌려보라는 무책임한 말은 안 한다.

좋다, 이런 식으로 반복해 문제들을 풀어가보면 잘 모르던 것들도 틀이 잡힐 것 같다.

주변에 새로 구직을 하는 분들을 가끔 보는데, 요즘은 코딩 테스트 기본으로 알고리즘 풀이를 한다고 한다. 그렇다면 어떤 책이든 알고리즘 풀이 연습도 하고 개념도 익혀야 할 텐데, 이 정도의 친절함이라면, 그리고 대세 언어 중 하나인 파이썬이라면 많은 도움이 될 듯도 하다.

간만에 맘에 드는 알고리즘 책을 찾았다. 아까 언급했다시피 오탈자 만날 때마다 검증 후 신고해야겠다. 살짝 봤는데 2건 신고됐더라. 내가 아직 제대로 파악 못한 부분들 같은데, 한 번 쭉 따라가봐야겠다.

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공 받아 작성된 서평입니다.”

아래는 이벤트를 안내하는 링크입니다.

https://lightning.korbit.co.kr/notice/?noticeId=2V28e9sGQKYYSyL7WuSRmX

#코빗 #수수료무료이벤트 #메이커인센티브

코빗에서 하던 득이 되는 메이커 인센티브 이벤트가 있는데 더 얹어서 꽤 강한 수수료 무료 이벤트를 열었습니다. 한 번 확인해보세요.

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

이런 책을 얼마만에 읽어본 것일까? 무엇보다도 이 책은 쉽게 읽어 나가기에는 난이도가 상당했다. 이유? 간단하다. 그동안 일하면서 쌓인 경험치들이 책 한 줄 읽을 때마다 되살아나서, 책에서 얘기하는 것과 나의 경험 사이의 관계를 재정리하느라 빠르게 읽어나갈 수가 없었다. 속도를 높일수록 그 저항감은 이루 말할 수 없었다. 그만큼 이 책은 경력이 많을수록 공감을 할 수밖에 없고, 생각을 많이 할 수밖에 없는 책이다. 그렇다고해서 그 내용이 전부 옳으냐? 그 답은 “2019년 10월에 이 책을 쓰기 시작했을 때, 나는 마침내 훌륭한(영향력 있는) 기술 리더가 되는 몇 가지 방법을 알아냈다고 생각했다. 그래서 지금까지 경험으로 배운 것을 공유하고자 결심한 것이다.”와 “3년 후에 이 책이 출간되자마자 충격적인 판매량을 기록했다.”로 정리할 수 있을 것 같다. 결국 경력이 쌓여가는데 어떻게 성장해야 하는지 그 이정표를 알고 싶은 사람은 IT의 역사에서 수없이 있고, 그 열망은 예나 지금이나 마찬가지인 것이다. 그러니 단순한 기술을 익혀 사용하고자 하는 사람은 이 책에서 얻을 건 없다. 요는 현재 나의 상사의 속마음을 짚어보거나 내 방향성을 설정하고자 하는 이들에게는 이 책은 더없이 알맞을 거라 생각한다.

1부. 빅 픽처 관점의 사고력, 2부. 성공적인 프로젝트 실행력, 3부. 조직 차원의 레벨업. 이렇게 구성해서 본인의 경험과 업계 사람들의 의견들로 구성해 진행하는 얘기가 다소 반복적이거나, 장황한 얘기가 나오다보면, 자칫 그 흐름을 잃을 수도 있음을 주의하자. 어차피 키워드는 제목 형태로 제대로 제공하고 있으니 그 점을 항상 기억하면서 읽어나가면 진도가 안 나가는 불상사는 피할 수 있으리라. 사실 주요 내용이 마무리 될 때마다 “마치며”를 제공하고 있으니 미리 읽어서 키워드와 설명 사이의 간극을 좁혀보는 것도 좋겠다.

다시 말씀드리지만, 이 책은 빨리 읽을 수 없는 책이다. 그리고 혼자 읽어서도 안 되는 책이다. 무조건 동료와 일독하고 내용을 서로 검토해보는 게 필요하다. 각자의 위치에서 이 내용을 이해하는 바가 다를 것이고, 이를 확인해보는 것도 매우 중요하다. 그러면 내 얘기가, 상사의 얘기가, 그 전과 어떻게 다르게 들리는지 알 수 있으리라. 그런 느낌을 한 번이라도 느낄 수 있다면, 이 책은 성공했다! 개인적으로는 머릿속이 더 복잡해졌지만.

카미유 푸르니에가 적은 추천의 글 마지막 문장으로 마무리하는 게 옳겠다.
“이 책은 스태프 엔지니어 역할에 필요한 기술을 알려주며, 모든 엔지니어의 책장에 놓여야 하는 책이다.” 이제 내 책장에도 한 권 있다!