비동기 프로그래밍 관점에서의 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 기반 프로그래밍도 현재로썬 적절한 병렬 처리 선택지 중 하나 아닐까 싶다.

도구의 중요성

명필은 붓을 가리지 않는다.

이 말이 와전 된 말이라는 것은, 이젠 꽤나 많은 사람들이 알게 됐다.

‘명필이 붙을 안가린다’라지만 사실은 붓을 가린다. - http://yopangyopang.tistory.com/296

개발 도구도 똑같다.

툴마다 어마어마하게 큰 생산성 차이를 낸다. 중요한 것은 절대적 툴 차원에서의 지원의 차이도 물론 존재하지만 자신에게 익숙한 툴인가도 매우 중요하다. (특히 단축키)

너무나 당연한 얘기지만 중요하게 여기는 포인트는, 내가 원하는 기능들이 온전히 제공 되는가이다.

intellisense, open declaration, open implement, formatting, checkstyle, debugging (watch, stacktrace, step into, step out, recompile and continue 등), performance, package manager interlocked 같은 다양한 관점에서 얼마나 만족도가 높은가이다.

다양한 관점의 만족도가 전반적 유료 툴들이 높은편이지만, 비용은 현실적인 문제니 검토 대상에 포함될 수 밖에 없다.

나는 Visual Studio를 오래 써왔었고, 자바를 처음 사용할 때도 IntelliJ IDEA를 써서 못 느꼈는데 Eclipse는 큰 확장성에 비해서 너무 느렸다.

Visual Studio

Visual Studio는 완벽에 가까운 개발 툴이다. 현재는 Community 버전으로 개인 프로젝트 단위는 무료 사용 가능하다는 큰 장점이 있다.

Intellij IDEA

JetBrains의 명성을 널리 알리기 시작한 시발점이 된 Java IDE. Key Set과 Color Theme만 바꿔도 딱히 손댈 게 없을 만큼 기능 지원이 우수하다.

Eclipse

오랜 기간 명맥을 유지해온 무료 IDE. Java 전용이 아님에도 Java 진영에서의 오랜 선택을 받아온지라 그런 이미지가 있다. Plugin 설치로 기능 확장이 여러가지 면에서 가능하나 대다수의 기능 설정을 개인이 해야하며, 성능 이슈가 존재하는 아쉬움이 있다.

Eclipse를 사용하고 있던 팀에 합류했다보니, 나도 자연스레 Eclipse로 환경 설정을 하게 됐고, 기능적으로는 부족함이 없었음에도, 플러그인으로 구현되면서 문제로 보여지는 많은 파일을 잡고 있는 문제 (runtime이 아닐 때에도 pom.xml을 통해 참조되는 maven jar를 모두 잡고 있었고, UI 갱신 속도도 무척이나 느렸다. 아마도 보안 프로그램과의 충돌이 원인인 상황)였는데, 테스트 삼아 설치해본 IntelliJ IDEA의 trial버전은 이런 문제가 전혀 없었다.

그리고 그것이 IntelliJ IDEA 구매 요청하게 된 계기가 됐다.


보안 프로그램과의 충돌의 가능성이 높은 것은, 파일 억세스를 통한 기능 확보 방식으로 구현된 기능들이 문제였다.

이는 쉽게 개선되기 어려운 문제이기도하고, 무료 툴에서 덜 관심을 가지는 성능 이슈에 대한 아쉬움이기도 했다.

그에 비해 Eclipse와 같은 무료툴이며, 범용 툴인 Atom이나 VS Code는 plugin 설치로 인한 실행 속도 감소가 매우 적었다. 다만 플러그인을 통한 기능 지원도 제한적이긴 했다.

Atom

Github에서 만든 Text Editor이자, IDE. Plugin 방식으로 기능이 확장 되는 구조다.

Visual Studio Code

최근 내가 사용하고 있는 툴. Atom 기반이나 단축키가 Visual Studio 키셋과 동일하며, Plguin 개발이 활발해 매우 다양한 언어 개발 용도나, Text Editor 용도로써의 사용에도 매우 편리하다.

가볍게 사용 했을 때는 문제가 없었지만, 특정 언어나 프레임워크에 종속적인 설정 파일 관리/편집 기능, linter, formatter 설정에서 아쉬움이 존재했다.

Notepad++같은 순수 Text Editor보다는 구동 시간이 느리지만, IDE들 보다는 훨씬 빠른 구동 시간은 장점이다.

요약하자면, 자신이 툴 종속적인 기능을 잘 활용하고, 그에 대한 메리트를 느낀다면 전용툴, 유료 툴을 적극 검토해야 한다는 의미다.


내 경우에는 사용해야 하는 툴의 종류로 IDE, Database Tool, SSH Tool, REST API Test Tool, Text Editor 등의 툴들이 필요하다.

