2026년 7월 24일 금요일

다시 하루 걸러 하루 달리기로 운동 주기를 바꾸어 보다

2026년 7월 말이면 달리기를 시작한 지 꼭 2년이 된다. 일반적인 체력이나 의지가 있는 사람이라면 이미 하프마라톤 코스 정도는 최소한 한 번쯤 소화하였을지도 모르겠다. 그에 비하면 나의 성적은 초라하다. 아직까지 6분 이내의 평균 페이스, 쉽게 말하여 30분에 5km 이상 달리기도 달성하지 못하고 있으니 말이다.

달리기 2주년을 앞두고 받은 배지
어제 받은 배지. 집을 나설 때에는 '오늘은 몸이 좀 피곤하니 과연 1km나 달릴 수 있을까?'하고 걱정을 하지만, 결국은 쉬지 않고 5km를 달리게 된다.

처음에는 하루 뛰고 하루 쉬는 것을 목표로 하였으나 피로감 극복이 힘들어서 하루를 달리고 이틀을 쉬는 것으로 운동 주기를 바꾸어 꽤 오래 지속하였다. 한 번에 달린 거리는 6~7.5km 정도였다. 최근에는 출장과 여행, 날씨 등으로 쉬는 기간이 더 길어지는 일도 많았다.

지속 가능성을 높이기 위하여 이번 주부터는 한 번에 달리는 거리를 5km로 약간 줄이고, 다시 처음과 같이 하루 걸러 뛰는 방식으로 돌아가기로 하였다. 만약 2~3km 정도라면 매일 뛰어도 괜찮을 것이다. 주 3회가 아니라 무조건 이틀에 한 번 달리기이다.

이번 주 달리기 기록
금주에는 하루 뛰고 하루 쉬기를 3회 반복하였다.

달리기를 시작한 이후 체중은 눈에 띄게 줄었다. 그러나 나이가 들면서 근육량 감소는 지속되고 있다. 오른쪽 상완골 대결절 1분 골절을 극복하기 위한 목적으로 시작한 아령 운동 정도로는 어림도 없는 것 같다. 이번 달 초에 받은 건강검진의 인바디 검사 결과는 정말 초라하였다.

달리기를 유일한 운동으로 삼아 심폐지구력을 향상시키는 것만으로는 당연히 근육량 증가뿐만 아니라 유지도 힘든 것 아니겠는가? 피트니스 클럽을 가지 않더라도 특별한 기구 없이 집에서 할 수 있는 근육 운동 방법이 있을 것이니 검색을 해 봐야겠다.

ChatGPT가 자동 생성한 기구 없이 집에서 하는 근력운동법을 아래에 소개하였다. 과거에 쓴 글에서는 아령 운동법도 소개한 일이 있다(긴 여행 뒤 일상으로 돌아와 다시 운동하기).

50대 중반을 위한 집에서 하는 근력운동법
ChatGPT가 자동 생성한 근력운동법.

먹는 것에 대한 유혹도 견뎌내야 하고, 운동 계획은 더욱 치밀하게 세워서 끈기 있게 실천해야 한다. 건강한 몸을 유지하는 것이 참 어렵다. 나 혼자 이렇게 궁리하고 실천할 것이 아니라 아내에게도 운동의 중요성을 설파해야 하는데, 참 걱정이다.

2026년 7월 22일 수요일

천박한 표어

표어는 조직의 철학을 압축한 문장이다. 좋은 표어는 짧지만 오래 남는다. 그 조직이 왜 존재하는지, 무엇을 지향하는지를 몇 마디 말로 설명한다. 그래서 표어를 만드는 일은 쉽지만, 좋은 표어를 만드는 일은 어렵다. 여기서는 새로운 프로젝트와 사업, 서비스의 이름도 넓은 의미의 표어에 포함하기로 한다.

좋은 표어는 처음에는 다소 생소할 수 있다. 대개 신조어에 바탕을 두기 때문이다. 하지만 좋은 표어는 스스로를 설명할 수 있다(self-explanatory). 그 이름을 듣는 것만으로 자연스럽게 의미가 전달되고, 시간이 흐를수록 이 표어를 내세우는 조직의 철학과 함께 사람들의 기억 속에 자리 잡는다.

