더 나은 프로그래머 되는 법 리뷰

더 나은 프로그래머 되는 법 - 지금 바로 실천할 수 있는 선배 개발자의 39가지 노하우 / 국내 개발자 8인 인터뷰 수록
피트 구들리프 지음, 최원재 외 옮김 / 한빛미디어 / 2024년 4월

프로그래머로 회사에서는 물론 개인 프로젝트를 개발하다 보면 어느 순간 지금의 나는 지난번의 나보다 더 발전했는가?라는 생각이 지속적으로 떠오르게 됩니다. 그리고 더 좋은 코드를 작성하기 위해 우리는 노력합니다. 그렇다면 그 노력은 정말 더 나은 프로그래머가 되기 위한 노력이 맞을까요? 더 나은 프로그래머 되는 법 도서 리뷰를 해보도록 하겠습니다.

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

파트 1: you.write(code);

지옥에 보내버려야 할 코드 역시 좋은 의도로 포장되어 있다.
-p32: 코드에 신경 쓰기

"좋은 프로그래머는 무엇일까? 좋은 코드를 작성하면 좋은 프로그래머, 나쁜 코드를 작성하면 나쁜 프로그래머일까?" 저는 나쁜 코드를 작성하면 나쁜 프로그래머가 아닐까라고 생각했습니다. 하지만 도서에서 말하는 바에 따르면 의도적인 나쁜 프로그래머는 없다는 것입니다. 올라온 PR 혹은 다른 프로젝트에 involve 후 코드를 볼 때 '나쁜 코드다!'라고 생각할 수 있겠지만, 실제로는 그 당시 최선이었거나 다른 의도가 있을 수 있는 것처럼 대부분의 프로그래머는 고의적으로 나쁜 코드를 작성하지는 않을 것입니다.

이 책에서도 간단한 예시로 설명하는 것이, 모든 프로그래머는 좋은 코드를 작성하고 싶지만 할당된 작업 기간이 매우 촉박하거나 작업량이 매우 많은 경우 어쩔 수 없이 나쁜 코드를 작성되는 경우가 존재할 수 있다! 는 것입니다.

좋은 코드가 되기 위한 최소한의 방지책으로 코드 구조, 일관성, 명명, DRY 등 도 함께 설명하고 있는데 사실 이는 너무나도 당연한 내용들이기도 합니다.

공정하게 말하자면, 불쾌한 코드는 고의성을 띠지 않는다. 대부분의 개발자는 힘들고, 중복 되며, 무의미한 코드를 의도적으로 작성하지 않는다 (간혹 좋은 코드에 시간을 투자하기보다 낮은 품질의 코드를 계속 사용하는 게으른 프로그래머가 없지는 않다).
-p63: 그래서 무엇을 해야 할까

내가 개발하는 과정 혹은 프로젝트가 오랜 시간 많은 사람들에 의해 유지보수 되면서 발생할 수 있는 각각의 상황에 대해 예시를 빗대어 해결법을 안내하고 있습니다. 다양한 내용들이 소개되었지만 파트 1에서 기억나는 내용 중 하나는 죽은 코드를 제거하는 일은 해롭지 않다. 라는 내용입니다.

물론 그냥 버리는 것은 아니고, 미래에 필요할지 모르는 기능이라도 코드를 제거하는 것이 안전하며 이는 버전관리시스템을 통해 언제든 복원이 가능하다는 것입니다.

파트 2: 연습을 통해 완벽해진다

프로그래밍 세계에 널리 알려진 이상한 가설 중에는 다음과 같은 것이 있다. “일단 어떤 코드 가 작성되면, 그것은 신성한 것이 된다. 절대 수정되어서는 안 된다.” 만약 다른 사람의 코드 일 경우는 그 신성함이 두 배가 되므로 감히 건들지 말라.
-p235

기존 정상적으로 동작되는 로직이 있다면 건들기가 조금은 무서워집니다. 시간이 지나 전반적인 흐름을 파악하기 어렵거나 특히 핵심적인 로직인 경우 잘못 건드렸다가는 엄청난 후폭풍(?)이 찾아올 수 있기에 예민하게 반응될 수 있습니다. 이에 대해 저자는 다음과 같이 말하고 있습니다.

코드란 절대로 불변 이어서 는 안 되며 , 그 어떤 코드 도 신성 시 되어서 는 안 된다. 어떠 한 코드 도 완벽 할 수는 없다. 코드 주변의 세상 은 끊임없이 변화한다. 코드 가 부지런히 세상의 요구 사항에 맞춰 나간다 해도 , 요구 사항 은 언제나 끊임없이 변화한다
-p236

저자는 리팩터링을 두려워하지 말고 자신감을 가지고 변경하라 이야기합니다. 물론 생각 없이 자신만의 생각으로 자유롭게 수정하는 이른바 '카우보이 코딩'은 금기하며 "잘 돌아가는 로직을 효율적으로 리팩터링함!"으로 올린 기능에 대해 "효율적으로 리팩터링함에 따라 발생된 이슈에 따라 기존 코드로 롤백함"과 같은 상황은 방지해야 한다 합니다.

사실 이는 너무나도 당연한 이야기입니다. 리팩토링을 통해 굳어있는 코드를 효율적으로, 효과적으로 변경하는 행위는 필요하지만 이를 통해 다른 이슈가 발생한다면 그것만큼 죄악인 일은 없지 않나 싶습니다. 이는 제가 이전에 작성했던 도서 리뷰글에도 동일한 생각으로 작성하였습니다.

개인적으로 리팩토링을 하는 행위는 새로운 기능을 만드는 행위보다 더 위험하다고 생각됩니다. 개발자의 관점에서는 더 직관적이고 효율적인 로직으로 바꿈으로써 일종의 이쁜 코드(?)로 바꾸는 행위이기에 완료하고 바뀐 코드를 볼 때 희열을 느낄 수 있습니다. 저도 리팩토링이 끝난 이후 코드를 보면 너무나 아름답다는 생각에 엄청난 희열을 느낄 때 가 있습니다.
/* 중략 */
물론 어디서든 펑펑 터지는 crash 혹은 잘못된 로직으로 큰 부하나 비용이 발생한다면 리팩토링이 시급할 수 있겠지만, 기존 정상적으로 동작되던 기능을 단순히 더 깔끔한 로직을 위해 리팩터링 하다 무결했던 기능까지 망쳐버린다면 그것만큼 큰 잘못은 없다고 생각합니다.

코틀린으로 마이그레이션을 원한다면, 자바에서 코틀린으로: 코틀린으로 리팩터링하기

저자도 리팩토링은 필요하지만 그것으로 인해 무결한 기능을 망쳐서는 안 된다. 이것은 마치 양날의 검과 같다고 설명하고 있습니다. 그래서 저자는 본 도서에서 가장 중요하게 언급하는 것이 리팩터링과 단위 테스트입니다. 단순히 이 파트의 리팩토링에 대해 이야기할 때에만 테스트를 이야기하는 것이 아닌, 각 파트 전반적으로 리팩터링과 단위 테스트의 중요성에 대해 목이 터져라(?) 언급하고 있습니다.

물론 테스트 코드를 작성할 수 없는 상황(너무 짧은 개발기간 등)이 있을 수 있고 만능은 아니라고 설명합니다. 다만 좋은 코드가 되기 위해서 시간 여유가 생긴다면 한 부분 씩이라도 테스트 코드를 작성하는 것을 권장하고 있습니다.

파트 3: 개인적인 일로 받아들이기

파트 3에서는 효율적인 코드를 작성하는 방법! 에 대해 설명하기보다는 프로그래머로써 어떤 식으로 성장하면 좋을지에 대해 설명합니다. 여기서 프로그래머로서 발전하고 싶다면 배움 그 자체에 숙련되고 노련 해져야 하며, 배움을 즐기는 법도 배워야 한다.(p309) 동일하고 지루한 코드를 줄줄 뽑아내는 '코딩 공장'에 갇히면 흥미가 떨어지고 배우는 것을 멈추게 될 것이다.(p332)라는 내용이 많은 공감이 갔습니다.

