(내맘대로 선정한) 프로그래머를 위한 필독서 16선

내가 읽어온 서적 중에서 프로그래머를 위한 필독서라 느껴졌던 책들을 추천한다.

16개 서적으로 다른 필독서 추천 글 (한상곤님 글, iostream) 보다 의도적으로 조금 더 적게 추천했다.

추천하고 싶은 서적이 늘어나고 줄어들 수 있겠지만, 그 시점에 생각을 반영한 것이니, 새로 글을 작성할 예정이다.

임백준씨 관련 책이 많은 것은 다분히 의도적이니 참고바라며, 자신에게 도움이 될 서적을 고르는데에 보탬이 되길 바란다.

  1. 실용주의 프로그래머
    • 프로그래머의 마음 가짐에 대해서 알려주는 책들 중 가장 적절한 분량에, 핵심 메시지를 잘 요약 전달 해주는 책이다.
    • 자신이 프로그래머인 행세만 하고 살고 싶은 지, 프로그래머가 되고 싶은 지를 이 책의 가르침을 얼마나 따를 수 있는 지로 평가해도 될 만큼 좋은 책.
  2. 대체 뭐가 문제야?
    • 이 책은 프로그래밍 서적이 아니지만, 나는 프로그래머의 필독서로 전혀 부족함이 없는 책이라고 생각한다.
    • 프로그래머는 난제를 자주 맞이하는 숙명을 안고 사는데, 이 숙명에서 유용할 수 있는 책이라고 확신한다.
    • 특히 문제 해결을 위해선, 해결 능력 혹은 해결 권한을 가진 사람의 문제로 만들어야 한다는 얘기는, 직업 프로그래머 생활 하는 내내 큰 도움이 되었다.
  3. 누워서 읽는 알고리즘
    • 먼저 나온 것은 행복한 프로그래밍이지만, 나는 임백준씨 서적 중에 제일 먼저 읽게 된 서적이다.
    • 어려운 알고리즘을 누워서 읽을 수 있다고? 약을 파는 듯한 제목이었지만, 그 약은 마약도 아니고 나에게 충격이며 감동이었다.
    • 알고리즘 이야기를 다양한 주제와 엮어 쉽게 표현한 임백준씨의 재능은 임작가라는 별명 처럼 뛰어나며, 개발자계의 로맨티스트가 아닐까 싶은 감동을 주었다.
    • 당신이 프로그래밍으로 인해 조금 지친다면, 이 책을 읽어보는건 어떨까?
  4. 행복한 프로그래밍
    • 위에서 너무 극찬을 많이해서 딱히 쓸말은 없다.
    • 다만 프로그래밍으로 인해 행복하다는, 행복하기 위해 프로그래밍 한다는 그런 말도 안될거 같은 이야기에 속아보고 싶다면 이 책을 읽어봐라. 아마도 임백준씨의 다른 책들도 모두 읽게 되겠지만, 시작은 이 책이나, 누워서 읽는 알고리즘이 적당할 것이다.
  5. Refactoring
    • 이 책을 제대로 읽고, 리스크가 적게 리팩토링해라.
      • 특히 서비스 중인 코드를 고칠땐 더더욱.
    • 괜히 설계 다 뒤엎고 새로짜면서 리팩토링한다고 착각하지 말자.
      • 리팩토링은 동일한 동작을 유지하면서라는 전재가 있다. 잊지 말자.
  6. Legacy 코드 활용 전략
    • Legacy 코드에서 배워라.
    • Legacy 코드를 안정적으로, 개선하는 Test Driven Refactroing에 대한 방법과 방향성에 대해서도 알 수 있는 좋은 서적이다.
    • 몇몇 방법은 Legacy 코드를 감추면서라도, 기존 동작을 유지하라는 이야기도 있는데, 찜찜하면서도 합리적인 해결책중 하나였다.
      • 어찌보면 문제를 격리하고, 이외의 영역을 Clean하게 관리하고 보호할 수 있다면 그것도 나쁘지 않겠다 싶은 결론이다.
  7. Test Driven Development
    • 지금은 한풀 꺾인 TDD에 대한 바이블.
    • 지금은 TDD보다는 유닛 테스트 자체가 살아남은 편이고, 코드 리뷰에 대한 관점이 더 많이 고민되고 있는게 사실이지만, TDD 자체가 무의미하진 않다.
      • 번거로울 뿐.
      • 그 번거로움을 낮추는 이야기가 없고, 쉽지 않은 문제라 (프로젝트의 상황과 레거시 코드의 뿌리에 따라 다르기 때문) 그렇겠지만, TDD로 개발할 수만 있다면 퀄리티는 예상보다 크게 높아진다.
      • TDD를 한다고해서, 코드 리뷰나, 별도의 QA가 없어도 되는것은 아니다. □ 방심 금물.
  8. Art of Unix Programming
    • 전격 윈도우 디스서.
    • 유닉스는 프로그래머를 위해 우월하고, 윈도우는 그렇지 않다는 이야기가 꽤나 길게 다뤄진다.
    • 사실 유닉스의 쉘 기반 문화는 훌륭한 것이 맞지만, 사용자 기반 문화의 윈도우와 맥이 가진 장점도 분명히 꽤 있음.
    • 윈도우의 GUI 기반 문화로 인해 쉘 기반 연동마저 어렵게 만들어버린 것은 아쉽지만, 윈도우의 태생과 발전하게 된 계기가 어찌보면 그런 부분을 포기하고 GUI로만 무언가를 할 수 있게 했기 때문이 아닐까 싶은 생각도 든다.
    • 윈도우에 대한 반감이 있다면 반드시, 호감이 있다해도 한번쯤은 읽을만한 서적.
  9. 폴리글랏 프로그래밍
    • 자바의 발전 속도가 더디다 못해, 멈췄다고 느낄 때 쯤 나온 서적.
    • C#의 빠른 발전 속도와 발전 방향에 대한 찬양의 내용이 많아 국내에선 이견이 많았던 서적.
    • 지금은 자바도 빠른 발전 속도를 내고 있지만, 오라클의 유료화로 인해 자바의 운명은 어찌 될지 잘 모르겠다.
    • 결론은 적재 적소에 합리적인 언어 사용을 통해 효율과 완성도를 올리자는 이야기.
  10. Modern Effective C++
    • 이제는 C++ 0x 이후와 이전으로 나뉜다.
    • 11, 14, 17등 마일스톤을 정해가며 지속적으로 발전하고 있는 C++에 대한 깊은 이해를 원한다면 이 책이 최적이다.
    • C++이 죽지 않았다고 주장하는 사람들의 근거가 될 수 있는 서적.
  11. The C++ Programing Language
    • TCPL이라 불리우는 C++의 창시자 비야네 스트롭스투룹의 저서.
    • C++의 다양한 문법과 제약이 어떠한 근거로 만들어졌는지 알 수 있는 서적으로써, 언어에 대한 이해도를 한층 높일 수 있다.
    • 이제와서는 Modern Effective C++과 같이 읽어야 더 큰 의미가 있을 서적.
      • 현재 Modern C++의 발전 방향과 당시의 비야네 스트롭스투룹의 생각과 비교하면서 읽어보자.
  12. 자바의 신
    • 자바 입문서로 적격.
    • 쉽고, 친절하다. 최근 개정서도 나온 만큼 더 완성도가 올라갔다.
    • 나 역시 자바 학습하면서 이 책을 봤는데, 충분히 추천 할만큼 쉽고 적절한 순서로 구성 되어있다.
  13. 코딩호러의 이펙티브 프로그래밍
    • 스택 오버 플로우의 창시자가 말해주는 소프트웨어 개발/관리 이야기.
    • 스택 오버 플로우의 창업자가 조엘만 알았는데, 제프 앳 우드가 엔지니어링 적인 부분을 대부분 책임지고 개발했다는 것을 나중에 알았다.
    • 해외에서도 지원자에 대한 검증 이슈나, 프로그래밍도 못하는데 프로그래머로 지원하는 지원자가 있어서 괴롭다는 이야기를 할줄 몰랐다. 꽤나 큰 충격.
    • 원격 개발을 하면서도 퀄리티를 낼 수 있고, 내고 있다는 사실에도 꽤나 큰 충격이었다.
    • 이외에도 훌륭한 선배 프로그래머의 생각과 조언을 들을 수 있는 훌륭한 서적이 아닌가 싶다.
  14. 윈도우 개발 282 스토리
    • 윈도우가 왜 이런 모양새가 되었는가를 설명해주는 서적.
    • 심시티를 위한 예외처리를 통한 하위호환 이야기는 게임의 파급효과와 영향력에 대해 다시금 고민하게 됐다.
    • 위에서 언급한 The Art of Unix Programming에서의 비난 대상이지만, 나는 윈도우가 훌륭한 OS고 이런 다양한 하드웨어위에서 안정적으로 동작할 수 있게 끌어올린 선택과, 엔지니어링 기술력은 시대의 큰 획을 그었고, 그 과정에 대한 자세한 이야기를 들어보는 것은 꽤나 가치가 있는 일이 라고 생각한다.
  15. 대살개문
    • 전격 팩폭서.
    • 한국의 개발환경이 조금 더 좋아지길 기도하며, 읽어보자.
    • SI를 해보지 않았지만, 그럼에도 철야, 야근을 자주 했던 과거와, 엔지니어이면서도 탱킹 (몸으로 때우면서 일하는)을 해야 했던 지난날, 엔지니어링 퀄리티와 사업적 경쟁력과 동떨어진 현실, 엔지니어링은 알아서 잘해야 하는 것이라는 느낌을 받았던 나날들을 떠올리며 공감할 수 있었다.
    • 중간 중간 대한민국에 대한 이야기가 아닌 챕터도 꽤 많았지만, 임백준씨의 확고한 철학과 생각을 공유할 수 있어 좋았다.
  16. 7가지 동시성 이론
    • 병렬 처리에 대한 다양한 접근과 구현 방법, 변화 방향등을 살펴보며 대용량 처리의 근간인 병렬 처리 (동시 처리)에 대한 이해도를 높일 수 있다.
    • 스케일 인 아웃이 중요하다지만, 여전히 인스턴스 내에서의 처리량도 크게 중요한 문제다. (쓰루풋 대비 스케일 아웃 해야 할 인스턴스가 덜 필요하기 때문)
      • 그런 측면에서 꼭 읽어볼만한 책이 아닌가 싶다.
    • 함수형 프로그래밍이 왜 화두인지, 스칼라가 왜 주목받았었는지, 액터 모델이 왜 각광 받았는지 등을 짧은 시간에 이해할 수 있는 좋은 책이었다.

