Akka or Orleans

이 컨텐츠는 akka.net과 microsoft orleans의 주요 설계자들이 참여하여 두 액터 모델 기반 프레임워크의 특징, 장단점, 그리고 어떤 상황에 더 적합한지에 대해 토론하는 패널 토론입니다. 두 프레임워크는 클라우드 환경에서의 분산 시스템 구축이라는 유사한 문제를 해결하지만, akka.net은 더 많은 설정 자유도와 성능 최적화에 초점을 맞추는 반면, Orleans는 추상화 수준을 높여 개발자가 비즈니스 로직에 집중하고 신뢰성 있는 애플리케이션을 빠르게 구축할 수 있도록 돕는다는 점이 핵심적인 차이점입니다. 궁극적으로 어떤 프레임워크를 선택할지는 개발자의 선호도와 프로젝트의 구체적인 요구사항에 따라 달라진다는 결론을 내립니다.

2. 🤔 액터 모델과 기술 발전의 흐름

• Akka와 Orleans는 비슷한 시기에 개발되었으며, 두 기술의 필요와 인기는 클라우드와 확장성과 같은 요소에 기인한다. 이 기술들은 높은 신뢰성, 확장성, 가용성을 필요로 하는 시대의 요구를 반영하고 있다. 18

• 기술 개발 과정에서 현실적으로 목표를 명확히 알기 어려울 때가 많으며, 때로는 나중에 우리가 만든 것에 대한 용어나 개념을 찾는 경우가 있다. 22

• Orleans는 2014년에 " 가상 액터"라는 용어를 사용하여 공식 명칭을 정립하게 되었으며, 이는 당시의 주요 혁신이었다. 24

• akka.net는 Scala에서 포팅된 프로젝트로, 높은 성능의 분산 시스템을 구축하기 위해 노력하며, 여러 산업적 기대를 충족하기 위해 문서화, 호환성 관리, 릴리스 관리 등의 프로세스를 갖추어야 한다. 39

• 액터 모델은 소프트웨어 시스템에서 상태와 작업을 분리하여 분산 소프트웨어의 진화 가능성을 열어주며, 이를 통해 다양한 문제 해결 방안을 발명할 수 있게 된다. 50

2.1. ️ Akka와 Orleans의 발전 배경

• Akka와 Orleans는 약 동시기에 시작되었으며, 서로에 대해 알지 못했다고 알려져 있다. [18]

• Akka는 2012년에 처음 알려졌고, 그 필요성이 점차적으로 대두되었음이 강조된다. [19]

• 클라우드와 확장성의 필요성은 개발자들에게 중요한 과제가 되었고, 이러한 기술들이 인기를 얻은 이유로 판단된다. [19]

• 개발자들은 신뢰성, 확장성, 가용성과 같은 요구 사항을 강조하며, 이는 우리가 흔히 언급하는 '능력'의 중요성을 반영한다. [20]

• 기술 산업은 지속적으로 기술을 재발명하는 경향이 있으며, 예를 들어 erlang은 90년대에 개발되었고, 액터 모델은 70년대부터 존재해왔다. [20]

2.2. ️ 기술 발전의 반성과 이해

• 기술을 개발하는 과정에서는 종종 목적이나 방향을 명확히 알지 못하는 경우가 많다. 이런 불확실성 속에서도 직감과 직관에 의존하게 된다. [22]

• 2014년경, 이들은 자신들이 만든 것에 대한 명칭이나 용어를 정립하는 데 어려움을 겪었다. 당시, 최고 수준의 학회에 논문을 제출하고자 했다. [23]

• 작품의 핵심 혁신인 "가상 액터(virtual actors)"라는 용어는 개발 시작 후 5년이 지나서야 탄생되었다. [24]

• 제품을 실제 운영하면서 그들이 만든 것에 대한 본질을 점차 깨달아 갔다. 초기 개발 목표와 시행착오가 있었다. [25]

• 실제로 계획하고 건축한 이후에도, 종종 자신들이 가고자 하는 방향을 재검토하고 수정하는 경우가 많다. [27]