반대로 천박한 표어는 이름보다 설명이 길다. 회의마다, 발표마다, 문서마다 '이 이름은 이런 뜻입니다.'를 반복해야 한다. 정작 설명을 다 듣고도 '그래서 왜 이런 이름을 붙였지?'라는 의문이 남는다면, 그 표어는 이미 목적을 잃은 것이다. 만약 권력의 기울어진 운동장에서 이러한 의문이 제기되면, 그 표어를 이해하지 못하는 '하급자'에게 십중팔구 그 잘못이 돌아간다.

또 하나의 기준이 있다. 몇 년이 지나도 이름이 입에 잘 붙지 않는다면, 그것도 좋은 이름은 아니다. 사람들은 억지로 만든 이름을 오래 기억하지 않는다. 결국 줄여 부르거나 다른 이름으로 바꾸어 부른다. 이름은 사람이 적응해야 하는 대상이 아니라, 사람이 자연스럽게 받아들이는 것이어야 한다.

이 원칙은 법과 정책에도 그대로 적용된다. 좋은 법은 끊임없이 자신의 존재 이유를 변명하지 않는다. 만약 담당자가 수년 동안 '법이 있으니 해야 합니다.', '제도가 생겼으니 따라야 합니다.'를 반복해서 설명해야 한다면, 문제는 국민이나 연구자가 아니라 법과 제도에 있을 가능성이 크다.

법이 있으니 중요한 것이 아니라, 중요한 일이기 때문에 법이 만들어진 것이고, 또 그래야 한다. 좋은 법은 시간이 흐를수록 왜 필요한지 스스로 설명한다. 좋은 정책은 담당자가 바뀌어도 살아남는다. 정책의 생명력은 추진자의 열정보다 해결하려는 문제의 타당성에서 나온다.

표어도 결국 다르지 않다. 이름은 철학을 담는 그릇이다. 그릇이 내용을 압도하기 시작하면 사람들은 철학이 아니라 이름만 기억하게 된다. 그래서 새로운 표어를 볼 때마다 나는 먼저 묻는다.

이 이름은 스스로를 설명할 수 있는가.

좋은 표어는 설명을 요구하지 않는다. 설명을 들으면 의미가 더욱 깊어지며, 이것은 깊어질수록 좋은 일이다. 반대로 표어를 이해시키는 데 끊임없이 에너지를 써야 한다면, 그것은 철학을 담은 이름이 아니라 포장에 가깝다.

좋은 표어는 조직의 철학을 설명한다. 천박한 표어는 표어 자체를 설명하느라 조직의 철학을 설명할 시간을 빼앗는다. 표어가 철학을 대신하는 순간, 조직은 이름을 만들고 철학을 잃는다.

2026년 7월 15일 수요일

Fluid Ardule, 블루투스 오디오 기능까지 넣어도 될까?

 


수 개월 동안의 개발을 거쳐 이제 겨우 DIY synth module로서 안정적인 작동을 하게 된 Fluid Ardule에 자꾸 새로운 기능을 욱여넣는 것이 과연 올바른 일인지 고민을 하고 있다. Fluid Ardule은 리눅스 기반의 운영체계로 돌아가는 매우 작은 컴퓨터이다. 따라서 오디오를 다루는 범용 기기로서 원하기만 한다면 새로운 기능을 추가해도 충분히 감당할 수 있다. 다만 건반을 연결하여 선택한 악기 음색으로 연주한다는 기본 기능에 지장을 주어서는 곤란하다.

재미와 활용성을 모두 높이기 위해서 처음부터 추구했던 것은 음원 파일과 인터넷 라디오 재생이었다. 여기까지는 큰 문제가 없었다. 그러나 자연스럽게도 다음 단계의 욕심이 발동하였으니 그것은 바로 블루투스 오디오 기능이다. 신뢰할 수 있는 기기를 미리 등록해 놓은 뒤, 필요한 때에 UI를 조작해서 블루투스 페어링을 하여 휴대폰에서 송신하는 음악을 재생하는 것.

부팅 과정에 걸리는 시간을 최소화하기 위해 블루투스 관련 기능은 전부 막은 상태였다. SSH로 접속하여 이를 해제한 다음, 단계별로 테스트를 진행하였다. 음악이 흘러나오게 만드는 데에는 많은 시간이 걸리지는 않았다. 실험 기록은 별도의 문서 Experimental Documents - Bluetooth Audio Activation and Pairing (Raspberry Pi OS Trixie)에 기록해 두었다.

