Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

기술 뉴스 #119 : 19-02-01

웹개발 관련

  • HTTP/3: From root to tip : 1991년에 나온 HTTP/0.9부터 QUIC 기반의 HTTP/3까지 어떻게 발전해 왔는지를 그 역사를 정말 자세하게 설명하는 글이다. 표준을 제정하는 IETF가 어떤 프로세스로 RFC를 만드는지 설명하고 HTTP/0.9, HTTP/1.0, HTTP/1.1, SSL, TLS와 최근에 나온 HTTP/2의 역사를 설명하고 앞으로 나올 HTTP/3의 배경을 설명하고 이를 한눈에 볼 수 있는 타임라인을 제공하고 있다. HTTP의 역사를 총정리해 놓은 글이나 다름없어서 HTTP에 대해서 궁금할 때 두고두고 봐도 좋을 글이다.(영어)
  • React-cache, time slicing, and fetching with a synchronous API : 비동기 동작을 동기 API로 사용할 수 있게 하는 react-cache를 설명하는 글이다. 글만으로는 완전히 이해하지 못했는데 React의 fiber 아키텍처에서 동기로 보이는 코드가 어떻게 비동기 작업이 실행되는지 설명하기 위해서 Algebraic effects의 개념과 실제로 어떻게 동작하는지 보여주고 있다. 그리고 이 방식이 React에서 컴포넌트 렌더링에 어떻게 영향을 주는지 설명하는데 React를 별로 안 해봐서 완전히 이해하진 못했지만, 시간을 들여서 자세히 볼만한 가치가 있어 보인다.(영어)
  • How I built an async form validation library in ~100 lines of code with React Hooks : form의 유효성 검사는 다른 필드와의 검사 타이밍이나 동기/비동기 검사, 폼 제출 전에 검사 등 신경 쓸 요소가 많은데 아직 실험적인 API이지만 React Hook을 이용해서 이를 쉽게 처리하는 방법을 설명하는 글이다. 코드가 많지 않으면서도 깔끔하게 폼 처리를 하고 있어서 React Hook에 관심 있다면 살펴볼 만하다.(영어)
  • 코딩 없이 10분 만에 REST API/Graphql 서버 개발하기 : 최근 Headless CMS에 관심이 많은데 그중 하나인 strapi로 API 서버를 만드는 방법을 설명한 글이다. 백엔드 서버를 코딩하지 않고도 UI 상에서 간단하게 데이터베이스 스키마를 구성해서 RESTful API와 GraphQL로 제공하는 방법을 설명한다. 아주 복잡한 백엔드는 힘들겠지만 간단한 기능은 strapi로 쉽게 만들 수 있을 것 같다.(한국어)

