사용자 도구

사이트 도구


사이드바

blog:start

스트라바 구독모델 변경에 마음을 놓으며

작년 이맘때쯤 여러 구독을 점검하면서 스트라바 구독이 곧 끝남을 알게 됐습니다. 그때까지는 스트라바를 유료로 구독하고 있었는데 여러 기능들이 썩 만족스럽지 않았습니다. 심박기반의 운동부하계산은 가민이 제공하는 정보에 비해 제 몸에 잘 맞지 않는다고 느꼈고 목표설정 기능은 재미있었지만 들쭉날쭉한 회사 업무식간을 제 의지대로 활용할 수 없는 상황에서는 좌절감을 키우는 역할을 하고 있었습니다. 퍼스널 히트맵은 재미있지만 매일 혹은 매달마다 보기에 적당한 컨텐트는 아니었고 이 정도를 제외하면 프로필에서 제 이름 옆에 유료 구독자 아이콘이 표시되는 것 외에는 무료로 사용할 때와 별로 다른 점을 느끼지 못했습니다. 그래서 고민 끝에 구독을 연장하지 않기로 결정했습니다. 그리고 머지않아 찾아올 다운그레이드를 맞이할 작정이었습니다.

그런데 이때쯤 스트라바가 유료 구독 모델을 변경했습니다. 제가 구독을 중단할 때 까지는 스트라바에 유료 구독 모델은 딱 하나만 있었습니다. 무료로 사용하거나 연 $60을 내고 유료로 사용하거나가 있을 뿐이었습니다. 그런데 이때쯤 스트라바는 유료 구독 모델을 세 가지로 분리하고 각각에 연 $20 정도로 변경했습니다. 이전에 $60짜리 구독에서 한 번에 지원하던 모든 기능을 'Training', 'Safety', 'Analysis'로 구분했습니다. 스트라바의 여러 유료 기능을 사용자들의 요구에 따라 필요한 부분만 구독해서 전체적으로 비용을 낮춰 기존 유료 사용자들이 유료 사용자로 전환할 더 많은 기회를 만들 목적이었을 거라고 짐작합니다. 하지만 단순하게 생각해도, 또 디지털 기반의 유료 컨텐트를 개발하는 입장에서도 이건 썩 좋은 아이디어가 아니라고 생각했습니다. 일단 회사 입장에서 아무런 안전장치 없이 객단가를 3분의 1로 떨어뜨리는 조치일 뿐 아니라 사용자들이 어떤 구독 상품을 선택해야 하는지 헛갈리게 만들고 모든 기능을 필요로 하는 기존의 충성고객들이 손해보는 느낌을 받게 만들기 때문입니다.

일단 전체 기능을 세 가지로 나눈 다음 각각의 가격을 3분의 1로 설정하는건 신규 유료고객을 늘리는 효과보다는 기존 유료고객들의 객단가를 낮추는 역할을 합니다. 저는 위에서 스트라바 유료구독을 중단헸습니다. 그런데 자잘하게 심박 기반의 통계를 포함한 몇몇 기능이 아쉬웠고 이 기능만 사용하기 위해 $20을 내고 'Analysis'팩을 구독하기로 했습니다. 이 사례만 보면 저는 단가 $60짜리 고객에서 $0짜리 고객이 될 뻔 했다가 $20짜리 고객이 된 셈입니다만 다른 고객들을 생각해보면 원래 $60짜리 고객이 될 수 있었던 신규고객들이 $20짜리 고객이 될 뿐 아니라 기존 $60짜리 고객들이 $20짜리 고객으로 변하게 됨을 의미하기도 합니다. 뭐. 어떤 사람들은 더 낮은 가격으로 구독을 유지하고 또 어떤 사람들은 더 낮은 가격으로 새롭게 구독을 시작하는게 이들의 예쁜 계획이었을 겁니다. 뭐. 여기까지는 그럭저럭 괜찮습니다.