블루투스로 음원을 들으면서 건반을 연주하겠다는 욕심을 가져서는 안 된다. 그것은 Pi의 내장 마이크로SD카드나 USB 드라이브에 수록된 음원 파일을 재생할 때와도 같은 제약 조건이라고 받아들이는 것이 낫다. 물론 기술적으로는 가능하다. 하지만 그 순간부터 JACK, PulseAudio, PipeWire가 하나둘 등장하기 시작한다. 그 길은 기능이 늘어나는 길이기도 하지만, 동시에 유지보수가 급격히 어려워지는 길이기도 한다. 적어도 지금의 Fluid Ardule에서는 그 문을 열 생각은 없다. 나에게는 그곳이 '지옥으로 들어가는 입구'처럼 보이기 때문이다.

최근 Fluid Ardule UI에서 console로 진입하는 방법을 구현해 놓은 일이 있다. 블루투스 기기의 최초 등록은 SSH나 console을 통해서 진행하고, UI에서는 이미 등록된 기기를 연결하거나 해제하는 방식으로 운영하면 매우 간단할 것이다. 블루투스 오디오 재생 중에는 다른 기능으로 건너뛰는 것을 제한할 것이다. 그것은 Combi의 운영 방식과 유사하다.

아직 운영 스크립트에 이 기능을 넣을지 여부는 결정하지 않았다. 어쩌면 한동안은 Experimental 문서로만 남아 있을지도 모른다. 하지만 이번 실험을 통해 적어도 '할 수 있는 일'과 '하지 않기로 한 일'의 경계는 한층 분명해졌다. 프로젝트가 커질수록 새로운 기능을 추가하는 일보다, 그 유혹을 적절한 선에서 멈추는 일이 더 어려워진다. Fluid Ardule도 이제는 그런 고민을 해야 하는 단계에 이른 것 같다. 그 유혹에 넘어갈 때, Fluid Ardule은 컴퓨터 옆에 놓고 언제든지 즐길 수 있는 Desktop Music Workstation에 가까워지는 것은 사실이다. 이러다가 녹음 기능까지 넣고 싶어지면 절대로 안된다! 끝을 모르는 지옥의 입구로 진입하는 일은 없어야 하니까 말이다.


2026년 7월 19일 업데이트

이미 나흘 전, 그러니까 이른 여름 휴가를 떠나기 직전에 운영 스크립트에 블루투스 오디오 재생 기능을 넣었다. GitHub에도 스크립트를 올리고 관련 문서도 전부 수정하였다(commit 2e6b405, 스크립트 버전 260715f). Why not? 




2026년 7월 11일 토요일

Fluid Ardule 소개용 동영상을 새로 만들다

누구에게나 멋진 계획이 있다. 졸작을 만들어내기 전까지는...

인클로저까지 가공하여 만들고, 운영 소프트웨어의 기능과 안정성도 현저히 개선된 지금이야말로 Fluid Ardule의 본격적인 소개 영상을 만들어서 공개할 시점이다. 지저분한 물건을 가릴 배경지까지 구입하여 늘어뜨린 것은 좋았다.

나름대로 시나리오를 구성하여 촬영을 하였는데, 별로 마음에 들지 않는다. 게다가 OpenShot Video Editor는 왜 이렇게 말썽인 것인가? 최신 버전으로 업그레이드했지만 별로 나아지지 않았다. 오늘 작업에서 새로 발견한 문제점은 다음과 같다.

  1. 캡션 종료 시 1프레임 플래시

    일부 캡션이 끝나는 순간, 방금 사라진 캡션이 약 1프레임 동안 다시 나타났다 사라지는 현상이 발생했다. 이 문제는 미리보기뿐 아니라 내보낸 MP4 파일에서도 확인되었으며, 모든 캡션에서 동일하게 나타나지는 않았다.

  2. 캡션 배경 박스 크기 오류

    특정 캡션에서 반투명 배경 박스가 위쪽으로 비정상적으로 크게 확장되었다. 같은 설정을 사용한 다른 캡션은 정상적으로 표시되었고, 문제가 있는 캡션을 다시 만들자 정상으로 돌아왔다.

  3. 첫 PNG 타이틀이 내보내기에서 누락

    영상의 첫 화면에 배치한 PNG 타이틀은 미리보기에서는 정상적으로 보였지만, 최종 MP4 파일에서는 아예 나타나지 않았다.

  4. 마지막 PNG 슬라이드가 내보내기에서 누락

    영상 끝에 배치한 PNG 엔딩 슬라이드도 미리보기에서는 정상적으로 표시되었지만, 내보낸 영상에서는 빠져 있었다.