그 밖의 프로그래밍 관련

  • 타다 시스템 아키텍처 : VCNC에선 만든 모빌리티 플랫폼인 타다의 전체 시스템 아키텍처를 설명한 글이다. Kotlin, k8s, gRPC, Terraform 등 선택한 기술과 서비스를 설명하고 전체 구조부터 차량 위치를 업데이트하거나 배차할 때 시스템에서 어떻게 처리하고 있는지를 설명하고 있다. 전체 구조를 파악해 볼 수 있는 좋은 글이다.(한국어)
  • AWS Lambda@Edge에서 실시간 이미지 리사이즈 & WebP 형식으로 변환 : 당근마켓에서 이미지를 AWS Lambda로 리사이징 처리하던 기존 방식을 Lambda@Edge를 이용해서 첫 요청 시 동적으로 리사이징하도록 개선한 과정을 설명하고 있다. 모든 리사이징 이미지를 저장해 두어야 하고 이미지 크기나 형식을 바꾸기 어려운 문제점을 바꾸기 위해서 요청 시 리사이징해서 CDN에 캐시 하도록 개선했으며 Lambda@Edge의 제약사항을 포함해서 사용한 코드까지 나와 있어서 Lambda@Edge를 어떻게 사용하면 되는지 이해하기 좋다.(한국어)
  • 오픈소스 프로젝트를 운영하며.. : TOAST UI 시리즈를 오픈소스로 공개하면서 인기를 많이 얻고 있는 NHN엔터테인먼트의 FE 개발 랩에서 그동안 TOAST 프로젝트를 오픈소스로 공개한 과정과 그 성과를 정리한 글이다. ui.jsdoc-template를 시작으로 오픈소스로 공개하기 시작하면서 GitHub에서 인기를 얻기 시작해서 얻은 결과와 이를 통해서 채용에서 효과를 본 내용을 설명하고 있다. 국내 회사에서 오픈소스를 하는 회사가 많지 않고 하더라도 대부분 국내용 오픈소스 프로젝트를 많이 하는데 전 세계에서 인기를 얻는 프로젝트를 여럿 진행하고 있다는 점에서 고무적이다.(한국어)
  • Flutter란? : Eric Windmill의 글을 번역한 글이다. Dart로 iOS/Android 모바일 앱을 만들 수 있는 Flutter가 왜 좋은지 설명하는 글이다. Flutter로 만드는 방법 자체보다는 핫 리 로딩을 지원해서 빠르게 개발할 수 있고 React Native가 사용하는 JavaScript Bridge 대비 네이티브로 컴파일되기 때문에 성능이 좋다는 점을 강조하고 있다.(한국어)
  • I-want-to-study-Data-Science : 데이터 사이언스 공부에 도움이 될 내용을 정리한 저장소이다. 직군 설명부터 공부해야 할 내용뿐 아니라 취업까지 데이터 사이언스를 어떻게 공부하면 좋을지 어려운 사람들이 참고하기 좋은 자료를 정리해 놓았다.(한국어)

블록체인 관련

  • 이더리움 콘스탄티노플 하드포크 무기한 연기 : 1월에 예정되어 있던 이더리움의 콘스탄티노플 업데이트에서 문제점이 발견되어 무기한 연기되었다.(한국어)
  • 왜 우리는 지금 EOS인가? : EOS를 왜 주목해야 하는지 설명하는 글이다. 사용할 때 Gas를 지불해야 해서 사용자에게 큰 장벽이 되는 Ethereum과 달리 서비스 제공자가 EOS를 스테이킹 해 두어야 하므로 사용자는 무료로 이용할 수 있고 높은 가용성을 제공하고 있다고 설명하고 있다. 추가로 EOS의 헌법을 통해서 스마트 컨트랙트의 의도를 확인하고 중재할 수 있으므로 다른 블록체인과 차별점을 가지고 있다.(한국어)