하지만 기존 $60을 내고 구독하던 고객들에게 이 세 가지 구독모델 구분은 그리 좋은 소식이 아니었습니다. 모든 사람들이 스트라바의 모든 유료 기능을 활용하지는 않습니다. 자전거를 조금 더 본격적으로 탈수록 이 유료 기능을 점점 더 활용하게 되는데 이들이 서로 다른 구독 모델에 흩어져 있을 경우 가격 할인 효과가 없었습니다. 가령 심박과 파워미터 기반의 분석 데이터만 필요로 한다면 $20만 내면 되지만 여기에 비컨 기능을 사용하려면 $20을 더 내야 하고 여기에 퍼스널 히트맵을 보고싶으면 $20을 더 내야 하는 상황이 됐습니다. 분명 스트라바 블로그 소개에는사용하는 기능에 따라 더 낮은 가격으로 구독하라는 달콤한 메시지가 있었는데 정작 스트라바를 잘 활용하고 있는 내게는 적용되지 않는 겁니다. 기분이 나쁩니다.

그래서 원래 스트라바의 기능을 사용하던 사람들이 구독 선택 페이지에 예쁘게 정리해 놓은 기능 목록을 보고 이들 각각을 대체할 서비스를 찾기 시작합니다. 가령 비컨은 가민 라이브트랙으로 대신할 수 있고 분석기능 일부는 가민커넥트로부터 비슷한 차트를 볼 수 있습니다. 이런 식으로 원래 스트라바를 통해 사용하던 기능을 대신해가다 보면 사이트 두 개에 걸쳐 정보를 봐야 하는 불편함이 생기지만 스트라바에 의존성을 줄이고 기존 $60이던 비용을 3분의 1 수준으로 줄이거나 아예 없애버릴 수도 있게 됐습니다.

그렇게 시간이 흐르고 다시 구독 연장을 고민할 때가 될 즈음 스트라바는 구독 모델을 다시 한 번 변경1)했습니다. 이번에는 $20짜리로 구분돼있던 모델을 이전처럼 $60짜리 모델 하나로 통합하고 기존에 무료 고객들에게도 제공되던 몇몇 정보를 유료 전용으로 변경했습니다. 일단 스트라바가 앞으로도 지속되길 원하는 입장에서 객단가를 3분의 1로 낮추고 기존 유료 고객들을 몹시 불편하게 만드는 자기파괴적인 구독모델을 포기하는 것만으로도 다행이라고 생각했습니다만 흥미롭게도 이제부터는 스트라바가 가지고 있는 컨텐트 중 가장 재미있는 컨텐트를 유료로 팔기 시작했고 디지털 컨텐트를 만드는 입장에서 이번에는 생각보다 잘 될 거라고 예상합니다. 작년의 자기파괴적인 구독모델에 비해 이번에는 꽤 잘 될 겁니다. 정말 가장 재미있고 사람들이 관심 없는 척 하면서도 다들 한번씩은 슬쩍 열어보는 컨텐트를 유료 전용으로 바꿨거든요. 바로 순위표입니다.

기존에도 순위표는 완전 무료는 아니었습니다. 구간 별 순위는 전체, 성별, 기간에 따라 제공됐고 여기까지는 모든 스트라바 고객들이 똑같이 볼 수 있었습니다. 여기에 나와 내가 팔로잉하는 사람들로만 구성된 순위표를 추가로 볼 수 있었고요. 여기에 국적, 체중, 나이, FTP2) 등으로 구성된 보다 전문적인 순위표는 유료 고객들에게만 표시됐습니다. 하지만 스트라바는 선수들만 사용하는 서비스가 아닙니다. 스트라바는 블로그에서 자신의 고객들을 '선수'라고 부르기는 하지만 모두가 전문 사이클리스트는 아닙니다. 이들에게 스트라바가 제공하는 순위는 무료로 제공되는 순위면 충분히 재미있었습니다. 이 구간은 나와 내가 팔로잉하는 사람들 중에 몇 위인지 보거나 서로 팔로잉하는 친구들끼리 모여 누가 더 빠른지 비교하는 정도면 힐클라임 어택을 끝낸 다음 근처 카페에서 클릿슈즈로 바닥을 또각거리며 음료를 놓고 모여앉아 이야깃거리를 만들기 충분했습니다. 굳이 체중이나 FTP를 순위에 끌어들여 이야기를 복잡하게 만들 필요가 없었습니다.