2.3. ️ Akka.net 프로젝트의 발전 과정

• Aaron Stannard는 클라우드 프로젝트를 위해 상태 관리 시스템이 필요하다고 설명하며, 수백만 건의 클릭 이벤트를 처리하는 실시간 스트리밍플랫폼 구축에 대한 필요성을 강조한다. [29]

• 초기에는 이를 설명할 언어가 부족했지만, 이를 통해 상태를 효율적으로 관리할 수 있는 시스템을 구축해야 한다는 점을 인식하게 된다. [33]

• 2013년 후반, 그는 Akka를 발견하고, 기존의 배포된 액터 모델을 활용할 수 있는.NET 구현체를 찾고 있었음을 언급한다. [35]

• 당시 Orleans는 공개되지 않았으며, Aaron은 Orleans 사용자로서의 기회를 기대했지만, Akka를.NET으로 포팅하는 결정을 내리게 된다. [37]

• akka.net프로젝트는 원래 아카의 Scala 버전을 기반으로 하며, 지속적인 학습을 통해 프로젝트를 산업 수준의 품질로 발전시켜야 할 필요성을 느끼게 되었음을 밝힌다. [41]

2.4. 액터 모델과 분산 소프트웨어의 혁신

• 액터는 상태와 작업을 분할하고 탈중앙화된 진실의 원천을 설정하는 데 필수적인 요소로 작용한다. 이를 통해 분산 소프트웨어 개발에 많은 가능성을 열어준다. [49]

• akka.net이나 Orleans를 사용한 개발자들은 실시간으로 상태를 조회하여 문제 해결을 위한 다양한 솔루션을 발명할 수 있다. [49]

• 네트워크의 토폴로지를 인식함으로써 각 노드가 어떤 데이터 파티션에 할당되어 있는지를 알 수 있다. [50]

• akka.net과 액터는 분산 컴퓨팅 이외에도 임베디드 프로그래밍이나 모바일, 데스크톱 애플리케이션의 이벤트 처리 등 다양한 용도로 활용될 수 있다. [51]

• 액터를 배우기 전후로 소프트웨어 구축 방법이 완전히 변화한다는 점이 특징적이다. [52]

2.5. 액터 모델에 대한 개발자들의 관심 변화

• 최근에 일부 개발자들이 액터 모델에 대해 덜 이야기한다고 언급했으며, 초기에는 관심이 많았으나 현재는 안정세를 보이고 있다는 의견이 제기되었다. [57]

• 사용자가 액터 모델을 매일 활용하고 있기 때문에, hype에 대한 질문이 별로 없는 것으로 보이며, 오히려 이 모델이 다양한 현실 세계의 활동을 모델링하는 데 더 유용하다는 생각을 전달하였다. [58]

• 액터 모델의 고전적인 원칙, 예를 들어 감독 전략이나 액터의 계층 구조에 대한 개발자들의 집중이 줄어든 것 같다는 주장도 있었다. [58]

• 또한, 상태를 가지는 서버리스 서버의 기능이 일부 개발자들에게 더 많은 관심을 끌고 있는 것으로 추정된다. [58]

• 전체적으로 액터 모델에 대한 논의가 줄어들었다는 의견에 대한 동의 여부와 추가 설명을 요청하는 질문도 존재하였다. [59]

3. 🤖 액터 모델과 개발 생태계의 변화

• 액터 모델이 일반화되어 기술이 지루해진 것으로 보이는 것은, 기술 생태계의 성숙을 나타내는 긍정적인 변화이다. 60

• .NET 개발자들이 내구성 함수, 가상 액터(Orleans), dapper 기반 크로스 플랫폼 액터 등 다양한 선택지를 가지고 있다는 점이 과거와 비교해 유리하다. 61

• 기술이 지루하다는 것은 그 이후에도 여전히 널리 사용되고 있다는 것을 의미하며, 어쩌면 오히려 더 많은 개발이 이루어지고 있음을 나타낸다. 64