LOL 게임 기록 (+임무) 장애에 대한 이야기

자주 언급하진 않았지만, 나는 취미로 LOL을 플레이한다.

이번 주말 (토요일 오후) 통계가 쌓이지 않는 오류가 발생했다.

처음에는 op.gg와 같은 통계 사이트에 제공되는 API 서버 오류인걸로 추정했으나, 토요일경에는 하루 이전 데이터만 보였고, 현재는 모든 경기 기록 데이터를 조회할 수 없다.

오류

이에 대해 라이엇 게임즈 측에서는 공지를 올렸는데 내용은 다음과 같다.

임무 오류 관련 공지

내용은 임무 달성 관련 오류였는데, 나는 장애 시간을 잘 피해서 플레이 했는지 임무는 잘 진행됐다.

임무 관련 오류의 시작 시간부터, 현재까지 대전 기록은 표시되지 않는다.

추정해보면, 몇가지 가정을 할 수 있다.

  1. 대전 기록 처리는 두 종류로 나뉘어져 있는 것 같다.
    1. 승/패/MMR 변동/LP 변동
    2. 상세한 통계 기록. (KDA를 포함한 디테일한 결과 데이터)
  2. 1-1번에는 문제가 없었다. 그래서 라이엇이 장애 발생시 랭크 게임을 닫아버리는 대처는 하지 않았다.
  3. 1-2번에 문제가 생겼고, 이로 인해 대전 기록이 남지 않았다.
  4. 1-2번 대전 기록을 남기는 시점에서 임무 해결 처리도 같이 트랜잭션을 묶어 처리했다.
    • 이를 분리함으로써 임무 장애는 해결됐다. (추정)