이제 스트라바를 사용하는 사람들의 이야깃거리를 만들어주는 재미있는 정보가 유료화됐습니다. 이제 연 $60을 내야 이 정보에 접근할 수 있습니다. 만약 오늘 스트라바를 켠 채로 뒷산을 어택하고 나서 PR3)을 달성했다면 이 기록이 내 주변의 다른 사람들과 비교해 어느 정도 기록인지 알고싶으면 이제 유료 구독을 시작해야 합니다. 이전에는 정말 꽤 전문적인 순위에만 돈을 내면 됐습니다만 이제는 내 궁금증을 채워주고 주변 사람들과 이야깃거리를 만들 정보에도 돈을 내야 합니다. 함께 자전거를 타는 사람들 중 누군가 한 명만 스트라바를 유료로 구독하고 있어 이 사람이 순위정보를 알려줄 수도 있을 겁니다. 라이딩 후 다들 그 사람 주변에 모여 앉아 그 사람의 폰을 들여다보며 자기 순위를 알아내고 음료를 마시며 이야기를 계속합니다. 어느 자기 폰을 통해 주변 사람들의 순위를 보여주던 그 사람이 이야기의 중심이 되었군요. 사람들과 헤어져 돌아오며 생각해봅니다. 아. 나도 유료 구독 시작할까? 하고요.

작년에는 좀 많이 걱정했습니다. 저 자신도 $20짜리 구독으로 바꾸면서 이러다 이 사람들 망하면 무슨 서비스를 써야 하나 고민했습니다. 물론 가민 커넥트 같은 서비스가 있기는 하지만 주변의 모든 사람들이 가민 기계를 사용하지는 않고 또 어떤 사람들은 자전거를 꽤 오래 탔고 장거리 라이딩을 꽤 했음에도 스마트폰만 사용하시는 경우도 꽤 있어 많은 사람들이 함께 라이딩 기록을 공유하는 서비스는 거의 없었습니다. 그래서 이게 없어지면 꽤 고통스러울 거라고 생각했습니다. 하지만 올해의 유료 구독모델 변경을 보고 이번엔 꽤 장사가 잘 될 거라고 예상4)합니다. 한동안은 스트라바가 돈을 못 벌어 사라질 걱정은 하지 않기로 했습니다.

· 2020-06-07 14:22

동기화

장애 경험

처음 서비스를 라이트세일로 옮기고 나서 한동안은 이걸 전통적인 호스팅 서비스와 비슷한 것으로 생각했습니다. 하지만 호스팅과는 달리 문제가 생길 때 내가 직접 해결해야 했습니다. 그러다가 지난번에 루트볼륨이 읽기전용으로 바뀌는 장애를 겪었습니다. 이 즈음부터 인스턴스가 오동작하는건 클라우드 컴퓨팅 세계에서 꽤 흔하게 일어나는 일이고 서비스는 인스턴스에 장애가 일어날 경우를 대비해서 구성해야 한다는 점을 배웠습니다. 이 전까지는 그저 인스턴스에 자동 스냅샷 생성이 전부였습니다. 하지만 이때부터는 장애가 생긴 인스턴스와 격리할 수 있도록 디스크를 하나 붙여 루트볼륨의 사라지면 안되는 데이터를 일정 시간마다 복사하기 시작했습니다.

그리고 두번째 장애가 생겼습니다. 이 때는 애초에 인스턴스에 접근할 수가 없었습니다. 터미널에 접속할 수 없었고 다른 웬만한 방법으로도 반응이 없었습니다. 문서를 찾아보니 지원 요청을 하면 사람이 직접 상태를 알아봐준다고 나와 있었고 바로 포기했습니다. 이상하게도 그동안 생성했던 스냅샷으로 인스턴스를 생성했는데 이들 역시 접근이 불가능했습니다. 이 때 스냡샷이 백업으로써 내 예상대로 동작하지 않을 가능성이 있다는 의심을 하기 시작했습니다. 한참 낑낑댄 끝에 인스턴스를 포기하고 디스크를 분리했습니다. 새 인스턴스를 생성해 디스크를 붙여보니 다행히 디스크는 문제가 없었습니다.서버에서 돌고 있던 스크립트는 깃헙5)에 올려놓고 관리하고 있어 같은 경로에 클론하고 디스크는 같은 자리에 마운트했습니다. 몇몇은 설정을 다시 편집해야 했지만 처음 각오한 것 보다는 훨씬 짧은 시간 안에 다시 서비스할 수 있었습니다. 이 경험을 통해 백업은 인스턴스 바깥에 해야 하고 문제가 생길 때 서비스 중단을 막거나 줄이려면 서버를 추가해 로드밸런싱을 해야겠다는 결론에 이르렀습니다.