여기에 사용해야 되는 프로그래밍 언어, DB 종류가 늘어난다면 사용해야 될 툴이 늘어날 수도 있다.

사용해야 되는 툴이 늘어난다면, 툴의 특화 기능도, 단축키도, 암묵적인 룰도 학습 해야하며, 태스크 전환시 부담이 될 수 있다.

도구가 내 손에 딱 맞았을 때의 생산성은 매우 높다. 반면 도구에 익숙하지 않은 상태에선 한번 더 생각하거나, 어떤 메뉴나 단축키로 설정된 기능인지 생각해야 될 때의 생산성은 매우 낮다.

내 경우에는 Visual Studio로 개발을 시작했으므로, 여러 개의 툴을 사용할 시에도 Visual Studio key Set으로 모두 맞추어서 적응 코스트를 낮춘다.

내가 필요한 기능이 해당 툴 선정 조건에 포함되었으므로, 당연히 툴 사용에 불편함은 없다.

이와 관련해 나는 집, 노트북, 회사 PC의 환경을 최대한 일치시키려 하는데, 이는 작업시의 적응 비용을 최소화 하기 위한 노력이다.

애초에 환경을 최대한 유사하게 세팅 해둔다면, 불시에 작업을 해야 되거나, 머릿속의 생각을 구현하기 위해 바로 코딩을 하려 했을 때 환경 구성에 대한 시간 소요 없이 즉시 작업에 돌입 할 수 있기 때문이다.

자신이 최상의 퍼포먼스를 내는 환경이 무엇인지 떠올려보고, 그런 환경에 최대한 근접하게 하기 위한 노력이 필요하고, 그 중에서도 내 손에 맞는 도구는 매우 중요도가 높다.

자신이 효율성에 대해 고민하는 사람이라면, 도구의 중요성도 고민 선상에 두는 것은 어떨까?

실수를 두려워하지 않기

누구나 실수를 한다.

더 나아가 누구나 버그를 만든다.

구글도, MS도, 애플도 넷플릭스도 아마존도 버그를 만든다.

버그 없는 소프트웨어는 존재하지 않는다.

사용자 입장으로 가정하면, 정말로 버그 없는 소프트웨어는 존재 할 수 없다.

조금은 억울한 이야기는 하드웨어 오류로 인한 버그마저 소프트웨어에 대한 불신으로 이어질 수 있고, 사용자에겐 그것은 어떤 티어의 문제였건 간에 버그다. 불편한 사용성, 하드웨어 fault로 인한 오류, 네트워크 응답 속도로 인한 오류마저 버그로 간주 될 수 있기 때문이다.

위 상황마저, 개발자가 커버해야 된다는 얘기냐고? 오히려 그 반대에 가깝다.

소프트웨어 기업이라면 개발자의 실수가 어떻게 받아들여 지느냐에 따라 그 기업의 성장력에 차이를 낸다.

과감해야 할 때와 그렇지 않아야 할 때, 많은 코스트를 들여서라도 새로운 시도를 해야 할 때, 보수적으로 접근해야 할 때를 엄격히 구분하고, 그에 대한 판단과 책임은 회사가 져야 한다.

개인이 지나치게 부족한 역량과, 지나친 월권으로 안정성을 해치고 있는 케이스는 물론 개인의 책임이다. 이 사람이 변화에 적절한 상태인지, 얼마나 합리적인 결론을 낼 수 있는지에 대한 판단은 회사의 몫이다.

대다수의 과감한 시도로 인한 리스크마저 개인이 떠안아야 한다면, 어느 누구 과감한 선택과 도전을 하려 할까?

새로운 시도, 노력없이 성장 할 수 있는 소프트웨어는 없다. 심지어 보수적인 선택으로 기존 기술을 선택한다 하더라도, 안정성은 보장 할 수 없다.

심지어 코드 한 줄 작성 안하고 운용하는 소프트웨어라 할지라도, 그에 대한 대처가 되어있지 않은 환경에선 사고가 날 가능성은 존재한다. 심지어 그 확률마저 꽤나 높다. 변화를 기피하는 보수적인 선택이 안정성에 대한 해결책이라 여기는 분들 입장에선 슬픈 이야기겠지만 말이다.


결국엔 얼마나 변화와 안정성, 디테일간의 밸런스를 맞출 수 있느냐에 문제다.

그 과정에서 한번에 완벽하게 변화할 순 없기에 그 과정을 두려워하지 않게 만들어주어야 한다.

두려움을 느낀다면, 마지못한 도전을 할 것이고, 가능한한 보수적인 접근으로 적은 실수를 혹은 실수를 하지 않게끔 행동 할 것이다.

당연하게도 그 과정에서 얻는 경험과 통찰 등 실수로 인해 얻을 수 있는 소득은 줄어들 것이다.

