2022년 1월부터 2월까지, 출퇴근 시간 지하철에서 틈틈히 읽어나간 책들을 소개합니다.
프론트엔드 개발자로서 뿐만 아니라 디자이너, PO, PM, 다른 개발 직군분들도 읽으면 도움이 될 것 같네요.
글재주가 없기도 하고 시간도 없어 두서 없음을 감안해주시면 감사하겠습니다.
최근에 읽은 책 네 권이 가까운 시일 내에 내가 발전해야 할 방향과 잘 맞는것 같아 추천하게 되었습니다. 『개발자의 글쓰기』는 개발자의 직무와 떼려야 뗼 수 없는 '글쓰기'를 가볍게 이해하기 좋은 책이었으며 『자바스크립트 코딩의 기술』은 ES6 이후 모던 자바스크립트의 문법을 효율적으로 활용하는 방법을 다시 한 번 복습할 수 있었던 책입니다.
『누구나 자료 구조와 알고리즘은』 저와 같은 개발자 초년생이 정렬, 큐, 스택, 그래프, 해시테이블과 같은 개념을 알기 쉽게 풀어 설명한 입문용 책으로 추천드리며, 마지막으로 『도널드 노먼의 UX디자인 특강』의 저자는 사용자 경험 분야와 사용성 평가 분야에서 큰 기여를 한 인물로서 일상에서의 UX 개념 정립을 설명한 책입니다.
앞으로 읽을 책은 개발자가 읽음직한 책도 있고, 조금 동떨어져 보이는 책도 있겠지만 프론트엔드 개발이 궁극적으로 사용자에게 제공하는 것은 더 나은 경험이기에 끊임없이 공부해야 한다고 생각합니다.
김철수 저 | 위키북스
글쓰기는 직군·직무와 관계 없이 업무의 근간이 되는 중요한 기본 소양 중 하나라는 사실은 누구도 부정하지 않습니다.
간단한 보고서부터 기획서, 제안서 등 모든 일은 문서화되어 관리되고 공유됩니다. 글쓰기는 업무 뿐만 아니라 자신이 배운 것을 정리해서 기록을 남기고, 생각을 쉽게 정리해주는 가장 좋은 도구입니다.
글을 탈고하는 과정 속에 생각의 체계를 구축하고 논리를 이루어간다고 합니다. 만약 업무와 일상에서 좋은 글쓰기 습관을 가지고 꾸준히 훈련한다면 우리의 삶을 윤택하게 해줄 것이라는 말에 저는 깊은 공감을 느낍니다.
제가 서점에서 이 책을 집어 든 이유는 저 또한 써야할 무수히 많은 글을 탁월하게 쓰고 싶다는 욕구가 있고, 필요성을 느껴왔기 때문입니다.
개발자가 글을 써야할 상황은 많습니다.
API 문서나 가이드, 체인지 로그, 에러 메시지, 장애 보고서, 주석과 변수명을 포함한 업무용 글쓰기부터, 제가 지금 써내려가는 개인 블로그나 새로 배우는 기술을 정리하거나 모르는 개념을 알기 쉽게 편집하는 문서까지 개발자의 과업 중 많은 부분에 글을 쓰는 일이 필요합니다.
물론 이 책이 A부터 Z까지 글쓰기에 필요한 모든 것을 채워주는 것은 아닙니다.
가볍게 읽기 좋을 정도의 크기와 두께의 『개발자의 글쓰기』 는 글을 쓰는 상황과 목적에 따라 어떤 구조와 논조로 글을 써야 하는지 방향을 제시해주는 가이드라고 할 수 있습니다.
빈 화면에서 글을 써내려 가는것은 막연하고 두렵습니다. 하지만 글쓰기란 코딩으로 목적에 맞는 구조를 짜맞추어가는 과정이라고 생각하게 되었습니다. 화려한 수사나 현란한 용어 없이도 하고자 하는 말을 의도와 대상에 맞게 잘 전달할 수 있는 글을 구성하는 연습을 하고 있습니다.
어쩌면 개발자에게 좋은 코드를 짜는 일은 좋은 글을 쓰는 것과 같다고도 생각이 됩니다.
저는 이 책을 목적이 있는 좋은 글을 쓰기 위한 또 하나의 프레임워크라고 여기고 있습니다.
Joe Morgan 저 | 길벗
원제: Simplifying JavaScript: Writing Modern JavaScript with ES5, ES6, and Beyond
사실 이 책은 제작년 개발자가 아니었을때, 취미 쯤으로 코딩을 독학하던 시기에 구매했던 책입니다.
기껏 해야 DOM을 조작하며 동적인 화면을 만들던 것으로 흥미를 느끼던 시기여서 Node나 NPM, 재귀, 비동기에 대한 이해가 없었습니다.
그래서 책장 한 구석에 넣어놓았다가 프론트엔드 개발자가 된 지금 다시 꺼내보고 이제서야 재밌게 읽을 수 있게 되었습니다.
특히 프론트엔드는 트렌드의 변화가 잦고 빠릅니다.
본격적으로 React를 배우며 공부하고, 회사에서 Vue를 사용하고 있는데 Angular는 구글로부터 사망 선고를 받고, Svelte가 새롭게 고개를 들고 있습니다.
현업의 코드들은 많은 의존성이 얽혀있고 숙지해야하는 툴과 배움과 적용을 동시에 병행해야 하는 상황도 많습니다. 바쁜 업무에 치여 레거시는 쌓여만 갑니다.
흔히 급변하는 시기일수록 최신의 기술을 맹목적으로 따라가기보다 본질적인 것에 집중하라고 합니다.
제 생각엔 이 모든 기술과 방법론으로서 화면에 표현하려고 하는 근간은 HTML, CSS, JavaScript가 아닐까 생각합니다.
이런 사유로 JS를 더 깊이 이해하고 아키텍쳐의 코어 컨셉을 이해하는 것에 시간을 투자하라는 조언을 자주 듣습니다.
채용 공고의 JD를 보면 수 많은 기술들이 나열되어 있습니다.
TypeScript, ES6+, SPA Frameworks, SSR, TDD, CI/CD 등 요구되는 기본 소양은 숨막힐 정도입니다.
저의 성격은 급한 편입니다. 요구되거나 업무에 필요한 스킬이 나타난다면 Udemy 같은 플랫폼에서 강의 결제부터 해버립니다. 하지만 급하게 최신 스택을 채워나가려고 무리하는 것은 지양되어야 할 태도라는 것을 금세 깨닫게 되었습니다.
웹 개발자라면 결국 다양한 프레임워크의 근본은 JavaScript입니다.
NodeJS를 배울때 이벤트 루프와 큐, 스택과 컨텍스트, 프로토타입 등 숨겨진 근본 원리(behind the scene?)를 이해하지 않고선 최신 기술을 사용하더라도 왜 이렇게 되는지 이해할 수 없었던 상황에 처한 많은 기억이 있습니다.
흔한 개발자 meme으로 "이게 왜 안 되지? 이게 왜 되지?"가 있습니다.
급하게 다음 진도로 넘어가기 전에 내가 지금 사용하고 있는 언어나 아키텍쳐에 대해 깊게 공부하고 이해하려 노력하다보면 적어도 되고 안되는 이유는 알 것이며, 다른 언어도 쉽게 이해할 수 있는 경지로 향할 것이라고 믿고 있습니다.
신기한것은 Ruby나 Python으로 작성된 다른 코드를 봐도 대강 이게 이런 느낌이겠지 짐작은 가능해지는 점이었습니다. 어느 분야나 극점은 통한다는 말이 이런거겠지, 아직까지는 그렇게 대강 짐작만 하고 있습니다.
이 책은 ES6 이후 버전의 모던 자바스크립트를 소개하고 더 나은 코드를 작성하는 지향점을 제시합니다.
자바스크립트 런타임에 대한 이해와 간단한 개발 환경을 설정할 수 있는 정도라면 어렵지 않게 읽을 수 있습니다. ES6+의 주요 피쳐를 이미 알고 있다면 몇 단원은 시시하게 느껴질 수 도 있습니다.
저는 개인적으로 함수를 주입하거나 커링과 배열 메서드를 조합한 부분 적용 함수를 업무에 꽤 유용하게 활용할 수 있었습니다.
코딩을 본격적으로 배울때 미리 읽었다면 도움이 되었을 것 같다고 생각하고 있습니다.
새로운 것을 배움에 앞서 내가 가진 도구를 더 잘 활용하기 위해 스킬을 추가한다고 생각해도 좋을 것 같습니다. 자바스크립트를 더 깊게 공부하기 위한 안내서와 같은 책은 많지만 이 책도 실용서 중 하나로서 추천드리고 싶었습니다.
Jay Wengrow 저 | 길벗
CS를 전공하지 않고 기술 위주로 학습해서 이제 갓 개발 현업에 입문한 사람으로서 느끼는 컴플렉스가 있습니다. 자료 구조와 알고리즘, 네트워크 기반 지식 등 CS 학문의 기본적이고 기초의 부재입니다.
혹자는 이런것은 잘나가는 테크 기업 취업용이고 현업에선 잘 쓰이지 않는다고 공부할 필요가 없다고 합니다. 하지만 이 책의 서문에선 아래와 같이 이야기합니다.
우리가 소프트웨어를 문제없이, 빠르게 실행할 수 있는 명쾌한 코드를 작성하는 능력을 갖추고
소프트웨어 공학자가 가져야 하는 전문성을 키우려면 다양한 자료 구조를 알고, 각각의 자료 구조가
개발 중인 프로그램의 성능에 어떤 영향을 미칠 지 확실히 이해하고 있어야 한다.
언어에 내장된 함수나 다양한 도구들은 이미 빠른 성능과 높은 효율성을 보장합니다.
자료 구조와 알고리즘을 배웠다고 해서 더 효과적인 알고리즘을 만들 것 같진 않습니다.
만들 수 있다고 해도 그건 저에게 이미 발명된 바퀴를 재발명 하는 것과 같다고 느껴지기 때문입니다.
비즈니스 로직에 따라 우선 순위가 다르고 대용량 트래픽이나 무거운 태스크를 처리해야 하는 경우
어떻게 복잡도를 낮추고 효율성을 극대화 할지 논의하기 위해선 적합한 방법론이 필요할 것입니다.
저의 조심스러운 생각으로는 이 지식들은 현재의 개발 씬에서 어떤 상황에서 어떤 도구를 사용하는 것이 효율적이고 적합한지 판별할 수 있는 능력을 주는 것 같습니다.
어쩌면 이제 구현하는 것 자체는 중요한지 않은 것 같습니다. 쉽게 원하는 피쳐를 만들 수 있도록 좋은 툴이 많이 나와있고, 클라우드 컴퓨팅, 서버리스 등 어렵고 복잡한 파트는 더 이상 내가 하지 않아도 되는 시대로 바뀌어가고 있습니다.
하지만 모든 분야가 그렇듯 가장 본질적이고 기초가 되는 지식의 중요성을 인지하지 못한다면 업계의 흐름 속에서 정작 중요한 부분을 놓치게 되지 않을까, 보편적인 시각에서 조심스레 생각하곤 합니다.
이 책은 다음과 같은 독자에게 이상적이라고 소개되어 있습니다.
이 책의 예제는 루비와 파이썬, 자바스크립트로 구성되어 있지만, 최대한 언어를 공통적인 수준에서 작성했기 때문에 전혀 이해 못할 수준은 아니었습니다.
입문자의 시각에서도 어렵지 않게 이해할 수 있도록 쉽게 풀어 설명해 놓았습니다. 기본적인 지식을 이해하고 넘어가기에 좋은 책이었습니다.
Donald A. Norman 저 | 유엑스리뷰
저는 산업 디자이너 출신으로서 운 좋게 UX Driven Design Process에 대해 개론적으로나마 배울 수 있었던 계기가 있었습니다.
그 때마다 사용자 페르소나를 설정하고 User Journey에 따라 사용자가 느끼게 될 감정과 보완책을 포스트잇에 써붙여가며 생소한 UX 방법론이 개발 프로세스를 이끄는 과정을 아주 얕게나마 경험할 수 있었습니다. 요즘은 흔하게 UX라는 말이 사용되고 있습니다. 그리고 이상하게도 자주 UI 개념과 혼용되기도 합니다.
물리적 제품과 하드웨어 개발에서 산업의 무게 중심은 소프트웨어로 점점 옮겨가고 있는 듯 합니다.
제가 갓 디자인을 배우기 시작한 때에는 Product Designer는 물리적인 제품, 금형, 주로 플라스틱 사출로 이루어진 피쳐의 기획, 디자인, 초도 생산을 담당하는 직무였는데, 어느새부터 Sketch, Figma를 활용해서 웹앱 / 모바일 앱 / 소프트웨어를 디자인하는 직군이 Product Designer라고 검색 결과에 더 많이 나오는 것 같습니다. (그래서 이젠 Industrial Designer라고 찾아야 합니다)
이 책을 산 것은 몇 년 전이었지만 막상 책을 펼쳐보진 않았습니다.
하지만 최근 제가 고민하고 있는 질문에 대한 답을 찾기 위해 이 책을 펼쳐보게 되었습니다.
그 고민은 "디자이너 출신의 프론트엔드 개발자가 가질 수 있는 우위적 역량은 무엇인가" 입니다.
물론 조직이 커지고 분업이 명확한 조직일수록 개발자가 디자인을 기웃거릴 일은 전혀 없겠지만 모든 것이 그렇듯 알고 따르는 것과 그냥 따르는 것은 많은 차이가 있을것 같습니다.
SPA 프레임워크가 화면을 개발하는 단위는 재사용성을 전제한 UI가 중심이 됩니다. 디자이너가 UI 시안을 만들어 넘겨주고 있지만 사용자와 상호작용하는 디테일은 공란으로 비어있게 됩니다. 애초에 디자인 시스템이 잘 구축되어 있다면 모를까 나머지는 정책적인 결정을 기다리거나 프론트엔드 개발자의 상상력을 채워 다시 컨펌을 받게 되곤 합니다. 물론 프로세스가 잘 지켜지는 곳은 이야기가 다르겠죠.
회사의 백엔드 시니어분에게 프론트엔드에게 핵심적인 역량은 무엇이냐고 물었을때 그는 "User Experience"라고 답을 했습니다.
프론트엔드 개발자는 의도된 바가 명확한 설계와 디자인은 무엇이든 구현할 수 있어야 합니다. 하지만 의도가 명확하지 않고 뜬구름 잡는 듯한 부분은 짚어낼 수 있어야 한다고 생각합니다. 그 기준점은 사용자이고 프레임은 UX 관점이라고 생각했습니다.
프론트엔드는 고객과 서비스의 접점을 설계하고 주로 시각적으로 보여지는 피쳐를 만듭니다. Interface라는 말은 '계면'으로 직역됩니다. 이는 "서로 맞닿아 있는 두 물질의 경계면"이라고 합니다. 당연한 말이지만 User Interface는 서비스와 고객이 만나는 지점이기 때문에 직관성, 사용성, 심미적인 고려가 수반됩니다. 저는 디자이너 출신의 프론트엔드 개발자인 제가 강화해야 하는 역량이 이 지점에 있다고 생각하게 되었습니다.
어떻게 하면 고객이 더 쉽고 편하게 우리의 서비스를 사용할 수 있을까?
어떻게 하면 고객이 더 직관적으로 우리의 서비스를 이해할 수 있을까?
개발 직군 뿐만 아니라 PO, PM, Product Designer 등 다양한 직군의 사람들은 저 물음에 각자의 답을 가지고 있어야 합니다.
화면을 기획할때도 왜 여기선 모달을 사용하고 왜 저기선 Drawer를 사용했는지, Confirm 버튼은 어느 위치에 있어야 하는지, 앱의 유저 플로우는 어떻게 진행되는 것이 맞는지 타당한 답을 할 수 있어야 한다고 생각합니다.
결국 기획·개발 단에서 추구하는 지향점의 중심은 사용자에게 있기 때문에 각자의 분야에서 더 나은 답을 찾으려 노력하고 있습니다.
언젠가부터 디자이너도, 기업도 맹목적으로 'Simple is the best'를 외치기 시작했습니다. 단순한 것이 많은 문제를 해결한 것 처럼 보여지는 것은 단순함이 필요한 곳이었기 때문입니다. 현상에 집착해서 정작 해결해야 할 핵심을 놓치게 되는 경우를 흔치 않게 겪게 됩니다. 핵심이 빠진 채 업무 논의는 자주 산으로 가곤 합니다.
제가 UX 개념에 대해 다시 공부하려 하는 이유는 논의가 교착된 상태에서 사용자의 관점에서 다시 되짚어갈 수 있는 도구와 방법론이 요구되고 왜 이렇게 되어야만 하는지 설득할 수 있는 논리가 필요했기 때문입니다.
"누구나 단순함을 원한다. 하지만 핵심은 놓치고 있다. 단순함 자체가 목표일 수 없다. 기술이 지닌 유용성과 유연함을 포기하고 싶은 사람은 없다. 주차장 문을 열어주는 하나의 버튼은 간단할지 모르지만 그것 말고는 할 수 있는 일이 없다. 휴대폰에 버튼이 하나만 있다면 틀림없이 단순해 보이겠지만 아마 전원을 켜고 끄는 것 외에는 하지 못할 것이다. 전원버튼으로 전화를 걸 수는 없다. 건반이 88개, 페달이 3개나 있는 피아노가 너무 복잡한가? 사실 음악에서 그 건반을 다 사용하는 경우는 드물다. 그렇다고 해서 건반과 페달의 수를 줄여야 할까? 이처럼 단순함을 맹목적으로 추구하면 핵심을 빗겨 나가게 된다."
이 책은 UX 디자인에 대한 다양한 이슈를 다룹니다. 어떤 방식으로 디자인해야 사용자가 복잡한 것을 빠르게 이해할 수 있을까요? 우리가 일상적으로 마주하는 문제들도 기획과 디자인적인 관점에서 재해석하는 통찰로부터 기획과 개발의 접근 방식을 배울 수 있었던 것 같습니다.
글 ⓒ Wonkook Lee
I am very impressed with your article. Like you said when you delete a result, trap the cat it will be pushed from the left participant column to the right result column. I like it very much.
좋은 글 감사합니다! 잘 읽고 갑니다 :)