객체의 필드에 직접 접근하지 마세요?

다른 사람을 편협한 시각으로 짐작하지 말고 충분히 소통하고 존중하세요.

요즘 학습과정에서, 객체지향 프로그래밍에서는 getter와 setter를 사용하여 객체의 필드에 직접 접근하는 시도를 최대한 자제하라는 소리를 정말 많이 들었다. 그 이유가 궁금하여 곰곰이 생각해보다가, 객체의 필드에 직접 접근하는 행위는 현실 세계와 비슷하다는 생각이 들었다. 사람들의 복잡하고 다양한 자아를 단면적으로만 이해하려는 잘못된 시도가 떠오르게 했다.

나의 브런치 글을 읽으시는 많은 분들은 개발자가 아니므로, 내가 학습한 내용을 일반인이 쉽게 이해할 수 있도록 설명하고, 학습 과정에서 생각해보았던 프로그램 설계와 현실 세계의 유사점에 대해 간략하게 설명해보도록 하겠다. 당연한 말이지만 개발과 관련된 내용은 아니므로 코드는 단 한 줄도 없을 것이다. ^^

알바 친구에게 꼰대처럼 주문정보 내놓으라고 재촉하지 마세요

컴퓨터 프로그램은 사용자가 필요한 기능을 구현하여야 한다. 이 과정에서 컴퓨터 프로그램은 자신에게 주어진 역할을 작게 쪼개서 각자 분담하는 인력을 만들어낸다. 이러한 인력을 함수(메서드)라고 부르자. 만약 카페를 만든다고 가정하자. 이 카페는 신기한 게 컴퓨터 프로그램이 주문부터 음료 제조까지 모두 담당한다. 그렇다면 이 카페 프로그램의 역할은 소비자에게 메뉴 주문을 받고, 받은 메뉴 주문에 따라 돈을 받고 거스름돈을 넘겨주고, 받은 주문을 바탕으로 음료를 제조하고, 마지막으로 소비자에게 완성된 음료를 가져다주는 것일 테다.

카페 프로그램을 만드는 입장에서는 너무 만들어야 할 기능이 많다. 일단 기능을 하나하나 쪼개 보자. 소비자에게 메뉴 주문을 받는 인력(메서드)을 만들자. 이 친구는 주문받는 알바 친구라고 부를 수 있겠다. 알바 친구는 소비자에게 주문을 받고 금액을 받아 돈을 거슬러주는 역할을 수행한다. 매니저는 알바 친구가 받은 소비자의 주문내역을 보고 바리스타에게 만들어야 하는 메뉴의 순서를 조정한다. 바리스타는 주문 내역에 따라 음료를 만드는 역할이다. 알바 친구는 만들어진 음료를 다시 손님에게 전달하는 역할을 수행한다.

이렇게 카페 프로그램 하나에는 벌써 3명의 사람들이 왔다 갔다 메시지를 주고받으며 일을 하고 있다. 서로 각자에게 부여된 역할과 책임이 있고 원활한 커뮤니케이션을 통해 성공적인 카페 운영에 기여하는 것이다. 어느 하나의 로봇에게 수동적이고 반복적인 업무를 맡기는 것이 아니다. 본인이 학습한 내용에 따르면, 이렇게 객체(사람) 간의 동적인 관계를 고려하여 프로그램을 설계하는 것이 바로 객체지향 프로그래밍이다.

그렇다면 객체가 서로서로 갖고 있는 정보에 직접 접근한다는 것은 어떤 뜻일까? 알바 친구가 소비자에게 음료 주문을 받았다고 가정하자. 이제 매니저는 알바 친구에게 물어볼 것이다. 소비자가 무엇을 주문했니? 알바 친구는 손님이 주문한 아포가토를 노트에 적어두었다. 그런데 매니저는 알바 친구가 적어둔 노트를 뺏어 자기 마음대로 봐놓고 돌려주지도 않는다. 아르바이트하는 친구는 화가 단단히 났다. 자기의 노트를 말도 없이 뺏었기 때문이다. 나에게 손님이 무슨 메뉴를 주문했니?라고 물어보면 친절하게 대답할 수 있는데, 정말 어이가 없다.

이 뿐만이 아니다. 가끔은 뺏어간 메모에 이상한 내용을 적어 돌려준다. 자꾸 헷갈린다. 분명히 아포카토라고 적혀 있었는데 밑줄이 찍찍 그어져 있고 대신 카페라떼라고 적혀있다. 뭐 매니저님께서 내 노트에 그렇게 적은 거니까 그러려니 하는데, 뭔가 이상하다. 그러면 바리스타에게 아포가토를 만들라고 시킨 건가? 카페라떼를 만들라고 시킨 건가? 손님이 주문하고 나서 나는 이 집 바리스타가 사실 카페라테는 잘 못 만드는 대신 아포가토는 괜찮다고 말해뒀기 때문이다. 이 아르바이트생은 매니저의 이해 못할 갑질에 혼동과 멘붕에 빠진다.

