프로그래머의 고민상담

임백준

퇴근시간 무렵 타임스퀘어는 퇴근하는 사람과 관광객이 인산인해를 이룬다. 유명한 사람이 나타나기라도 하면 정말이지 걷는 게 아니라 사람들 머리 위로 떠다니는 느낌이 들 정도다. 사람들 사이를 어렵게 통과해서 8번 거리 정도에 도달하면 그래도 걷기가 조금 수월해진다.

어느 날 퇴근길에 8번 거리를 따라 내려가고 있을 무렵에 같은 회사에 다니는 친구가 어깨를 치며 아는 척을 했다. 회사는 같지만 프로젝트가 다르기 때문에 회사 안에서는 마주칠 기회가 별로 없는 친구다.

자바를 이용해서 낮은 지연 프로그래밍(low latency programming)을 수행하다가 입사한 이 친구는 내가 아카(Akka)를 이용해서 만든 동시성 프로그램 라이브러리를 기반으로 새로운 어플리케이션을 제작하면서 나와 인연을 맺었다. 오랜만에 만난 그는 나에게 고민을 토로했다. 나름 뛰어난 자바 실력을 이용해서 고성능 자바 프로그램을 제작하던 자신이 지금 프로젝트에서는 대부분의 시간을 복잡한 SQL 구문을 제작하면서 보내고 있는 게 고민이었다. 그는 이렇게 말했다.

학교를 졸업하고 지금까지 여러 프로젝트를 수행하면서 SQL 구문은 아주 간단한 insert, update 정도만 작성했거든. 그런데 여기에서는 한 페이지 분량이 넘는 길고 복잡한 SQL과 PL/SQL을 작성하며 데이터만 다루고 있으니 말이야. 지루하기도 하고, 프로그래밍 실력도 하루가 다르게 줄어드는 것 같아서 괴롭네. 뭐, 재밌는 프로젝트 좀 없을까.

프로그래밍을 직업으로 삼고 있는 사람 중에는 이와 유사한 고민을 하는 사람이 의외로 꽤 있을 것이다. 나도 이런 고민을 한 적이 있다. 이러한 고민이 드물지 않은 이유는 간단하다. 프로그래밍이라는 범주가 크게 코드와 데이터라는 두 개의 하위범주로 나누어지기 때문이다.

내가 과거에 수행했던 프로젝트 중에서 실시간 금융거래 시스템을 구현하는 프로젝트에서는 코드가 갑이었다. 관건은 언제나 코드가 얼마나 빠르고 정확하게 동작하는가 하는 것이었다. 시스템이 축적하는 데이터는 최종결제(settlement)를 위한 참고적인 데이터에 불과했다. 이러한 프로젝트에서 SQL이나 PL/SQL을 다루는 작업은 대개 별도로 존재하는 ‘데이터베이스 프로그래머’에게 일임되기 때문에 코드를 작성하는 ‘프로그래머’들은 간단한 SQL 구문 정도만 다룰 수 있으면 충분했다.

그렇지만 데이터가 갑인 프로젝트도 존재한다. 리포트를 작성하고, 비즈니스 데이터 분석을 수행하고, 데이터를 이용해서 시뮬레이션을 수행하는 부서에서는 데이터가 갑이다. 데이터를 어떻게 저장할 것인지, 시간의 흐름에 따른 데이터의 변화를 어떻게 포착할 것인지, 중요한 데이터를 취합, 분석, 계산해서 보기 좋게 요약한 리포트를 어떻게 만들 것인지가 핵심인 이러한 프로젝트에서는 코드가 찬밥신세를 면치 못한다.

이런 상황에서는 모든 개발자가 당연히 장문의 SQL이나 PL/SQL을 작성해야 하고, 경우에 따라서는 KDB와 같은 특이한 데이터베이스를 학습하거나 R과 같은 이색적인 언어를 공부해야 하기도 한다. 마이크로소프트 액셀을 자유자재로 다룰 수 있어야함은 물론이다. 이러한 프로젝트에서는 사용자들이 리포트를 수시로 요구하기 때문에 미리 정해진 프로젝트 스케줄에 따라서 개발업무를 수행하는 것이 아니라 그때그때의 필요에 따라 SQL 구문을 작성해야 하는 경우가 많다.

예컨대 수많은 쓰레드가 상호작용을 하면서 외부의 이벤트를 가장 빠른 속도로 처리하도록 만들기 위해서 자바 가상기계의 가비지 컬랙션 알고리즘의 내부를 낱낱이 파악하고, JIT 컴파일러가 바이트코드를 어떻게 바이너리코드로 변환시키는지, 왜 바이너리코드를 다시 바이트코드로 원상복귀 시키는지 등을 연구하던 사람이라면 확실히 SQL 구문을 작성하면서 장부의 숫자가 일치하는지 여부를 따지는 일은 지루하다. 다른 사람에게 일임하던 일을 직접 하려니 고통이 느껴지는 것이다.

더구나 NoSQL 운동이 확산되면서 이름부터 섹시한 카산드라, 몽고DB, HBase, Neo4j 등이 시장을 점유해 나가고 있는 요즘, 그런 기술을 활용하지 못하고 ‘고리타분한’ 관계 데이터베이스를 위한 SQL 구문을 작성하는 일은 더욱 지루하게 느껴질 것이다.

물론 코드와 데이터는 어느 것이 더 중요하다고 말하거나 어느 것이 더 재미있다고 말할 수 있는 성질의 것이 아니다. 중요성으로 말하자면 둘 다 중요하고, 재미로 말하자면 그것은 개인의 취향일 뿐이다. 예를 들어서 15년 동안 데이터베이스를 다루어오던 사람에게 자바를 이용해서 고성능 멀티쓰레딩 코드를 작성하라고 말하면, 그것이 어렵게 느껴지는 것은 둘째로 하더라도 일단 그 일이 재미가 없을 것이다.

그렇기 때문에 친구의 고민은 원인분석과 처방이 간단하다. 그는 기본적으로 번지수를 잘못 찾아왔다. 코딩에서 기쁨을 느끼는 친구가 모든 것이 데이터를 중심으로 돌아가는 부서에서 일을 하고 있으니 재미를 느낄 리가 만무하다. 그는 코드가 갑인 프로젝트를 찾아서 자리를 옮겨야 한다. 필요하다면 회사를 옮기는 것도 고려해야 한다.

확실히 그 친구는 나와 액터시스템(Actor system)에 대해서 이야기하고, 멀티쓰레딩 코드를 디버깅할 때 눈이 빛나고 생기가 돌았다. 반면 화면에 이클립스가 아니라 RapidSQL을 띄워놓고 있을 때 그는 수시로 자리에서 일어나서 차를 마시고, 인터넷 뉴스 사이트를 돌아다니고, 한숨을 내쉬었다. 그리하여 나는 그 친구에게 다른 사람에게 아무 말도 하지 않겠으니, 시간을 두고 다른 부서나 회사를 알아보라고 권유했다.

우리 인생이 얼마나 길다고 고민을 할 정도로 싫은 일을 하면서 시간을 보내야 하는가. 그럴 필요는 없다. 8번가에서 우연히 마주친 친구의 고민상담 덕분에 생각했긴 하지만, 이 말은 우선 나 자신에게, 그리고 비슷한 고민을 하는 모든 사람들에게 들려주고 싶은 말이다. 하고 싶은 일을 하라. 모든 행복과 성취의 출발은 바로 거기에 있다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.