3번과 4번은 처음 접하는 문제점이었다. 유튜브에 올린 영상은 이 문제 때문에 마지막 화면이 수 초 동안 암흑 + 배경으로 처리되었다. 어쩌면 이제는 OpenShot을 졸업할 때가 된 것 같다. Kdenlive가 무료 오픈소스 비디오 편집 프로그램으로서는 더 나은 선택이라고 한다. 

OpenShot과 Kdenlive 비교

항목 OpenShot Kdenlive
사용 난이도 초보자가 배우기 쉽고 화면 구성이 단순하다. 기능이 많아 처음에는 다소 복잡하지만 익숙해지면 작업 효율이 높다.
편집 방식 간단한 자르기, 이어 붙이기, 이미지 삽입 등에 적합하다. 멀티트랙 편집, 복잡한 타임라인 구성, 중첩 시퀀스 등에 유리하다.
자막 기능 간편하지만 캡션 표시와 종료 과정에서 렌더링 오류가 나타날 수 있다. 전용 자막 기능이 있으며 자막 파일과 음성 인식 기반 자막 제작도 지원한다.
타이틀과 이미지 PNG와 SVG를 쉽게 배치할 수 있지만 미리보기와 내보내기 결과가 다르게 나타나는 사례가 있었다. 내장 타이틀 편집기가 강력하며 이미지와 그래픽 오버레이를 세밀하게 조절할 수 있다.
효과와 키프레임 기본적인 효과와 키프레임 애니메이션을 비교적 쉽게 적용할 수 있다. 효과와 키프레임 설정이 더 다양하고 정밀하다.
색보정 기본적인 밝기와 색상 조절에 적합하다. 색상 범위, 스코프와 다양한 색보정 효과를 제공한다.
오디오 편집 볼륨과 페이드 등 기본적인 조절이 중심이다. 오디오 믹서, 파형 표시, 필터와 효과 등 보다 전문적인 기능을 제공한다.
미리보기 성능 간단한 프로젝트에서는 가볍고 빠르지만 복잡해지면 반응이 느려질 수 있다. 프록시 클립과 미리보기 해상도 조절을 이용해 대형 프로젝트를 관리하기 좋다.
내보내기 신뢰성 사용하기는 쉽지만 프로젝트에 따라 미리보기와 최종 결과가 달라질 수 있다. 렌더링 설정이 세분화되어 있으며 비교적 복잡한 프로젝트에 적합하다.
지원 운영체제 Windows, macOS, Linux, ChromeOS Windows, macOS, Linux, BSD
가격과 라이선스 무료 오픈소스 소프트웨어 무료 오픈소스 소프트웨어
추천 용도 짧은 영상, 단순한 편집, 빠른 제작 자막이 많은 영상, 기능 소개, 장시간 프로젝트, 정밀한 편집

OpenShot은 배우기 쉽고 간단한 영상을 빠르게 만드는 데 장점이 있다. 반면 Kdenlive는 처음에는 다소 복잡하지만 자막, 타이틀, 오디오, 효과와 내보내기 설정을 더욱 정밀하게 관리할 수 있다. 편집 결과의 안정성과 확장성이 중요해진다면 Kdenlive가 더 적합한 선택이 될 수 있다.

그리하여 만들어진 오늘의 졸작은 다음과 같다. 분량은 5분을 약간 넘는다. 보다 시나리오를 철저히 구성했다면 마치 주저하듯이 버튼을 누르면서 낭비한 시간을 줄일 수 있었을 것이다. 


인터넷 라디오가 작동하는 모습을 그대로 촬영했더니 유튜브에 올렸을 때 저작권에 대한 경고가 떴다. 영상이 차단될 정도로 심각한 것은 아니라서 그냥 두기로 했다. 문제가 된 곡은 노르웨이의 밴드 Flunk의 Sit Down이란 곡이다. 경고 화면은 다음과 같다.


배경 음악, 아마추어 밴드의 기성곡 커버 등 유튜브에 영상을 올릴 때 이런 점을 유의해야 한다. 1분 이내면 괜찮다는 잘못된 정보가 너무 많다. 

숏 영상을 다시 만들 기력은 없다!

2026년 7월 9일 목요일

Fluid Ardule의 3.5인치 화면에서 리눅스 콘솔을 만나다