볼만한 링크

  • 발표의 정석 : 발표를 잘하시는 하용호 님이 그동안의 발표 경험을 정리한 글이다. 발표를 통해서 하용호 님이 어떤 기회를 얻었는지를 설명하고 발표를 할 때 어떻게 준비하는지를 정리한 자료이다. 하용호 님의 발표를 들으면 정말 재미있으면서도 핵심 내용이 모르는 사람도 이해하기 쉽게 잘 전달된다는 느낌이 강한데 이 자료를 보면 그런 발표를 만들기 위해서 얼마나 노력하셨는지를 알 수 있다. 120 장이 넘는 자료지만 꼭 읽어봐야 할 정도로 알차다.(한국어)
  • 왕년의 마이크로소프트가 아니다. (번역) : This is not your father's Microsoft의 번역 글로 현재 Microsoft의 사티아 나델라(Satya Nadella)가 Microsoft를 어떻게 바꾸고 있는지를 설명한 글이다. 최근 몇 년간 MS가 달라지는 모습은 놀라울 정도인데 나델라가 CEO가 되면서부터 "마이크로소프트를 좀 더 트렌디하게, 좀 더 요즘 느낌으로 리브랜딩하는 것"을 목표로 하면서 어떻게 바꿔왔는지가 잘 나와 있어서 재미있게 읽었다. MS 정도의 공룡 기업이 이렇게 단기간에 변화하는 것은 놀라울 정도다.(한국어)
  • ‘스타2’ 프로게이머 이긴 ‘알파스타’가 의미하는 것 : 지난 25일 딥마인드의 AlphaStar가 Starcraft 2로 사람과 대결을 하고 10:1로 승리했다.(한국어)
  • 2018년, 내가 모르는 기술들 : Redux를 만들고 현재 React 프로젝트에 참여하고 있는 Dan Abramov의 Things I Don’t Know as of 2018를 번역한 글이다. Redux와 React에 참여하고 있는 유명한 개발자인 만큼 사람들이 개발 관련한 모든 기술을 다 알고 있을 거라고 생각하는데 자신이 모르는 기술들을 솔직하게 정리한 글이다. 이런 사람도 다 아는 건 아니구나 싶은 생각이 드는 글이다.(한국어)
  • 파이썬 코어 개발자가 되기까지 : Emily Morehouse가 파이썬 코어 개발자가 된 과정을 쓴 MY PATH TO BECOMING A PYTHON CORE DEVELOPER를 번역한 글이다. 파이콘에서 귀도 반 로섬의 얘기를 듣고 코어 개발자가 되려고 노력해서 3년이나 걸려서 코어 개발자가 된 얘기인데 오래되고 인기 있는 프로젝트에 새로 들어갔을 때의 어려움과 고민까지 잘 나와 있다.(한국어)
  • 좋은 기술 블로그를 만들어나가기 위한 8가지 제언 : 좋은 블로그를 만든다는 관점에서 좋은 글을 쓰는 것 부터 블로그 도구와 독자와 나중을 위한 콘텐츠 보존 및 수익 등 전체적인 운영에 대해서 정리한 글이다. 블로그를 만들 생각이 있거나 운영을 시작한 사람들이 중요하게 생각하는 부분을 잘 지적하고 있다.(한국어)

IT 업계 뉴스

프로젝트

  • CloudQuery : 웹사이트에서 선택한 콘텐츠를 CSS 셀렉터로 필터링해서 API로 만들어주는 프로젝트.
  • GitHub Actions Toolkit : GitHub 액션에 필요한 파일을 만들어주고 Node.js 환경에서 액션에 필요한 Octokit SDK와 함수를 제공하는 npm 모듈.
  • Docker Traffic Control : 컨테이너 레이블에 따라 네트워크 제한을 걸거나 지연시간, 손실, 복제 등을 에뮬레이트할 수 있는 프로젝트.
  • Lighthouse Bot : GitHub 풀리퀘스트와 통합해서 Lighthouse 검사를 해주는 봇.
  • websocketd : STDIN/STDOUT을 쓰는 프로그램을 WebSocket 서버로 만들어주는 명령행 도구.

버전 업데이트

2019/02/01 04:25 2019/02/01 04:25

[Book] 함께 자라기: 애자일로 가는 길

항상 발표나 글에서 많이 배우던 김창준 님의 첫 책이라 바로(?) 구매를 했다. 책 살 때 출판사는 잘 확인 안 하는 편이라 인사이트 책인 줄 모르고 종이책을 구매했다가 이북을 다시 구매했다. 설명도 잘하시고 책이 두껍지 않아서 아이패드로 들고 다니면서 금방 읽었다.

먼저 애자일에 대해서 말하자면 애자일을 그리 좋아하는 편은 아니다. TDD도 염두에 두고 코딩하고 있고 애자일의 많은 실천 방법과 개념들을 좋아하지만 애자일이란 말은 거의 사용하지 않는 편이다. 이 책의 후반부에도 나오지만 한창 애자일이 유행할 때 열심히 세미나 등을 따라다녔지만 언젠가부터 전혀 애자일 스럽지 않게 느껴졌고 애자일이라는 힙한 느낌의 단어에 많은 것을 가두고 국내에서는 애자일의 원래 의도와 달리 관리 기법으로 쓰이는 것 같아서 그 말을 잘 쓰지 않게 된 것 같다.

김창준 님이 국내에서 애자일을 대표하는 한 분이시기에 "함께 자리기" 제목으로 어떤 얘기를 하실까 하는 궁금함을 가지고 책을 보았다.

