Loading
2022. 12. 26. 01:32 - lazykuna

개발 관련하여 읽은 책과 글들 (2022년 하반기)

개발 관련하여 읽은 책과 글들 (2022년 하반기)

사람은 독서를 해야 합니다. 학교에서 그렇게 배웠어요.

그런데 고등학생 이후로는 문학 작품을 일절 접해본 적이 없고, 대학교/대학원 이후로는 기술서적마저 딱히 읽지를 않았던 것 같습니다.

아무것도 읽지 않고 닥치는대로 약 3년간 일만 하다 보니, 새로운 기술에 점점 뒤쳐진다는 것을 느끼게 되었습니다. 그래서 새로운 정보를 얻기 위해 여러 매체를 사용했고, 그 방식 중 하나가 책이었습니다.

서론이 길었네요… 그래서, 앞으로도 매 분기마다 읽은 책(과 글)을 정리하는 시간을 가져보려고 합니다. 다만 올해 하반기는 이직하고 새로 회사 일에 적응하랴, 그 외에도 이것저것 하랴 시간을 쓴 덕에 책을 거의 읽지 못했습니다 😓. 내년에는 좀 더 많이 읽어야겠네요.

읽었던 책들

1. Refactoring 2

이건 원래 제일 먼저 읽기 시작하던 건데 다른 공부들 하다 보니 한참 후순위로 밀려서... 출퇴근 하면서 패드 미니로 어찌어찌 읽었습니다.

이 책을 읽으면서 개인적으로는 내용도 좋았지만 생애 최초 원어로 읽는 소프트웨어 엔지니어링 서적이라는게 제일 의의가 컸습니다. 500 페이지 분량의 영어로 쓰인 기술서적 특유의 용어와 맥락을 따라가는 게 확실히 나아집니다. 처음 읽기 시작할때와 다 읽어갈때쯤 읽어가는 속도 차이가 확실히 있더라고요.

이런저런 내용이 많지만 결국은 feature extraction, pack related code together가 대부분의 모토를 차지합니다. 이를 뒷받침해주는 다양한 예시들이 많은 것이 장점.

그리고 책 내용도 좋지만, 원어 기술서를 읽으면서 또 배울 수 있는 한가지 좋은 점은 terms 들에 익숙해 질 수 있다는 것입니다. 책에 굉장히 많은 코드 관련한 용어들이 쓰이고 있고, 이것들에 익숙해지면 굉장히 도움이 될 듯 합니다.

몇 가지 생각나는 키워드: Guard Clause, Reference Transparency, 또 뭐 있더라…

이거 말고 다른 책으로 읽는다면 Clean Code 읽어도 무방.

아직 읽지 못한 책들

1. Software Design at Google

맨먼스 머신이 추상적인 원칙 위주로 이야기한다면 이건 보다 구체적인 이야기들로 되어 있을거라고 생각합니다. 단순 보여주기식 내용이 아니라 실제 프로젝트 설계 수립 및 매니징 관련 경험들을 책에서 다루고 있는 걸 보고 이거다! 싶었습니다. 좋은 내용이 있을 것 같아, 빨리 읽을 수 있기를 기대하고 있습니다 ㅎㅎ.

2. 데이터 중심 어플리케이션 설계 (Designing Data-intensive Applications)

근래 수요가 많아진 빅데이터 시스템을 어떻게 설계할지에 대한 바이블 느낌의 책이라고 하여, 이것도 시간나면 읽어보려고 합니다. 그래도 이제 목차 보니 좀 익숙한 기술들이 많이 보여서 가볍게 읽을 수는 있어 보입니다. 메시징 시스템이나 분산 시스템에서의 장애극복, 컬럼 지향 저장소 등...

3. Advanced Programming in the UNIX

유닉스 시스템을 쓰면서 유닉스에 대해서 정작 잘 모른다고 느낀 게, 이번 면접 준비를 하면서였습니다. 수없이 많은 스레드와 프로세스를 쓰지만 그게 내부적으로 어떻게 동작하고, 어째서 Nginx가 최적화를 이루어내었는지, DB 엔진에서 어떤 식으로 최적화를 이루어내는지 등에 대해서 한번도 제대로 생각해보지 않았다는 것을 뼈저리게 느꼈습니다.