이렇게 추정되는데, 세부적인 구현과 예외 처리는 어떻게 되어있는지 알 수 없으나, 종종 있어왔던 라이엇의 통계 시스템 오류로 돌이켜보았을 때, 결합도를 분리하는 선택으로 장애 리스크를 감소한걸로 보인다.

통계 데이터 오류가 종종 발생하는걸로 보아서, 통계 시스템이 큰 하나의 벌크로 운영되고 있는건 아닐까 싶은데, 이에 대한 결론은 통계 시스템 복구 이후로 미뤄야 할 것 같다.

raw 데이터는 잘 쌓고 있고, 그 데이터를 pipeline으로 보내서 처리되는 과정에서의 오류라면 현재 장애 발생중이 플레이 데이터도 통계에 반영이 될 것이고, 그렇지 않다면 raw데이터가 사라져 해당 기간중 플레이데이터가 유실됐을 것이기 때문이다.

라이엇이라면, raw데이터는 살아있어 곧 복구되게끔 잘 갖춰놓았을 것이라고 기대해본다. 기나긴 한국 서버 장애를 겪고나서는 같은 문제를 겪지 않는 잘 성장하는 라이엇 엔지니어링 문화를 믿어본다.


2018-07-02 오후 1시경 추가

오후 1시경에 확인해본 결과 장애 기간의 전적 정보가 되살아났다.