각 객체는 자신만의 정보를 갖는다. 이를 필드라고 부른다. 다른 메서드나 객체가 다른 객체에 접근하여 정보를 그냥 가져가려고 하고(getter 함수) 또는 정보를 바꿔서 지정하려고 한다.(setter 함수) 우리는 분명히 살아있는 생명체를 만들고 생명체끼리 서로 살아있는 대화와 협력을 하도록 프로그램을 설계하는 것이 객체지향 프로그래밍이라고 배웠다. 객체 고유의 정보를 마음대로 가져가거나 수정해버리는 경우, 객체의 자율성을 인정하지 않는 것이라고 들었다. 경우에 따라 의도에 맞지 않는 형식의 정보가 저장되어 객체가 자신의 책임을 제대로 이행하지 못할 수 있다. 혹은 객체가 자신의 정보에 따라 만들어둔 메서드가 모두 무의미해질 수 있다고 한다. 

알바 친구에게 꼰대마냥 메모해둔 종이를 가져가지 말고, 대신 알바 친구에게 정중하게 손님이 무엇을 시켰는지 물어보자. 아포카토가 지금 주문이 안되면 알바 친구에게 손님이 다른 메뉴로 바꾸도록 안내해달라고 부탁을 하면 되지 않을까?

나는 여러 취향과 특징이 혼합되어 나타나는, 세상에 딱 하나밖에 없는 나 자신이랍니다

각 객체의, 각 사람이 가지고 있는 여러 정보와 특징 중 하나만 꼭 찝어서 내뱉으라고 강요하는 것, 하나의 가치관을 강제로 주입하는 행위를 떠올려보았다. 현실 세계에서 자주 벌어지면서 아주 위험한 행위이기도 하다. 객체지향 개념과 현실 세계의 경우를 연결시키게 된 계기는 어느 모임에 참석한 것이었다. 

한 토론 참석자는 자신이 비거니즘(채식주의)을 실천하고 있다고 말하면서, 여느 모임의 뒷풀이 때마다 고기집을 가는 것이 불편하지만 반대할 수가 없다고 토로한 바 있다. 자신이 채식주의자라는 사실을 밝힐 때, 많은 사람들은 채식만 먹으니까 몸이 안 좋아지겠다느니, 무엇을 먹을 수 있겠느냐느니와 같이 자신의 정체성에 시비와 도전을 건다고 언급했다. 이에 따라 자신이 원하지 않는 행동을 해야 하고, 때로는 공동체에 제대로 속하지 못하는 경우가 있어 불편하다는 것이다. 특정한 식생활 정보를 강제로 꺼내려고 하지 말고, 그 사람이 어떠한 생활을 하고 있는 지 답변자 스스로 판단하여 자신의 이야기를 충분히 할 수 있도록 해야 한다. 이는 배려의 문제가 아니라 사람으로서 응당히 누려야 하는 권리이다.

최근 숙명여대에 합격한 트랜스젠더 여성이 입학을 포기하여 사회적으로 많은 논란을 낳았다. 소위 TERF라고 불리는 래디컬 페미니스트가 생물학적 여성만 여대에 입학할 수 있다고 주장하며, 트랜스젠더 여성은 존재해서는 안된다는 혐오 발언을 서슴치 않아 발생한 일이다. 숙명여대에 합격한 여성은 지정성별이 비록 남성일 지라도 사회적인 성별이 여성이라고 스스로 인지했을 것이다. 깊은 고뇌 끝에 자신의 정체성을 따라가기로 결심했을 것이고, 사회적 약자인 여성이 교육 받는 여자대학교에 진학하여 혐오와 차별에서 조금이나마 자유롭고자 했을 것이다. 

이 여성에게 생물학적 지정성별만 강제로 물어본다면(get) 남성이라고 대답했을 것이다. 가끔 너는 절대 남성성을 버릴 수 없어, 너는 비정상이야라는 편견을 강제로 주입(set)할 수도 있을 것이다. 사람들은 이게 강제로 정보가 주입당하는 지, 혹은 정보가 꺼내지는 것인지도 모른다. 우리는 이를 보고 가스라이팅이라고 한다.

하지만 이 여성은 정말 다양한 정체성을 가지고 있을 것으로 짐작된다. 지정성별은 남성일지 모르지만 이제 성별을 바꾸었고 법적으로도 인정되었다. 법적으로도, 사회적으로도 이제 여성일 것이다. 아마 소수자 혐오와 차별을 극복하고자 하는 페미니스트일 것이다. 특정한 정보 하나가 아니라 여러 가지 정보를 취합하여 나 자신, 자아가 만들어질 것이다. 특정하고 협소한 정보 하나로 객체의 특징을 속단하고 단죄할 때 그 객체는 죽어버린다.

타인의 시각에서 다른 객체를 바라볼 때, 다른 사람을 바라볼 때, 그것의 정보 하나를 강제로 꺼내거나 강제로 주입하려 하지 마세요. 대신 그 객체에게, 사람에게 충분히 자신의 이야기를 할 수 있도록 여유를 주고 그 소리에 귀를 기울이세요. 객체지향 프로그래밍에서 getter와 setter를 쓰지 마라는 조언을 통해 사람을 인격체 그 자체로 존중하라는 교훈을 배울 수 있었다.

P.S 위의 글 중에 본인이 잘못된 지식을 작성했을 가능성이 있습니다. 이 경우 지적해주시면 학습하고 수정하도록 하겠습니다. 이 글을 작성하기 위해 참고한 링크를 첨부합니다.

- Tell, Don't Ask https://pragprog.com/articles/tell-dont-ask

Tell, Don't Ask | The Pragmatic Bookshelf

- Getter, Setters are Evil. Period. https://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

Getters/Setters. Evil. Period.