로드밸런싱

로드밸런싱 서비스를 선택하는건 어렵지 않았습니다. 간단히 라이트세일은 한달에 $18을 내면6) 트래픽에 관계 없이 로드밸런싱을 사용할 수 있었고 클라우드플레어는 $5를 내면7) 기본적인 로드밸런싱 서비스를 시작할 수 있었습니다. 단 트래픽과 서버 수에 따라 추가 과금을 해야 합니다. 라이트세일은 최근에 저 개인의 경험 상 여러 번 문제를 일으켜 리전을 옮기도록 만들어 신뢰도가 약간 떨어진 상태였습니다. 계속 이런 식이라면 아예 다른 회사 제품으로 옮겨야 할지도 모른다고 생각하는 중이었고 또 당장 서버를 한 대만 더 붙여서 로드밸런싱을 시작하기에는 클라우드플레어 제품이 기초 기능을 훨씬 싸게 제공했기 때문에 클라우드플레어의 로드밸런싱을 선택했습니다. 두 번째 인스턴스를 만들고 설정한 다음 로드밸런서에 연결하자 바로 동작하기 시작했습니다.

첫 번째 서버는 지금까지 사용하던 바로 그 서버입니다. 이 서버에는 디스크를 추가로 붙이고 서비스의 핵심 데이터를 모두 이 디스크를 통해 서비스하고 있습니다. 디스크 자체의 백업은 인스턴스를 매일 자동 스냅샷을 만드는 정도로 만족하기로 했습니다. 지난번에 스냅샷을 통해 생성한 인스턴스 역시 똑같은 장애가 일어났지만 디스크를 분리하면 대응할 수 있을 거라고 예상합니다. 두 번째 서버는 첫 번째 서버보다 사양이 낮고 추가로 디스크를 사용하지 않은 채 핵심 데이터를 첫 번째 서버의 디스크와 같은 경로에 놓고 서빙합니다. 두 서버는 어느 한 쪽 데이터가 변경되면 느슨하게 이를 다른 쪽에 동기화합니다. 첫 번째 서버는 백업 대상으로 디스크를 추가해 내결함성을 약간 더 가지고 있고 두 번째 서버는 첫 번째 서버가 중단될 때 서비스를 계속하는 역할을 합니다. 두 번째 서버는 처음 설정을 마치고 나서 만들어 둔 스냅샷 외에는 별도로 백업을 하지 않게 했습니다.

단방향 동기화

그렇게 꽤 행복한 결말에 다다랐지만 간단히 이야기한 서버 두 대 사이에 파일 뭉치를 동기화하는 일은 난처한 문제였습니다. 서버가 두 대가 되면 로드밸런서가 사용자들을 어느 서버에라도 데려다 놓을 수 있었습니다. 두 서버는 겉으로는 한 대 처럼 동작하기 때문에 사용자의 눈에 띄지 않게 변경사항을 계속해서 동기화해야 했습니다. 다행히도 위키는 읽기에 비해 쓰기가 훨씬 더 적게 일어나고 쓰기 자체가 같은 파일에 집중될 가능성이 거의 없는 시나리오여서 느슨하게 동기화할 수 있었습니다. 하지만 파일 동기화 문제는 현대에도 정답이 없는 복잡한 문제였고 여러 솔루션이 난립하며 이들을 시나리오에 맞게 적당히 선택해 사용해야 하는 상황이었습니다.

처음에는 서버 두 대를 하나는 오리진 서버, 다른 하나를 카피 서버라고 하고 항상 오리진에서 카피 방향으로 동기화가 일어나게 해봤습니다. 그러면 읽기는 아무 서버에나 접근하면 되고 명시적으로 쓰기 작업을 할 때 별도 오리진 서버 주소로 접근하는 겁니다. 그래서 이 때는 rsync를 써서 간단하게 시작했습니다.