전 회사에서 어느 시점부터 기존 프로젝트를 비슷한 형태로 빠르게 변형하여 짧은 기일 내 출시해야 하는 과정이 여럿 생기다 보니 프로젝트에 애정을 갖고 개발할 수 있는 시간이 짧고 무언가 찍어내는 듯한 느낌이 들어 복합적으로 공장이 된 것 같다는 생각이 든 경험이 있습니다.

물론 이 과정에서 유사 프로젝트이기에 이전에 겪었던 구조적 문제를 반복하지 않도록 한번 더 생각하여 설계한다거나 새로운 기술을 활용하더라도 마이그레이션 해야 하는 부분이 크게 없었기에 큰 무리 없이 도입할 수 있어 이런 부분에선 빠른 성장을 할 수 있었지만 조금은 아쉬웠던 시기가 아닌가 싶습니다. (그렇기에 Jetpack Compose를 빠르게 도입할 수 있었던 이유 중 하나가 되지 않았을까...)

결과적으로 이 파트에서는 코드적인 부분이 아닌, 정말 프로그래머로서 성장하는 방법에 대해 고민하고 탐구할 수 있는 시간을 제공합니다. 외적으로 건강을 위해 자세와 눈에 대해서도 이야기하고 있는데...

집중하라. 30장에서의 충고를 적절히 받아들이지 않는다면 엄청난 의료 비용을 감당하게 될 수 있다. 언젠가는 필자에게 감사하게 될 것이다.
-p367: 프로그래머의 자세

자세가 중요하다는 것은 누구나 알고 있는 사실이지만 저의 경우 알고 있음에도 나쁜 자세를 통해 지난 4월 병원에 입원하여 병원비로 200만 원이 증발되었습니다.

정확하게 이틀 전부터 허리가 조금 안 좋은 것 같은데 라는 생각은 했지만 무시하고 지내다 3일 차가 되는 날 아침에 일어날 수가 없을 정도의 허리 통증으로 결국 2일간 입원하게 되었습니다. 의사 선생님께서 경과에 따라 최소 3일 입원해야 할 수 도 있다 말씀하셨는데 3일 차 되는 날이 상권님의 컨퍼런스에서 KMP를 주제로 발표하기로 하여 무조건 2일 아니면 입원 안 하겠다고 말씀드렸고 결국 행사 전날 퇴원하여 무사히 발표도 마치고 지금은 허리도 괜찮아졌습니다. (다만 퇴원 후 3주간 지속적인 통증으로 약과 함께 살았습니다.)

개발자는 허리가 생명이다!라고 다들 말하고 저도 그렇게 말하지만 실제로는 모두 자세가 좋지 않기에... 이 글을 읽으시는 분은 지금이라도 자세를 고쳐 앉으면 좋을 것 같습니다. 만약 이 책을 지난달 입원하기 전에 읽었다면 200만 원을 아낄 수 있지 않을까...

파트 4: 일 끝내기

본 파트에서는 10장 정도의 분량으로 효율적인 일에 대해 설명합니다. 여러 가지 내용이 있지만 와닿았던 부분은 NIH 증후군을 극복하자입니다. 다른 프로그래머의 코드를 사용하는 경우 꺼림칙하거나 조금 비효율적인 것 같은데 하며 다시 작성하는 경우가 종종 있습니다. 그렇지만 이미 작동한다면 다시 작성할 필요가 없으며, 만약 자신의 시스템에 통합해야 한다면 퍼사드 패턴 사용을 추천하고 있습니다.

또한 코드 외적으로도 생략 가능하고 효율적으로 다룰 수 있는 부분은 효율적으로 다루자고 하고 있는데, 필자의 실화 이야기로 모서리가 둥근 예쁜 화살표를 만들어야 했기에 처음에는 Graphics API로 그렸으나 이쁘지 않았고, 이미지로 만들자 생각하여 포토샵으로 한 시간 동안 만들었지만 이쁘지 않게 나와 포기하고 차를 타고 오니, 다른 동료가 10초 만에 우리가 모두가 알고 있는 오피스 프로그램으로 모서리가 둥근 예쁜 화살표 도형으로 이미지를 만들어줘 해당 이미지를 사용했다는 사례를 이야기하고 있습니다.

여기에 감명받은 저는 현재 진행하고 있는 개인 사이드 프로젝트에서 완벽을 위해 아이콘을 굳이 하나하나 찾아 넣고 있었는데, 그냥 아이콘 라이브러리를 임포트 해서 사용하였고 그 결과 매우 만족하고 있습니다 (굳)

이처럼 야매처럼 보일 수 있는 방법이라도 결과가 명확하고 효율적이라면 사용하자는 이야기를 담고 있는데, 어느 정도 타협한다면 보다 효율적으로 개발할 수 있지 않나 라는 생각이 들었습니다.

그리고 개인적으로 인상 깊었던 한 멘트가 있었습니다.

전통적 조언을 기억하라. 한 번 이상 반복 해야 하는 일이 있다면 , 그것을 수행하는 스크립트를 작성하라.
-p387: '더 열심히' 보다는 '더 현명하게'

파트 5: 사람의 일

마지막 파트는 프로그래머는 혼자 일하는 것이 아닌 함께 일한다는 것. 그리고 스스로 프로그래머로서 어떠한 방향을 걸어갈 것 인지에 대해 고찰하도록 하는 내용으로 마무리되고 있습니다.

각자 자기가 옳다며 팀원과 싸운다면, 같은 작업을 불필요하게 반복하거나 코드베이스에서 Conflict 폭탄을 맛볼 수 있으며, 더 나은 프로그래머가 되길 원한다면 납득할만한 개발 선언문을 지지하되 맹목적으로는 따르지 말자!라고 이야기 합니다.

아래는 필자의 선언문인데, 이를 통해 필자가 생각하는 더 나은 프로그래머가 되기 위한 정의가 무엇인지를 알 수 있는 대목이 아닌가 싶습니다.
• 코드에 신경 써라.
• 팀의 힘을 키워라.
• 간결함을 유지하라.
• 머리를 써라.
• 그 무엇도 고정된 것은 없다.
• 꾸준히 배워라.
• (주체가 자신이든, 팀이든, 코드든 간에) 나아질 방향을 꾸준히 모색하라.
• 언제나 가치를 전달하려 애쓰라. 길게 볼 수 있도록 해보라.

Appendix: 국내 개발자 8인의 이야기

부록에서는 국내 개발자 8명의 이야기를 2-3장 정도 분량으로 담고 있습니다. 앞의 파트 1~5의 내용도 좋았지만 부록에서도 많은 배움과 고민을 할 수 있었습니다.

몇 가지 기억에 남는 문구를 작성해 보자면

• 생성형 AI 시대
  • 프로그래머들이 테스트 주도 개발 (TDD)을 해야 한다.
  • 더 중요하게 생각해야 할 또 하나의 영역은 소프트웨어 아키텍처이다.
• 팀플레이어
  • 신형 노트북 구매를 요청할 때 본인뿐 아니라 팀을 챙기고 수치적 근거를 제시한다.
  • ‘배포 속도가 2분에서 1분으로 줄기 때문에 하루에 배포를 15번 한다고 하면 한 달에 300분을 아낄 수 있다’

이외에도 많은 공감 가거나 정말 새롭게 생각하게 되는, 그동안 가진 생각에서 살짝만 틀어서 생각한다면 더 효과적으로 효율적으로 개발자로서 성장할 수 있는 주옥같은 말이 많았습니다. 정말 2-3장 정도의 짧은 분량이지만 이 부록 내용 만으로도 많은 성장을 할 수 있을 한 문장 한 문장에 정말 깨달음을 얻은 것처럼 몸이 짜릿했습니다.

