내가 브리즈번에서 가장 좋아하는 스시 일식당인 Takashiya는 함께 비즈니스 하는 분들과 축하할 일이 있거나, 고마움을 표현해야 하는 분이 있을 때 방문한다. 얼마 전엔 결혼 25주년 기념으로 아내와 함께 하려고 계획한 한 달간의 식사 코스 첫 날로 이곳을 찾았다. 평일 저녁이고 상대적으로 덜 붐비는 마지막 프리미엄 세션이라 나이가 지긋한 호주인 커플과 우리 부부만 자리해서 편안하게 식사를 하게 되었다. 평소엔 꽤 높은 텐션으로 분주하게 움직이며 요리를 준비하고 밝게 잘 웃던 셰프 Takashi Nami도 이날은 차분하게 음식을 준비하고 서빙하면서 조용히 이런저런 이야기를 들려주었다. 호주 전역에서 나는 특색 있는 해산물과 뉴질랜드, 일본, 스페인에서 직접 구해온 좋은 재료를 가지고 매번 예상을 넘어서는 맛과 향을 가진 창의적인 코스를 준비해 주는 건 여전했고.
그런데 이날은 앉은 위치 때문인가 바로 앞 벽에 걸린 칼들이 눈에 들어왔다. 스시 셰프에게 가장 중요한 도구를 꼽자면 아마 칼일 거다. 좋은 재료를 구하면 이를 잘 손질해서 손님 앞에서 꺼내 마지막 썰어내기에 좋은 크기로 준비하고, 마지막 세밀한 손놀림과 함께 최적의 모양과 크기로 잘라내어 하나의 초밥이나 회를 이용한 요리를 완성하는데 데 칼만큼 중요한 도구는 없을 거다. 큰 참치 등을 다룰 때 쓰는 양날을 가진 큰 칼부터 세포의 손상까지 고려해서 빠르고 선명하게 부드러운 횟감을 잘라낼 때 쓰는 가늘고 날카로운 칼까지, 내가 잘 모르지만 아무튼 여러 용도에 쓰일 것 같은 크기와 특징을 가진 칼들이 잘 손질되어 준비되어 있는 게 보였다.
세션 중간에 몇 개의 칼을 꺼내어 설명해주었는데 가장 인상에 남은 건 크기가 다르지만 실은 같은 종류인 칼 두 개를 비교해서 보여준 것이었다. 원래 칼은 왼쪽의 크기인데 Takashi 셰프가 이걸 36년 동안 계속 손질해서 사용하면서 날이 닳아서 크기가 작아진 게 오른쪽의 칼이다. 36년 동안 이걸 계속 사용했다니.
Takashi 셰프는 홋카이도 출신이다. 15살 때 스시 요리사가 되기 위해 식당에서 도제식으로 셰프를 희망하는 젊은 사람들을 쓰는 식당에 견습생으로 들어갔다. 종일 보이지 않는 곳에서 궂은일을 했고, 식당이 문을 닫은 뒤에야 혼자 연습하며 실력을 키우며 셰프의 꿈을 위해 버텨왔다고 한다. 보통 일본 스시 식당 견습생들은 5년 이상 버티고 실력을 인정받아야 겨우 손님 앞에서 칼을 잡을 수 있는 기회가 주어진다. 그런데 Takashi 셰프는 매일 밤마다 칼을 가지고 재료를 준비하는 연습을 치열하게 한 끝에 2년 만에 칼을 잡고 보조 셰프로 일을 시작할 수 있었다. 그때부터 40년을 일본과 호주에서 스시 셰프로 일하면서 장인의 수준에 오르게 됐다. 지금은 자신의 이름을 건 식당을 브리즈번의 강남이라고 할 수 있는 사우스뱅크에 열고, 평론가와 손님들의 찬사를 받으며 지금 까지 마스터 셰프로 일을 하고 있다.
이날 미소를 지으며 자랑스럽게 보여준 이 칼은 36년간 사용했다고 하니 아직 성인이 되기도 전인 어린 시절부터 사용해온 것이겠지. 칼의 크기가 점차 달라지면 쥐고 움직이는 방법도 바뀌어야 했을 것이다. 여유가 생기면 원래 크기와 비슷한 좋은 칼을 새로 구해서 써도 그만이었을 것인데, 자신이 소중하게 사용해서 셰프의 자리에 오르기까지 매일 밤 손에 쥐고 연습해 왔던, 떨리는 마음으로 처음 손님 앞에서 재료를 손질해서 음식을 낼 때 잡았던 도구를 정말 소중하게 계속 간직하고, 계속 연마하면서 작아지는 칼에 맞춰 자신의 손의 움직임도 계속 따라 연습을 해온 게 분명하다.
자신이 하는 일에 도구가 얼마나 중요하고 소중한지 잘 알고, 이걸 계속 손질하고 관리해서, 궁극적으로 손님을 만족시키는 좋은 요리를 만들어내는데 사용할 줄 아는 사람. 바로 도구를 사용해서 자신의 운명과 환경을 제어할 수 있는 인간을 가리키는, 도구의 인간이라는 뜻의 Homo Faber가 아닐까 하는 생각이 들었다.
저 두 개의 칼을 들고 활짝 미소짓고 있는 Takashi 셰프의 모습은 꽤 오래 기억에 남을 듯하다.
도구를 사용하는 개발자
원래 개발자는 원래 무엇인가 창조하는 일을 하는 사람이다. 어제는 없던 코드를 설계하고 작성해서 오늘은 누군가 사용할 수 있는 동작하는 소프트웨어를 만드는 사람이니까. 그런데 때로는 주어진 도구를 기계적으로 활용해서 매번 비슷한 결과물을 내는, 약간의 훈련만 되어있으면 별 다를 바 없는 작업을 반복하기만 하는 단순 노동자로 취급되기도 한다. 백엔드 개발자는 JSON으로 포장된 데이터의 상하차 작업을 하는 사람이라는, 농담이라고 하기에도 너무 허탈하게 느껴지는 이야기를 하기도 하는데.
그건 아니라고, 우리는 꽤 창조적인 작업을 하는 사람들이다.
개발자가 창조적인 작업을 하는 사람이 될 수 있는 건 무엇인가 만들어낼 때 적절한 도구를 사용할 줄 알기 때문이다. 바보같은 컴퓨터가 알아먹을 수 있는 바이트를 뽑아내는 컴파일러를 만들고,그 위에 얹을 표현력이 좋은 구조를 가진 언어를 만들고, 반복적으로 사용되는 코드를 라이브러리로 만들고, 그걸 이용해서 온갖 애플리케이션과 시스템 프로그래밍을 한다. 단순한 텍스트 에디터로부터 모든 개발 작업을 한 곳에서 다 처리할 수 있는 통합개발환경(IDE), 그리고 각종 플러그인과 부가 기능, 서비스, 도구를 얹고 또 얹어서, 예전 같으면 상상도 못할 속도로 소프트웨어를 만들어낸다.
소프트웨어 개발자만큼 도구를 다양하게 많이 활용하는 사람도 없을 것 같다.
그런데 그러면 충분한가?
도구를 만드는 개발자
나는 처음 기업에서 개발을 시작한 뒤로 오랜동안, 고객이 원하는 애플리케이션을 만드는 중에도 끊임없이 내 작업을 더 효과적으로, 더 빠르게, 더 편리하게 해 줄 수 있는 무엇인가 만드는데 집착해 왔다.
90년대 처음 웹 개발이란 걸 CGI 방식을 이용해서 시작했는데, 웹 서버가 프로세스를 띄워서 코드를 실행해주면 데이터 등을 가져와 로직을 적용한 다음 브라우저에 돌려줄 HTML을 printf()로 출력해야 했다. printf("<HTML>..."); 이런 C 코드를 길게도 작성했다. 며칠이 지나자 저 문자열에 HTML 태그와 데이터를 이리저리 합성해서 출력하는 코드를 만지는 게 불편해졌다. 내가 이런 작업에, 오타 때문에 툭하면 잘못된 결과가 나서 고쳐대야 하는 노가다를 해야 하는가라고 생각을 했다. 비록 주변 개발자들은 묵묵히 그렇게 개발하고 있었지만. 그래서 편집을 안 해도 되는 HTML 코드만 있는 파일을 만들고, 동적으로 변경되는 정보를 넣어줄 수 있는 위치를 마킹한 뒤에 그걸 읽어서 C 코드를 생성하는 프로그램을 만들었다. 지금으로 치면 템플릿 엔진 비슷한 코드 생성기를 만든 것인데, 반나절쯤 여러 케이스를 다 지원하도록 그 작업을 하고 났더니, 다음 날부터 전에는 반나절 걸리던 작업이 30분이면 끝이 났다. 나머지 시간은 새로운 웹 개발 기술이 뭐가 나오고 있는지 찾아서 공부하는데 시간을 썼지.
고정사이즈 문자열을 프로토콜에 맞춰서 전문으로 보내거나 파싱해서 처리해야 하는 은행 서비스 개발을 할 때도 비슷한 생각을 했다. 프로토콜을 정의한 엑셀 문서에 나온 내용에 맞춰서 전문을 생성하거나 파싱 하는 코드를 만들면 편리하지 않을까 생각했고 남들 모르게 라이브러리를 만들어 다음부터는 그냥 찍어내 듯이 쉽고 정확하게 동작하는 코드를 만들 수 있었다.
개발자라면 자신이 만드는 코드에서 반복적인 작업이 자주 등장하고, 이를 재사용할 수 있는 필요가 있다면 당연히 도구를 만들어야 한다고 생각했다. 라이브러리나 프레임워크를 만들기도 했고, 사용하는 개발툴의 확장 기능을 만들기도 했다. 필요하면 소스코드를 구할 수 있는 서버 프로그램을 뜯어고치기도 했고.
자바로 넘어오니 이건 완전 내 세상이었다. 상용 서버 코드도 Jar 파일 압축을 푼 뒤 나오는 클래스파일을 디컴파일하면 내부 구조가 보였다. 설명은 없지만 그래도 디컴파일해서 보면 어떻게 동작하는지 보였고, 클래스 로딩 순서를 강제로 바꿔서 내가 고쳐 만든 클래스로 대체될 수 있게 해서, 서버를 내가 원하는 방식으로 동작하도록 바꾸는 일도 했다. 본격적으로 오픈소스라는 걸 만나면서는 정말 환상적이었지. 당시 나온 프레임워크, 빌드 도구, 서버 따위를 프로젝트 초반에 내가 원하는 스타일로 튜닝하거나 기능을 추가해서 사용하는 걸 즐겨했다. 새 버전이 나오면 이번 것은 어떻게 만질 수 있을까 살펴보는 게 즐거움이었고.
이클립스를 사용하니 플러그인을 만들 수도 있었다. 메이븐도 플러그인과 각종 설정을 건드리면 기본 방식을 내가 좋아하고 편하다고 생각하는 걸로 변경해서 쓸 수 있었다. 내가 좋아하는 방식으로 모든 걸 고쳐서 써야 마음이 편했으니, 한동안 기본 세팅으로 써본 툴이 거의 없을 정도였다. 물론 버전업 될 때마다 계속 손이 가야 했지만.
스프링은 그때 만난 최고의 도구였다. 세상에 이렇게 멋진 도구가 있을까 싶었다. 내가 스프링을 교육할 때 자주 하는 질문이 있다. 스프링은 뭘로 만들었을까인데. 뭐 자바로 만들었겠지. 근데 내가 원하는 답은 그게 아니었다. 스프링은 스프링으로 만들었다. 스프링은 가장 기본이 되는 DI 기본 기능과 그 확장 포인트를 가지고 스스로 끊임없이 확장하고, 확장해서 만든 것이다. 거의 모든 기능이 그렇다. 거의 DSL 수준으로 기능을 외워서 써야 하는 애노테이션 범벅이 되었을 때도 마찬가지 었다. 그것도 스프링의 기존 기능을 확장하는 방식으로 만들었다. 스프링 코드를 뜯어 고쳤다는 게 아니라, 제공되는 유연한 확장 포인트를 가지고 기존 코드에 영향을 주지 않은 채로 기능을 추가할 수 있었다. 이게 바로 그 짜릿한 OCP구나라는 걸 매번 느끼면서. 이렇게 강렬하게 자신을 확장해서 써보라는 프레임워크들이 너무 좋았다. 객체지향 프레임워크라면 당연히 확장해서 개발하는 프로젝트에 맞게 만들어 쓰는 게 당연하다고 생각하고 이야기해 왔고.
대부분 오픈소스인 도구들도 마찬가지였다. 소스 코드를 받아서 내부 동작원리를 보고, 확장 포인트를 찾아서 이리저리 만져보는 게 즐거웠다.
근데 어느 때부터인가, 그런 작업을 하지 않게 되었다. 튜닝의 끝은 순정이라는 따위의 말을 하면서 도구를 만든 사람들이 준 기본 방식을 따라서 잘 쓰면 된다, 없으면 안 쓰면 그만이라는 생각이 서서히 들어왔다. 귀찮은 건지, 기본 도구들이 너무 발전한 것인지 모르겠지만. 그래서 빌드 툴의 플러그인을 만드는 것도, 라이브러리나 프레임워크를 확장한 기능을 만드는 것도 어느새 시들해져 갔고, 이젠 남들이 만들어 놓은 게 있으면 쓰고 아님 말고, 약간의 코딩 노가다는 치매 예방에도 좋으니까 하면서 살기 시작한 지가 제법 된 듯하다.
직접 만들고 손질할 가치가 있다
자신만의 도구를 소중하게 30년 넘게 손질하고 그에 맞춰 계속 자신의 실력을 쌓아왔던 Takashi를 보고 나니, 갑자기 부끄럽다는 생각이 들었다. 내가 그분보다 어릴 텐데, 그리고 도구를 손질하고 만드는 데 훨씬 유리한 개발 일을 하고 있는데 이렇게 느긋하게 살고 있다는 게 뭔가 싶었다.
얼마 전 테스트 코드에서 기존 스프링이 제공하는 방식으로는 맘에 들지 않는 코드를 매번 추가해야 하는 케이스가 나왔다. 이전 같으면 그냥 그렇게 테스트 만들면 그만이지라고 생각했는데, 최근 함께 일하게 된 개발자에게 그런 모습을 보여주고 싶지 않았다. 그래서 이거 스프링 테스트 프레임워크를 기반으로 조금 확장한 기능을 만들면 테스트 코드도 깔끔해지고 가독성도 높아지고 이후에 변경에 흔들리지 않는 좋은 코드를 만들 수 있다고 설명하고, 함께 테스팅 프레임워크를 확장한 애노테이션과 이를 활용한 테스트 프레임워크 확장 기능을 만들었다. 별 거 아니지만, 만들고 나니 예전에 도구를 만들어 적용하고 날 때마다 짜릿했던 기억이 떠올랐다.
그래서 다시 나와 우리 개발팀이 필요한 도구를 본격적으로 만들어볼까라는 생각을 하기 시작했다.
최근에 개발하면서, 더 빠르게, 더 간단하게, 잘 만들고 싶은 건 테스트이다. 시간을 최소한으로 쓰면서 우리 프로젝트의 특성에 맞게 더 간결한 테스트를 만들 수 있는 여러 가지 방법에 대한 아이디어가 있는데, 매번 그냥 있는 거 쓰고 말지라고 넘어갔다. JUnit 5만 해도 확장 포인트가 잔뜩이고, 스프링 테스팅 모듈과 각종 Mock 프레임워크들도 마찬가지지. 최신의 테스트 지원 방식을 조합해서 핵심에만 집중한 이해하기 쉬운 테스트를 만들 포인트들이 보이거든. 거기에 IDE 플러그인까지 만들어 단축키와 메뉴를 이용하게 만들면 더 즐겁겠지.
그런데 개발 도구를 연마하는 걸 오랫동안 게을리했더니 따라잡으려면 꽤 시간을 투자해야 할 거 같다. 대부분 그래왔듯이 아마도 혼자 작업을 할테고 조금은 외롭기도 하겠지. 그래도 시작을 해볼까 싶어졌다. 예전에 이클립스 OSGi 플러그인을 이용해서 개발하는 걸 열심히 해봤던 것처럼, 이제 IntelliJ의 확장 기능과 플러그인을 만드는 걸 본격적으로 해보고 싶다. IntelliJ 커뮤니티 버전은 다 오픈소스다. 거기에 IDE 핵심은 다 들어있거든, 원하면 IntelliJ 커뮤니티 버전 자체를 확장해 보는 것도 할 수 있다. 코틀린 플러그인 개발은 또 얼마나 좋은 기회가 많은지. 스프링 이니셜라이저는 사실 스프링부트 프로젝트 만들라고 제한해 놓은 도구가 아니다. 얼마든 회사 내부에서 쓰는 표준 레이아웃과 기본 구성을 가진 프로젝트를 손쉽게 생성하는 데 사용할 수 있다. 코드를 다 분석하고 이걸 어떻게 쓸지 다 설계도 해놨는데 코딩을 안 하고 10년은 미뤄온 듯하다. 해볼 게 참 많구나.
다시 도구를 만드는 재미를 느껴보고 싶어졌다. 그걸로 최종 애플리케이션을 개발하는 걸 더 잘해야겠지. 그게 아니어도, 도구를 만드는 것만으로도 충분히 즐거움을 느낄 수 있는 걸. 몇 명이라도 같이 만드는 걸 즐겨주면 좋겠고.
그럴 가치가 있다.
얼마 전에 본 김영재 님의 발표에 이런 이야기가 나온다.
문제에 적중하는 시스템이 없다면, 만들자
어떤 도구로도 우리만의 문제를 해소하지 못한다면
우리 문제를 완벽하게 해결하는 정답 같은 경험이라면
직접 만들 가치가 있다
뭐가 됐든 도구를 찾고 다듬고 필요하면 고치거나 새로 만든다.
도구의 인간, 도구의 개발자니까.
직접 만들 가치가 있다.
....
이날 프리미엄 코스는 너무 좋았다. 예약을 할 때 무슨 특별한 날이냐고 묻길래 몇 주 후에 결혼 25주년이라고 했더니 축하하는 메시지를 담아서 메뉴 노트를 준비해준 것도 고마웠고. 셰프의 제자로 일을 배우고 있는 걸로 보이는 젊은 호주 직원이 내 취향을 듣고는 추천해준 Eigashima 일본 위스키도 놀라웠다. 고급 식재료를 쓴 여러 요리가 있었지만 가장 기억에 남는 건 일본 블루핀 참치를 아삭한 호주 야채로 감싸고 바삭하게 튀긴 케이퍼를 얹은 것이었는데, 맛과 식감이 너무 감탄스러웠다. 서호주에서 난 식재료는 동부 태평양과는 다른 인도양의 해산물이라 같은 종류라도 맛이 차이가 나는게 많다고 퍼스의 스시 셰프에게 들은 적이 있는데, Takashi 셰프가 그 먼 서호주의 재료도 적절하게 활용해서 창조적인 음식을 구현해 내는 것도 인상적이었다. 계절마다 새로운 재료를 찾아서 메뉴를 새로 구성한다고 하니, 호주 겨울인 6월 쯤 다시 찾아야겠다.
36년은 아니더라도 3년 동안 만들어 다듬어왔다고 내놓을만한 도구를 하나쯤 꺼내 놓으며, 웃으면서 이야기를 들려줄 수 있게되면 좋겠다.
'사상' 카테고리의 다른 글
| 테스트가 관리하는 트랜잭션 - 향로 님의 @Transactional 글을 읽고 (1) | 2024.03.04 |
|---|---|
| 테스팅 프레임워크는 직접 만들어 써보자 (0) | 2023.10.10 |