새 프로그램이 복잡하게 느껴지면 예전 도구가 더 나았던 것 같기도 하다. 메뉴가 단순했고 설명 없이도 쓸 수 있었다는 기억이다. 하지만 편리함에 대한 기억과 작업을 얼마나 안전하게 남길 수 있었는지는 별개의 질문이다. 나는 도구를 비교할 때 기능 수 옆에 “중간에 멈추면 무엇이 남는가”도 적고 싶다.
Jake Voytko는 10월 27일 글에서 현대 소프트웨어의 문제를 인정하면서도 과거를 지나치게 좋게 기억하는 태도를 돌아본다. 개인의 경험담이므로 시대 전체의 품질 순위를 매긴 통계는 아니다. 원문에 등장하는 개별 게임의 기억 중에는 작성자 자신도 확인하기 어렵다고 밝힌 부분이 있다. 그런 숫자를 역사적 사실로 가져올 필요는 없다.
참고 원문: 관련 원문을 직접 읽기
기능보다 작업의 수명을 비교한다면
가상의 글쓰기 도구 A와 B를 생각해 보자. A는 화면이 단순하고 저장 버튼이 있다. B는 메뉴가 많지만 변경 내역을 되돌릴 수 있다. 이 설명만으로 어느 쪽이 낫다고 할 수 있을까. 저장하기 전 닫힌 창, 연결이 끊긴 순간, 실수로 지운 문단을 떠올리면 비교해야 할 항목이 달라진다. 실제 제품 평가가 아닌 선택 기준을 세우기 위한 예시다.
먼저 작업의 상태를 나눠 본다. 아직 저장하지 않은 생각, 저장한 파일, 다른 기기에 전달한 사본은 같은 것이 아니다. “자동 저장”이라는 문구도 어느 상태를 어디에 남기는지에 따라 뜻이 다르다. 화면에 보이는 내용이 원격에 반영됐는지, 반영에 실패하면 알려 주는지 확인하지 않으면 안심의 근거가 모호해진다.
나는 이 비교표에서 복구 가능성과 복구 방법의 발견 가능성을 따로 두고 싶다. 이전 내용이 어딘가 남아 있어도 사용자가 찾지 못하면 실제 작업에서는 도움을 받기 어렵다. 메뉴 이름, 변경 시각, 어느 상태로 돌아가는지 미리 볼 수 있는지가 모두 사용 경험에 들어온다. 기능이 존재한다는 체크 표시로 끝내기에는 중요한 차이다.
다섯 문장짜리 가상 시험
도구를 검토할 때 길고 민감한 원고를 처음부터 넣을 필요는 없다. 가상의 다섯 문장을 만들고 저장한 상태와 아직 저장하지 않은 상태를 구분해 보자. 그중 한 문장을 지운 뒤 정상적인 되돌리기 기능으로 복원할 수 있는지 확인하는 시험을 제안할 수 있다. 실제로 이 시험을 실행했다고 주장하지는 않는다.
그다음에는 사본을 내보내고 다른 승인된 환경에서 읽는 경로를 검토한다. 파일이 존재하는지뿐 아니라 문장 순서와 이미지, 링크, 작성 시점처럼 필요한 정보가 남는지 묻는다. 내보내기 메뉴가 있다는 사실과 업무에 쓸 수 있는 사본이 생긴다는 사실은 다르다. 무엇을 보존할지 먼저 정하면 확인할 대상도 줄어든다.
이때 원본을 지워 복구 기능을 시험하는 식으로 시작하지 않는다. 분리된 예제와 사본을 쓰고 정상적인 복원 절차를 확인하는 편이 안전하다. 도구의 계정 설정이나 보안 기능을 바꿀 필요도 없다. 복구 가능성을 평가한다는 이유로 실제 기록을 위험하게 만들면 목적이 뒤집힌다.
빠른 화면과 남는 작업
반응 속도는 분명 중요하다. 그런데 클릭이 빠른 도구가 항상 작업을 빨리 끝내게 하는 것은 아니다. 장애 후 같은 내용을 다시 만드는 시간과, 지금 어떤 버전이 맞는지 확인하는 시간도 들어간다. 이를 계산하려면 실제 관찰 기간과 장애 기록이 있어야 한다. 이 글은 임의의 손실 시간을 비용 절감액으로 바꾸어 제시하지 않는다.
대신 내 작업에 자주 생기는 멈춤을 하나 적어 볼 수 있다. 이동 중 연결이 끊기는지, 여러 사람이 같은 자료를 수정하는지, 파일을 다른 도구로 옮기는지가 다를 것이다. 같은 기능 목록을 보더라도 반복되는 장면이 다르면 우선순위가 달라진다. 남의 회고를 읽고 내 도구의 승자를 바로 고를 수 없는 이유다.
과거 도구의 단순함을 좋아하는 감상은 남겨 두어도 된다. 다만 그 감상으로 현재의 모든 복잡함을 불필요하다고 단정하지는 않으려 한다. 일부 복잡함은 협업과 복구를 위해 생겼을 수 있고, 다른 일부는 정리되지 않은 설계일 수 있다. 무엇을 얻기 위해 무엇을 감수하는지 구체적으로 살펴야 둘을 구분할 수 있다.
반대로 복구 기능이 많다는 이유로 가독성과 기본 동작의 혼란을 정당화할 수도 없다. 저장 상태를 보여 주는 문구가 모호하거나 복원이 예상과 다르게 작동한다면 실제 결함이다. 작은 예제에서 발견한 문제를 버전과 절차와 함께 기록하면 “요즘 도구는 다 별로다”라는 말보다 수정할 대상이 선명해진다.
작업의 소유권도 비교표에 넣을 수 있다. 계정에 접근할 수 없게 되었을 때 읽을 수 있는 사본이 있는지, 특정 도구만 해석하는 표현에 중요한 의미가 들어 있는지 묻는다. 편한 동기화와 장기 보관은 겹치는 부분이 있지만 같은 요구는 아니다. 어느 쪽을 검증했는지 기록하면 도구를 옮길 때 필요한 준비도 더 구체적으로 잡힌다.
도구를 바꾸지 않아도 확인할 수 있는 것부터 시작하고 싶다. 지금 저장한 예제의 위치와 내보내기 경로를 적어 두는 일은 비교적 작다. 그 기록이 있어야 다음 버전에서도 같은 질문을 이어 갈 수 있다.
나는 다음 도구 비교에서 옛날과 지금의 승패를 정하기보다, 지금 하는 작업을 내일도 이어 갈 수 있는지 먼저 보려고 한다. 단순한 화면이 주는 편안함과 잃지 않는 기록이 주는 안도감은 함께 추구할 수 있다. 오늘 쓰는 도구가 멈추더라도 다시 시작할 수 있는 지점은 어디에 남아 있을까?
함께 읽기: 완료 조건을 문장으로 적기