rsync -e "ssh -i /path_to_private_key/private_key.pem" -arvz --delete /path_to_origin_data/ [email protected]_ip_address:/path_to_copy_data/

이걸 크론탭에 넣고 1분마다 돌렸습니다. 오리진 서버 주소를 별도로 입력해 나타난 사이트에 글을 쓰고 잠깐 기다리면 양쪽 서버에 동기화됐습니다. 뭐 이 정도면 괜찮지 않을까 하고 한 시간 쯤 만족하다가 사용하기 굉장히 불편하고 실수하기 쉽다는 사실을 깨달았습니다. 일단 글을 읽을 때와 쓸 때 서로 다른 주소를 사람이 선택해야 한다는 점은 어떻게 봐도 이상했습니다. 또 글을 쓸 때 잘못된 서버에 접속했다는 점을 눈치채지 못하면 최대 1분 안에 글이 사라질 것이었습니다. 잘못된 서버에 접속해 있다는 사실은 주소표시줄을 보고 알 수 있었는데 항상 여기 신경을 쓰고 있어야 한다는 건 납득할 수 없었습니다.

양방향 동기화

찾아보니 서로 다른 두 기계 사이에 파일을 양방향으로 동기화하는데는 lsyncd라는 솔루션과 unison이라는 솔루션이 널리 사용되는 분위기였습니다. 전자는 백그라운드에 계속 떠있다가 파일시스템에 변경이 일어나면 바로바로 이를 다른 쪽 서버에 동기화해주는 식으로 동작했습니다. 후자는 크론탭에 넣어 일정 시간마다 한번씩 돌리도록 되어있는데 일단 실행되면 양쪽을 비교해 변경된 파일을 다른 쪽에 복사해줍니다. 제 시나리오는 읽기가 많이 일어나고 쓰기가 적게 일어나며 같은 파일에 동시 쓰기는 거의 일어나지 않았고 파일시스템 기반의 위키라 동기화할 파일 개수가 아주 많았습니다. lsyncd는 아주 많은 파일을 동기화 대상으로 할 때 종종 일어난다는 문제를 직접 확인하지 않기로 하고 unison으로 동기화를 설정했습니다.

위에서 rsync는 상대 서버의 로그인 인증서를 포함한 모든 옵션을 커맨드 한 줄에 쭉 나타낼 수 있는 점이 취향에 맞았습니다. 어딘가 한 눈에 안 보이는 장소에 적힌 작은 설정 하나 때문에 전체 동작이 좌우되는 경험은 썩 마음에 들지 않았습니다. 하지만 unison은 최소한 상대 서버에 로그인할 때 사용할 키 파일 경로만은 별도 설정 파일에 적어야 했습니다.

~/.unison$ cat default.prf
# Unison preferences file
sshargs = -i /path_to_private_key/private_key.pem

위 처럼 키 파일 경로를 설정하고 나면 나머지 옵션은 모두 커맨드 한 줄에 표시할 수 있습니다. 로그인은 설정 파일의 프라이빗 키로 알아서 하고 커맨드 상에는 동기화할 로컬 경로와 리모트 경로, 동기화 옵션들만 나열합니다. -auto는 어느 한쪽이 새 파일이라고 판단하면 바로 덮어쓰는 결정을 합니다. 단 양쪽 모두 파일이 변경됐을 때는 아무것도 하지 않고 지나갑니다. -batch는 실행 중 나에게 아무것도 묻지 않습니다. 이전 옵션과 함께 사용하면 충돌 상황을 해결하지 않고 방치하게 됩니다. 그래서 -prefer newer옵션이 필요한데 양쪽에서 수정이 일어나 파일이 충돌하면 그냥 더 나중에 수정한 쪽으로 덮어씁니다. 제 시나리오는 양쪽의 변경사항에 민감하게 반응해 머지하는 대신 '어쨌든' 어느 한쪽으로 동기화 되는 것입니다.

unison /path_to_origin_data ssh://[email protected]_ip_address//path_to_copy_data -auto -prefer newer -batch