마지막으로 본 리뷰를 끝내기 전에 남기고 싶은 부록의 한 문장은 좋은 직함이나 회사보다 ‘내가 잘 할 수 있는 일’을 찾기 입니다.

개발자로 일했을 때, 저는 스스로 탑 0.1%의 락스타(Rock Star) 개발자는 아니라는 것을 일찌감치 깨달았습니다. 코딩 인터뷰 성적만으로 다른 경쟁자들을 제치고 들어갈 낭중지추감 역시 아니었습니다.
- 마이크로소프트, 주한나: 좋은 직함이나 회사보다 ‘내가 잘 할 수 있는 일’을 찾기

개인적으로 저는 초등학교 때 처음 프로그래밍을 접하면서 재미를 느꼈기에 같은 나이 대의 사람들보다 그저 조금 더 개발 경험이 많을 뿐 기술적으로 상위 n%에 들 수 있는 매우 뛰어난 사람이라고는 생각하지 않습니다. 항상 이제 조금 실력이 오른 것 같은데 생각하고 반년 뒤에 내가 짠 코드를 보면 이게 무슨...이라고 말하는 전형적인 평범한 개발자라고 생각합니다.

더욱이 중학교 때 창업한 경험을 바탕으로 언젠간 다시 창업을 꿈꾸고 있으며, 이를 위한 발판으로 사이드 프로젝트를 만들 때에는 그동안 읽은 스타트업 관련 도서에 따라 빠르게 MVP를 만들어 시장 검증 및 차근차근 업데이트하자 라는 생각을 하면서도 조금만 더 모듈을 분리하고 구조를 잡으면 이쁠 것 같은데 라는 생각이 충돌되는 아이러니한 상황을 가지고 있습니다.

지금도 출시를 위해 개발하고 있는 프로젝트의 경우에도 기본 기술 검증을 위한 테스트 데모앱은 3일 만에 끝낸 뒤 3개월이 지났지만, 더 좋은 코드가 무엇일까 고민하고 개발하다 보니 기능 추가가 아닌 코드 구조에 더 집중하고 있는 모습을 발견하였습니다. (물론 이 과정에서 MVI 디자인 패턴을 공부하여 적용할 수 있는 좋은 기회가 되었습니다.)

주한나 님의 이야기에 따르면 본인을 제한 AI팀 구성원 80%는 박사학위가 있다고 합니다. 본인보다 자격이 있는 사람은 최소 수만, 수십만 명이 있지만 본인은 지속적으로 다니면서 증명할 수 있었기에 AI팀에 합류할 수 있었다고 합니다. (사실 이미 마이크로스프트인 것부터가 실력이 뛰어나셨겠지만...)

이 과정에서 내가 가진 잘 할 수 있는 것에 대해 한번 더 고민하게 되었고, 내가 가진 아이디어를 빠르게 실행하여 결과물을 만들 수 있다는 것과 뛰어나지는 않지만 조금씩 항상 성장한다는 것. 이 2개가 내가 가진 잘 할 수 있는 일이라고 생각되었으며, 이 2개를 포기하지 않는 방법이 무엇일지 고민하여 내린 결론으로 창업을 위한 발판으로 준비하는 인디해커 프로젝트를 만들 땐 MVP 위주로, 오픈소스 프로젝트를 만들 때는 더 나은 프로그래머가 되기 위한 방향으로 만들어 두 가지 실력을 모두 키워보자 를 내리게 되었습니다.

무언가 도서 리뷰 마지막에 개인적인 이야기가 조금 길게 들어간 것 같지만, 그만큼 본 도서를 통해 개발자로서 좋은 코드를 작성하는 방법, 소통하는 방법, 성장하는 방향 등 더 나은 개발자가 되기 위해 많은 고민을 할 수 있는 길을 제시해 준 도서가 아닌가 싶습니다.

스타트업을 생각하고 있다면 - 린 스타트업 도서 리뷰

린 스타트업 - 린 캔버스 창시자가 전하는 설계, 검증, 성장 3단계 스타트업 가이드 I 스타벅스, 메타, 에어비앤비 등 린 캔버스 사례 수록, 10주년 기념, 전면 개정판 ㅣ 린 스타트업
애시 모리아 지음, 권혜정 옮김 / 한빛미디어 / 2023년 6월

이제 우리는 좋은 아이디어만 있다면 남녀노소 누구든 창업을 할 수 있습니다. 필요한 자료, 기술은 인터넷에 검색하거나 ChatGPT를 통해 도움 받으며 고도화 해나가거나 전문 업체를 통한 외주로 런칭할 수 있습니다. 이는 누구든 쉽고 빠르게 창업을 할 수 있다는 것이고 반대로 말하면 누구든 쉽고 빠르게 망할 수 있습니다.

이번에 리뷰할 도서는 린 캔버스를 통해 내가 가진 아이디어를 사업화할 수 있도록 정리 및 사람들을 고객으로 바꾸기 위한 스텝 그리고 더 나아가기 위한 설계 방향에 대해 담은 도서 린 스타트업을 리뷰해보겠습니다.

린 캔버스를 아시나요?

린 캔버스는 에릭 리스가 창안한 린 스타트업에 입각하여 애시 모리아가 비즈니스 모델 컨버스를 응용하여 만든 방법론으로 일종의 사업 시작 전 핵심 목표와 비즈니스 모델을 정리하는 프레임워크입니다.

도서를 읽으면서 단순히 한 페이지에 불과한 린 캔버스가 사업을 하기 위해 필요한 초기 정립에 많은 도움이 되겠다는 것을 느끼고 그제서야 고등학교 시절 스타트업 관련 행사나 캠프를 다니면서 만났던 방법론이라는 것을 깨닫고 좋은 도구가 있어도 사용자가 멍청하면 활용하지 못하는 게 아닌가... 라는 생각이 들었습니다.

계속 린 캔버스를 이야기하는 이유는 책의 핵심 내용이 린 스타트업 내용이기도 있지만, 바로 이 도서의 저자가 린 캔버스를 만든 애시 모리아이기 때문입니다.

린 캔버스 더 알아보기 - LEANSTACK

스타트업을 향한 스티브의 도전기

자신의 아이디어로 스타트업을 하고 싶은 스티브는 부푼 꿈을 안고 도전하지만, 18개월 뒤 유사 아이디어로 출시한 경쟁사의 등장으로 혼란에 빠진 주인공은 메리의 도움을 받아 맨 처음으로 돌아와 린 캔버스를 통해 핵심 목표 및 비즈니스 모델 정립을 시작으로 단계별 성장해나가는 이야기로 전개되고 있습니다.

처음 표지를 보고 딱딱한 내용으로 여러 방법론의 종류와 설명을 담고 있을 것이라 생각하였는데, 스티브의 이야기를 보며 '내가 스타트업을 시작했다면 책에 나온 여러 같은 실수들을 하지 않았을까?' 라는 공감과 함께 step by step으로 성장하는 모습을 보며 응원하게 되었습니다.

"기업가는 대부분 이미 염두에 둔 솔루션이 있어서 무작성 엎을 순 없으니까요. 그래서 내 고객 이 겪고 있는 가장 중요한 문제' 가 아니라 '내 솔루션 을 통해 해결할 수 있는 가장 중요한 문제'가 무엇 일지 고민 하는 경우가 많아요."
- p268. 주인공 스티브를 향한 메리의 조언

단순히 가이드만을 담은 도서였다면 각 가이드에 대해 흥미를 느낄지언정 큰 공감을 하지 못했을 것 같습니다. 그러나 주인공이 실수하고 놓친 부분들을 각 방법론이 가진 특징을 활용하여 대처, 활용하는 방법들을 보며 실제로 큰 도움을 준다는 것들과 응용할 수 있겠다 느꼈습니다.