그래서 아무래도 기초를 닦을 필요가 있다고 생각해서 읽을 준비까지 다 해 놨습니다만 … 물밀듯 쏟아지는 k8s 및 도커 공부에 밀려서 결국 못 봤습니다. 나중에 봐야죠!

4. Linux Kernel Development

리눅스 환경에서의 보다 심층깊은 개발을 위해서 읽어보려고 했으나... Advanced Programming in the UNIX 책에 우선순위가 밀렸네요 ^^; 나중에 읽어야겠습니다.

읽으려고 했으나 더 이상은 아니게 된 책들

아래 서적들은 원론적이거나 현재 일들과 관련이 많이 적어서 아마 당분간 안(못) 읽을 것 같은 책들…

처음에 이 목록을 짰을 당시에는 데이터 사이언티스트/엔지니어링 분야도 생각을 해두고 있었는데, 지금은 꽤 멀어지게 되어서 보류중입니다. 그럼에도 불구하고 재미있는 내용들도 많아서 관심 대상으로 정리해 둡니다 ㅎㅎ.

1. 신경망과 심층학습

예전부터 데이터과학 분야에 있어서 정말 좋은 기본서적이라고 들어왔다. 겉핥기로 읽었을때도 흥미로운 내용이 많아, 내 토이프로젝트 작업할 욕심도 있어서 주문까지 해놓고 읽어보려고 했으나... 읽어보기도 전에 우선순위에서 밀려나 버렸다 😂 나중에 읽어야겠습니다.

2. Deep Learning - Ian Goodfellow

데이터 사이언스에서 필수적으로 사용되는 개념인 정보이론에 대한 기본서입니다. 이전에 읽었긴 했는데, 정말로 80% 정도는 이해를 제대로 하지 못하고 (…) 넘어간 부분이라 다시 읽어보려고 했습니다. 하지만 하는 일이 다시 데이터 사이언스쪽과 멀어지면서 우선순위가 내려왔습니다. 나중에 다시 읽어야겠습니다.

3. Information Theory, Inference, and Learning Algorithms - David MacKay

위와 마찬가지 이유로 미뤄짐.

4. 실전 시계열 분석

마찬가지 이유긴 한데, 시계열이라는 굉장히 실용적인 문제를 가지고 재미있게 다뤄놓은 것 같아 빠른 시일 내로 읽어보고 싶네요.

5. 실무 예제로 배우는 데이터 공학

아키텍쳐를 넘어서, 실제 데이터 엔지니어링에서 사용하는 툴을 직접 사용하여 실무 환경 구축하는 법을 알려준다. 아무래도 이쪽 분야에서 종사하는 게 아니면 해볼 수 없는 경험을 책을 통해서 쌓을 수 있다는 것 자체가 굉장히 흥미로운 일이라서, 읽어두면 굉장히 재미있을 것 같다.

근래에는 인터넷에 데이터 파이프라인/워크플로우에 대한 아키텍쳐 등의 자료들이 많아서, 굳이 이 책에 얽매일 필요가 없다는 생각이 듬.

읽었던 개발 관련 글들

1. 토스의 개발 문화

https://evan-moon.github.io/2022/05/07/toss-retrospective/

언제나 그렇듯 다른 회사에서 일처리하는 방식(=불구경)을 알아간다는 것은 재미있습니다. 말 많은 토스 또한 재미있는 점들이 많았습니다. 위의 독단적인 의사결정을 막고 아래에서 의견이 올라올 수 있도록 하기 위한 DRI 나, 빠른 실패를 독려하는 환경이나, 팀이 커져가면서 적극적이지 못한 사람이 생겨나는 현상과 원인을 파악, 그리고 해결을 위해 모두가 팀에 기여할 수 있도록 독려하고 친밀도를 유지하기 위한 에반젤리스트 결성, 그리고 그들의 활동 내역들을 알 수 있었습니다.