커맨드를 만들어 크론탭에 넣고 1분마다 돌리기 시작했습니다. sudo크론탭에 넣으면 동작을 안하는데 이유는 모르겠습니다. 유저 권한의 크론탭에 넣어야 동작했습니다. 그리고 오리진 서버에 접근하는 별도 주소를 사용하지 않고 파일을 써야 할 때도 똑같이 로드밸런서가 지정해주는 서버에 로그인해서 똑같이 글을 썼습니다. 그리고 잠깐 기다리면 다른 쪽에도 변경사항이 동기화됐습니다. 일부러 다른 쪽 서버에 로그인해서 글을 써도 똑같이 동작했고 규모가 작은 쓰기 시나리오에는 문제를 일으키지 않을 겁니다.

결론

  • 라이트세일 인스턴스는 예상보다 훨씬 더 자주 장애가 일어나며 이를 통해 구동하는 서비스는 인스턴스 장애상황에 대응할 수 있도록 구성해야 합니다.
  • 인스턴스의 핵심 데이터는 별도 디스크를 사용해 백업하거나 디스크 자체를 통해 서비스해서 인스턴스 장애상황에 인스턴스와 격리할 수 있어야 합니다.
  • 서비스에 사용하는 스크립트는 깃헙에 올려 관리하고 있었습니다. 이번 장애상황에는 재설치 없이 클론만 했습니다. 몇 가지 설정8)을 더 올려 관리하기 시작했습니다.
  • 백업과는 별도로 장애상황에 서비스 중단을 줄이려면 서버를 추가해 로드밸런싱을 해야 합니다. 클라우드플레어 로드밸런싱이 월 $5로 가장 싸서 선택했습니다.
  • 로드밸런싱을 하려면 서버 간에 파일을 양방향으로 동기화해야 합니다. 쓰기 서버를 두고 단방향으로 동기화해보니 너무 불편했습니다.

참고

· 2020-06-05 22:12

가스보일러

지난주에는 제주도에 갔었습니다. 지금처럼 멀리 나다니는 일이 나와 나를 포함한 사회 전체의 위험을 감수해야 하는 일이 된 시대에 그렇게 멀리 나가도 괜찮을까 고민하지 않은 것은 아니었습니다. 올해 상반기에 모든 브레베9)가 대체 브레베로 전환되거나 완전히 취소된 시점에 이대로 가다가 올 시즌에는 정규 브레베를 단 하나도 못하게 생겼다는 위기감이 있었습니다. 그러던 중에 제주200 브레베는 참가자 수가 적은지 대체 브레베로 전환하지 않고 정규 브레베로 진행한다는 공지10)가 올라왔습니다. 좀 많이 멀기는 하지만 내려가서 조심조심 타고 오자고 결정했습니다. 자전거를 들고 제주로 향했습니다.

출발지와 멀지 않은 숙소를 잡았습니다. 새벽에 일어나 캐리어에 자전거를 달고 어쩌고저쩌고 하는 대신 그냥 자전거를 타고 잠깐 이동할 생각이었습니다. 대신 저녁 열시까지는 공항에서 이착륙하는 비행기 소리를 들어야 했고 밤에는 지상에서 이동하는 비행기들 때문에 바깥 공기가 매케했습니다. 하지만 그럭저럭 나쁘지 않았습니다. 동네는 비행기 소리를 제외하면 조용했고 숙소는 작고 예쁜 골목 어귀에 있었습니다.

작은 문제가 있었습니다. 이 숙소는 온수를 가스보일러를 통해 공급하고 있었습니다. 이 가스보일러는 여느 가정에 설치되어 있을 법 한 가정용 가스보일러였습니다. 한동안 지역난방이 공급되는 지역에 살다 보니 샤워기로 온수를 켠 다음 한참을 기다려야 하는 가스보일러가 잠시 동안 생소했습니다. 오래 전에는 이런 가스보일러에 잘 적응해 별 문제 없이 따뜻한 물을 잘 꺼내 썼는데 간만에 가정용 가스보일러로부터 따뜻한 물을 받아 샤워를 하려니 아무리 기다려도 온수가 나올 생각을 하지 않았습니다. 잠시 동안 한여름에도 따뜻한 물로 샤워하는 사람들의 모임 원로로써 이 배신의 위기를 어떻게 극복해야 할지 고민했습니다. 다행히 자전거 타는 방법을 한 번 배우면 잊어버리지 않듯 곧 가스보일러로부터 안정적으로 따뜻한 물을 끌어내는 방법을 떠올려 무사히 모임에 배신하지 않고 샤워를 마칠 수 있었습니다.