기업 사례들

"그래서 기존 자동차의 라이선스를 사고 그 안에 테슬라의 배터리를 넣어서 이미 방법이 알려진 작업 대부분을 건너뛰고 방법이 알려지지 않은 작업을 우선시했네요. 자동차 엔지니어를 고용하거나 큰 공장을 지을 필요 없이 전기 배터리 개발에 집중하고, 그걸 기존 차량에 꽂아서 판매할 수 있었어요. 제가 단순화시켜서 말하고 있는 건 알지만 정말 천재적이네요."
- p181. 오즈의 마법사 MVP를 활용한 테슬라 사례를 들은 주인공

또한 오즈의 마법사 MVP, 마피아 제안을 활용한 일론 머스크의 테슬라 사례, 마피아 제안을 활용한 스티브 잡스의 아이패드 사례 등 실제 사례들을 이야기 함으로써 누구나 알고 있는 네임드 기업들 역시 똑똑하면서도 교묘하게 활용하고 있다는 생각과 정말 다양한 방면으로 사용 가능하다는 것에 한번 더 놀랐습니다.

이외에도 스타벅스, 메타 등을 기반으로 린 캔버스를 만들어본다거나 스타워즈를 삼아 피치 스토리를 만들어 보여주는 등 각 기업들이 방법론을 활용하였을 때의 모습을 보여줌으로써 보다 쉽게 이해하는데 많은 도움이 되었습니다.

여러 조언

아래의 조언 외에도 각 챕터별로 많은 조언들을 담고 있는데, 조언 하나하나가 많은 공감이 되면서도 새롭게 생각하게 되는 좋은 기회가 되었습니다.

망치를 개발하기로 한번 마음을 먹으면 세상 모든 것이 못으로 보인다.
- p104. 혁신가의 편견이라는 걸림돌

잘못된 모델을 붙잡고 5개월을 허비하는 것보단, 5분을 투자해서 틀린 모델을 걸러내는 편이 훨씬 낫다.
- p146. 비즈니스 모델 조언 중

모든 팀 은 피자 2판으로 배를 채울 수 있을 만큼 작아야 한다.
- p230. 제프 베조스 , 아마존 창업자

문제 정의만 잘해도 반은 해결된다.
- p262. 미국의 두 번째 발명왕, 찰스 케터링

진통제를 내미는 가장 좋은 시점은 고객이 아플 때이다.
- p326. 이상적인 선각수용자 파악 관련 조언 중

이 도서도 방법론을 활용하였습니다.

예를 들어 필자는 2010년에 이 책의 초판(자가 출판)을 내기 위해 마피아 제안 캠페인을 이용했다. 초기 MSC 목표는 3년 안에 1만 부를 판매하는 것이었다. 10배 성장률을 사용하여 책 백 부를 판매하거나, 책 구매에 관심 있는 사람(적격 잠재 고객) 천 명의 이메일 주소를 확보하는 것을 문제/솔루션 적합성 달성이라고 해석했다.
- p265. 애시 모리아의 전략

인상 깊었던 것 중 하나는 필자는 이 도서를 처음 출판하기 위해 MSC 목표 산정 및 마피아 제안을 통해 어떤 식으로 프로젝트를 진행하였는지 가볍게 설명하고 있는데, 긴 내용은 아니지만 어떤 식으로 캠페인을 활용하여 정말 독자가 원하는 책이 무엇인지 분석하고 집필하는 과정을 설명하는데, 정말 다양한 분야에서 활용이 되면서도 필자(애시 모리아)가 단순 제시만 하는 것이 아닌 실제로도 활용한다는 사실이 인상 깊었습니다.

아래 사람들에게 추천합니다.

만약 본인이 스타트업에 관심이 있다면 정말 적극 추천합니다. 혹은 스타트업까지는 아니더라도 상업적이나 사용자를 위한 사이드 프로젝트를 진행할 계획이신 경우에도 초기 계획을 수립하는데 많은 도움이되실 수 있을 것이라 생각됩니다.

이상 애시 모리아의 말을 인용하며 리뷰 글을 마치도록 하겠습니다.
감사합니다.

" 아무도 원치 않는 제품이나 만들면서 살기에는 인생이 너무 짧다."
- 애시 모리아

위키피디아(나무위키)를 믿을 수 있을까? 랜선 사회 도서 리뷰

랜선 사회 - 온라인 커뮤니티에서는 어떤 일이 일어나는가
에이미 S. 브루크먼 지음, 석혜미 옮김 / 한빛미디어 / 2023년 5월

이제 우리는 개인 컴퓨터를 넘어 스마트폰을 통해 언제 어디서든 인터넷에 접속할 수 있고 그곳에서 자신이 관심 있는 커뮤니티 속에서 이야기를 나눌 수 있습니다. 또한 과거에 새로운 지식이나 사건을 찾기 위해 백과사전을 찾았다면 이제는 위키피디아 혹은 나무위키를 통해 쉽게 정보를 찾을 수 있습니다.

그렇다면 해당 위키피디아(나무위키) 및 온라인 커뮤니티의 정보의 내용은 과연 믿을 수 있을까요? 모든 사람들이 자유롭게 자신이 알고 있는 지식을 공유하기에 보다 풍부한 정보가 담길 수 있겠지만, 모든 사람이 수정 가능하기에 실수 혹은 의도적으로 잘못된 정보를 기입될 수 있습니다.

이런 온라인 커뮤니티는 과연 진짜 공동체일까요? 그렇다면 잘못거나 한쪽으로 치우친 정보를 피해 활동하는 방법은 무엇일까요? 이러한 주제를 바탕으로 온라인 커뮤니티의 이야기를 담은 책, "랜선 사회"에 대해 리뷰를 남겨봅니다.

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

제3의 장소와 가상 공간

사람들은 자신과 사회적 계급이 가장 비슷한 사람들 중에서 동료, 친구, 동반자를 선택하는 경향이 있다. 그러나 제3의 장소는 그 가능성을 확장하는 기능을 한다… 제3의 장소에서는 사회적 지위보다 성격의 매력과 색깔이 중요하다

- p37 올든버그

올든버그는 제3의 장소가 모든 사람을 평등하게 한다고 강조 및 단골이 해당 장소의 꽃이라고 이야기합니다.
가장 따뜻하게 환대받는 사람은 돌아온 단골, 일반 단골, 새로운 사람을 데려온 단골 그리고 함께 온 새로운 사람 순으로 환대를 받는다고 하는데 이때 혼자 온 새로운 사람이 집단에 받아들여지는 속도가 가장 느리다고 합니다.

그렇다면 이런 실제 세상 속 제3의 공간과 가상공간(온라인 커뮤니티)의 가장 유사한 점은 무엇일까요? 바로 단골에 해당하는 '고인물'입니다. 커뮤니티에서 이야기하는 사람의 대부분은 고인물이며 일부 사람들만이 이야기에 참여하거나 그외 대부분 눈팅을 합니다. 그렇기에 커뮤니티 구성원은 고인물의 행동을 관찰하고 어떻게 행동해야할지를 배우기에 커뮤니티의 문화는 일종의 고인물이 만들어내는 행동이자 문화이며, 이는 실제 세상에서 새로운 장소에 방문하였을 때 기존 단골 손님들의 행동을 보고 따라하는 새로운 사람들의 모습과 유사하다고 안내합니다.

실제 세상의 공간과 유사한 가상 공간

