Java 22

클래스, 객체, 필드, 메서드의 기본 관계

변수와 메서드를 묶는다는 말은 알겠지만 클래스, 객체, 필드, 메서드, new, 도트 연산자가 한꺼번에 등장해 관계가 흐릿하다.

근거 · 교안 p147-p157

1장: 클래스의 필요성: 흩어진 정보 묶기

솔라는 거실 벽에 붙은 색색의 포스트잇들을 보며 미간을 찌푸렸다. 동아리 신입 부원들의 정보를 급히 받아 적어둔 것인데, 막상 정리를 하려니 막막했다. 어떤 종이엔 이름이, 어떤 종이엔 전화번호가, 또 다른 종이엔 사는 도시 이름이 제멋대로 적혀 있었다. 서로 다른 필체로 휘갈겨 쓴 정보 조각들은 마치 암호처럼 벽을 뒤덮고 있었다.

“언니, 이것 좀 봐. 완전 뒤죽박죽이야.”

노트북을 덮고 다가온 루나가 벽을 잠시 살폈다.

“뭘 하려던 건데?”

“동아리 회원 명부 정리. 그냥 생각나는 대로 막 받아 적었나 봐. ‘김철수’, ‘010-1234-…’, ‘부산’, ‘박영희’… 이게 다 누구 정보인지 하나하나 짝을 맞춰야 해.”

솔라는 ‘김철수’라고 적힌 포스트잇을 떼어 들고는, 전화번호가 적힌 수많은 포스트잇 사이에서 그의 것을 찾기 시작했다. 한참을 헤매다 겨우 전화번호 하나를 찾아 ‘김철수’ 옆에 나란히 붙였다. 하지만 ‘부산’이라고 적힌 포스트잇은 김철수의 것인지, 박영희의 것인지 알 길이 없었다.

“아, 정말… 한 사람 정보면 한곳에 딱 모여 있으면 얼마나 좋아.”

솔라가 포스트잇 한 장을 뗐다 붙였다 하며 투덜거렸다.

루나가 조용히 물었다. “만약 지금 새 회원이 한 명 더 들어온다고 하면, 어떻게 해야 할까?”

“음… 이름, 전화번호, 사는 곳. 이렇게 포스트잇 세 장을 새로 써서 붙여야겠지. 그리고 또 섞이지 않게 정신 똑바로 차리고 한쪽에 잘 모아두거나. 생각만 해도 번거롭네.”

솔라는 잠시 말을 멈췄다. 방금 자신이 한 말이 기시감처럼 머릿속을 스쳤다. 이름, 전화번호, 사는 곳. 변수 세 개. 새로 온 회원. 또 다른 변수 세 개. 뇌리에 희미한 경고등이 켜졌다.

“잠깐만. 나 코딩할 때도 이러고 있었던 것 같아.”

솔라는 허공에 코드를 그리는 시늉을 했다.

“학생 한 명의 정보를 다룰 때, string studentName1, int studentAge1, string studentAddress1. 이렇게 변수를 만들었어. 학생이 두 명이면 studentName2, studentAge2, studentAddress2… 이런 식으로 계속.”

“어떤 느낌이었어?” 루나가 물었다.

“바로 지금 이 느낌! 한 학생에 대한 정보인데 이름은 여기, 나이는 저기, 주소는 또 다른 곳에 흩어져 있는 거잖아. 학생이 열 명이면 변수를 서른 개나 만들어야 하고, 관리하기도 너무 힘들어. 만약 실수로 studentName3의 정보를 보면서 studentAge5를 가져다 쓰면 어떡해? 아…”

솔라의 눈이 커졌다. 머릿속에 흩어져 있던 점들이 하나의 선으로 이어지는 순간이었다. ‘관련 있는 데이터를 묶어서 관리하면 좋다.’ 책에서 무심코 지나쳤던 문장이 눈앞의 난장판과 겹쳐 보였다. 왜 ‘좋은지’를 한 번도 체감한 적 없이, 그저 좋은 말이라고만 생각했던 것이다.