• 액터 모델의 채택이 증가함에 따라, 관련 자료와 정보가 풍부해져 많은 개발자들이 접근할 수 있는 환경이 조성되었다. 66

• Orleans는 많은 사람들이 액터라는 용어에 익숙하지 않아, 상태 관리와 같은 다른 개념으로 설명하는 것이 더 효과적일 수 있다. 74

3.1. 액터 모델의 발전과 .NET 개발자의 도구 선택

• 액터 모델이 이제는 잘 이해되고 있는 기술로 인식되어 "지루한 기술"이 되었다는 것은 생태계의 놀라운 변화이다. [60]

• 현재.NET 개발자들은 Azure의 내구성 함수, Orleans의 가상 액터, dapper의 크로스 플랫폼 액터 등 다양한 도구를 선택할 수 있는 기회를 가지고 있다. [61]

• 이처럼 다양한 도구 선택이 가능하다는 것은 전문적으로 유지 관리되는 코드와 탄탄한 오픈 소스 커뮤니티의 지원을 받을 수 있음을 의미한다. [62]

• 이러한 선택의 풍부함은 생태계와 커뮤니티 전반에 긍정적인 영향을 미친다고 평가된다. [63]

3.2. ️ 기술의 성숙과 Adoption

• .NET 개발자를 포함한 모든 개발자들은 신규 기술에 대한 매력이 있지만, 점차적으로 이 기술들이 재미없어지는 경향이 있다. 이는 기술의 배포 속도와는 무관하다. [64]

• 현재는 액터 모델의 hype가 줄어들었으나, 사용자는 대폭 증가했으며 정보 접근성이 좋아졌다. [65]

• 2014년에는 akka.net 관련 교육 자료가 전무했으나, 현재는 수십 개의 pluralsight 과정이 개설됐다. [66]

• 문서화, 튜토리얼 업데이트 등 성숙한 기술의 일환으로, 사용자가 실제로 사용할 수 있는 신뢰할 수 있는 도구로 거듭나는 과정이 이루어지고 있다. [68]

• Sergey의 발언을 통해, 기술의 성숙 과정에서 신뢰성과 효율성이 중요하다는 점이 강조되었다. [69]

3.3. Akka와 Orleans의 이해를 위한 관점

• 기술이 지루해지면 성공의 신호로 간주되며, 이는 소프트웨어가 세상을 지탱하는 기초가 되는 이유와 연결된다. [71]

• 오래된 소프트웨어는 여전히 많은 산업에서 사용되고 있으며, 이들 소프트웨어는 10년 또는 15년 전에 개발된 것들이다. [72]

• '액터'라는 용어가 이해되지 않거나 잘못 해석되는 경우가 많아, 오랜 고민 끝에 이를 사용하지 않기로 결정했으며, 대다수의 사람들이 이 용어에 대한 지식이 없다는 사실을 발견했다. [74]

• 상태 관리및 프로그래밍 모델이 중요해지며, 객체들의 상태와 진화에 대한 명확한 이해가 필요하다. [78]

• '객체'라는 용어를 사용함으로써 개발자들에게 더 많은 연결과 이해를 제공할 수 있다고 주장한다. [80]

3.4. 커뮤니티의 영향력과 피드백 사례

• akka.net과 microsoft orleans는 강력한 개발자 커뮤니티를 보유하고 있으며, 최근 nuget 패키지 다운로드수는 약 250만 건에 달한다. [82]

• 커뮤니티의 피드백은 제품 개발에 큰 영향을 미치며, 변화의 예시로는 초기 오픈 소스단계에서 "코드 생성 팩토리 클래스"에 대한 부정적인 반응이 있었다. [87]

• 오픈 소스 전환 후, Microsoft의 전통적인 접근 방식에서 벗어나 유연성을 중시하는 방향으로 변화하였고, 이런 피드백은 프로젝트 방향성을 재조정하는 데 도움을 주었다. [92]

