만들 수 있는 것이 늘어나면 하고 싶은 일도 커진다. 예전에는 귀찮아서 넘겼던 도구를 하루 만에 흉내 내고, 오래 쓰던 프로그램의 작은 부분을 자기 취향에 맞게 바꿔볼 수 있다. 반가운 변화다. 다만 구현을 시작하는 문턱이 낮아졌다고 해서, 결과가 맞는지 판단하는 문턱까지 같은 속도로 낮아지는 것은 아니다.
Dan Luu의 소프트웨어에 더 큰 야심을 가져도 된다는 글은 이 간격을 생각하게 한다. 개인에게 유용한 도구를 만드는 가능성을 이야기하면서도, 직접 검증할 수 있는 범위와 유지보수의 어려움을 함께 다룬다. 글에 등장하는 속도와 비용은 작성자의 설명이며, 여기서는 그 수치를 재현한 것처럼 사용하지 않는다. 대신 작은 파일 검색 도구를 만든다는 가정으로 범위를 정해보려 한다.
검색창 하나에도 약속이 들어간다
가상의 도구는 지정한 폴더 안에서 파일 이름을 검색한다. 처음 떠오르는 설명은 간단하다. 빠르게 찾고 보기 좋게 보여주면 된다. 하지만 빠르다는 말도, 찾는다는 말도 아직 기준이 없다. 하위 폴더를 포함하는지, 대소문자를 구분하는지, 한글 이름을 어떻게 처리하는지에 따라 다른 도구가 된다.
시작 전에 입력 자료를 작게 고정해볼 수 있다. 같은 이름을 가진 파일 두 개, 한글 이름 하나, 공백이 있는 이름 하나, 읽기 권한이 없는 폴더 하나를 준비한다고 가정하자. 검색 결과에는 이름뿐 아니라 위치를 보여주기로 정한다. 열 수 없는 폴더는 검색 결과가 없다는 말 속에 숨기지 않고, 읽지 못했다는 상태로 남긴다.
그러면 맞았는지 볼 방법이 생긴다. 찾을 수 있어야 할 파일과 나오면 안 되는 파일을 미리 적어둘 수 있다. 결과 목록이 화려한지보다 먼저 그 목록을 비교한다. 속도를 비교하고 싶다면 같은 자료와 같은 조건을 사용해야 한다. 파일이 적을 때 한 번 빨랐다는 이유로 어느 폴더에서든 빠르다고 적지는 않는다.
이 정도의 약속만으로도 하지 않을 일이 보인다. 첫 버전에서는 파일 내용을 읽지 않고, 원본을 옮기거나 지우지 않으며, 컴퓨터 전체를 자동으로 훑지 않는다고 정할 수 있다. 제한을 넣는다고 해서 야심이 사라지는 것은 아니다. 이번에 확인할 수 없는 동작이 제품의 약속으로 섞이지 않게 하는 것이다.
만드는 시간 옆에 판단하는 시간을 놓기
도구를 만드는 데 한 시간을 쓰겠다고 정했다면, 그중 얼마를 확인에 남길지도 정해야 한다. 모든 시간을 구현에 쓰고 마지막에 화면이 한 번 열리는지만 보면, 다음에 다시 손볼 근거가 적다. 작은 입력 묶음을 반복해서 돌려보고 예상과 다른 결과를 보존할 시간이 필요하다. 잘못된 결과도 다음 변경을 판단하는 자료가 된다.
이 예시에서는 검색어를 비웠을 때와 결과가 많을 때를 따로 본다. 빈 검색어가 전체 파일을 내놓아야 하는지, 아무것도 하지 않아야 하는지는 취향에 따라 정할 수 있다. 다만 그 선택을 코드가 우연히 결정하게 두지는 않는다. 예상한 동작이 문장으로 있어야 다음 수정에서 달라졌는지 알아볼 수 있다.
더 큰 기능을 넣고 싶어지면 검증 자료도 같이 늘려야 한다. 파일 내용 검색을 추가한다면 인코딩과 큰 파일, 읽지 못하는 자료를 다룰 기준이 필요하다. 파일 이동 기능을 넣는 순간에는 되돌리는 방법과 원본 보존이 중요해진다. 기능 버튼 하나가 늘어났다는 사실보다, 사용자의 어떤 자료에 손을 대게 되는지가 범위를 더 크게 바꾼다.
그래서 개인 도구와 다른 사람에게 맡길 도구 사이에는 별도의 문턱을 두는 편이 좋다. 자기 폴더에서 몇 번 잘 돌아간 것은 출발점이 될 수 있다. 다른 사람의 파일 구조와 권한, 사용 습관을 견딘다는 증거가 되지는 않는다. 그 간격을 숨기지 않으면 개인 도구의 작은 성공도 과장할 필요가 없다.
접어둘 조건도 설계의 일부
계속 고치는 것이 언제나 좋은 선택은 아니다. 가상의 검색 도구가 기본 입력에서도 결과를 빠뜨리는데, 원인을 설명할 수 없다면 기능을 더 붙이기 전에 멈출 수 있어야 한다. 기존 도구를 계속 사용하면서 실패한 입력을 정리하는 선택도 남아 있다. 이미 시간을 썼다는 이유만으로 새 도구에 중요한 작업을 맡길 필요는 없다.
잠시 접어두기 쉽게 만들려면 처음부터 기존 자료를 건드리지 않는 구조가 도움이 된다. 새 프로그램의 결과와 원본 자료를 분리하고, 도구가 만든 색인도 따로 저장한다고 정할 수 있다. 그러면 실험을 지워도 원본은 남는다. 편리한 기능을 얻기 위한 시도가 중요한 자료 전체의 이사가 되지 않도록 하는 것이다.
이 글의 검색 도구는 설명을 위한 설계 예시이며 실제 성능 결과가 없다. 그럼에도 적어볼 수 있는 것은 있다. 첫 입력 묶음, 기대하는 결과, 읽지 못한 자료의 표시, 원본을 보존하는 경계, 다음 기능을 넣기 전에 확인할 조건이다. 구현 전에 이 다섯 항목을 쓰면 상상이 너무 커졌는지도 알아볼 수 있다.
더 큰 것을 만들 수 있다는 가능성은 반갑다. 그 가능성을 오래 가져가려면 결과를 알아볼 눈도 같이 준비해야 할 것 같다. 다음에 만들고 싶은 도구를 떠올릴 때, 기능 목록 옆에 맞았는지 확인할 입력 한 묶음을 적어보면 어떨까. 야심의 크기는 그대로여도 첫걸음의 모양은 훨씬 분명해질 수 있다.
관련 글은 Engineering에서 이어 읽을 수 있습니다.
공개 원문을 참고해 AI의 도움으로 구성·작성한 글입니다. 본문의 가상 예시는 실제 수행 결과와 구분했으며, 표지는 Google Gemini로 만든 개념 일러스트입니다.