Fluid Ardule을 다른 사람도 만들어 쓸 수 있도록 배포하려면 어떻게 해야 할까? 요즘 이런 생각을 조금씩 하고 있다. GitHub에는 소스 코드와 설치 문서를 올려 두었지만, 실제로 Raspberry Pi OS부터 설치해서 시스템을 구성하려면 제법 많은 수고가 필요하다. 특히 Wi-Fi 설정은 사용자마다 다를 수밖에 없다.

현재 Fluid Ardule은 부팅 시간을 줄이기 위해 NetworkManager를 사용하지 않는다. 실제로 systemd-analyze blame으로 확인했을 때 NetworkManager 서비스가 부팅 과정에서 13초 이상을 차지한 적이 있었다. 전원을 켜고 빨리 악기를 사용하고 싶은 시스템에서 13초는 결코 짧은 시간이 아니다.

그래서 Fluid Ardule은 wpa_supplicantdhcpcd를 이용하는 비교적 단순한 네트워크 구성을 사용한다. 문제는 새로운 Wi-Fi를 등록할 때이다. 내가 사용하는 집 Wi-Fi와 휴대전화 핫스팟 정도만 미리 등록해 두면 별 문제가 없지만, 배포판을 사용하는 사람은 자신의 SSID와 비밀번호를 입력해야 한다. 내가 공개한 문서에서는 SSH로 연결한 터미널 창에서 명령어를 넣어서 설정을 입력하는 방법을 소개해 두었다. 그러나 아무래도 불편하지 않을 수 없다.

처음에는 여러 방법을 생각했다.

Fluid Ardule의 인코더를 돌려 ASCII 문자를 선택하게 할까? SSID는 스캔 목록에서 고르고 비밀번호만 입력하면 된다. 그러나 90개가 넘는 printable ASCII 문자를 인코더로 돌려 고르는 장면을 상상하니 썩 내키지 않았다.

Raspberry Pi를 잠시 무선 AP로 만들어 휴대전화에서 접속하게 하는 방법도 있다. 이른바 captive portal 방식이다. 편리하기는 하지만 AP 모드, DHCP, 간단한 웹 서버와 설정 페이지까지 필요하다. Wi-Fi 비밀번호 하나를 입력하기 위해 또 하나의 작은 시스템을 만드는 셈이다.

USB 키보드를 연결하게 할까? 이것도 나쁘지 않다. 하지만 그러려면 Fluid Ardule의 전용 UI 안에 텍스트 입력 기능을 새로 넣어야 한다.

이쯤에서 생각을 바꾸었다.

Fluid Ardule은 상용 전자악기가 아니다. Raspberry Pi에 운영체제를 설치하고 Arduino 펌웨어를 올리며 MIDI 장치를 연결하는 DIY 프로젝트이다. 그렇다면 사용자에게 Raspberry Pi OS와 SSH에 대한 기본적인 숙련을 요구하는 것이 그렇게 부당한 일일까?

최초 Wi-Fi는 Raspberry Pi Imager에서 설정하면 된다. 새로운 네트워크가 필요하면 SSH로 접속하여 설정 파일을 수정할 수 있다. 아무도 요구하지 않은 captive portal을 만들다가 또 며칠을 보내는 것보다는 이 편이 훨씬 낫다.

그래서 설치 문서와 네트워크 문서에 이 원칙을 명시했다. Fluid Ardule은 DIY Raspberry Pi synthesizer project이며, Raspberry Pi OS와 SSH에 대한 기본적인 숙련을 권장한다고 말이다.

여기서 오늘의 이야기가 끝났어야 했다.

그런데 문득 이런 생각이 들었다.

“Fluid Ardule 서비스를 잠시 끄고 3.5인치 TFT를 그냥 리눅스 모니터처럼 쓸 수는 없을까?”

현재 Fluid Ardule의 TFT는 /dev/fb1이라는 framebuffer 장치이다. 운영 스크립트는 Pillow로 화면을 렌더링하고 그 결과를 framebuffer에 직접 출력한다. Raspberry Pi의 Linux 콘솔은 기본적으로 다른 framebuffer를 사용하고 있다.

확인해 보았다.

$ cat /proc/fb
0 vc4drmfb
1 fb_ili9486

framebuffer 0은 HDMI 쪽이고 framebuffer 1은 ILI9486 SPI TFT이다.

Linux console의 framebuffer 연결 상태도 확인했다.

$ con2fbmap 1
console 1 is mapped to framebuffer 0