결론부터 얘기하면 많은 부분을 공감하면서 재미있게 읽었다. 난 애자일 전문가나 전도사도 아니고 깊게 공부해 본 적은 없지만 애자일 소프트웨어 개발 선언이 나온 지도 18년이나 되었기에 그 많은 정신과 실천방법은 이미 IT에 자리 잡았고 애자일이라고 부르던 안 부르던 괜찮은 문화를 가졌다고 생각하는 조직에 스며들어 있다고 생각하고 내가 좋아하는 기업/팀 문화와도 어느 정도 연결된다. 이 책에서 김창준 님이 "함께 자라기"라는 제목 아래 설명하는 협업? 혹은 일 잘하기? 에는 공감할 내용이 많았다.

전혀 몰랐던 깜짝 놀랄 내용이 있다기보다는 어느 정도 머릿속에 있고 어디선가 얘기해 본 적도 있는 내용이지만 정리 안 된 채로 있던 내용이 이 책을 통해서 훨씬 체계적으로 정리가 되었고 연구나 논문을 통해서 근거를 알게 되었다. 근거를 알게 되었다는 것은 어디선가 논쟁을 할 때 써먹기 위함이라기보다는 "이건 OO인 것 같은데..." 같던 생각이 실제 연구에서 어떤 결론으로 이어졌는지 알게 되어 훨씬 명확해졌다.

1부 자라기

학습 방법을 학습해야 합니다.

1부에서는 학습에 관해서 설명한다. 경력 연차나 학력이 업무와의 연관성이 거의 없다는 걸 보여주고(없다고는 생각했지만 이렇게까지 상관없는 줄을 몰랐다.) 학습을 통해서 성장하는 방법과 그 중요성을 설명하고 있다.

  • 자신이 이미 가진 것들을 잘 활용하라.
  • 외부 물질을 체화하라. - 주기적인 외부 자극을 받으면 좋다. 단, 외부 자극을 받으면 그걸 재빨리 자기화해야 한다.
  • 자신을 개선하는 프로세스에 대해 생각해 보라.
  • 피드백을 자주 받아라.
  • 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라.

개발하면서 오랫동안 자기 계발을 열심히 해왔지만 이젠 관성으로만 움직이는 느낌도 있다.(사실 이 말도 최근 몇 년 동안 여러 번 하고 있다.) 그래서 이 책에 나온 실천 방법들이 지금 나는 이런 학습 환경을 어느 정도 유지하고 있는지 되돌아보는 계기가 되었다.

실력을 높이기 위해서는 '의도적 수련(Deliberate Practice)'이 중요합니다. 의도적 수련이 되려면 나의 실력과 작업의 난이도가 비슷해야 합니다.

의도적 수련에서 난이도를 맞추기 위해서 실력을 낮추거나 난이도를 높이는 방법은 실제로 해보면 좋겠다는 생각을 했다. 조금 더 의도적으로 수련을 할 필요가 있다.

실수 예방 문화에서는 실수를 한 사람을 비난하고, 처벌하고, 따라서 실수를 감추고 그에 대해 논의하기 꺼리며 문제가 생겼을 때 협력도 덜하게 됩니다. 실수에서 배우지 못하겠지요. 반대로 실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생깁니다.

실수가 없으면 학습하지 못합니다(고로 직원들에게 실수하지 말라고 하는 조직은 학습하지 말라고 지시하는 것과 같습니다). 이는 학습이론의 기본입니다. 즉, 실수 관리를 하는 문화일수록 학습을 더. 잘합니다.

뛰어난 개발자들은 약 70%가 동료와의 협력을 언급하는 반면, 실력이 그저 그런 개발자들은 20%도 안 되는 사람들만이 동료와의 협력을 언급했습니다. 이 정도면 차이가 꽤 크니 면접에서 개발자의 실력을 가릴 때 이용하면 도움이 될 수. 있겠죠.


2부 함께