이 부분에 대해 크게 공감한 것은 활동을 많이하는 구성원, 즉 고인물이 해당 커뮤니티의 큰 영향을 미친다는 것 입니다. 초등학교 시절 가입한 Crazy GameMaker라는 커뮤니티는 하루에 수십건이 넘는 개발 질문, 개발 상황 공유, 정보 공유 등이 이루어지고 있었습니다. 가입한 이후 게시글을 작성하거나 댓글을 달 때 다른 사람들이 작성한 양식을 많이 참고 하였던 기억이 납니다. 커뮤니티 규칙이 위반되지 않더라도 일반적인 문화에 어긋난다면 다른 구성원이 먼저 조심스럽게 지적을 하거나 가이드라인을 제시하기도 하였습니다.

이처럼 새로운 커뮤니티에 들어가게 된다면 가장 먼저 기존 고인물의 스타일을 참고하게 되는 것은 실제 세상에서 동아리 같은 새로운 장소에 들어가게 된다면 혹여나 피해를 끼치지 않게 독자적으로 활동하는 것이 아닌 기존 구성원, 그 중에서도 많이 활동하는 구성원(단골)의 행동을 보고 따라하는 것과 유사하다 느꼈습니다.

책에서도 커뮤니티의 리더가 전형적인 구성원으로 비칠수록 의도적으로 특정한 행동 양식을 취해 다른 회원들에게 영향을 미치고 집단의 규범을 형성하는 데 기여하는 능력이 커진다 라고 이야기하며 이 부분이 온라인 커뮤니티 설계의 핵심 원칙이라 안내하고 있습니다.

즉 이러한 이야기를 종합적으로 보았을 때, 온라인 커뮤니티는 현실 세계의 공동체를 이은 또 다른 가상 속 공동체라 생각됩니다.

온라인 협업으로 무엇을 성취할 수 있을까?

갤럭시 주 사이트는 2008년 온라인에 공개됐고, 3주 만에 자원봉사자 15만 명이 사진 5,000만 장을 분류했다. 자원봉사자들이 기존 데이터의 이미지를 모두 분류해버리는 바람에 프로젝트가 일시 중단되는 일까지 있었다. 이후에 새로 등록된 데이터는 심지어 더 빨리 처리됐다. - p59

지금은 딥러닝과 같은 A.I 기술을 통해 자료 분석 및 통계를 내기가 쉽지만 과거에는 컴퓨터로 분류 하기에는 한계가 있었습니다. 옥스퍼드 대학원생 케빈 쇼빈스키는 박사 논문에 사용하기 위해 대량의 분류된 은하계 이미지가 필요하였고, 자원봉사자들의 도움을 받기 위해 갤럭시 주라는 온라인 사이트를 만들어 도움을 요청하였습니다. 그렇게 시작된 프로젝트는 위의 내용처럼 수천만장의 사진을 시작한지 얼마 지나지 않아 모두 분류 해버렸습니다.

이러한 정보는 믿을 수 있을까?

그렇다면 이렇게 분류된 사진들 즉 시민 과학 프로젝트는 과연 신뢰할 수 있는 정보일까요? 어떤 사진을 보고 한 사람만이 나선형 은하라고 분류한다면 틀릴 수 있겠지만 수십 명이 나선형 은하라고 말한다면 신뢰도는 높아질 것 입니다. 이러한 신뢰도를 얻기 위해서는 검증된 자료를 여러 사람이 처리하게 하여 원하는 수준의 신뢰도를 얻기 위해서 몇 명이 평가를 해야하는지를 얻을 수 있고 이를 통해 데이터의 신뢰도를 평가할 수 있습니다.

만약 6명이 평가하면 정확도가 80%, 15명이 평가하면 99%라고 가정 하였을 때, 99%가 충분하다면 16명 평가 없이 15명으로 평가를 진행하면 됩니다.

이렇게 자원봉사자들의 모여서 내린 판단은 97.9%의 정확도를 보인 반면, 전문가 한명은 96.6%의 정확도를 보이며 이는 전문가도 실수를 할 수 있으며 여러명의 검증이 더 정확할 수 있다는 이야기를 첨언하고 있습니다.
# A generalized approach for producing, quantifying, and validating citizen science data from wildlife images

이처럼 여러명이 참여하는 작업일 수 록 신뢰도는 증가한다는 것을 알 수 있습니다. 그렇다면 우리가 궁금할 내용 '위키피디아(나무위키)는 과연 믿을 수 있을까요?

그렇다면 위키피디아(나무위키)는 믿을 수 있을까?

위의 내용을 읽었다면 간단하게 추측할 수 있습니다. 수백 명이 편집하는 문서는 가장 많이 검토된 최신 정보라고 볼 수 있습니다.

지식의 사회적 구성이라는 관점에서 더 많은 사람이 검토할수록 신뢰도가 높아진다. 수백 명이 계속해서 업데이트한 위키피디아의 인기 문서는 역사상 가장 많이 검토된 최신 정보라고도 볼 수 있다. - p101

같은 문서를 지속적으로 관찰하고 편집하기에 검토의 검토를 얹게 됩니다. 이 과정에서 악의적인 사람이 문서를 훼손하거나 거짓된 정보를 기입하는 경우가 발생할 수 있겠지만 이 경우에도 여러 사람들의 관찰과 추가적인 검토를 통해 어느 정도 신뢰 있는 문서를 만들어낼 수 있습니다.

위키피디아의 경우, 인기 문서는 깜짝 놀랄 정도로 수준이 높다(3장 참고). 백신이나 기후 변화 등 논쟁적인 주제에 관한 문서는 전쟁터가 돼 정보와 오정보가 뒤섞일 것이라고 생각하기 쉽지만, 이 경우 전문 편집자들이 문서의 정확도를 유지하고 오정보를 삭제한다. 물론 전문 편집자들은 동료 평가를 거친 과학적 연구 결과를 신뢰하고 기준으로 삼는다. 이러한 문서는 많은 사람들이 지켜보고 있기 때문에 문제없이 유지된다. - p119

하지만 악의적인 트롤(도서 내 고의적으로 훼손하려는 사람을 지칭하고 있음) 수십 명이 지속적으로 거짓된 정보를 기입한다거나 인기 없는 문서의 경우에는 충분한 검토가 이루어지지 않기에 신뢰도가 떨어지게 될 것 입니다.

일부 기여자가 고의로 최종 결과물을 손상시키려고 노력하는 경우다(나는 일을 시작하고 첫 20년 동안은 인터넷에 있는 사람 대부분이 진정으로 서로 돕고 싶어 한다고 믿었다. 앞으로 20년은 순진했던 나 자신을 비웃으며 보내려고 한다!) - p125

그렇기에 결국 도서에서도 최종적으로 이야기하는 내용은 다음과 같습니다.

‘위키피디아를 믿을 수 있는가’라는 단순한 질문에 대답하려면 놀랍게도 상당한 철학적 사고가 필요하다.

최종적으로 도서의 결에서 문서의 인기도에 따라 다르다 라고 표현 하였지만 결국 저자 역시 수많은 사람들이 편집한 문서는 다른 문서에 비해 신뢰도가 높겠지만 이를 확신할 수는 없다라는 이야기를 내포하고 있다 생각됩니다. 이에 대해 수많은 익명의 사람들이 정보를 공유하는 과정에서 발생할 수 밖에 없는 이슈라고 생각하고 감내하고 참고를 해야하며 인용 시 관련 논문과 같은 추가적인 서치가 필요하다 생각됩니다.

그리고 이러한 생각에 덧붙여 도서에서는 거짓 인용의 고리를 이야기 하는데, 결국 정보를 인용을 할 때에는 많은 고려를 해야된다 생각이 들었습니다.

가끔 거짓 인용의 고리, 이른바 무근본 출처 생성 사태가 발생하는데 과정은 다음과 같다. 먼저, 누군가가 위키피디아에 출처가 없는 내용을 등록한다. 그리고 다른 누군가가 이 내용을 기사로 쓰면서 위키피디아를 출처로 언급하지 않는다. 위키피디아 편집자가 인용을 보완해 페이지 내용을 개선하기 위해서 검색하다가 그 기사를 찾아내서 인용한다! 사실은 근거가 전혀 없는데도 출처가 생성됐다 - p102