실패로, 실수로 인해 배우는 것은 너무나도 크다.

실패를 적게 한 사람은 실패로부터 배우는 방법마저 모른다.

그 방법을 알 수 있게, 더 많은 걸 실패로 부터 배울 수 있게 지원해야 하며, 과감함 속에서 성장하고, 그 성장을 밑바탕으로 삼을 수 있는 고민과 문화를 만들어야 한다.

발전하고 싶다면 말이다.

경험과 인사이트

누군가가 말한다. 경험이 전부라고.

또 다른 누군가는 말한다. 경험보다 재능이라고.

사실은 두가지 모두 중요한 요소다. 내 경험상 서류와 수치로 증명 가능한 재직 경력, 좋은 회사 재직자, 좋은 학교 졸업자 같은 것들이 무의미하다는 것은 아니지만 그것이 전부라 보기 어렵다.

그런 서류나 수치적인 것들을 뛰어 넘는 루키들은 업계에나 있어왔지만 그 수가 많지 않았고, 경력자라고 해서 실력을 보장해주지 않는다.

특히 각종 커뮤니티에서, 우리 업계 출신 프로그래머가 더 잘해 같은 부심이 오고 가는 것을 보면, 꽤나 많은 사람들이 경험의 기간보다, 경험의 종류의 차이를 좀 더 높게 평가하는 듯 하다.

재능이 있는 사람은 경험도 뛰어넘는다. 그렇지만 그 경험이 경험의 종류나, 경험의 기간을 뛰어 넘는 것이 대부분이었다.

그렇다면 흔히 말하는 인사이트란 무엇인가?

insight 미국·영국 [ɪnsaɪt]  영국식   중요

  1. 통찰력
  2. 이해, 간파

사전적 의미로 통찰력이다. 바로 어떠한 일의 본질과, 상황의 핵심을 꿰뚫는 능력, 무엇이 더 중요한지 이해하는 능력 등의 넓은 시야로 상황을 파악하는 능력이라고 볼 수 있다.

통찰력의 근간은 유추 능력이다.

경험이나 학습, 관찰, 독서 등의 다양한 방법으로 접하게 되는 정보들을 연관 짓고, 연관성을 바탕으로 솔루션을 얻는 것을 통찰력이라고 할 수 있다.

창의력은 참신한 것을 발상하는 능력이라고 봤을 때, 통찰력은 참신할 필요는 없다. 문제의 본질을 파악하고, 적합한 솔루션을 선택하는 능력이 필요하다.

이런 능력을 어느정도 타고난 사람들이 분명히 존재한다. 위에 언급한 능력들과 창의력이 더해져서 통찰력으로 표출되는 경우가 있지만, 이는 흔치 않는 케이스였다.

대 다수는 정보가 많거나, 유사 혹은 동일한 경험에서 교훈을 얻었던 것들 사이의 연관성과, 현재 상황과의 매칭을 통해서 해결책을 떠올리는 케이스가 다수라 할 수 있다.

경험이 다양하다는 전재로, 이 사람이 합리적이고 논리적인 사람이라면 반드시 통찰력을 갖추고 있을 것이라고 가정 하기에, 주로 경험이 많은 (경력이 많은) 사람을 시니어 프로그래머 부르며 선호하는 것이다.

나 역시 주어진 주제에 대해서 통찰력과, 고찰을 통해 좋은 솔루션을 가진 사람이 여러 논란이 있는 시니어 프로그래머에 어울리는 사람이라고 생각하지만 이는 경력과 비례하지 않기에 (그래서 각종 채용 논란이 있는 것이지만), 그 사람이 진지하게 개발을 해온 경험이 있고, 그 경험을 진지하게 마주해왔다면, 너무나 당연하게도 시니어 프로그래머라는 명칭이 아깝지 않은 사람일 거라고 믿는다.

그리고 난 시니어 프로그래머라는 명칭은 경력이 아닌, 이 사람의 통찰력에 대해서 주어져야 하는 것이라고 생각한다.

그만큼 프로그래머의 문제 해결 능력은 중요하고, 그 만큼 통찰력이 그 프로그래머의 경쟁력이고 아주 중요한 능력 중 하나다.

그 능력을 개발하기 위해선, 진지한 개발태도가 중요하다. 그럭저럭 나쁘지 않은 결과물을 만들려는 태도와 회고와 반성을 게을리 하는 사람에겐 통찰력을 비롯한 발전은 아주 더딜 것이다. 그리고 그런 사람이 내는 결과물은 당연하게도 퀄리티가 좋을 리 없다.

그런 사람은 통찰력을 가진 척 할 수 있을 뿐이다. 진짜 통찰력을 갖기 위해서는 다양한 경험과 시각을 가지고 진지하게 결론 지을 줄 알아야 한다.