신뢰를 쌓는 데에 널리 사용되는 한 가지 방법은 투명성과 공유, 인터랙션입니다. 자신이 한 작업물을 투명하게 서로 공유하고 그에 대해 피드백을 주고받으며 인터랙션을 하는 것이죠.

2부는 주로 협업에 관한 내용이다. 나는 그동안 경력에서 혼자 일한 경우가 꽤 많고 관리자 역할을 하진 않아서 관리 차원에서의 협업에 대해서는 큰 관심은 없다. 일을 더 즐겁게 하려고 하는 협업에 관심이 있고 이젠 시니어 개발자이다 보니 시니어의 역할에서의 협업에 관심이 있는 정도이다. 협업에 대해서는 여기 나오는 대부분을 동의하지만, 현실에서는 뭔가 생각처럼 되지 않는 어려움이 있는 것도 사실이다.

남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 합니다. 그래야 현실적으로 설득이 가능합니다. 내가 설득하고 싶은 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야 합니다. 출발은 결국 내가 설득하려는 사람에게서 하는 것입니다. 자료에서 출발하는 것이 아닙니다.

위 같은 방법을 많이 해본 적은 없긴 하다. 뭘 도입하겠다고 열심히 하는 편은 아니고 그냥 혼자 하는 편이기도 하지만(싫다는 사람을 굳이...) 위와 같은 설득 방법은 내가 잘 못 하는 영역이라서 고민을 좀 하기도 했다. 다만 뭔가 하기 위해서 항상 설득하거나 반대에 부닥치기 보다 문제의식에 대한 공감대 형성 같은 부분에 대해서 어려움을 느끼는데(지금도 말로도 잘 설명이 안 된다.) 그런 부분은 정리되진 않았다.(나도 내가 뭘 원하는지 잘 모르겠다.)

뛰어난 팀이라면 거의 한 팀도 빠지지 않고 공통적으로 갖고 있는 특징이 몇 가지 있었는데, '삼투압적 의사소통'이 거기에 속합니다. 삼투압적 모형에서는 은연중에 서로 간에 정보가 스며드는 겁니다.

이런 의사소통 방식은 내가 좋아하는 방식인데 실제로 삼투압적인 의사소통을 만들려면 어떻게 해야 할지를 고민 중이다. 혹은 모두가 이런 의사소통을 좋아하는 것은 아니라고 생각하기에 조직 전체가 더 나은 의사소통으로 넘어가는 방법은 무엇일지가 고민이긴 하다.

3부 애자일

사실 애자일은 불확실성이 클 때 우리가 어떻게 해야 하는지를 고민한 결과물입니다. 따라서 애자일은 불확실성이 높은 프로젝트에 더 적합합니다. 사실 우리가 이제까지 이야기했던 학습과 협력이 애자일이 불확실성을 다루는 핵심적인 구동 원리입니다.

학습적 면에서 보면, '매일'하는 것은 학습의 빈도를 말합니다. 불확실성이 높을수록 빈도가 자주 있어야 합니다. 협력이라는 면에서는 '고객에게'라는 부분이 그 중요성을 말하고 있습니다.

3부에서는 보통 많이 얘기하는 애자일에 대해서 얘기하고 있는데 조직 차원에서 애자일 도입을 하는 경험을 해본 적은 많지 않아서 가볍게 읽었다. 프로젝트 성공에 영향을 주는 요소에 "고객 참여"와 "코드 공유"가 중요하다는 부분은 흥미로웠다.

일전에 모 매체와 인터뷰에서 기자가 이런 질문을 했습니다. "애자일을 진행하는 가운데 가장 빈번히 빚어지는 폐단은 무엇인가?" 저의 답변은 이랬습니다. "애자일을 반애자일적으로 진행하는 것이다. 예컨대 애자일은 불확실한 상황에 대한 접근법인데, 애자일을 도입할 때 확실성 위에서 진행하려고 한다면 문제가 된다."



이 글에는 제휴(Affiliate) 프로그램의 링크가 포함되어 있습니다.

2019/01/31 23:58 2019/01/31 23:58