Rock the JVM 강의 내용을 기반으로 정리하였습니다.
(https://courses.rockthejvm.com/p/akka-classic-essentials)
Actor 소개
Actor(액터) 모델은 1970년대에 객체 지향 프로그래밍 패러다임에 영감을 주었지만, 이후 프로그래밍 역사는 다른 방향으로 흘러가 오늘날 우리가 알고 있는 클래스와 객체를 만들어냈습니다.
전통적인 객체 지향 프로그래밍에서는 클래스를 기반으로 코드를 모델링하고, 각 인스턴스는 고유한 데이터를 가지고 메서드를 통해 외부 세계와 상호작용합니다.
Actors(액터)도 개인적인 데이터를 갖고 있다는 점에서는 비슷하지만, 외부와 상호작용하는 방식은 다릅니다.
액터와 소통하는 방법은 메서드를 호출하는 것이 아니라, “메시지를 보내는 것”입니다. 즉, 액터는 직접 접근할 수 없고 오직 메시지를 통해서만 상호작용할 수 있습니다.
이것을 좀 더 직관적으로 이해할 수 있도록 실제 생활 예시를 들어보겠습니다.
액터 모델은 우리의 일상적인 상호작용과 매우 자연스럽게 맞아떨어집니다. 예를 들어, 제가 좋아하는 밴드인 Bon Jovi가 런던에서 다음 공연을 언제 하는지 알고 싶다고 해봅시다. 그리고 제 친구 Alex가 그 정보를 알고 있다고 가정합니다.
그 정보를 얻기 위해 저는 Alex와 평범한 대화를 시작할 것입니다.
“Alex, Bon Jovi가 런던에서 언제 공연하는지 알려줄래?”
라고 질문하겠죠.
그러면 Alex는 제 질문을 이해하고, 본인의 캘린더 앱이나 Bon Jovi 팬 앱 같은 걸 확인한 다음, 몇 초 후에 답장을 해줄 겁니다.
“11월 20일에 공연해!”
이렇게 말이죠.
이것이 우리가 일상적으로 정보를 주고받는 자연스러운 방식입니다.
그런데 전혀 다른 방식으로 정보를 얻으려 한다면, 예를 들어 Alex의 뇌를 억지로 들여다보고 정보를 빼내려고 한다면 어떨까요?
모두가 알다시피, 이런 행동은 끔찍하고 비정상적입니다.
하지만 우리가 전통적인 객체 지향 방식으로 코드를 작성할 때는, 매일같이 비슷한 방식(객체의 내부 상태를 직접 조회하거나 조작하는 방식)으로 프로그래밍하고 있는 셈입니다.
잠시 멈춰서, 이런 전통적인 Java 스타일의 사고를 벗어나 보다 자연스러운 관점에서 코드를 생각해본다면 몇 가지 원칙을 발견할 수 있습니다.
첫 번째, 모든 상호작용은 “메시지를 주고받는” 방식으로 일어나야 합니다.
두 번째, 이 메시지 전달은 반드시 비동기적(asynchronous) 이어야 합니다. 이유는 여러 가지가 있는데, 우선 현실 세계에서는 메시지를 보내고 받는 데 물리적으로 시간이 걸립니다. 보내자마자 바로 반응이 오는 게 아니기 때문입니다.
예를 들어, 친구에게 질문을 던졌을 때, 친구가 질문을 듣고 캘린더를 찾아본 다음 답변하는 데까지 시간이 걸립니다.
심지어 질문을 문자메시지로 보냈다면, 친구가 2시간 후, 2일 후, 심지어 2년 후에야 답장할 수도 있습니다.
그리고 가장 중요한 것은, 저는 결코 제 친구의 뇌를 “직접 조작”해서 정보를 얻어올 수 없다는 점입니다. 메서드 호출 같은 식으로 내부에 직접 접근할 수는 없습니다.
이제 다음 영상으로 넘어가서, 이런 액터 모델의 원칙을 실제 코드로 구현해보겠습니다.
또한, 왜 이런 사고방식이 자연스러우면서도 전통적인 스레드 모델이 가진 문제들을 해결할 수 있는지 이야기해보겠습니다.
강의 내용
Actors inspired the object-oriented paradim back in the 1970s, but somehow the computer programming history took a different turn and created the classes and objects we know today.
Now, with traditional objects, we model our code around instance of classes and each instance has its own data and interacts with the world via methods.
Actors are similar in that they also have private data, but the interaction with the world is different.
The way that you communicate with an actor is by sending messages to them. So, in a sense, actors are objects which you cannot access directly, but you can only send messages to them.
Let me show you what I mean by giving a real-world example.
Actors are very intuitive if we look at day to day interactions. So, for example, say I’d want to know when my favorite band Bon Jovi, which I love, plays next in London, and my friend Alex happens to know that.
So, to get that information, I’d have to start a normal conversation. So, I would say, hex Alex, when is Bon Jovi playing next in London?
And after a couple of seconds after she’s understood my question, and she will probably look at her calendar or at her BJ fan app or something like that, and she will reply, hey, they will play on November 20.
This is the natural way we interact. Now, a completely different way of getting that information would have been somehow obtaining her brain and then poking it for the information I want.
We would all agree that this kind of thinking is obnoxious, but the traditional object oriented thinking does that every single day with our code.
So, if we stop for a second and step out of our Java hamster on a wheel and think about how to think code in a more natural way, we’ll quickly find some principles.
First of all, every single interaction happens via sending and receiving messages.
Second, these messages that we send and receive must be asynchronous for a number of reasons. First of all, it takes physical time for a real message to be sent and received, and the receiving might not immediately follow sending.
So, it might take some time for my friend to register my question and look at her calendar app and reply with the date of the concert. And even the context might be different.
Assume instead of asking my friend for the date of the concert, I would have texted her instead. In that case, for all I know, she might pick up the phone 2 hours later or 2 days or 2 years later.
And most importantly, I can never ever poke into my friend’s brain or otherwise get that information out of her by calling some kind of method.
So, let’s go to the next video as we will dive right into the code and show these principles in practice. And then we’ll go on to discuss how this thinking framework is so natual and still manages to solve the problems that got us so upset about the traditional threading model.