모두 하나같이 제가 다녔던 회사들에서 겪어왔던 문제들이라서 공감하는 바가 많았습니다. 그 중 가장 인상깊었던 것은 실패에 많은 가치를 두고 공유한다는 점이었습니다. 확실히 실패가 배울 점들을 동반한다는 걸 생각하면 좋은 방법인 것 같네요.

2. 원격외노자가 일하는 회사

https://www.leonkim.net/posts/원격외노자가-일하는-회사/

크게 정보성 있는 글은 아니지만, 다른 외국회사의 문화는 어떨까? 궁금하다면 약간은 도움을 얻을 수 있는 글인 것 같습니다. 회사가 약간 외주(?) 비스무리하여 특이한 점도 있긴 한데, 그래도 재미있는 점은 일하는 시간에 확실하게 제한을 두고, 추가근무를 했을 경우 그 원인을 확실하게 짚어본다는 점이 꽤 특이했습니다. “일을 무조건 많이 하면 좋다”라고만 생각했는데, 반대로 일을 많이 하는 사람은 문제가 있을 수 있다는 점을 생각해 본 적이 없었거든요. (기획에서 문제가 있었다거나, 아니면 의외로 업무 효율성이 떨어지는 경우라던가!)

3. Kafka, MongoDB, HBase, K8s 로 유연하고 확장 가능한 LINE 쇼핑 플랫폼 구축하기

https://engineering.linecorp.com/ko/blog/line-shopping-platform-kafka-mongodb-kubernetes/

쇼핑몰 플랫폼만큼 많은 데이터를 처리하는 곳이 또 없을 것입니다. 여기에서는 굉장히 다양한 범주의 데이터 플랫폼을 사용하고 있던데, 각각 그 역할이 존재합니다.

요구 사항 사용 기술
이벤트 기반 데이터
* 전달된 이벤트는 이후 필요한 곳에서 처리하게 됩니다. (데이터 분석, ElasticSearch 등) Kafka
저장 공간에 제약이 없으며 확장성이 우수 Mongo
빠른 배포 및 확장성 Kubernetes
시점이 중요한 쇼핑 특성상, 데이터의 히스토리를 추적할 필요가 있음
* 이를 테면, 가격 변경이라던가 …
* 컬럼 단위 버저닝의 지원
* 칼럼 단위 엑세스가 많음
* Key-Value 형태 ⇒ Hadoop ecosystem HBase 혹은 Cassandra

특이할 점은 같은 종류의 NoSQL인 HBase와 Mongo의 차이점이었습니다. 두 DB 모두 같은 역할을 하는 NoSQL이지만, 데이터를 저장하는 방식이 크게 달랐고, 이로 인해 데이터 처리 특성이 크게 다른 모습을 볼 수 있었습니다. NoSQL의 경우 도큐먼트 단위로 작업(쓰기/읽기/데이터 가공)이 무척 편리하다는 대신 Key-Value 대용량 프로세싱에서는 불리한 점이 있었고, HBase에서는 그 반대가 되죠. (더군다나 hadoop ecosystem에서도 매우 적절)

알아두면 나중에 비슷한 설계를 할 때에도 크게 도움이 될 것 같네요.

다만 개인적으로는 아주 오래된 데이터 보관을 위해, MongoDB에 배치성 job이나 TTL을 걸고, 모든 데이터를 S3에 보관하는 식으로 하면 어떨까 하는 생각도…

4. 대규모 분산 시스템 추적 플랫폼, Pinpoint

https://d2.naver.com/helloworld/1194202