• akka.net이 사용자의 피드백에 따라 async await, 의존성 주입과 같은 기능을 지원하게 되었으며, 이는 커뮤니티의 요구에 기반한 반응에 해당한다. [99]

• 커뮤니티는 akka.net과 타 기술 간의 상호작용을 개선하기 위한 피드백을 지속적으로 제공하고 있으며, 다양한 플러그인과 시각화 시스템이 개발되고 있다. [107]

3.5. 커뮤니티 참여 증진 방안

• akka.net의 커뮤니티 참여를 늘리기 위해, 사용자들이 기여할 수 있는 경로를 명확히 하는 것이 중요하다. [111]

• 혁신과 새로운 시도를 위한 충분한 공간을 제공해야 하며, 사용자들이 새로운 경험을 제공하는 시스템을 구축할 수 있도록 해야 한다. [112]

• 프로젝트에 참여하려는 사람들에게 성공적인 참여를 위한 조직적 접근 방안을 마련하는 것이 필요하다. [113]

• 지속 가능한 오픈 소스커뮤니티를 구축하기 위해서는, 사람들에게 필요한 지식과 기술을 배워나갈 수 있는 기회를 제공해야 한다. [114]

4. 🤖 Akka.NET과 Microsoft Orleans의 차이점

• akka.net은 클라우드 애플리케이션이 아닌 용도로 사용 시 적합하며, 다양한 비클라우드 사용 사례를 지원할 수 있는 유연성을 제공한다 120.

• Orleans는 비즈니스 로직에 신속하게 접근할 수 있는 추상화를 제공하여 신뢰할 수 있는 애플리케이션을 쉽게 구축할 수 있도록 돕는다 126.

• akka.net은 배포 성능과 처리량을 관리하려는 사용자에게 더 많은 조정(다양한 설정 변경)을 허용하는 반면, Orleans는 기본적으로 높은 성능과 관리가 용이한 접근 방식을 제공한다 136.

• 개발자의 필요에 따라, 애플리케이션 실패 처리 방식이나 응답 기대와 같은 시나리오의 차이가 두 프레임워크 선택의 중요한 기준이 될 수 있다 149.

• Orleans는 가상 액터 모델을 활용하여 안정적인 엔터티 아이디를 가진 애플리케이션에 적합하며, 이를 통해 클러스터 간의 상태를 관리할 수 있도록 설계되었다 154.

4.1. ️ Akka.NET과 Microsoft Orleans의 선택 기준

• 분석적 맥락이 없이는 akka.net과 microsoft orleans중 하나를 선택하는 질문이 의미가 없다고 주장된다. [117]

• 개발자들에게 도움이 될 수 있는 것은, 두 프레임워크를 선택할 때 필요한 요구사항과 기준 목록을 작성하는 것이라고 언급된다. [117]

• 경험과 커뮤니티의 질문을 기반으로, 두 선택지를 고려하는 개발자들에게 체크리스트 형태의 요구사항을 갖추기를 권장한다. [118]

• 패널 토론에서 어떤 사람들이 먼저 발언할지에 대한 질문이 이어진다. [119]

4.2. ️ Akka.NET과 Orleans의 비교

• akka.net은 비 클라우드 애플리케이션을 구축하려는 경우에 적합하며, 많은 비 클라우드 사용 사례를 지원할 수 있다. [120]

• akka.net과 Orleans는 분산 컴퓨팅 공간에서 유사점을 가지며, 현대의 소프트 실시간 애플리케이션 개발에 효과적이다. [122]

• Orleans는 비즈니스 로직에 더 빨리 접근할 수 있는 추상화를 제공하여 애플리케이션 구축을 용이하게 만든다. [126]

• Orleans는 직렬화와 영속성 등 인프라 문제에 대한 걱정을 덜 수 있도록 만들어져 있어, 신뢰할 수 있는 애플리케이션을 빠르게 개발할 수 있다.

4.3. ️ Akka.NET과 Orleans의 차이점