“그래서 ‘묶어야 한다’고 했던 거구나. 이 뒤죽박죽인 상황을 피하고 싶으니까.”

솔라는 벽에 어지럽게 붙은 포스트잇들을 다시 바라봤다. 이제 그것들은 단순한 정보 조각이 아니라, 잘못된 방식으로 관리되고 있는 데이터의 구체적인 증거처럼 보였다. 한 사람의 신상 정보라는 정체성은 여러 조각으로 흩어져 제 주인을 잃고 있었다.

고개를 끄덕인 솔라가 루나를 보며 물었다. 이제야 진짜 질문을 할 수 있게 된 참이었다.

“알겠어. 왜 묶어야 하는지는 이제 확실히 알겠어. 그럼, 이 흩어진 정보들을 하나로 묶어주는 그 ‘틀’은 대체 뭐라고 불러? 코딩에서는 뭘 사용해서 이 포스트잇들을 한 묶음으로 만들 수 있는 거야?”

2장: 클래스: 객체를 만드는 설계도

솔라의 질문이 끝나기 무섭게, 루나는 대답 대신 조용히 움직였다. 벽에 어지럽게 붙은 포스트잇들 앞으로 다가간 언니는 ‘김철수’라고 적힌 노란색 포스트잇을 떼어냈다. 그러고는 잠시 벽을 훑어보더니, 그의 것으로 보이는 전화번호와 도시 이름이 적힌 포스트잇 두 장을 더 찾아냈다. 루나는 그 세 장을 한 덩어리로 모아 벽의 깨끗한 공간에 나란히 붙였다. ‘김철수’라는 한 사람의 정보가 마침내 제자리를 찾은 작은 섬 같았다.

다음으로 루나는 책상 위에서 깨끗한 A4 용지 한 장과 펜을 가져왔다. 그리고는 김철수 정보 묶음 옆에 종이를 대고, 마치 견본을 만들 듯 또렷한 글씨로 적어 내려갔다.

[ 학생 정보 양식 ] - 이름: - 연락처: - 거주 도시:

루나는 아무 말 없이, 방금 만든 정보 양식과 그 옆에 붙은 김철수 정보 묶음을 번갈아 가리켰다.

“이건… 그냥 빈 양식이잖아.”

솔라가 고개를 갸웃하며 말했다. 흩어진 정보를 묶는 ‘틀’이 뭐냐고 물었는데, 언니는 웬 양식을 만들어 보이고 있었다.

“네가 물었지. 흩어진 정보들을 하나로 묶어주는 ‘틀’이 뭐냐고.”

루나는 손에 든 A4 용지를 가리켰다.

“코딩에서는, 이 양식을 **클래스(Class)**라고 불러. ‘학생’이라는 데이터가 앞으로 어떤 모양을 가져야 하는지에 대한 약속, 일종의 설계도인 셈이지.”

그러고는 루나의 손가락이 옆에 붙은 포스트잇 묶음으로 옮겨갔다.

“그리고 이 설계도를 바탕으로 실제로 만들어낸 정보 묶음, 즉 ‘김철수’라는 한 명의 학생 데이터. 이게 바로 **객체(Object)**야.”

클래스와 객체. 솔라는 두 단어를 입안에서 굴려보았다. 양식과 실제 내용. 설계도와 실제 사물. 어렴풋이 감이 잡히는 듯했다.

“아, 그러니까 클래스는 ‘학생은 이런 정보를 가져야 한다’는 정의 같은 거고, 객체는 그 정의에 따라 만들어진 ‘진짜 학생 데이터’구나! 그럼 이 양식, 아니 클래스는 하나만 있으면 되겠네. 이걸로 김철수도 만들고, 박영희도 만들고…”

거기까지 생각한 솔라는 문득 고개를 저었다. 무언가 이상했다.

“잠깐, 근데 좀 이상한데? 이 종이 양식은 하나뿐이잖아. 여기에 김철수 정보를 적어버리면, 박영희 정보는 어디에 적어? 이 종이를 복사해서 또 써야 하나?”

