미국 소프트웨어 개발자 사이에서는 스칼라 언어가 인기다. 빅데이터 시대의 도래와 함께 뜨거운 관심을 받고 있는 아파치 스파크나 아카 라이브러리가 스칼라로 작성된 것은 물론이고, 트위터, 링크드인, 넷플릭스, 텀블러, 애플 같은 IT 업계의 선두 회사들이 스칼라를 사용하면서 스칼라는 차세대 JVM 언어로 확고하게 자리를 잡았다.
문제는 스칼라 언어를 배우는 것이 보기보다 쉽지 않다는 점이다. 스칼라를 창시한 마틴 오더스키는 객체지향 기법과 함수 프로그래밍 기법을 하나의 언어 속에 녹여내고자 시도했기 때문에 스칼라의 문법은 OOP + FP라는 공식이 낳은 장점과 단점을 동시에 떠안으며 복잡해졌다.
자바 언어를 사용하는 회사의 직원들이 스칼라 언어를 익히기 위해서 만든 스터디 그룹에 참여해서 도움을 준 적이 있다. 어떤 책을 선택해서 공부할지 토론을 하는데 한 친구가
때마침 타입클래스(type class)에 대한 이야기를 하고 있었기 때문에 그 친구에게 스칼라에 타입클래스가 존재하는 이유가 무엇인지 설명해달라고 말했다. 트레이트(trait)와 임플리싯(implicit)을 거론하면서 타입클래스를 만드는 방법을 설명하기에 ‘방법’이 아니라 ‘이유’를 설명해달라고 말했고, 그 친구는 대답하지 못했다.
그날 저녁에 사이먼 사이넥(Simon Sinec)의 “왜에서 시작하라”라는 제목의 테드 강연 링크(https://www.youtube.com/watch?v=IPYeCltXpxw)를 직원들과 공유했다. 왜, 무엇, 어떻게 중에서 어느 것이 가장 중요한 지에 대한 이야기도 했다. 그러면서 ‘어떻게’에 집중하는 쿡북류의 서적이 가진 한계와 단점을 설명했다.
개발자가 새로운 언어나 기술을 접할 때 취할 수 있는 전략은 크게 두 가지가 있다. 하나는 손에 흙과 피를 묻히면서 ‘어떻게’에 초집중하는 방법이다. 눈앞에 닥친 문제를 해결하는 테크닉에 초점을 맞추고 배후에 존재하는 원리나 이론은 나중에 공부하거나 혹은 영원히 신경 쓰지 않는 전략이다.
또 하나의 방법은 선(禪)과 명상이다. 실제 명상을 이야기하는 것이 아니라 그렇게 보일 정도로 키보드를 두드리는 일보다 원리와 개념을 이해하는데 비중을 둔다는 뜻이다. ‘어떻게’가 아니라 ‘왜’와 ‘무엇’에 집중한다. 원리가 이해될 때까지 책을 읽고, 읽고, 또 읽는다.
대부분의 개발자는 첫 번째 방법을 선호한다. 그러한 방법을 써도 필요한 기술을 익히거나 요구되는 작업을 수행하는데 문제가 없기 때문이다. 시간이라는 측면에서는 더 효율적이기도 하다. 스프링 프레임워크가 업그레이드되거나 자바의 버전이 올라가는 경우라면 이러한 방법이 잘 통한다. 하지만 패러다임이 바뀌는 경우라면 사정이 다르다.
패러다임의 변화는 근본적인 원리와 이론에 대한 이해를 필수적으로 요구한다. 그러한 내용을 철저하게 자기 것으로 만들지 않은 상태에서 ‘일단’ 새로운 패러다임을 수용하고 본다는 말은 성립하지 않는다. 그렇게 하는 것은 심지어 위험하기도 하다.
자바 개발자가 스칼라 개발자가 된다는 것은 단순히 사용하는 문법이 달라지는 것을 의미하지 않는다. 자바와 스칼라는 패러다임을 달리하기 때문에 사고방식 자체의 변화를 수반한다. 그런 면에서 마틴 오더스키가 직접 저술한
다시 스터디 그룹으로 돌아가 보자. 새로운 언어를 접하는 개발자들은 ‘빨리’ 해당 언어를 사용하는 개발자가 되기를 희망한다. 쿡북류의 책은 그러한 욕망에 부합하는 책이다. 그런 책이 의미가 없다고 말하는 것은 아니다. 그런 책은 나름의 용도가 있고, 지름길을 통해서 핵심적인 원리에 도달하는 능력을 가진 개발자도 많이 있다.
하지만 패러다임의 변화를 수용할 마음가짐이 있는 사람이라면 그런 욕망을 버려야한다. 느긋한 태도로 원리와 이론에 집중해야 한다. ‘어떻게’는 생각하지 말고, ‘왜’와 ‘무엇’에 초점을 맞춰야 한다. 코드를 작성하지 못하더라도 그 안에 담긴 풍부한 추상의 정글에서 삼시세끼를 꼬박꼬박 다 해먹어야 한다.
고계함수(higher-order function), 람다(lambda), 커링(currying), 대수적(algebraic) 타입, 변경 불가능성(immutability), 참조 투명성(referential transparency), 타입클래스(type class), 펑터(functor), 어플리커티브(applicative), 모노이드(monoid), 모나드(monad), 범주이론(category theory) 등으로 이어지는 끈끈한 추상의 늪을 통과한 다음, 중후한 내공을 실어서 코드를 작성해야 옳다.
이러한 추상은 ‘어떻게’의 잡다함을 눈앞에서 사라지게 만들기 때문에 자연스럽게 ‘왜’라는 질문과 연결된다. 그런 연결고리를 사색하는 태도가 선과 명상이다. 패러다임을 넘다드는 사람은 이런 태도가 필요하다.
스칼라에 대한 이야기를 하고 있지만 사실 ‘왜’에서 출발하라는 원리는 프로그래밍 언어에 국한되는 이야기가 아니다. 우리 인생의 모든 것이 사실은 ‘어떻게’를 고민하는 것이 아니라 ‘왜’를 생각하는 데에서 출발할 때 해답을 얻게 되는 경우가 많다. 전공, 직장, 결혼, 유학, 이민 등을 고민할 때 ‘어떻게’에 집착하지 말고, 뒤로 물러서서 ‘왜’를 고민하면 정말로 해야 하는 일이 더 선명하게 드러난다.
관련기사
- 개발자, 바보처럼 보이는걸 두려워말자2015.03.10
- 지금 당장 가상 개발자 모임 시작하자2015.03.10
- 프로그래밍 공부하는 인문계 대학생에게2015.03.10
- 구글에 입사하려면…좋은 스펙이 오히려 독?2015.03.10
모든 것을 왜에서 시작하라.
'나는 프로그래머다'라는 제목의 팟캐스트 방송을 곧 시작합니다. 현재 준비 중인 홈페이지에 자세한 내용이 공지될 예정입니다. 독자 여러분들의 많은 관심과 청취 부탁드립니다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.