• akka.net은 배우기 쉬운 높은 구성 가능성을 제공하며, 개발자가 액터의 생명 주기에 대한 세부 조정을 할 수 있도록 한다. [129]

• akka.net은 성능과 처리량 관리에 중점을 두기 때문에 기본 설정이 빠르지만, 메시지의 확실한 전달을 보장하지 않으며, 메시지의 복제나 자동 저장은 개발자가 직접 선택해야 한다. [136]

• 반면 Orleans는 신뢰성과 안정성을 제공하기 때문에 초기 성능 저하가 있을 수 있으며, 복잡한 시스템에서 이벤트 전달 보장이 필요하다면 유리하다. [141]

• 특정한 비즈니스 요구 사항과 처리량 마감에 따라 시스템 설계에 적합한 선택은 달라질 수 있으며, akka.net은 조정 가능한 솔루션을 제공해 대량의 데이터를 처리하는 데 적합할 수 있다. [146]

• 각 기술의 기본 설정은 소프트웨어 개발 방식과 얼마나 밀접하게 일치하는지에 따라 선택할 수 있으며, Orleans는 신뢰할 수 있는 추상화를 제공하고 akka.net은 성능을 중시하는 접근 방식을 갖고 있다. [147]

4.4. ️ 애플리케이션 요구사항에 따른 접근 방식

• 애플리케이션의 요구사항에는 실패 처리 방식과 같은 두 가지 주요 요소가 있으며, 예를 들어 일부가 실패했을 때 전체를 다시 만들어야 하는 경우가 있다. [149]

• Akka와 같은 시스템은 일방향 메시지를 강조하여, 응답을 같은 호출 내에서 기다리지 않도록 설계되어 있다. [150]

• 개발자들은 각기 다른 성향을 가지고 있어, 일부는 작은 조각을 조립하여 해결책을 만들고, 다른 이들은 전체 구성의 실행을 우선시한다. [152]

• Orleans는 가상 액터 모델을 사용하여 더 평탄한 계층 구조에 적합하며, 사용자 계정이나 장치 ID와 같은 안정적인 식별자를 가진 엔티티에 적합하다. [154]

• Orleans의 프로그래밍 방식은 단일 머신의 메모리처럼 프로그래밍할 수 있는 가상 주소 공간을 이용하는 것을 특징으로 한다. [155]

4.5. ️ Orleans와 Actor 모델의 차이점

• Orleans의 초기 론칭 시, Actor 모델에 대한 혼란이 많았으며, Carl Hewitt가 클라우드에 적합한 Actor 모델의 확장을 인정한 시간이 걸렸다. [156]

• Roger Johansson는 Orleans와 다른 모델을 비교하기 위해 만화 형태의 그림을 게시했으며, 하나는 Lego 블록을 흩뿌린 형태이고 다른 하나는 작은 Lego 자동차가 움직이는 형태였다. [159]

• 이 비유에서 Lego 블록은 원하는 대로 조합할 수 있는 저수준의 구성 요소를 나타내고, Orleans는 주어진 형태의 자동차를 나아가게 하는 구조임을 암시한다. [161]

• 소프트웨어의 경우, 사용할 수 있는 기술이 주어지면 대부분의 문제를 해결할 수 있지만, 어떤 시나리오에 적합한지와 개발자의 기술 수준에 따라 최적의 선택이 달라진다. [164]

• Orleans는 기본적으로 메시지의 보장된 전달을 선택할 필요 없이 제공되며, 사용자 호출 시 응답 또는 오류를 돌려받는 방식으로 작동한다. [166]

5. ⚖️ Akka와 Orleans 비교 및 언급된 특징들

• Akka와 Orleans의 전체 행위는 "최대 1회 전달"이라는 점에서 유사하다, 그러나 각각의 프레임워크의 접근 방식에 차이가 있다 173.

• Orleans는 비전문가가 효율적이고 확장 가능한 분산 서비스를 작성할 수 있도록 돕는 데 초점을 둔다, 반면 Akka는 전체 강력함을 제공하지만 복잡성을 노출하는 도구 모음이다 180.