솔라는 마치 스캐너를 쓸 때의 답답함을 다시 떠올렸다. 키보드 입력을 받으려고 했을 뿐인데, new Scanner니 뭐니 하면서 뭔가를 ‘새로 만들어야’ 했던 복잡한 과정. 그때도 ‘객체’라는 단어가 나왔었다. 설계도와 실체라는 비유는 그럴듯했지만, 하나의 설계도로 어떻게 여러 실체를 만드는지에 대한 구체적인 방법이 와닿지 않았다.

“그 비유가 와닿기 시작했네.” 루나가 미소 지으며 말했다. “종이 양식은 한계가 있으니, 아파트 건설 현장을 상상해 보자.”

“건설 현장?”

“내가 ‘드림 아파트’라는 이름의 완벽한 설계도를 딱 한 장 가지고 있다고 생각해 봐. 그 설계도에는 방이 세 개, 화장실이 두 개, 주방은 남향이어야 한다는 모든 규칙이 담겨 있어. 이 설계도가 바로 클래스야.”

솔라는 고개를 끄덕였다. “‘드림 아파트’ 설계도. 오케이.”

“자, 그럼 질문. 그 설계도 한 장으로 아파트를 몇 채나 지을 수 있을까?”

순간 솔라의 머릿속이 환해졌다.

“아! 당연히… 수십, 수백 채도 지을 수 있지! 설계도만 있으면 똑같이 생긴 건물을 계속 찍어낼 수 있으니까!”

“바로 그거야. 설계도 자체가 건물은 아니지. 그냥 건물을 짓기 위한 ‘정의’일 뿐이야. 프로그래밍도 똑같아. 우리는 Student라는 클래스, 즉 학생 설계도를 한 번만 잘 정의해두면 돼.”

루나는 벽에 붙은 포스트잇들을 향해 손짓했다.

“그리고 그 설계도를 사용해서 김철수라는 객체(101동 건물), 박영희라는 객체(102동 건물), 또 다른 누군가의 객체(103동 건물)를 얼마든지 만들어낼 수 있는 거야. 각각의 건물, 즉 각각의 객체는 설계도에 정의된 대로 자신만의 방과 화장실을 갖게 되겠지. 자신만의 이름과 연락처를 가지는 것처럼.”

‘클래스는 객체를 만들기 위한 설계도이고, 객체는 그 설계도로 만들어진 실체다.’

책에서 무심코 지나쳤던 문장이 전혀 다른 무게로 다가왔다. 그냥 외워야 할 정의가 아니라, 수많은 데이터를 질서정연하게 관리하기 위한 강력한 문제 해결 방식이었다. 솔라는 벽에 붙은 A4 용지와 김철수 포스트잇 묶음을 다시 바라봤다. 이제 그것들은 빈 양식과 정보 조각이 아니었다. 하나의 ‘정의’와 그 정의로부터 태어난 첫 번째 ‘실체’로 보였다.

고개를 끄덕인 솔라가 만족스러운 표정을 지었다. 하지만 그 표정은 오래가지 않았다. 그녀는 루나가 들고 있던 A4 용지, 즉 ‘학생 클래스’를 다시 유심히 뜯어보았다.

“알겠어. 클래스는 설계도, 객체는 실체. 이건 확실해. 그런데 언니, 이 설계도… 뭔가 빠진 것 같지 않아?”

솔라가 종이를 톡톡 치며 말했다.

“여기엔 ‘이름’이나 ‘연락처’ 같은 정보 항목만 있잖아. 그런데 사람은 정보만 가진 존재가 아니잖아. ‘공부한다’거나 ‘밥을 먹는다’ 같은 ‘행동’도 하잖아. 그런 건 이 설계도에 어떻게 표현하는 거야?”

3장: 필드와 메서드: 설계도 속 구성 요소