그렇다면 console 1을 framebuffer 1로 바꾸면 어떻게 될까?

SSH로 접속한 상태에서 Fluid Ardule 서비스를 멈추고 다음 명령을 실행했다.

sudo systemctl stop fluid_ardule.service
sudo con2fbmap 1 1
sudo chvt 1

놀랍게도 3.5인치 TFT에 진짜 Linux console이 나타났다.

Fluid Ardule의 메뉴도 아니고 Pillow로 렌더링한 운영 화면도 아니다. Raspberry Pi의 텍스트 콘솔이다. USB 키보드를 연결하면 명령어를 직접 입력할 수 있다. raspi-config도 실행할 수 있다.

다만 화면은 정확히 180도 뒤집혀 있었다.

사실 당연한 결과였다. Fluid Ardule의 TFT 설정에는 다음과 같은 항목이 있다.

dtoverlay=piscreen,spi0-0,rotate=90,speed=32000000,fps=30

여기서 rotate=90은 ILI9486의 기본 세로 방향 framebuffer를 Fluid Ardule이 사용하는 480×320 가로 화면으로 바꾸기 위한 것이다.

그런데 실제 Fluid Ardule에서는 케이스 내부의 커넥터와 케이블 배치를 편하게 하기 위해 TFT를 반대 방향으로 장착했다. 따라서 가로 화면은 맞지만 실제 사람이 보는 방향에서는 180도 뒤집혀 있다. Fluid Ardule 운영 스크립트는 Pillow로 렌더링한 화면을 다시 180도 회전하여 이를 보정한다.

Linux console은 당연히 이런 사정을 모른다.

그래서 /boot/firmware/cmdline.txt에 다음 커널 파라미터를 추가했다.

fbcon=rotate:2

재부팅 후 다시 console을 TFT에 연결했다.

이번에는 정상 방향이었다.


3.5인치 화면에 raspi-config를 띄워 보았다. 화면이 너무 작지 않을까 걱정했지만 의외로 아무 문제가 없었다. 메뉴를 읽고 조작하기에 충분했다.



그리고 다시 Fluid Ardule로 돌아오는 것도 간단했다.

sudo con2fbmap 1 0
sudo systemctl start fluid_ardule.service

잠시 뒤 익숙한 Fluid Ardule 화면이 다시 나타났다.

오늘은 Wi-Fi 설정 방법을 고민하다가 시작했다. 결론은 “굳이 모든 것을 Fluid Ardule UI 안에서 해결하려 하지 말자”였다.

그런데 그 과정에서 더 재미있는 가능성을 발견했다.

Fluid Ardule의 3.5인치 TFT는 악기 화면으로만 사용할 필요가 없다. 평소에는 Pillow 기반의 전용 악기 UI를 표시하다가, 필요할 때 서비스를 멈추고 Linux console로 전환할 수 있다. 설정이나 진단이 끝나면 다시 악기 UI로 돌아오면 된다.

이제 운영 스크립트에 필요한 것은 Wi-Fi 설정을 위한 복잡한 암호 입력 화면이 아닐지도 모른다. 단지 “Console Mode”로 들어가는 문 하나면 된다.

악기 UI는 악기답게 단순하게 유지하고, 시스템 관리는 Linux에게 맡긴다.

오늘은 기능 하나를 더 만든 날은 아니다. 오히려 만들지 않아도 될 기능을 찾아 헤매다가, 이미 시스템 안에 있던 다른 문 하나를 발견한 날이다.

2026년 7월 7일 화요일

완벽함의 유효기간은 생각보다 짧다

보다 정확히 말하자면 '완벽하다는 믿음의 유효기간은 생각보다 짧다'라고 하는 것이 맞을 것이다.

어제 수정한 Fluid Ardule 운영용 파이썬 스크립트(버전 260706b; 10,725줄)가 정말 완벽하게 작동하는 것 같았다. 

"이만하면 됐다!"

이제는 소개용 영상을 찍어서 유튜브에 올려도 손색이 없겠다고 자신감에 부풀어 있었다. Fluid Ardule의 프로토타입을 소개한 숏 영상은 나의 유튜브 채널에 몇 개 올라가 있지만, 본격적인 소개 영상은 정식으로 인클로저에 넣고 나서 테스트가 어느 정도 되면 그때 찍으려고 잔뜩 벼르고 있었다. 이번 주말에는 영상 작업이 가능하리라! 