극단적인 관점이 만들어내는 '에코 체임버' 현상

여러 명의 검토를 통해 신뢰도를 높일 수 있다면 커뮤니티에서의 정보도 지속적으로 검토된다면 믿을 수 있는 정보 일까요? 이와 관련하여 에코 체임버 현상에 대해 소개하고 있습니다.

극단적인 관점을 가진 자발적인 심사자 집단이 서로의 신념을 강화하면 어떤 일이 일어날까? 이것이 바로 에코 체임버(echo chamber) 현상이다.

에코 체임버 그 자체로는 나쁜 것이 아니며 오히려 이를 통해 같은 주제를 가진 사람들끼리 모여 새로운 채널을 만들어내거나 관리되는 커뮤니티를 만들 수 있습니다.

관리자가 있는 ‘사회과학-페미니즘’ 그룹은 초창기 온라인 에코 체임버였다. 페미니즘의 원칙에 동의하는 사람끼리 사려 깊고 예의 바르게 논의하기에 완벽한 장소였다. 관리자가 없는 ‘기타-페미니즘’ 그룹에서 이런 논의는 불가능했다. 에코 체임버는 종종 귀중하고 필요하다. - p122

그러나 장점만 있는 것이 아닌 단점 역시 존재하는데, 바로 기본적으로 본인들이 생각, 공감하는 전제에 대해서는 비난을 하지 못하는 문제가 있습니다. 책에서 예시로 드는 내용 중 하나로, 과연 '사회과학-페미니즘' 채널에서 남녀 간 임금 차이를 계산하는 것에 대해 의문을 품고 이야기를 하면 환영받지 못할 것입니다.

에코 체임버 안에 있는 사람들은 특정한 세계관 안에서 나아갈 수 있는 안전한 공간을 확보하는 한편, 이 세계관을 비판하는 세력에는 노출되지 않는다. 기본 전제에 대한 공격을 차단한 상태인데, 어떤 면에서는 그래서 생산적일 수 있다. 근본적인 원칙을 계속 방어해야 한다면 대화가 진전되지 않을 테니 말이다. 한편 타당한 비판도 접할 수 없게 된다. 에코 체임버에 있는 사람들이 합당한 이의까지도 전혀 고려하지 않는 경향은 오늘날 인터넷의 핵심 문제다. - p123

이 내용을 읽고 에코 체임버 현상이 오늘날 일부 극단적인 사이트들을 만들어낸게 아닐까 싶었습니다. 본인들의 생각하는 주체, 사상에 대해서 성역을 지정하고 이를 비판하는 순간 척결의 대상(?)으로 받아들이는게 아닐까... 라는 생각이 들었습니다.

마치면서

이외에도 도서에서는 다양한 이야기를 담고 있습니다.

일반적으로 실패하는 OSS 프로젝트(레이먼드)를 성공하기 위한 방법이라던지

온라인 협업 프로젝트를 조직하려면 새로운 참여자를 영입하는 법(최초 동기의 설계)과 구성원이 지속적으로 기여하도록 장려하는 법(지속적인 참여를 위한 설계)을 둘 다 고려해야 한다

이러한 커뮤니티를 운영하는 경우 고려, 참고하자는 이야기

광고 실적에 대한 욕구가 전체 시스템 설계의 중심이 된다면 고객이자 시민인 사람들에게 나쁜 결과를 가져온다. 이러한 딜레마의 해결책 중 하나는 기업이 기업의 가치를 문장으로 표현하고 우선순위를 매기는 것이다.

그리고 정보의 편차에 대한 이야기

가난한 사람들은 콘텐츠를 필터링하는 자동 프로그램을 사용하고, 수천 명이 같은 필터를 쓴다. 반면 부자들은 자신의 기호와 관심 분야를 파악해 맞춤형 정보를 제공하는 인간 편집자를 고용한다. 결국 경제력을 가진 사람이 더 나은 정보에 접근한다.

결론적으로 저자가 이 도서를 통해 의미하고자 하는 내용은 단순히 온라인 커뮤니티에 대한 이야기를 넘어 이제 일상이된 인터넷 속 가상의 세계가 인류에게 있어 이로운 영향을 끼치기 위해서 사업자 역시 단순히 이윤만을 바라보는 것이 아닌 이롭게 발전시킬 수 있도록 노력해야한다는 것. 그리고 그 방법 중 하나는 미래의 인터넷은 비영리 방향으로 비영리 비즈니스 모델과 세계관을 바탕으로 움직이는 것을 희망한다는 것 입니다.

'진실'이 부자의 특권이 될까 우려된다

앞으로도 우리는 가상의 공동체, 즉 온라인 커뮤니티를 통해 새로운 지식을 배우고 성장하고 소통하며 살아갈 것 입니다. 잘못된 정보를 배우거나 편협적인 사고를 가지지 않도록 절제할 수 있는 이용자가 되어야하며 사업자, 운영자의 경우에는 이로운 방향으로 흘러갈 수 있도록 노력을 기해야되지 않을까 라는 생각으로 글을 마쳐봅니다.

코틀린으로 마이그레이션을 원한다면, 자바에서 코틀린으로: 코틀린으로 리팩터링하기

자바에서 코틀린으로 - 코틀린으로 리팩터링하기
덩컨 맥그레거.냇 프라이스 지음, 오현석 옮김 / 한빛미디어 / 2022년 11월

최근 자바 개발에서 코틀린으로 넘어오시는 분들을 많이 볼 수 있습니다. 저 역시도 19년 첫 회사에 취업하여 자바로 안드로이드를 개발하다 20년부터는 코틀린으로 개발을 시작하였습니다.

이 글을 읽는 여러분들은 자바에서 코틀린으로 마이그레이션을 고민 중 이시거나 혹은 코틀린에 대한 공부를 원하시는 분들이라 생각됩니다. 그런 분들을 위한 도서. 자바에서 코틀린으로: 코틀린으로 리팩터링하기 도서를 읽고 리뷰를 해보도록 하겠습니다.

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

시작하기 앞서

코틀린은 먼 미래가 아닙니다.

코틀린은 Stack Overflow 2022 survey 기준으로 가장 인기 있는 언어(Most popuplar technogoies) 15위, 가장 사랑/원하는 언어(Most loved, dreaded, and wanted) 11위를 기록하고 있습니다.

또한 2017년 구글에서 정식 언어로 채택하였으며, 안드로이드의 경우 Google I/O 2019에서 Kotlin-first 를 발표하였습니다.

Kotlin-first는 Jetpack 라이브러리, 샘플, 문서, 교육 컨텐츠와 같은 새로운 Android 개발 도구와 콘텐츠를 빌드할 때 Kotlin을 우선으로 디자인함을 의미하며, 자바에서도 사용할 수 있게 지원을 제공합니다.

단적인 예시로 이전에는 안드로이드 개발자 공식 문서에서 자바로 예시 소스코드를 설명하였지만 Kotlin-first 이후로는 코틀린을 기본 소스코드로 설명하고 있습니다.

코틀린을 경험하면 돌아갈 수 없습니다.

물론 사람들마다 선호하는 언어가 다르기에 코틀린을 경험하더라도 자바가 편하다고 생각하시는 분들도 있다고 생각됩니다. 하지만 필자는 물론 회사 내 백엔드 개발자분들이나 지인들 모두, 일명 코프링(코틀린 + 스프링)을 경험하고 나면 다시 자바로 돌아가 개발할 때에도 코프링 생각이 계속 난다고 할 정도로 동일한 의견을 내고 있습니다.

도서 내용

진행 방식