솔라의 질문은 허공에 맴돌지 않았다. 루나는 조용히 ‘학생 정보 양식’이라 쓰인 A4 용지를 다시 집어 들었다. 솔라가 제기한 의문—사람의 ‘행동’은 어디에 기록하는가—은 이 설계도의 명백한 구멍이었다. 루나는 펜을 들어 기존 항목들(이름:, 연락처:, 거주 도시:) 위쪽에 작은 제목을 달았다.

[ 상태 (State) ]

그리고 그 아래, 종이의 절반쯤을 비워두고 새로운 제목을 추가했다.

[ 행동 (Behavior) ]

두 개의 제목이 생긴 종이는 전보다 훨씬 균형 잡혀 보였다. 단순한 정보 나열이 아니라, 무언가를 정의하기 위한 체계적인 구조처럼 느껴졌다. 루나는 펜 끝으로 ‘행동’이라는 단어를 톡톡 두드렸다.

솔라는 언니가 수정한 설계도를 보며 중얼거렸다. “상태… 그리고 행동. 아, 그러네. ‘이름이 김철수’인 건 그 사람의 상태고, ‘공부한다’는 건 행동이구나.”

솔라의 눈이 반짝였다. 그녀는 금세 자기 생각에 빠져들었다.

“그럼 이 ‘행동’ 칸에는 그냥 ‘공부하기’, ‘밥 먹기’ 이렇게 적어두면 되는 건가? 그리고 ‘상태’ 칸에는 이름, 연락처처럼 변하지 않는 정보들을 넣고?”

솔라는 자신의 논리에 만족한 듯 고개를 끄덕였다. 하지만 곧 미간을 살짝 찌푸렸다. ‘변하지 않는 정보’라는 말이 마음에 걸렸다. 이름이나 연락처는 바뀔 수도 있지 않은가? 행동은 또 어떤가. ‘공부한다’는 행동의 결과로 ‘지식 수준’이라는 상태가 바뀔 수도 있다. 상태와 행동이 칼로 자른 듯 나뉘는 것 같으면서도 서로 영향을 주는 것 같아 머릿속이 복잡해졌다.

“꽤 중요한 걸 발견했네.”

루나가 A4 용지 위에서 펜을 움직였다. 그녀는 솔라가 ‘상태’라고 생각했던 부분을 가리키며 말했다.

“프로그래밍에서는 이런 데이터, 즉 객체의 특징이나 속성을 나타내는 값들을 **필드(Field)**라고 불러. ‘밭’이나 ‘영역’이라는 뜻이지. 각 객체가 자신만의 값을 가지는 공간이야.”

루나는 [ 상태 (State) ]라는 글자 위에 줄을 긋고 **필드 (Fields)**라고 고쳐 썼다. 그리고 이름: 대신, 더 코드다운 표현으로 바꾸었다.

String name; String contact; String city;

솔라는 익숙한 변수 선언 형식에 금방 고개를 끄덕였다. “아하! 결국 필드라는 건 그냥 변수네. 클래스 안에 들어있는 변수.”

“맞아. 그 객체의 고유한 데이터를 담을 변수들이지.”

다음으로 루나의 펜이 아래쪽으로 향했다.

“그리고 ‘공부한다’나 ‘밥을 먹는다’ 같은 객체의 동작, 즉 스스로 할 수 있는 기능이나 행동을 **메서드(Method)**라고 불러. ‘방법’이라는 뜻이야.”

루나는 이번에도 [ 행동 (Behavior) ]이라는 글자를 지우고 **메서드 (Methods)**라고 적었다. 그리고는 빈 공간에 이렇게 썼다.