마이크로시스템 형식의 아키텍쳐가 대중화되면서 문제를 추적하는데 어려움을 겪곤 하는데, 당시에 비슷한 문제를 겪은 사람들이 많았을 것입니다. 네이버 또한 그랬고, 그래서 자체적으로 개발한 분산추적시스템이라고 합니다. 현재는 이미 분산추적시스템 자체가 독립화된 서비스로서 제공되고 있지만, 그래도 당시의 설계나 특징이 궁금해서 조금 읽어보았습니다 ㅎㅎ.

  • “태그” 데이터를 넣어서 여러 서비스간에서 발생하는 메시지를 하나의 트랜젝션으로 찾을 수 있었다고 합니다.. 최근에는 이를 “task명" 이라고들 많이 지칭하고, opentracing 표준에서도 정의하고 있죠
  • 해당 로그를 발생시키도록 하는 방안으로 Pinpoint에서는 “Bytecode instructmentation” 방식을 채택했다고 합니다. 그러니까, 자동으로 로그를 생성하는 로직을 삽입시켜주도록 하는 방안입니다. 요즘에는 event-driven이 대세가 되었고, 이를 기반으로 자동으로 트레이싱을 하는 추세임을 감안할 때 다소 낡은 감은 있으나, 시도는 좋았다고 보여집니다.
  • 이외에도 프로토콜 및 압축으로 패킷최적화, 상수 테이블로 정보 압축, 대량의 요청의 경우 샘플링으로 저장 등으로 부하를 줄이기 위한 세부 설계가 많이 있었습니다.
  • 그리고 여러 workflow 관련 글을 읽고 별도 포스트로 정리해 두었습니다. (Relic, Zipkin, opentracing 등)

5. AI 분산 학습 플랫폼 NSML

https://engineering.clova.ai/posts/2022/06/nsml-components-and-infra

https://engineering.clova.ai/posts/2022/07/nsml-k8s-based-platform

https://engineering.clova.ai/posts/2022/08/nsml-scheduler-part-1

https://engineering.clova.ai/posts/2022/10/nsml-scheduler-part-2

아는 지인이 해당 프로젝트를 맡기도 했고, 또 머신러닝 시 발생하는 병목 현상들을 어떻게 해결했는지도 궁금해서 읽어봤습니다.

  • 대부분 머신러닝 시 발생하는 병목현상을 줄이기 위한 내용입니다. I/O 병목, 그래픽 대역폭 및 중간결과공유 등 ..
  • 그래픽카드의 경우 DMA처럼 host OS 거치지 않고 바로 다이렉트로 리모트 그래픽 메모리에 접근하는 RDMA 통신을 사용한 게 흥미로웠습니다. 이거 개발하는거 상당한 삽질이었을텐데
  • AI 학습 플랫폼을 개발하는 데 있어 “상태”에 주안점을 둔 것이 눈여겨 볼만한 점이었습니다. 상태를 쉽게 저장하고 불러다 쓸 수 있도록 하는 것이 흥미로운 기능이더라고요.
  • 스케쥴링 관련해서는 성능 최적화를 위해 시스템 설계상 신경써야 할 요인들이 흥미로웠습니다: Gang 스케줄러의 전제조건하에서 리소스 단편화 방지, zone 동기화, 선점 기능 …

흥미롭게도 비슷한 플랫폼으로 serve가 목적인 CLOps를 사내에서 또 개발했더라고요. NSML이 파라미터 조정과 같이 대규모 실험을 병렬로 빠르게 수행하기 위한 요구조건을 보다 신경썼다면, CLOps는 상용 프로세스로 활용될 것을 염두에 둔, 보다 고전적인 워크플로우 수행 플랫폼이라는 생각이 듭니다. (구체적인 사용 예가 없어서 조금 덜 와닿는게 아쉽네요)

6. 몇몇 알고리즘 글들

면접을 봤던 경험과, 면접 인터뷰를 진행하면서 자주 봤던 유형의 문제들을 몇 개 적어 두었습니다. 예전부터 사실 언젠가 써야지 생각하던 내용이었는데 막상 쓰니 후련한 ㅎㅎ. 정작 저는 알고리즘 경시에 쓰는 알고리즘은 잘 몰라요. 그래도 기본적인 자료구조들과 이에 대한 활용들이니만큼, 나중에 쭉 돌아보며 다져갈 생각입니다.