raw데이터는 살아있었던 상태였고, 이를 다시 stream에 밀어넣음으로써 전적 정보가 제대로 반영되었음을 (격리와 fail-over에 대해서 제대로 만들었음을) 확인 할 수 있었다.

라이엇이 운영 환경 장애를 겪으면서, 엔지니어링 적으로 발전했음을 확인 할 수 있는 단면 아닌가 생각이 든다.

Mongodb 팁

mongodb를 로그 디비로 운용하며 생긴 이슈 및 쿼리 튜닝에 대한 내용을 간략하게 정리해보았습니다. 운용을 검토중이시거나 운용 중이신 분들, NoSQL로 선정 고려중이신 분께 도움이 되면 좋겠네요.

  • 인덱스 작성시 쿼리와 1:1 대응 시켜라.
    • 적합 인덱스를 못찾았을 경우 rejectPlan을 타게 되는데 이 때, 매우 비효율적인 연산이 일어날 확률이 컸다.
  • 쿼리에 index가 의도대로 동작하지 않으면 hint를 줘라.
    • 그럼에도 느리다면 대게는 hint를 잘못 준 것.
  • group 연산시 인덱스에 없는 값을 필요로 할 경우, 해당 값에 대해 찾느라 디스크까지 내려갔다 오는 비용과 인덱스 못찾는 비용으로 소요 시간이 급격히 커질 수 있음에 유의하라.
    • 즉 group 연산 내에 들어가는 컬럼이 모두 index에 존재해야 성능상 이득이 크다.
      • group, match, project등의 연산도 모두 index에 존재해야 한다는 점에 유의하라.
  • 메모리를 확보하라. 인덱스가 메모리 영역에 올라와서 연산하기 때문에, VM이던 리얼 머신이건 램이 중요하다.
  • explain을 통해서 인덱스를 어떻게 타는지 확인하라.
    • winningPlan, rejectPlan을 참고하라.
    • winningPlan을 탈 것인지, rejectPlan을 탈 것인지를 알려주지 않지만, winningPlan을 탈 가능성이 있는 쿼리라는 것은 확실히 알려준다.
  • 메모리에 올라와있는 데이터냐 아니냐에 따라서 성능이 급격히 차이난다.
    • 인덱스 크기를 메모리 용량보다 작게 사용할 수 있도록 하는 것을 권장한다.
    • memory mapped file 기반이라는 것을 항상 유념해야 한다.

리액티브 프로그래밍

리액티브 프로그래밍에 대해 간단히 설명하자면, 다음과 같은 특징과 가치를 모두 보유한 시스템을 의미한다.

Reponsive (Future Pattern) : 요청 즉시 응답을 준 뒤, 실제로 완료하고 나서 다시금 응답한다.

Elastic: 결합도가 뭉텅이 작업이 아닌, 작은 동작의 조합으로써 하나의 큰 로직을 구현함으로써, 확장성있게 시스템을 구축하는 데에 목표가 있다.

Resilent : 상태를 갖지 않으므로, 회복 탄력성과 응답성을 가질 수 있다.

Message-driven (Reactor Pattern) : 메시지 기반으로 동작함으로써 클래스간 결합도는 존재하지 않는다. 자연스레 유연하고, 상태에 영향이 적어진다. 메시지를 처리 후에 삭제하므로, fail-over에도 강하다.

나는 처음 리액티브 프로그래밍이 비동기와 아주 큰 연관이 있을거라고 생각했다.

물론 연관이 없지 않다. 리액티브 프로그래밍이 구현되기 위해선 비동기 기법, 비동기식 동작이 반드시 필요하다.