void study() { // 공부하는 코드 }

void eat() { // 밥 먹는 코드 }

중괄호 {}와 괄호 ()가 붙은 모습은 솔라가 이전에 함수를 배울 때 봤던 것과 똑같았다.

“잠깐만!” 솔라가 외쳤다. “메서드는 함수랑 똑같이 생겼네! 클래스 안에 들어있는 함수를 그냥 메서드라고 부르는 거야?”

“정확해. 객체와 관련된 동작을 수행하는 함수라고 이해하면 돼.”

이제 솔라의 눈앞에 놓인 A4 용지에는 어설픈 ‘정보 양식’이 아니라, 진짜 코드의 뼈대가 그려져 있었다.

/* 학생 설계도: Student 클래스 */

// 필드 (객체의 데이터/속성)
String name;
String contact;
String city;

// 메서드 (객체의 기능/동작)
void study() {
  // 공부하는 코드
}

void eat() {
  // 밥 먹는 코드
}

솔라는 한동안 완성된 설계도를 뚫어지라 쳐다보았다. 필드와 메서드. 이름만 다를 뿐, 결국 자신이 알던 변수와 함수의 조합이었다. 하지만 ‘클래스’라는 울타리 안에 함께 묶여 있다는 사실 하나만으로 모든 것이 달라 보였다.

‘클래스에는 필드와 메서드가 있다.’

책의 문장이 다시 떠올랐다. 전에는 그저 ‘클래스는 A와 B로 구성된다’는 건조한 사실로만 읽혔다. 하지만 이제는 달랐다. 클래스는 단순히 변수와 함수를 담는 주머니가 아니었다. 하나의 대상을 표현하기 위해, 그 대상의 **속성(필드)**과 **동작(메서드)**을 한데 묶어 정의하는 유기적인 설계도였다. 필드는 ‘그 객체가 무엇인지’를 말해주고, 메서드는 ‘그 객체가 무엇을 할 수 있는지’를 말해준다.

“알겠다… 이제 확실히 알겠어. 학생이라는 존재를 정의하려면, 이름이나 연락처 같은 ‘상태 정보’도 필요하고, 공부하거나 밥을 먹는 ‘행동’도 필요한데, 이 둘을 한곳에 묶어서 표현하는 방법이 바로 클래스였던 거구나. 그리고 그 속성을 필드, 행동을 메서드라고 부르는 거고.”

솔라는 마침내 설계도의 구성 요소를 완전히 이해했다는 표정을 지었다. 그녀는 완성된 설계도를 들고 만족스럽게 바라보았다. 이름, 연락처, 도시를 적을 칸이 있고, 공부하고 밥 먹는 기능까지 명시된 완벽한 ‘학생’ 설계도였다.

하지만 그 만족감은 곧 새로운 질문으로 바뀌었다. 솔라는 설계도를 책상 위에 내려놓고, 루나를 보며 물었다.

“좋아, 이제 설계도는 완벽해. 그럼 이 종이 한 장으로, 진짜 살아 움직이는 ‘김철수 학생’은 어떻게 만들어? 설계도는 있는데… 건물을 지을 기계는 어디 있는 거야?”

4장: new 연산자: 설계도로 객체 만들기

솔라의 질문이 채 끝나기도 전에, 루나는 책상 위에 놓인 완벽한 ‘학생 설계도’를 조용히 들어 테이블 한쪽에 옮겨두었다. 마치 참고 자료를 비치해두는 듯한 움직임이었다. 그러고는 서랍에서 방금 전의 A4 용지보다 더 큰 새 종이를 꺼내 테이블 중앙에 펼쳤다. 그 위에는 아무것도 없었다.

루나는 펜을 들어 그 깨끗한 종이 한가운데에 커다란 직사각형을 그렸다. 그리고는 그 상자 위에 ‘메모리 (Memory)’라고 썼다. 텅 빈 공장 부지 같기도 하고, 아무것도 지어지지 않은 대지 같기도 했다. 한쪽에는 건물의 설계도(클래스)가 놓여 있고, 중앙에는 텅 빈 공간(메모리)이 펼쳐진 기묘한 대치 상황. 솔라는 언니가 무엇을 하려는지 숨죽여 지켜보았다. 건물을 지을 ‘기계’가 어디 있냐는 자신의 질문에 대한 대답이 이 정적 속에서 시작되려는 참이었다.

“좋아, 이 설계도를 가지고… 어떻게 저 텅 빈 메모리 안에 진짜 학생 한 명을 만드는 건데?”

솔라가 마침내 침묵을 깨고 물었다.

루나는 대답 대신, ‘메모리’라고 쓰인 종이 바깥쪽 여백에 코드 한 줄을 적기 시작했다.

Student student1 =

거기까지 쓰고 루나는 펜을 멈췄다. 익숙한 변수 선언이었다. ‘Student’ 타입의 변수 student1을 만들겠다는 뜻. 하지만 등호 뒤가 비어있었다. 이 student1이라는 이름표에 무엇을 담아야 진짜 ‘학생’이 되는 걸까. 솔라는 잠시 고민에 잠겼다. 그때, 희미하게 잊고 있던 기억 하나가 수면 위로 떠올랐다. 키보드로 무언가 입력받으려고 할 때, 의미도 모른 채 따라 쳐야 했던 그 이상한 주문.

“혹시… new 같은 거 쓰는 거야?” 솔라가 조심스럽게 입을 뗐다. “예전에 스캐너 쓸 때 new Scanner(...)라고 썼었잖아. 그때도 그게 ‘객체’를 만드는 거라고 했던 것 같은데, 너무 복잡해서 그냥 외워버렸거든.”

루나가 희미하게 미소 지으며 고개를 끄덕였다. 그러고는 비어있던 코드의 뒷부분을 마저 채워 넣었다.

Student student1 = new Student();

“네가 말한 ‘건물을 지을 기계’, 그게 바로 이 new 연산자야.”

루나는 펜 끝으로 new라는 단어를 가리켰다. 그리고는 마치 건설 과정을 중계하듯, 코드와 그림을 오가며 차근차근 설명하기 시작했다.

“new Student()라는 명령이 실행되는 순간을 상상해 봐. 먼저 컴퓨터는 new라는 단어를 보고 ‘아, 무언가를 새로 만들어서 메모리에 올려야겠구나!’라고 생각해. 그리고 뒤따라오는 Student()를 보고는, 우리가 한쪽에 치워둔 바로 저 ‘학생 설계도’를 찾아가.”

루나의 펜이 ‘메모리’라고 적힌 상자 안으로 들어갔다. 그녀는 그 안에 작은 상자 하나를 새로 그렸다.

“그리고 설계도에 적힌 그대로, 객체 하나를 찍어낼 공간을 메모리 안에 확보하는 거야. 이 새로운 상자가 바로 김철수, 박영희가 될 수 있는 실체, 즉 ‘객체’지.”

새로 그려진 상자 안을 루나가 채워 넣기 시작했다.

[ Student 객체 ]
name: null
contact: null
city: null
---
study()
eat()

“설계도에 따라 이름(name), 연락처(contact), 도시(city)를 담을 공간(필드)이 생기고, 공부하고(study), 밥 먹는(eat) 기능(메서드)도 함께 탑재돼. 처음 만들어졌을 땐 필드에 아무 정보도 없으니까 일단 비어있다는 뜻으로 null이 들어가.”

솔라의 눈이 커졌다. new는 마법의 단어가 아니었다. 설계도를 보고 메모리라는 공간에 실체를 찍어내는, 구체적인 공정 지시어였다.

“그럼 마지막으로, 이 등호 =는 무슨 뜻이야?”

“방금 만든 저 객체가 메모리 어디에 있는지, 그 주소를 student1이라는 변수에 연결해 주는 거야.” 루나는 student1 변수에서 메모리 안의 새 객체 상자로 긴 화살표를 그었다. “이제 student1은 단순한 이름표가 아니라, 저 객체를 원격으로 조종할 수 있는 리모컨이 되는 거지.”

솔라는 완성된 그림을 멍하니 바라보았다. 클래스, new 연산자, 객체, 그리고 변수. 흩어져 있던 개념들이 하나의 그림 안에서 각자의 역할을 수행하며 완벽하게 맞물려 돌아가고 있었다.

‘객체는 new 연산자로 생성하며.’

책에서 본 문장은 더 이상 암기해야 할 정의가 아니었다. 눈앞에 펼쳐진, 설계도(클래스)로 실체(객체)를 만들어내는 과정 전체를 한 문장으로 압축한 명료한 설명이었다.

“알겠다… new는 그냥 ‘새로운 것’이라는 뜻이 아니라, ‘메모리에 이 설계도대로 진짜 실체를 만들어줘!’라는 명령이었구나. 클래스는 그냥 종이 설계도고, new가 공장을 돌리는 스위치였어.”

만족스러운 한숨과 함께 솔라가 고개를 끄덕였다. 드디어 진짜 학생 한 명을 코드로 ‘창조’하는 방법을 알아낸 것이다. 그녀는 루나가 그린 그림 속, 메모리 한편에 자리 잡은 따끈따끈한 Student 객체를 가리켰다.

“좋아! 이제 ‘학생1’이라는 객체 한 명이 메모리에 딱 만들어졌어. 이름, 연락처, 도시를 넣을 빈칸도 있고, 공부하고 밥 먹는 기능도 있네.”

하지만 그 기쁨도 잠시, 솔라의 시선은 student1이라고 쓰인 ‘리모컨’으로 향했다. 새로운 질문이 자연스럽게 고개를 들었다.

“그런데 언니, 이 빈칸에 ‘김철수’라고 이름은 어떻게 넣어줘? 그리고 얘한테 ‘공부해!’라고 시키려면 어떻게 해야 해? 저 리모컨으로 조종하는 건 맞아?”

5장: 도트 연산자: 객체의 속성 및 동작 사용하기

솔라의 질문은 테이블 위, 루나가 그린 그림 속에서 맴돌았다. student1이라는 리모컨에서 출발한 화살표는 메모리 한편에 자리 잡은 Student 객체를 정확히 가리키고 있었다. 하지만 그 객체 내부는 텅 비어 있었다. 이름, 연락처, 도시를 담을 칸은 null이라는 표식만 덩그러니 남긴 채였고, study()와 eat()라는 기능은 어떻게 실행시켜야 할지 알 수 없는 버튼처럼 보였다.

대답 대신, 루나는 다시 펜을 들었다. 그리고는 Student student1 = new Student(); 라고 적힌 코드 바로 아랫줄에, 새로운 문장을 써 내려갔다. 솔라는 숨을 죽이고 언니의 펜 끝을 응시했다.

student1.name = "김철수";

한 줄의 코드가 추가되자, 루나는 곧바로 메모리 상자 안의 Student 객체로 펜을 옮겼다. name: 옆에 있던 null 이라는 글자를 지운 뒤, 그 자리에 "김철수"라고 적어 넣었다. 텅 비었던 칸 하나가 마침내 채워지는 순간이었다.

“잠깐… 방금 그거.”

솔라의 시선은 코드와 그림 사이를 바쁘게 오갔다. student1과 name 사이에 찍힌 작은 점. 그저 문장 부호처럼 생긴 그 기호가 이 모든 변화를 일으킨 열쇠 같았다.

“그 점, 마침표 같은 저게… 리모컨 버튼 같은 거야?”

“맞아.” 루나가 student1에서 객체로 이어진 화살표를 톡톡 두드렸다. “네가 가진 student1 리모컨으로 저 멀리 메모리에 있는 객체를 조종해야 해. 그런데 객체 안에는 name 필드도 있고, study() 메서드도 있잖아. 어느 것을 건드릴지 정확히 지정해 줘야 해.”

루나는 펜 끝으로 코드에 찍힌 점(".")을 동그랗게 감쌌다.

“이 점, 도트(dot) 연산자라고 불러. ‘~의 안에 있는’ 이라는 뜻으로 생각하면 편해. ‘student1 리모컨이 가리키는 객체, 그 안에 있는 name 필드에 접근하겠다’는 명령인 거지.”

솔라의 입에서 작은 탄성이 터져 나왔다. “아! student1의 name! 그럼 ‘공부해!’라고 시키려면…まさか(설마)…”

솔라는 허공에 손가락으로 코드를 써 내려갔다. student1을 쓰고, 망설임 없이 점을 찍고, study()를 적었다.

student1.study()

“이렇게?”

루나는 고개를 끄덕이며 솔라가 상상한 코드를 종이 위에 마저 적어주었다. 그러고는 그림 속 Student 객체의 study() 메서드 부분을 가리키며, 그 기능이 실행되는 듯한 작은 별 표시를 그렸다.

“정확해. student1이 가리키는 객체, 그 안에 있는 study() 메서드를 호출하라는 뜻이야.”

이제 모든 조각이 맞춰졌다. 흩어져 있던 개념들이 하나의 완벽한 작업 흐름으로 이어졌다.

class Student { ... } : ‘학생’이라는 존재를 정의하는 설계도를 만든다.
Student student1 = new Student(); : new 기계를 이용해 설계도대로 실제 학생 객체를 메모리에 찍어내고, student1이라는 이름의 리모컨과 연결한다.
student1.name = "김철수"; : 도트 연산자를 사용해 리모컨으로 객체의 name 필드에 접근하여 값을 저장한다.
student1.study(); : 도트 연산자를 사용해 리모컨으로 객체의 study() 메서드를 찾아 실행시킨다.

‘객체 변수를 통해 필드와 메서드에 접근할 때는 도트(.) 연산자를 사용한다.’

책의 건조한 문장은 더 이상 단순한 규칙이 아니었다. 그것은 설계도로부터 창조된 실체를 현실에서 조종하고 상호작용하는 유일한 방법이었다. ‘클래스는 설계도, 객체는 실체’라는 말은, 이 도트 연산자를 통해 비로소 생명력을 얻는 셈이었다.

“이제 알겠어… 진짜 알겠어!”

솔라는 만족스러운 미소를 지으며 의자 깊숙이 등을 기댔다. 벽에 어지럽게 붙어 있던 포스트잇들은 이제 문제점으로 보이지 않았다. 그것들은 모두 Student 클래스의 객체가 될 예비 재료들일 뿐이었다. 김철수 객체, 박영희 객체… 각각의 객체는 자신만의 이름과 연락처를 가질 것이고, 필요하다면 모두에게 ‘동아리 활동 참여하기’ 같은 공통된 행동을 시킬 수도 있을 것이다.

생각을 정리하던 솔라의 시선이 문득 책상 한쪽에 놓인 스탠드 조명에 닿았다. 늘 그 자리에 있던 평범한 조명이었다. 하지만 오늘따라 그것이 다르게 보이기 시작했다.

솔라는 혼잣말처럼 중얼거렸다.

“저 조명도… 클래스로 만들 수 있겠는데?”

루나는 아무 말 없이 솔라를 바라보았다. 솔라는 눈을 반짝이며 머릿속으로 코드를 조립하기 시작했다.

“DeskLamp 클래스. 필드로는… 전원이 켜져 있는지 아닌지를 나타내는 boolean isOn, 그리고 밝기 단계 int brightnessLevel이 있겠지. 메서드로는… 전원을 켜는 turnOn(), 끄는 turnOff(), 밝기를 조절하는 setBrightness()가 있을 거고.”

생각은 멈추지 않았다.

“그리고 지금 내 책상 위에 있는 이 조명은 그 설계도로 만든 수많은 조명 중 하나, 진짜 실체니까… DeskLamp myLamp = new DeskLamp(); 이렇게 객체로 만들 수 있어. 그리고 내가 스위치를 누르는 건, 코드로는 myLamp.turnOn()을 호출하는 거랑 똑같은 거야. 밝기를 3단계로 맞추면 myLamp.setBrightness(3)이 되는 거고!”

솔라는 자신의 스탠드 조명을 새로운 눈으로 바라보았다. 더 이상 단순한 사물이 아니었다. 속성(데이터)과 행동(기능)을 가진, 질서정연한 하나의 객체였다. 세상을 바라보는 새로운 안경을 쓴 기분이었다. 이제 그녀에게 세상은 무질서한 정보의 나열이 아니라, 저마다의 설계도를 가지고 태어난 수많은 객체들의 집합으로 보이기 시작했다.