프로그래밍에서의 기본기란?

축구로 비유하자면 드리블, 패스, 볼 트래핑 등에 해당하는 부분이 과연 프로그래밍에선 무엇일까?

로우 레벨에 대한 이해도?
다양한 분야에 대한 폭넓은 지식?
신 기술에 대한 경험과 관심?
낮은 러닝 커브?
알고리즘 구현 능력?
코드 리딩 능력?

여러 지인들과 토의 해본 결과, 너무 다양한 이야기가 나와서 새삼 놀랐다. 어느 한명 같지 않았다.

물론 모수가 늘어나면 비슷한 답변이 생길 수 있지만, 축구처럼 기본기에 대한 정의가 명확하지 않다는 느낌을 크게 받았다.

헌데 아이러니하게도 많은 채용 과정에서

기본기가 좋은 사람을 뽑고 싶어요
기본이 되는 친구를 뽑아서 키워야지

와 같은 말은 매우 자주 들었다.

그 과정에서 나온 문제는, 그 회사에 대다수 사람이 만점은 커녕 반도 못맞출 문제를, 이를 위한 스터디나 학습 시간을 들여서 잘 푸는 혹은 경험해보지 않으면 알기 어려운 문제를 암기 해서 풀어야 되는 문제를 내고 이런 어려운 문제를 잘 푸는걸보니 매우 기본기가 훌륭한 친구로군! 이라는 착각을 한다.

어려운 문제를 푸는 능력과 업무 능력과의 연관성이 전혀 없다고 보긴 어렵지만, 그렇다고해서 기본기가 훌륭하다거나, 업무 적응 확률이 매우 높다거나, 그 직원이 회사에 기여할만큼 성장할 수 있을지 여부는 전혀 다른 문제다.

그럼에도 어려운 문제를 통한 검증과 기본기에 대한 검증을 혼동하는 이유는 아마도 기본기에 대한 정의도 못내린 마당에 기본기를 검증하기 어려우니, 어려운 문제를 잘 푸는 인재라면 기본기도 좋을 확률이 높다고 보는게 아닐까 싶다.

내 생각은 탐구심과 향상심이 프로그래머의 기본기라고 생각한다.

앞으로 얼마나 성장할 수 있는 동력을 가지고 있는가나 좋은 가르침도 중요하겠지만, 도전 주제가 주어졌을 때 얼마나 그 문제를 합리적으로 풀면서 성장할 수 있는가는 탐구심과 향상심이라고 생각한다. (여기에 자기 반성도 필요하다. 자신이 틀릴리 없다고 가정하는 경우에 성장 가능성이 낮다는 내 의견은 여러 번 피력한바 있다)

끈기나 열정은 난 기본기라곤 생각하지 않는다. 필요야 하겠지만 넘칠 필요 있을까? 나 역시 밤샘도, 불철주야 근무, 스터디, 습작, 기술 서적 읽기 등을 잠 줄여가며 해봤지만 그 과정에서 얻은 것도 있지만 만만치 않게 정체됐다. 반면, 일정 수준이상의 근면함도 반드시 필요하다고 생각한다. 창의성이나 지식 기반 산업 종사자라고해서 밑도 끝도 없는 나태함이 허용되는 것은 아니다.

어느정도 밸런스 있게 삶을 유지하면서, 몸과 마음의 여유를 갖고 공부하거나 집중했을 때의 성장이 더 효과적이고, 산출물도 좋았다. 즉 배려와 압박의 적정선의 밸런스가 필요하다고 생각한다.

그렇게 밸런스가 있다보면 업무 만족도와 삶의 만족도가 밸런스가 맞게되면서, 업무를 즐길 수 있는 여지가 생긴다. 그리고, 즐거웠기 때문에 쉽게 지속할 수 있다는 점이 어찌보면 가장 큰 동력이 되지 않나 싶다.

중요한 것은 성장과 퀄리티에 대한 욕심을 얼마나 효율적으로 녹여낼 수 있는가다.

이 과정에서 위에서 언급한 일정 수준 이상의 근면함이 요구된다. 엔지니어는 증명해야하는데, 근면함이 부족하다면 자신의 머릿속에 있는 혹은 가상 시나리오를 증명할 수가 없다.

또한 구현해낸 것은 여러가지 의미로 수준 미달일 가능성도 높다.

당연히 과도한 업무 강도나, 과도한 업무 요구치는 문제가 되고, 이는 나역시 반대하는 부분이다.

향상심을 뒷받침 할만큼의 노력은 실력을 쌓기 위한 근간이고, 프로덕트를 완성하기 위한 근간이다. 그래서 난 이 부분 역시 지적 생산자에게는 기본기라고 생각한다.

자신이 탐구심이 있다면, 그 역시 증명해야 한다. 이를 증명하기 위해선 많은 시행착오를 겪게되는데 이 과정에서 필요한 노력이 작지 않다. (시행 착오를 적게했다면 이미 경험했거나, 자신이 깊게 이해하고 있는 분야의 연장선일 가능성이 높다. 혹은 당신이 천재거나)

배움의 기간이 짧아서, 해본 경험의 스케일이 작다고 느껴서, 만들어놓은 결과물의 디테일에 자신이 없어서, 자신이 알고 있는 지식이 적어서 등등.. 자신의 앞으로의 모습이나 성장에 대해 걱정 된다면, 지금부터 라도 향상심과 탐구심을 갖고 노력해보자.

그 과정이 진지하다면, 장기적인 레이스에서는 따라 갈수도 어쩌면 앞서갈 수도 있지 않을까?

(내맘대로 선정한) 프로그래머를 위한 필독서 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을 높이는 데에 있었음을 알 수 있고, 이 것이 현재의 패러다임이라는 생각이 든다.

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

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