샤워기 문제

전등 스위치나 아날로그식 볼륨 노브는 한 번에 한 가지 조작만 할 수 있습니다. 켜거나 끄고, 내리거내 올립니다. 반면 샤워기 레버는 두 가지 조작을 레버 하나로 하게 됩니다. 물을 틀거나 잠그는 것과 따뜻한 물과 차가운 물로 조절하는 것입니다. 레버 모양에 따라 조금씩 다르지만 이들 두 가지 방향으로 레버를 섬세하게 조절해 적당한 물의 양과 온도를 설정합니다. 물론 이런 섬세하고 복잡한 조작이 그저 길다란 레버 하나로만 되어 있어 이를 조작하려면 레버 전체를 잘 잡고 힘을 조절해야 하지만요.

샤워기 레버는 따뜻한 물 방향으로 레버를 움직여 명시적으로 보일러에게 따뜻한 물을 요구하는 것처럼 보입니다. 이에 비해 가스보일러에 따뜻한 물을 요청하는 인터페이스는 묵시적으로 동작합니다. 따뜻한 물 배관에 물이 흐르기 시작해 임계량을 초과해서 지나가기 시작하면 따뜻한 물을 요구하는 것으로 판단해 보일러를 점화하고 물을 데우기 시작합니다. 샤워기 레버로부터 따뜻한 물을 요구하더라도 충분한 물이 배관을 지나가는데 시간이 걸리고 이를 감지해서 보일러를 켠 다음 배관을 지나는 물이 데워져 샤워기까지 도달하는데는 시간이 걸립니다. 또 이 묵시적인 인터페이스 때문에 중간에 물의 양이 변하거나 따뜻한 물 요구량이 달라지만 레버를 통한 요청과는 다른 동작을 하기 때문에 원활하게 따뜻한 물을 사용하기 어렵게 됩니다.

보일러는 단위시간 당 데울 수 있는 물의 양과 물의 양에 따라 데울 수 있는 온도의 한계가 있습니다. 배관에 물이 빠르게 지나가 보일러의 한계를 넘어가면 충분히 따뜻해지지 않은 물이 그냥 배관을 통과한 다음 샤워기에 도달해 저를 깜짝 놀라게 만듭니다. 하지만 샤워기 레버는 이런 보일러의 사정을 봐 주지 않습니다.

방법

가스보일러로부터 지속적으로 공급되는 따뜻한 물을 사용하기 위해서는 먼저 보일러에게 이제부터 따뜻한 물을 사용하겠다고 명시적이고 또 강력하게 선언해야 합니다. 이는 보통 샤워기 레버를 따뜻한 물 방향으로 최대한 돌린 다음 물을 틀면 됩니다. 그러면 배관으로 물이 최대 수량만큼 흐르기 시작합니다. 이 정도면 보일러에게 충분핝 의사 표현을 한 셈이고 아마도 보일러는 점화될 겁니다. 하지만 많은 가정용 보일러는 이 최대 수량을 안정적으로 따뜻하게 바꿀 능력이 없습니다. 무슨 법적인 제한이 있거나 아니면 보일러의 근본적인 설계 결함 때문일 겁니다. 따뜻한 물을 사용하겠다는 의사표현을 해서 일단 보일러가 점화되면 최대한 빨리 수량을 조절해 보일러가 감당할 수 있는 양만 흐르도록 조절해야 합니다.

이 부분이 굉장히 중요한데 물을 너무 많이 줄이면 보일러에게 따뜻한 물을 그만 사용하겠다고 선언하는 셈이 되기 때문입니다. 일단 보일러에 불이 꺼지고 나면 다시 처음부터 따뜻한 물 사용 선언부터 다시 시작해야 하므로 조심스럽게 수온을 확인해 가며 물을 줄여야 합니다. 그런데 너무 신중하게 물을 줄일 경우 보일러가 감당할 수 없는 수량을 오랜 시간 사용하게 되어 따뜻한 물을 사용할 수 없게 될 가능성이 높습니다. 최대한 짧은 시간 안에, 보일러가 꺼지지 않는 범위 내에서 최대한 부드럽게 수온을 확인해 가며 샤워기 레베를 조절해 수량을 줄여야 합니다.