하지만 완벽함에 대한 믿음은 단 한 시간도 가지 않았다. 260706b를 GitHub에 commit한 직후 테스트를 해 보다가 미처 점검하지 못한 곳에 오류가 남아 있음을 또 발견한다. 완벽이 아니었던 것이다.

완벽함의 유효기간은 왜 이렇게 짧을까?

때로는 세상이 바뀌어서 나의 완벽함에 대한 바깥의 기대 수준이 훌쩍 올라간 때문이기도 하다. 하지만 세상이 하루 사이에 갑자기 바뀌는 일은 많지 않다. 가장 근본적인 원인은 어제 느꼈던 완벽함이라는 것이 전적으로 나의 착각일 수도 있다는 것이다.

소프트웨어 개발이 막바지에 접어들면서 필요한 기능은 거의 다 구현이 된 상태에 이르렀다. 그러나 소위 fine-tuning에 이렇게 많은 시간이 소요될 것이라고는 미처 생각하지 못했다. 지금은 더욱 매끄럽고 안정적인 작동을 보장하기 위한 미세한 조정 단계이다. 파레토 법칙의 변주라고나 할까? 나머지 20%를 채우기 위해 80%의 노력을 들이고 있다.

조금 더 긍정적으로 말하자면, 그만큼 나도 성장했기에 과거에 완벽하다고 생각했던 것 사이에 숨어 있었던 부족함을 비로소 눈치채게 되었다는 뜻도 된다. 따라서 값진 시행착오를 딛고 조금씩 나아지는 과정을 밟게 된다. 

예를 들어 완벽하다는 믿음의 유효기간이 24시간에 불과하여 매일 고치고 또 부족함을 느끼기를 일주일 동안 반복했다고 치자. 그래서 점진적인 개선을 거쳐서 A->B->C...->H를 만들어 냈다고 가정하자. 일주일 간의 경험은 결코 시간 낭비가 아니다. B에 도달했기 때문에 더 나은 C를 만들기 위한 개선점이 비로소 보이게 되었다. 그러나 타인으로부터 '왜 단번에 H를 만들어내지 못했어? 그러면 완벽했다고 보고한 A는 도대체 뭐야? 그동안 뭐했어?'라고 비판을 받으면 모든 의욕이 꺾인다.

Fluid Ardule의 운영 스크립트는 나 혼자 재미로 하는 일이니 중간 과정에 실수가 좀 있더라도 누구로부터 시간이나 예산을 낭비했다는 말은 듣지 않는다. 점검은 전적으로 나 혼자 한다. 

수시로 현장 점검을 하지 않으면 우리가 하는 일을 믿지 못하겠다는 사람들이 있다. 오늘 오후에도 그 사람이 찾아온다고 한다. 참으로 반갑지 않다.

형편없었던 장마 중 달리기

늦은 장마로 비가 계속 내려서 7월 2일에 이번달의 첫 달리기를 한 뒤 삼일이나 쉰 다음 어제(6일) 다시 밖으로 나갔다. 토요일의 건강검진에서 장을 깨끗이 비우느라 너무 애를 쓴 탓일까, 또는 수면내시경을 위해 투여한 진정제의 부작용인 것일까, 주말 내내 침대를 벗어나지 못했다. 

그렇다면 삼일이나 달리기를 쉬는 동안 꽤 몸이 많이 회복되었을 법도 한데 어제의 5.5km 달리기는 정말 형편없는 수준이었다. 매번 집을 나설 때에는 '아, 이상하게 몸이 무겁네. 오늘은 3km만 뛸까?'하는 유혹에 시달린다. 어제는 더욱 그러하였다.


7.xkm를 달리고는 했던 과거를 돌이켜 보자. 아주 오랜 옛날도 아니고, 불과 1년 정도 전이다. 5km와 7.xkm는 적은 차이가 아니다. 요즘은 달리는 거리도 줄고 쉬는 날도 늘었는데 왜 과거보다 더 힘들다고 느끼는 것일까? 신체의 자연스런 노화 때문인 것인지, 보충 운동을 제대로 하지 않아서 그런 것인지. 

8월이 되면 달리기에 입문한지 딱 2년이 지난다. 무엇이 나아졌는지 아직도 잘 모르겠다. 쉬지 않고 어쨌든 5km는 한번에 뛸 수 있다는(페이스는 신경쓰지 않고) 것에만 만족해서는 안 될 터인데...