• Orleans는 덜 복잡한 기본 모델을 제공하여, 개발자들이 신속하게 프로덕션에 배포할 수 있도록 도와준다, 그 결과 Akka에 비해 더 많은 인프라 문제에 대해 신경 쓰지 않을 수 있다 193.

• Orleans는 객체의 생명 주기를 관리할 필요 없이 메시지를 보내고 응답을 받을 수 있는 기능을 제공하며, 이는 더 간단한 분산 애플리케이션을 구축하는 데 유리하다 194.

• 특정 도메인에서의 사용에 대한 명확한 선호도는 없으며, 각 프레임워크는 요구 사항에 따라 적합할 수 있다, 따라서 사용자와 요구에 따라 해결할 수 있는 문제는 다양하다 211.

5.1. 프레임워크 비교 시 중요한 특성

• 두 프레임워크의 전체 동작 방식은 최대 한 번의 배달만 보장된다는 점이다. 이는 시스템을 비교할 때 자주 질문되는 사항이다. [173]

• 오해가 발생한 이유는 모호한 표현 때문이라는 주장이다. 문서에 포함된 한 문장이 사람들을 혼란스럽게 만들 수 있다. [175]

• 2014년 논문과 가상 액터에 대한 설명에서 실수가 있었으며, 그로 인해 구현이 복잡하다는 점이 강조된다. [176]

• 모든 참가자가 이해한다면 문제를 정리하는 것이 중요하다고 언급된다. [177]

5.2. ️ Akka와 Orleans 비교의 배경과 해석

• 2015년 Akka와 Orleans 간의 비교가 발표되었으며, 이 비교는 akka.net이 아닌 원래 JVM의 GitHub 페이지에 게시되었다고 한다. [178]

• 비교의 주요 초점은 Orleans가 분산 컴퓨팅을 단순화하고 비전문가가 효율적이고 확장 가능하며 신뢰할 수 있는 분산 서비스를 작성할 수 있도록 하는 것이며, Akka는 복잡성을 드러내는 분산 시스템 구축을 위한 도구 키트라는 것이다. [180]

• Ukranian 개발자 Anton Moldavan은 두 프레임워크를 사용한 경험을 바탕으로 Akka는 C++와 같고, Orleans는 C#와 같다는 의견을 제시하였다. [182]

• "비전문가"라는 표현은 긍정적이거나 부정적으로 해석될 수 있으며, 개발자가 신뢰할 수 있는 분산 시스템을 구축할 수 있게 돕는다면 긍정적이라는 견해가 있다. [186]

• 하지만 "비전문가"라는 개념이 Visual Basic과 동일시될 수 있다는 점에서 비판도 존재하며, 이는 표현 방식에 따라 다르게 해석될 수 있음을 시사한다. [187]

5.3. ️ Akka.NET과 Orleans의 차이점

• akka.net은 더 많은 인프라 수준의 고려사항을 요구하며, 사용자는 실패 처리 및 감독 모델에 대해 더욱 정교하게 고민해야 한다. [188]

• Orleans는 사용자가 복잡한 세부 사항을 몰라도 어플리케이션을 신속하게 생산에 배포할 수 있도록 한 기본 모델을 제공한다. [193]

• Orleans는 객체의 상태를 관리할 필요 없이 메시지를 통해 원하는 객체에 접근할 수 있는 기능을 제공한다. [194]

• akka.net은 유사한 기능을 제공하지만, 더 높은 학습 곡선을 요구하며 이를 구현하기 위해 더 많은 시간을 투자해야 한다. [198]

• 결국, 두 툴킷 간의 선택은 개발자의 선호도와 프로젝트의 요구사항에 따라 달라진다. [200]

5.4. ️ 프레임워크 비교: Akka와 Orleans

• Orleans은 초기 기본값 세트에서 시작하여 커스터마이징과 옵션 추가를 지향하고 있으며, 이는 프로젝트 발전에 따라 변화할 수 있다. [201]