그리고 그 결론을 가지고 다양한 사람과 나누다 보면 진짜 통찰력에 가까워질 수 있을 것이다. 그리고 그런 사람들이 더 많은 팀이, 더 많은 회사가 효율적으로 더 뛰어난 퀄리티의 결과물에 도달 할 거라 믿는다.

오픈 소스 기여하기

내가 프로그래밍을 처음 공부하던 시기였던 97년 즈음에 자료를 구할 곳이라고는 책과 PC통신 (하이텔, 나우누리), 인터넷(넷츠고를 통한)이 다였다.

그 즈음해서, 자료를 구하기한 쉬운 문제가 아니었고, 그 자료도 소수의 훌륭한 개발자 분들이 공개해주신 자료에 근거했고, 꽤나 다수는 대학교 교제의 틀을 크게 벗어나지 못했다.

공개되는 자료에 온전한 모듈이나, 완성된 프로그램으로써의 자료는 극히 드물었으며, 다양한 기능에 대한 코드를 많이 보유하고 있는 것이 개인의 경쟁력으로 여겨지던 시기라고도 할 수 있었다.

꽤나 다수의 기능은 습작이나, 샘플 코드에 다름이 없었음에도 그 교류는 흔치 않았는데, 남들도 공유하지 않는데 공유하면 나만 손해라는 생각이 어느정도 국내 개발자 사이에서 형성 되었던 것은 아닌가 싶다.

해외로 눈을 돌리면 애초에 리눅스가 오픈 소스였기에, 관련 코드 다수는 공개되어 있었고, sourceforge 등지에서의 코드 공유는 이루어지고 있었으나, 국내에서 자유롭게 접근하고 사용할 정도는 아니었다. 특히나 국내 개발자들에게 공감대가 크지 않았으므로, 가져와서 사용하는 경우는 존재했어도 오픈 소스 라이선스에 맞게 변형한 코드를 재 공개 해야 되는 케이스에서 마저, 그렇지 않은 경우도 종종 봤다.

이는 저작권 의식 부족과, 코드 공유는 손해라는 인식이 합쳐진 문제였다는 생각이 든다.

정확히 언제쯤 인지는 모르겠으나, 국내에서도 github를 기반으로한 코드 공유 움직임이 커졌다.

웹쪽에서 특히 spring이나 rails, django, node.js 같은 오픈 소스 기반 웹 프레임워크와 그 프레임워크들에서의 패키지가 github에 공개되어있는 만큼 오픈 소스로 접하게 되는 모듈들에 고마움을 느끼면서 그에 대한 보은(?)하려는 움직임으로 변한 걸지도 모르겠다는 생각이 들 만큼, 지금은 꽤나 많은 개발자 분들이 github를 이용하고 있음을 느낄 수 있다.

바퀴를 재발명하는 것이 합리적이지 않고, 잘 돌아가고 뛰어난 스펙의 자동차를 혼자 만드는 일은 즐겁기 보다는 고통과 인고의 시간이라는 것을 모두가 알고 있는 것처럼, 다른 사람이 작성한 기능을 니즈에 맞게 가져다 쓰면서, 자신이 필요한 커스텀 로직에 집중해 구현함으로써 차별화와 목적 달성을 동시에 이루는 것. 그것이 합리적이라는 공감대가 형성 된 것이라고 본다.

오픈 소스로 큰 모듈이나 차별화된 기능, 프로덕트로써 만드는 모든 코드를 공개하는 것은 당연히 어렵다.

하지만 개인적인 연구 주제나, 공부하는 자료, 또는 다른 오픈소스에서의 작은 아쉬움을 개선한 코드는 공유 했을 때에 얻는 것도 많다고 생각한다.

Pull request가 받아들여 졌을 때의 짜릿함, 내 프로젝트에 별이 많이 늘어났을 때의 짜릿함은 개발자로서의 자기 증명의 수단 중 하나라고 생각한다.

이런 저런 이유로 파이썬 보급률이 국내에 크게 높아진 걸 느낄 수 있다. 그리하여, 여러 유틸리티성 프로젝트나, 개인의 고찰이 묻어나는 습작들을 다수 접할 수 있는데, 꽤나 많은 인사이트도 얻을 수 있었고, 배울 것도 많았다.

직접 코드를 공개하는 것이 아직 두렵다면 시작은 오픈 소스 코드 읽고 배우기부터라도 시작하는 것은 어떨까 싶다. 그렇게 시작하고 나면, Pull Request를 통한 기여, 작은 샘플 코드 공개를 통한 기여, 많은 이에게 보탬이 될 모듈 개발을 통한 기여로 이어질 수 있게 되고, 그를 통해 많은 프로그래머들에게 도움이 되는 개발자가 될 수 있을 것이다.