페이스북에 공유된 “[번역]OOP를 빨리 잊을 수록 여러분과 여러분의 소프트웨어에 좋습니다“라는 글의 제목을 보고 누르면서 데이크스트라 옹이 인용되었겠거니 했는데 역시나 그렇다.

데이크스트라옹은 코드의 정확성(?)을 중요하게 생각하는 사람이었고 수학처럼 증명을 하면서 엄격하게 코드를 쌓아 올라가는 편을 선호했다. 그리고 그는 OOP란 아이디어를 별로 좋아하지 않았다. 반면에 OOP를 창안한 앨런 케이는 조금 더 실용적인 편이었고 데이크스트라가 지나치게 엄격하다고 비판하기도 했다.

암튼, 이 글은 유효할지 모르나 유용하진 않다.

글을 읽으며 들었던 세부 항목 하나하나에 대한 반론은 글 마지막에 덧붙여진 아샬님 트윗에 대부분 적혀 있다.

글쓴이는 글의 절반 정도를 “잘못된 OOP”를 공격하는데 할애한다. 어떤 개념을 반대하는 류의 글 대부분이 반대하려는 개념 자체보다 그 개념을 잘못 적용한 사례를 잔뜩 나열하며 해당 개념이 문제라고 공격한다. 이는 학자의 자세라기 보다는 정치인의 자세이다.

그럼에도 내가 유효하다고 한 이유는 사실상 OOP를 한답시고 저지르는 범죄들을 잘 나열했기 때문이다. 난 글에서 지적한 죄목들이 대부분이 유죄임을 인정한다. 그게 OOP을 오해했거나 OOP와 상관 없더라도 OOP의 이름으로 저질러지고 있다는 사실은 맞다.

횡단 관심사 같이 OOP에서 풀기 어려운 문제도 잘 지적했다.

이렇게 유효한 글이지만 유용하지 않다. 요즘은 이렇게 OOP를 까고나면 FP라도 내세우는 편인데 이 글을 대안을 딱히 얘기하지 않는다. 그런면에서 유용하지 않다.

무엇보다 OOP라는 것이 역사적 이유로 인해 명확한 정의가 없어 코에 걸면 코걸이, 귀에 걸면 귀고리인데 이걸 까 봐야 뭘 어쩔 것인가? 이 또한 이 글이 유용하지 않은 이유이다.

이 글은 로직보다 데이터가 중요하다는 선언으로 시작한다. 이 명제는 오랫동안 프로그래머 세계에서 공리처럼 받아들여졌다. 나도 데이터 구조가 중요하다는 생각에 동의한다. 하지만 거시적인 관점으로 올라가면 시스템은 서로 정해진 인터페이스로 협력하는 하부 시스템의 집합으로 그려질 수 있다. 데이터는 모듈 속으로 숨어서 보이지 않는다.

OOP의 캡슐화 관점에서 프로그래밍 언어는 크게 세가지로 나눌 수 있을 것 같다. 처음부터 데이터와 로직을 분리해서 다루는 방식과 모든 프로그램을 작은 컴퓨터로 분해해서 끝까지 데이터와 로직을 함께 묶는 방식과 이 둘의 어중간한 중간으로 어느정도까지는 데이터와 로직을 묶어서 다루지만 일정 수준 이상이 되면 분리하는 방식이다.

비 OOP 언어 대부분이 첫번째에 해당한다. 두번째는 소위 말하는 순수 OOP 언어로서 극소수이다. OOP에 대한 관점이 다양하다보니 어떤 이는 순수 OOP 언어는 스몰톡 뿐이라고 하기도 한다. 대부분의 OOP 언어는 세번째에 속한다. 여기에서 스칼라나 오캐멀(OCaml) 같이 OOP와 FP를 결합한 언어의 기회가 생기는 것이다.

글쓴이는 “제 의견을 말씀드리자면 클래스와 객체는 너무 나뉘어 있고, 제대로 ‘격리’ 나 ‘API’ 에 신경을 쓸 수 있는 지점은 ‘모듈’ / ‘컴포넌트’ / ‘라이브러리’ 의 경계라고 생각합니다”라고 말했는데 이 부분이 우리가 꼬인 실타래를 같이 풀기 시작해볼만한 실마리라고 생각한다. OOP를 난잡하게 전방위로 공격하던 이 분과 그래도 이야기를 시작해볼만한 접점이다. 세번째 부류 언어 관점의 OOP로서 말이다.

OOP는 좋은 코드를 작성하고자 하는 사람이 좋은 코드를 작성하는데 방법을 고민하면서 사용하면 도움이 되지만 남들이 OOP는 이러이러한 거라고 말하는 설명을 곧이곧대로 받아들여 기계적으로 따르면 자동으로 좋은 코드가 나오는 건 아니다.

세상에 그런 기술은 없다.