• 반면에 Akka는 처음부터 다양한 옵션을 제공하여 기본적인 기능이 확립되어 있는 상태이다. [203]

• 특정 도메인, 예를 들어 금융이나 온라인 트레이딩 산업은 두 프레임워크 중 하나를 선택할 수 있는 특별한 조건이 있을 수 있으나, 이와 관련된 구체적인 요구사항이 필요하다. [205]

• 금융 애플리케이션은 정형화된 요구사항으로 인해 Akka가 더 적합할 수 있으며, 게임과 같이 동적인 분야에서는 둘 다 요구사항을 충족할 수 있는 가능성이 있다. [210]

• 특정 애플리케이션 도메인에서 명확한 선호도가 없으므로, 각 시스템에서 동일한 요구사항을 표현할 수 있다. [211]

5.5. Orleans의 기원과 용도

• Orleans은 원래 Xbox Live 서비스를 구축하기 위해 Halo와 관련된 프로젝트로 시작되었으나, 이는 오해로 여겨진다. [214]

• Microsoft의 연구실에서 새로운 클라우드 애플리케이션 구축 방식을 연구하던 중, Twitter와 유사한 기능을 200줄의 Orleans 코드로 구현하고 이를 내부 기술 박람회에서 선보였다. [220]

• Halo 팀과의 짧은 협업을 통해 가상 액터 모델이 개발되었고, 이로 인해 Orleans는 Halo와 영원히 연결되게 되었다. [224]

• Orleans는 게임 외에도 비자와 같은 다양한 Internal Microsoft 서비스에서 활용되고 있으며, 범용적인 사용이 가능하다. [228]

• 기술 선택은 특정 도메인에 의존하기보다는 사용자의 선호와 스타일에 따라 달라지며, 두 가지 도구 모두 문제 해결에 유용하다. [230]

5.6. ️ 언어 선택과 프레임워크 구현

• C#에서는 패턴 매칭이 필요했으며, 이 기능이 추가됨으로써 메시지 핸들러를 작성하는 데 핵심적으로 사용되었다. [237]

• F#가 당시 akka.net을 개발할 때 더 나은 선택으로 보였지만, 팀의 숙련도 때문이 C#를 선택하게 되었다. [240]

• C# 사용은.NET 개발자들에게 필요한 도구를 제공할 수 있는 넓은 플랫폼을 가능하게 하여 기업에 이득이 되었다. [244]

• 다양한 언어의 특징을 부러워하고 있지만, C#이 초기 akka.net작업 시 적합한 언어로 여겨졌다. [247]

• 언어와 플랫폼 선택은 개발자 교육과 인력 채용에서 장애가 될 수 있으며, erlang 같은 특정 목적의 언어는 더 적은 인력을 확보할 수 있는 단점이 있다. [264]

5.7. Sergey Bykov과 Aram의 새로운 도전

• Sergey Bykov은 Microsoft를 떠나 Temporal Technologies에서 장기 작업 흐름 관리를 위한 기회를 발견하고 새롭게 도전하게 되었다고 언급한다. [275]

• Aram은 Sdkbin이라는 새로운 서비스를 출시했으며, 이는 앱 스토어와 nuget의 결합 형태로 설명된다. [279]

• Petabridge의 비즈니스 모델은 akka.net 관련 서비스의 판매에 의존해 왔으나, 성장의 어려움으로 인해 제품 판매로 전환하기로 했다. [281]

• SDK Bin은 아카닷넷 제품을 판매하기 위해 개발된 플랫폼으로, 미래에는 다양한 소프트웨어 제품의 판매를 지원할 계획이다. [289]

• Aram의 주요 역할은 조직 관리와 수익 예측의 일관성을 높이는 것이며, SDK Bin은 이를 위한 효율성을 제공하는 도구로 활용될 예정이다. [296]

6. 📚 Akka.NET 및 Orleans에 대한 추천 자료

• 가상 공간에서 다른 주제를 다루기 위해 이동할 필요가 있으며, 이 포맷은 서로 다른 지역에 있는 두 전문가가 한자리에 모일 수 있는 희귀한 기회를 제공한다. 307