본 도서는 트래블레이터(Travelator)라는 국제여행을 계획하고 예약을 도와주는 가상의 애플리케이션을 기반으로 작성된 자바 소스코드 기능 하나하나 코틀린으로 리팩터링 하는 방식으로 진행되고 있습니다.

또한 단번에 변환하고 끝내는 것이 아닌, 1차적인 변환을 마친 후 아쉬운 점 및 문제없이 완료된 것 같지만 실제 프로덕트로 배포 시 발생하는 상황을 보여주며 2차, 3차 다시 리팩토링을 하면서 자바 코드를 코틀린스러운 코드로 변환하는 과정을 보여줍니다.

한 예시로 실제 경험담을 상황으로 구성하여 발생할 수 있는 문제점과 이를 해결한 방안을 함께 포함하여 설명합니다.

덩컨과 냇은 2015년 연말 연휴가 끝난 후 업무로 복귀했고, 이전에 통과하던 단위 테스트가 실패한다는 사실을 발견했다. 이유는 2015-01-01T00:00:00라는 시간을 항상 미래일 것으로 생각하고 사용했기 때문이었다. 2015년이 되자 이 시간에 대한 이전이나 이후 관계에 의존하는 모든 테스트가 실패하기 시작했다. 덩컨과 냇은 이 책에서 설명한 리팩터링을 사용해 문제가 되던 테스트를 수정했다.

- 2015년은 시간의 끝이었다

테스트 중점

개인적으로 리팩토링을 하는 행위는 새로운 기능을 만드는 행위보다 더 위험하다고 생각됩니다. 개발자의 관점에서는 더 직관적이고 효율적인 로직으로 바꿈으로써 일종의 이쁜 코드(?)로 바꾸는 행위이기에 완료하고 바뀐 코드를 볼 때 희열을 느낄 수 있습니다. 저도 리팩토링이 끝난 이후 코드를 보면 너무나 아름답다는 생각에 엄청난 희열을 느낄 때 가 있습니다.

그러나 이것은 개발자의 관점일 뿐, 리팩토링 자체는 사용자 관점에서는 전혀 관련이 없습니다. 기존보다 성능이 향상되거나 crash 빈도를 줄임으로써 사용자에게 영향을 주기는 하겠지만, 요즘 디바이스의 성능은 과거에 비하면 상향평준화되었기에 성능이 2배-3배 상승하더라도 정말 n초 이상 걸리는 계산 로직을 제외하면 느끼기가 어렵습니다. 또한 crash 발생 비율이 줄었다 하더라도 '요즘 오류가 안나는 것 같네' 정도로 넘어갈 것입니다.

그렇기에 본 도서에서는 마틴 파울러의 말을 인용하면서 리팩토링 과정에서의 모든 기능들은 테스트 코드와 함께 작성을 하고 있습니다.

리팩터링을 하고 싶다면, 필수 전제조건은 탄탄한 테스트가 있어야 한다.
- 마틴 파울러

단순히 기능 로직을 자바에서 코틀린으로 리팩터링 하는 뿐만 아닌 테스트 코드도 자바에서 코틀린으로 작성하는 방법도 함께 설명하고 있습니다.

효율적인, 안전한, 더 나은 로직과 설계

각 챕터에서는 A코드를 B코드로 변경하였습니다로 끝나는 것이 아닌 변환하는 과정에서 효율적이고, 안전하고, 더 나은 로직과 설계를 위한 설명을 첨부하고 있습니다. 기초적인 내용부터 깊게 생각해 보았을 때의 내용 모두를 담고 있기에 외적으로도 배울 수 있는 여러 내용이 담겨있습니다.

한 예시로 챕터 7의 내용 중 '클라이언트 앱에서 고객의 현재 여행 정보를 받아오는 기능'을 자바에서 코틀린 코드로 리팩토링을 하는 부분이 있는데, 이때 동작과 계산에 대한 부분을 집중적으로 설명하고 있습니다.

계산이라는 행위와 동작이라는 행위는 결국 함수를 통해 구현되기에 결과가 같아 보일지언정, 동작이라는 행위가 들어간다면 리팩토링으로 인해서 각 동작이 호출되는 시점이나 호출 여부가 달라질 수 있기에 발생할 수 있는 문제점과 이를 해결하는 방법을 설명하고 계산과 동작에 대한 행위를 한번 더 생각해 보는, 그리고 어떻게 설계하는 것이 좋은지에 대한 내용이 담겨있습니다.

여러 가지 팁

챕터 중간중간에는 단순 Additional 한 내용 외에도 생각을 전환하고 발전에 도움을 주는 여러 팁들이 존재합니다. 다음은 챕터 9의 TIP 중 하나입니다.

단일식 함수를 계산에만 사용하라 우리가 단일식 함수를 계산(7.2절 ‘계산’을 보라)에만 사용하는 관습을 택한다면, 단일식 함수를 사용하는 의도를 다른 사람들에게 알릴 수 있는 수단이 생긴다. 단일식 함수를 보면 그 함수가 동작(7.3절 ‘동작’을 보라)이 아님을 알 수 있으므로 해당 함수를 더 안전하게 리팩터링 할 수 있다. 실질적으로 이 말은 단일식 함수가 Unit을 반환하거나 가변 상태를 읽거나 쓰지 말아야 한다는 뜻이다. 가변 상태를 읽거나 쓰는 것에는 I/O를 수행하는 행위도 포함된다.

- 단일식 함수를 계산에만 사용하라

저는 그동안 한 줄로 표현이 가능한 동작 역시 단일식 함수로 표현하는 경우가 있었습니다. 그러나 저자의 팀에서는 단필식 형태를 계산에만 제한하여 사용하였고 그에 대한 이유도 함께 풀이하고 있는데, 읽어보니 납득이 되며 앞으로의 개발에도 반영한다면 직관적이며 차후 자바에서 코틀린이 아니더라도 코틀린 로직을 리팩토링 할 때 에도 도움이 되겠다는 생각이 들었습니다.

이처럼 여러 팁을 통해 새로운 깨달음을 얻을 수 있었던 것 같습니다.

도서 평가

본 도서는 '자바 코드가 이렇게 코틀린 코드로 바뀌었습니다.' 하고 끝나는 것이 아닌, 기존 내장 함수들에 대한 원리와 리팩토링 과정에서 고려해야 하는 점, 개선할 수 있는 점 하나하나 단계별로 설명을 하고 있습니다.

그렇기에 현업 자바 개발자라면 코틀린을 경험하지 않았더라도 큰 어려움 없이 읽을 수 있겠지만 아직 개발 지식이 부족하거나 프로젝트 개발 경험이 적다면 각 함수가 가지고 있는 특징, 설계 방식 등에 대해 단순히 리팩토링 외적으로도 많은 생각을 하면서 읽어야 하는 어려움이 있을 것으로 보입니다.

다만 이 책을 모두 읽고 난다면, 고민하고 생각한 만큼 성장할 수 있을 것이라 생각되며, 이미 코틀린으로 개발하고 있는 개발자라 하더라도 조금 더 코틀린스러운 코드와 리팩토링을 고려할 수 있는 로직, 그리고 몰랐던 코틀린의 특징들도 배울 수 있을 것이라 생각됩니다.

마치면서

코틀린을 사용한 지 어느덧 3년이 지났기에 완벽하지는 않지만 코틀린에 대한 기본 이해도는 충분하였기에 단순히 마이그레이션 할 때에만 도움이 될 것이라 생각하였지만, 이 책을 읽으면서 자바에서 코틀린으로 넘어가는 과정에서의 기본 원리, 코틀린이 지향하는 방향, 더 나은 설계에 대해 많은 고민과 생각을 하면서 읽기 전과 후로 조금 더 성장할 수 있었던 것 같습니다.

자바 및 기타 언어를 사용하다 코틀린으로 마이그레이션을 고려하고 계시는 분이라면 본 도서를 적극 추천드립니다.