하지만 내가 찾아본 바로는 리액티브 프로그래밍에서의 큰 가치는 비동기 데이터 흐름이 좀 더 큰 포커스였다.

“리액티브 프로그래밍(Reactive Programming)은 비동기 데이터 흐름(data flow)에 기반을 둔 프로그래밍 패러다임이다. 데이터 흐름은 마치 강과 같아서 이를 관찰하거나 필터링하거나 다룰 수 있으며 새로운 사용자를 위한 새로운 흐름을 만들기 위해 다른 흐름과 병합할 수도 있다.” (RxJava Essentials 21p) 

비동기 데이터 흐름을 만든다는 것은, 같은 input이 발생했을 때 같은 output이 발생해야하며, 그러기 위해선 가변 상태를 보유하지 않아야 한다는 점에서 함수형 프로그래밍 패러다임과 일맥 상통한다.

즉 언어는 함수형이 아니지만, 코딩은 함수형처럼 해야 리액티브 프로그래밍의 핵심 가치를 지킬 수 있다는 점이다.

[리액티브 시스템vs리액티브 프로그래밍] http://blog.lespinside.com/reactive-programming-versus-reactive-systems/

  • 2015년부터 특히 2016년에 상용 미들웨어 벤더사와 사용자 모두 리액티브에 대한 관심이 급격히 증가했다.
  • 구현 관점에서 리액티브 프로그래밍은 리액티브 시스템의 일부이다.
  • 리액티브 프로그래밍은 컴포넌트 수준에서 내부 로직과 데이터 플로우(flow) 관리를 위한 성능과 자원 효율성을 통해 개발자의 생산성을 높여준다.
  • 리액티브 시스템은 시스템 수준에서 “클라우드 네이티브”[1] 혹은 다른 대규모 분산 시스템을 구축하기 위한 복원성과 탄력성을 통해 아키텍트와 데브옵스의 생산성을 높여준다.
  • 리액티브 시스템의 컴포넌트 안에서 리액티브 프로그래밍을 사용하는 것은 매우 유용하다.
  • 리액티브 프로그래밍을 사용하여 작성한 컴포넌트들로 시스템을 만들 때 리액티브 시스템을 사용하는 것은 매우 유용하다.

리액티브 프로그래밍에 대해 알아보고자 했을 때, 리액티브 시스템 얘기가 함께 나왔다. 그래서 찾아봤던 부분인데, 리액티브 시스템은 리액티브 프로그래밍으로 이루어진 소프트웨어를 시스템 단위에서 리액티브하게 다룰 수 있고 운용 할 수 있는 환경을 의미하는 것으로 이해했다.

즉 GCP같은 PaaS레이어의 auto-scaling이라던지, docker swarm을 통한 scaleing, AWS등의 클라우드 서버에서의 트래픽에 따른 scaling이라던지하는 자동화 된 시스템 확장 축소를 리액티브 시스템이라고 지칭하는 것이더라.

이렇게 이해하고나니, 사실상 리액티브 프로그래밍의 맥락도 국지적 최적화 (in-process 최적화)를 벗어난, 높은 확장성을 통한 through-put 향상이 목표였음을 알 수 있다.

결국 핵심은 많은 데이터를 다루기 위한 접근이, bulk를 크게 구성해서라도 전체적인 through-put을 높이는 데에 있었음을 알 수 있고, 이 것이 현재의 패러다임이라는 생각이 든다.

내가 국지적 최적화의 관점에서 오래 코딩을 해온 시스템 프로그래머의 레이어에 오래있었음에도 이런 접근은 공감이 됐고, 실제로 더 많은 양의 데이터를 처리하기에 적합하다.

또한 굳이 대용량 처리를 말하지 않아도, 로직 처리에서도 빠른 응답에 대한 가치는 높다. 그래서 리액티브 프로그래밍이 화두가 되고 있지 않나 생각이 든다.

비동기 프로그래밍 관점에서의 Akka

Akka란 Actor 기반 시스템의 한 구현체이다. 메시지를 주고 받을 수 있는 단위를 Actor로 놓고, Actor간의 통신을 메시지 수신으로써 처리하는 개념이다.

Win32에서의 메시지 기반 프로그래밍의 수신자를 여러 개 두는 개념이라고 봐도 무방하다. 프로세스 내에서의 메시지 단위 통신이라고 할까?