• Roland Kuhn의 Reactive Messaging Patterns 책은 Akka의 메시지 스타일을 이해하는 데 매우 유용한 자료로 추천되며, 그는 Akka의 주요 설계자 중 한 명이다. 312

• Orleans에 관한 책은 존재하지 않으며, 출판사와 논의 중이지만 저술 작업이 부담스러워 현실적으로 진행하기 어려운 상황이다. 314

• 기술적인 책을 쓰는 일은 수익성이 낮아 많은 시간과 노력이 필요하다는 의견이 제시된다. 315

• 마지막으로, 토론 존에서는 참석한 사람들이 추가 질문을 할 수 있는 기회를 제공하겠다고 언급된다. 319

1. 패널 소개 및 주제 설명 1

• Aaron Stannard와 Sergey Bykov이 패널로 참여하여 akka.net과 microsoft orleans에 대해 논의함 1.

• 두 기술의 선택에 대한 질문이 자주 제기되며, 이 자리에서 두 아키텍트에게 직접 질문할 기회를 가짐 3.

2. 아키텍트의 경험 12

• Sergey는 Akka와 Orleans가 비슷한 시기에 시작되었으며, 클라우드와 확장성의 필요성이 이들 기술의 발전에 기여했다고 설명함 19.

• Aaron은 자신의 클라우드 프로젝트에서 실시간 스트리밍 플랫폼을 구축하기 위해 Akka를 발견하게 되었고, 상태 관리 시스템이 필요하다고 언급함 29.

3. 액터 모델의 현재와 미래 57

• 액터 모델에 대한 관심이 줄어들었다는 질문에 대해 Aaron은 기술이 성숙해지면서 덜 화려해졌지만, 실제 사용자는 증가하고 있다고 답함 60.

• Sergey는 기술이 지루해지는 것이 성공의 신호일 수 있다고 덧붙임 71.

4. 커뮤니티의 영향 82

• 두 프레임워크 모두 강력한 개발자 커뮤니티를 가지고 있으며, 커뮤니티의 피드백이 제품 개발에 큰 영향을 미친다고 설명함 82.

• Sergey는 오픈 소스 전환 후 커뮤니티와의 소통이 얼마나 중요한지에 대해 이야기함 87.

5. Akka.NET과 Microsoft Orleans의 차이점 117

• akka.net은 비클라우드 애플리케이션에 적합하며, Orleans는 클라우드 애플리케이션에 더 적합하다고 설명함 120.

• Orleans는 비즈니스 로직에 더 쉽게 접근할 수 있는 추상화를 제공하며, akka.net은 더 많은 구성 가능성을 제공한다고 언급함 126.

6. 기술 선택 기준 118

• 개발자들은 애플리케이션의 요구 사항에 따라 akka.net과 Orleans 중에서 선택해야 하며, 각 기술의 기본 설정이 개발 방식과 얼마나 잘 맞는지를 고려해야 한다고 강조함 146.

7. 언어와 기술의 관계 236

• Aaron은 C#이 akka.net에 적합한 언어라고 생각하며, C#의 넓은 플랫폼 지원이 중요하다고 언급함 244.

• Sergey는 erlang과 같은 특정 언어의 사용이 제한적일 수 있으며, 인력 채용의 어려움도 고려해야 한다고 덧붙임 262.

8. 개인적인 변화와 미래 계획 274

• Sergey는 Microsoft를 떠나 Temporal Technologies에서 새로운 기회를 찾았다고 설명함 275.

• Aaron은 Petabridge에서 새로운 제품인 SDK Bin을 출시하며, 오픈 소스 프로젝트와 함께 성장할 계획이라고 언급함 279.

9. 추천 자료 311

• akka.net과 관련하여 Roland Kuhn의 "Reactive Messaging Patterns"를 추천함 312.

• Orleans에 대한 책은 현재 없지만, 출판 논의가 진행 중이라고 언급함