책의 제목에서도 알 수 있듯이 자바나 기본 개발 지식이 부족한 상태에서 본 도서를 읽는다면 고민과 생각을 깊게 해야 할 수 있기에 어려움을 느끼실 수 있지만, 만약 이겨내고 완독을 하신다면 오히려 더 높은 성장을 할 수 있을 것이라 생각됩니다.

[도서 리뷰] UX/UI 디자이너를 위한 실무 피그마

UX/UI 디자이너를 위한 실무 피그마 - 디자인 시스템에서 개발 전달까지, 개정판
클레어 정 지음 / 한빛미디어 / 2022년 11월

ㅍ

서론

피그마는 굉장히 핫한 UI/UX 디자인 도구로 사람들에게 사랑받고 있으며 최근 Adobe에서 200억달러(한화 28조원)에 인수를 하기로 하면서 큰 화제를 이끌기도 하였습니다.

이러한 피그마가 무엇인지, 그리고 어떻게 다루는지 담은 도서, ‘UX/UI 디자이너를 위한 실무 피그마(개정판)’을 리뷰 해보도록 하겠습니다.

본 리뷰는 한빛 미디어의 ‘나는 리뷰어다’를 통해 받은 도서입니다.

피그마란

피그마는 웹 기반 UI/UX 디자인 소프트웨어로 기존 UI/UX 디자인으로 유명한 Sktech와 다르게 모든 플랫폼에서 이용할 수 있다는 장점과 함께 2021년 기준, Sketch/Adobe XD/Adobe Illustrator/Adobe Photoshop을 제치고 넘볼 수 없는 압도적인 1위를 차지하고 있습니다.

또한 기본적으로 무료 소프트웨어 이기에 학생들도 부담없이 사용이 가능합니다. 어느정도 기능의 제한은 있지만 핵심 기능들 보다는 대부분 협업과 관련된 기능 이기에 "팀으로 협업을 할꺼면 유료로 사용해보는 것이 어때?" 정도로 생각하시면 편할 것 같습니다.

기존 Adobe XD도 무료 정책을 유지하다 어느순간부터 유료 정책으로 변경되어 더 이상 무료로 이용이 불가능 하기에, 당분간 피그마의 독주를 막기 힘들지 않을까 생각됩니다.

책의 구성 요소

본 도서는 크게 파트1과 파트2, 그리고 Appendix로 분류됩니다.
이를 통해 피그마에 대한 기본적인 지식 보유 여부에 따라 파트1부터 시작할지, 혹은 2부터 시작할지를 선택할 수 있습니다.

파트1. 피그마 활용하기

파트1에서는 피그마에 대한 전반적인 기능들에 대해 학습합니다.
마치 포토샵에서 도형을 그리는 방법, 레이어를 분리하고 합치는 방법, 각 도구들을 활용하는 방법 등을 배운다고 생각하면 좋을 것 같습니다.

파트2. 피그마로 디자인하기

파트2에서 부터는 본격적인 피그마를 활용한 디자인을 하는 방법에 대해 학습을 시작합니다.
iOS 뉴스앱, 안드로이드 스포츠 클래스앱, 글로벌 NFT 마켓앱 디자인 등 실습 파일을 통해 직접 만드는 과정을 따라 배울 수 있습니다.

Appendix

Appendix 파트에서는 디자인한 작업물을 개발자와 공유 시 유의할 점과 디자인 소스를 관리하는 방법에 대한 내용을 팁처럼 풀어내고 있습니다. 또한 핵심 단축키들에 대한 내용을 시트로 정리하였기에 빠르게 단축키를 학습하고 싶다면 해당 시트를 보고 배울 수 있습니다.

책의 내용

챕터와 레슨

핵심 주제를 의미하는 챕터안에 여러가지 레슨이 존재합니다.
해당 여러 레슨은 챕터를 이해하는데 필요한 요소들로 해당 레슨들을 익힌다면, 해당 챕터의 본질적인 의미를 이해할 수 있습니다.

따라하는 예제, 직접 해보는 실습

기본적으로 책의 내용은 예제/실습 파일을 통해 피그마의 기능들을 소개합니다.
해당 파일들은 피그마 커뮤니티에 업로드가 되어있으며, 책의 소개 파트에서 해당 URL을 제공하고 있습니다.

마치 포토샵 GTQ 도서와 같이 각 레슨별 파일을 통해 책의 내용을 따라하며 배울 수 있습니다.

핵심 기능과 단축키

피그마의 기능을 소개하는 과정에서 단축키를 사용할 수 있는 부분들은 간략 하면서 핵심적으로 설명하고 있습니다.
당연할 수 도 있는 부분이지만, 단순히 윈도우키 뿐만이 아닌 맥과 윈도우 각각의 단축키를 설명하고 있어 좋았습니다. 간혹 윈도우 단축키만 설명하는 도서도 있기에...

다양한 플러그인

피그마의 장점 중 하나는 다양한 플러그인을 쉽게 추가하여 사용할 수 있다는 것 입니다.
다만 플러그인이 아무리 많다 하더라도 자신에게 필요한 플러그인들을 찾는데는 오랜 시간이 걸립니다.

본 도서 에서는 피그마에서 유용하게 사용할 수 있는 플러그인들과 해당 플러그인을 어떻게 활용 하는지를 예제와 실습을 통해 함께 배울 수 있습니다.

좋았던점은

읽으면서 느꼈던 부분은 버릴 내용없이 핵심 내용만 잘 정리했다는 느낌을 받았습니다.

약 400페이지가 되는 내용에서 서론, 설치법 등을 제외하면 불과 150페이지가 피그마의 기능들을 학습하는 내용 임에도 앞으로 피그마를 활용하는데 있어 완벽하지는 않더라도 부족함 없이 사용할 수 있을 것이라는 생각이 들 정도로 매우 잘 정리되어있던 것 같습니다.

또한 예제/실습 파일을 통해 단순히 글로만 설명하는 것이 아닌, 독자가 스스로 따라하면서 배울 수 있는 부분이 직접 경험을 통해 피그마를 익히는데 큰 도움이 된 것 같았습니다.

아쉬운점은

다만 개인적으로 아쉬운점은 일부 예제/실습 부분에서 따라하였지만 무언가 책의 내용처럼 되지 않았던 부분이 있습니다. 물론 돌이켜보면 제가 실수를 하거나 놓쳤던 부분이지만, 간혹 당황하는 부분이 생겼었습니다.

이를 해결할 방법은 매우 상세하게 설명을 작성하는 것 이겠지만, 그랬다면 오히려 정보 대비 글의 양만 늘어나는 것 이기에 아쉽지만 어쩔 수 없는 부분이라고 생각됩니다.

(물론 제가 멍청해서 그럴 수 도 있습니다)

결과론적으로

저는 Adobe XD를 고등학생 때 부터 사용하여 4년 간 사용해오면서 피그마를 사용하는 많은 디자이너를 만났지만 굳이 피그마를 넘어갈만한 이유를 느끼지 못하였습니다.

그러다 이번 가격 정책 변동과 Adobe에서 조차 피그마를 인수했다는 소식을 듣고 강제로 피그마를 넘어가보았지만 어색함과 불편함의 연속이였습니다.

그렇게 어색함과 불편함을 가지고 피그마를 사용하던 도중, 한빛미디어를 통해 본 도서를 읽을 수 있는 기회가 생겼고, 책이 시키는데로 따라만 하였음에도 그동안 마치 강력한 도구를 가지고 있지만 사용할 줄 모르는 어린 아이과 같다는 것을 깨달았습니다.

물론 아직은 완벽하게 다루지 못하지만, 방학동안 다시 한번 읽어보면서 숙련도를 높여볼 생각입니다.
피그마에 관심이 있거나 UI/UX에 대해 관심이 있다면, 본 도서를 읽어보시는 것을 꼭 추천드립니다.