지켜야 할 것은 다른 Actor간의 메소드 직접 호출이 있어선 안된다는 점이다. Life-cycle이 유지되고 있는 Actor에 대한 메소드 호출은 동기화가 깨진다.

Akka는 메소드 직접 호출보다는 느리지만, 메시지 큐를 통한 접근 스레드를 하나만 유지함으로써, 멀티 스레드 동기화 이슈를 우회하는 접근이다.

싱글 스레드 구조에서, 요청에 대한 위임, 그에 대한 응답을 메시지 큐를 통해서 처리하는 WIN32 메시지 기반 프로그래밍이나 Node.js 방식과 차별화 된 요소는 바로 이 점이다.

주체적으로 동작하는 개체를 여러 개로 두면서도 (=멀티 스레드로 로직이 동작하면서도), 스레드 동기화에 대한 이슈를 제거했다.

이 경우의 핵심 고려 요소는 메시징 시스템 자체는 멀티 스레드 기반하에 동작시키게끔 구현되어야 하며, 메시징 시스템의 성능이 크게 영향을 주므로, 뛰어난 성능이 보장되어야 한다.

또한 Actor에 대한 Life-Cycle관리가 아주 중요하다.

이런 몇가지 고려 요소에 대해 신경쓴다면, 그만큼 얻을 수 있는 이득은 크다.

가장 중요 한 것은 멀티 프로세스보다 성능이 좋은 멀티 스레드 비동기 병렬 프로그래밍 로직을 적은 고민으로 구현 해낼 수 있다는 점이다.

Akka는 인프로세스 메시징 큐를 사용하는 것보다 좀 더 고차원적인 병렬 처리와 fail-over, persistence 등을 지원한다.

자세한 내용은 http://wiki.webnori.com/pages/viewpage.action?pageId=1507350를 참고하면 더 깊게 이해할 수 있다.

내가 Akka를 쓰면서 놀라웠던 것은, 몇가지 쉬운 원칙만 지키면 멀티 스레드 로직 프로그래밍보다 안전하면서도 높은 성능(through-put)의 시스템을 구축 할 수 있었다는 점이다.

멀티스레드 로직 프로그래밍은 조금만 삐끗나도 lock이 길어지거나, spin-lock이 발생하거나, 경합, 데드락이 발생하기 쉽상인데 그런 측면에서의 우려가 적으면서도 성능도 우수했으며 scale out에도 유연했다.

즉 직접 네트워크 라이브러리를 구현하는 사람 (Netty, SuperSocket, Asio 등등)이 아니라면 난이도도 높고, 막상 멀티스레드 로직을 직접 구현할 것이 아니라 Akka와 같은 비동기 메시징 시스템을 사용하는 것이 좋다고 본다.

함수형 프로그래밍도 내부적 상태를 갖지 않는 함수들 만으로 구현함으로써, 가변 데이터로 인해 생기는 데이터 안정성과 병렬 처리의 어려움에 대해서 회피하고자 다시금 주목 받은 측면이 크다.

함수형 프로그래밍의 이질감과 비직관성에 대한 적응이, 멀티 스레드 로직 프로그래밍이 가진 높은 복잡도와 제약들 보다 낫다는 결론이 한쪽 진영에서 있었다고 생각한다.

그걸 감안한다면 Akka와 같은 Actor기반 프로그래밍은 또 하나의 좋은 대안이고, 많이 선택되어 왔다.

사실 Akka는 함수형 프로그래밍과 멀티스레드 로직 구현과의 중간점에 존재하는 느낌도 강하다.

Akka를 통해 상태 기반 프로그래밍도 가능하지만 이는 몇가지 대안과 함께하지 않으면 fail-over를 어렵게 만드는 리스크가 되기도 하고, 함수형으로 시스템을 완성할 수 있으면 굳이 Akka를 쓰지 않아도 되기 때문인 측면이 있기 때문이다.

하지만 상황에 따라선 상태 기반 프로그래밍을 써야할 때가 있다. 또한, 캐싱을 통해 크래시가 발생했을 때의 리스크를 줄이는 접근을 통해 리스크 최소화를 하는 접근도 납득할만하다.

여러가지 측면에서 봤을 때, 함수형 프로그래밍이 좀 더 지지를 받고 있는 상황임에도, Akka와 같은 Actor 기반 프로그래밍도 현재로썬 적절한 병렬 처리 선택지 중 하나 아닐까 싶다.