이 단계를 무사히 수행했다면 바로 샤워하기에는 너무 뜨거운 물이 예상보다 낮은 수압으로 흘러나오고 있을 겁니다. 이제 보일러는 자신이 처리할 수 있는 최대 수량보다 적은 수량을 안정적으로 따뜻하게 만들고 있습니다. 이제 레버를 온도 방향으로 조절해 원하는 온도에 맞춰야 합니다. 이번에는 아까처럼 빠르게 조절할 필요는 없습니다. 하지만 섬세해야 합니다. 보일러에게 따뜻한 물을 사용하겠다고 의사전달을 할 때 강력한 선언을 위해 최대 온도로 돌려놨던 레버를 서서히 조절해 몸이 벌겋게 데이지 않을 정도의 적당한 수온으로 서서히 내립니다. 하지만 너무 많이 내리면 보일러가 이제 더이상 따뜻한 물을 만들지 않아도 된다고 착각하게 해서는 안됩니다.

보일러가 다뜻한 물을 만들지 않기 시작하는 수량은 확실하지 않습니다. 샤워기 레버는 보일러의 상태를 모니터링하지도 않고요. 그래서 레버를 서서히 조절해 보일러가 헛갈리지는 않되 샤워를 지속할 수 있을 정도의 수온을 유지하도록 섬세하게 조작해야 합니다. 만약 보일러가 꺼진다면이 모든 과정을 처음부터 다시 해야 하고 그 사이에 나는 추운 샤워부스 안에서 감기에 걸릴 각오를 해야 합니다. 요즘 같은 시대에 감기에 걸리면 많은 사람들에게 오해 받을 각오를 해야 합니다. 가스보일러를 잘 다루는 일은 현대에 이렇게 중요한 일이 됐습니다.

정리

이 모든 과정은 이렇게 요약할 수 있습니다.

  1. 보일러에게 강력하게 온수 사용 선언을 한다.
  2. '1'의 수량은 보일러가 소화할 수 없으므로 빨리 수량을 낮춰 보일러가 처리할 수 있는 수준으로 조절한다.
  3. '2'의 물은 너무 뜨거우므로 수온을 서서히 낮춰 내가 샤워할 수 있는 수준으로 조절한다.
  4. '2'나 '3'에서 너무 빨리 수량을 조절하거나 너무 빨리 수온을 조절하면 보일러가 내 의사를 오해해 온수공급을 중단하게 된다. 이 경우 '1'부터 다시 시작해야 한다.

한숨

오래 전에 이런 동작을 몸에 익혔지만 한동안 이를 사용할 일이 없는 환경에 있다가 다시 이 짓을 하려니 좀 짜증났습니다. 도대체 얼마나 쌍팔년도 보일러를 사용하길래 아직도 이렇게 따뜻한 물 쓰기가 어려운가 싶어 대여한 집을 뒤져 보일러 모델 이름을 찾아내 검색해봤는데 의외로 발매한지 몇 년 되지도 않은 신형이었을 뿐 아니라 공중파에 광고도 하던 모델이었습니다. 이런 최신 모델마저도 그냥 내 몸뚱이 하나 씻는데 필요한 따뜻한 물을 받기가 이렇게나 힘들다니 실망스러웠습니다. 요즘 보일러는 인터넷으로 제어도 하고 에너지도 절약하고 무슨 안전장치도 있다는데 애초에 가정에서 사용하는 수준의 온수조차 제대로 데워내지 못하는데 그게 다 무슨 소용인가 싶었습니다. 아. 그러고보니 어쟀든 브레베는 무사히 완주하고 이제 평화롭게 이런 복잡하고 섬세한 조작을 할 필요 없이 샤워할 수 있는 세계로 돌아왔습니다. 가스보일러 너무 구리고 짜증납니다.

· 2020-05-30 16:24

<< 새 항목 | 오래된 항목 >>

blog/start.txt · 마지막으로 수정됨: 2020-06-07 14:29 (바깥 편집)