[번역] 덜 검색하고, 더 많이 탐색하기

검색은 해결에 좋고 탐색은 아는 범위 바깥을 발견하기 좋습니다.

Share

문서는 거의 쓸모가 없습니다. 아무도 문서를 읽지 않습니다. 사람들은 한 페이지로 된 ‘빠르게 시작하기(quick start)’를 읽고 나서 바로 코드를 쓰고 싶어 합니다. 시작을 최소한으로 가져가고, 코드가 작동하도록 하는데 집중해야 합니다. - cbbloom

지난 주에 저는 엑셀을 배우기로 결정했습니다. 수만달러 가치를 가진 기업들이 거대한 엑셀 스프레드 시트로 일을 하고 있다는 무시무시한 이야기를 들어왔습니다. 수만달러 가치의 기업들이 그런 식으로 사업을 운영한다면 그 도구는 좋은 도구가 아니겠어요?

새로운 언어를 배우기 위한 제 일반적인 전략은 이렇습니다.

  1. 몇 가지 간단한 예제를 따라 해봅니다.
  2. 체계적으로 문서와 라이브러리를 읽고 예제에서 얼마나 많은 다른 이상한 일을 더 할 수 있을지 살펴봅니다.

사흘 정도 지난 후, 나는 트위터에 이런 스레드를 만들 정도로 많은 것을 배웠습니다.

이 트윗이 얼마나 인기를 끄는 지 보며 놀랐습니다. 수많은 엑셀 사용자들이 이런 기능에 대해서 들어본 적 없다고 했고, 이런 기능이 얼마나 강력한 지에 대해선 더 모르고 있었습니다. 저는 엑셀을 일주일도 살펴보지 않았는데, 왜 몇 년씩 사용한 사람들보다 더 많은 것을 알고 있는 걸까요?

이상하게도 제가 사용한 기능은 숨겨져 있지도 않았습니다. 예를 들어 셀, 상수, 함수에 이름을 붙여주는 ‘Name Manager’라는 기능이 그랬습니다. 사람들은 다양한 경우에 무척 유용한 이 기능 덕분에 엑셀 사용이 편해졌다고 했습니다. 바로 여기 표시한 곳에 'Name Manager’가 있습니다!

여기에 대해 할 수 있는 최선의 설명을 하자면, 대부분의 사람은 도구를 배울 때 탐색이 아니라 검색으로 배우기 때문입니다. 검색을 하면 특정 요구를 해결하기 위한 정보를 찾게 됩니다. 탐색을 하면 학습 또는 나중에 찾아 볼 내용에 대해 체계적으로 살펴보게 됩니다.

검색은 일상적인 업무 방식으로 사용하는 게 더 좋습니다. 문제에 대한 해결 방법을 더 빠르게 찾아주기 때문입니다. 탐색은 주제별 리소스로 묶여있기 때문에 문제를 해결해야 하는 입장에서는 검색 채널을 확장하는 것이 원하는 해결 방법을 찾기에 더 쉽습니다. 우리가 구글이나 스택오버플로우 같은 훌륭한 검색 인프라를 가지고 있는 이유기도 하죠. 그런 한편, 당신은 아는 것만 검색할 수 있습니다! 그래서 검색만 한다면 ‘전체적으로’ 유용한 정보는 찾을 수 없습니다.

다시 말해, 검색은 해결에 좋고 탐색은 아는 범위 바깥을 발견하기 좋습니다. 각각의 방식에서 다른 것을 배울 수 있습니다. 탐색은 당장 유용하지는 않지만, 알아두면 좋은 것들을 알려줍니다. 그런 정보들을 유용하게 사용할 수 있는 문제에 부딪혔을 때 읽어 둔 내용이 기억날 겁니다.

간단한 예: Python으로 디렉토리의 내용을 반복하는 방법은? 검색하면, 아래와 같이 3개의 다른 방법을 찾을 수 있습니다:

import os, glob

os.listdir("path") # 1
os.walk("path") # 2
glob.glob("*") # 3

2014년까지 우리는 “나름 괜찮은” 이러한 방식으로 일반적인 작업을 했습니다. 그런데 Python 3.4에서 올바른 방법이 추가됐습니다:

from pathlib import Path

Path('.').iterdir()

문자열 대신 경로 객체를 반환하는 이 방법이 훨씬 나은 접근입니다. parents/name/suffix/stem이라는 문자열만 반환하는 기존 방법 대신 is_file()를 호출하면 상대 경로인지 절대 경로인지 등을 확인할 수 있습니다. pathlib 라이브러리는 세 가지 다른 모듈에 분산된 동작을 통일하고 텍스트와 파일을 읽는 더 좋은 방법을 제공합니다!

몇 가지 검색 결과들이 어느 순간 경로에 대해 언급하겠지만, 대부분은 그 대신 맞지 않는 해결 방법을 알려줍니다. Python 공식 라이브러리를 탐색했을 때만 pathlib에 대해 알 수 있었습니다.

(엑셀 워크숍 관련 내용 후략)


note

검색은 해결에 좋고 탐색은 발견에 좋습니다.

여기에 공감하지만 현실적으로 모든 유저가 탐색을 먼저 하길 바랄 수는 없다.

그치만 만약 탐색이라는 방식을 더 용이하게, 그걸 넘어서 재밌게 만들 수 있다면? 사람들이 재미있어 하는 건 뭘까? 유튜브? 술술 읽히는 사용자 스토리를 가진 기술 문서? 무조건 처음부터 성공하게 해주는 튜토리얼? 어떻게 하면 '탐색'이 재밌을 수 있을까에 대한 방법을 고민해 볼 필요는 있을 것 같다.

Read more

살려 낸 101번 째 문서 시스템: (2) AI 시대, 문서의 가치

앞서 이야기 한 문제를 해결하기 위해 문득 생각난 RAG 기반의 챗봇을 도입했다. 업무 메신저에 챗봇을 붙이고, 챗봇에게 문서에 있는 내용을 물어보게 했다. 문서 사이트에 들어가 읽는 방식이 아니라 업무 메신저에 질문하고 답변을 받는 방식으로 바꾸자 실질적인 문서 콘텐츠 활용량이 엄청나게 늘었고, 다들 편리하다며 좋아했다. 챗봇을 사용해 문서 접근성을 높이면서 깨달은

By Jennybe

살려 낸 101번 째 문서 시스템: (1) 문제 정의 과정

지난 7월 26일에 Toss Makers Conference(TMC)에서 지난 1년 간 만든 문서 시스템에 대해 발표했다. 연초에 사내에서 발표 등록 공지가 났을 때는 제안을 받고 꽤 망설였다. 4년 정도 SLASH 컨퍼런스를 위해 연사분들의 장표와 스크립트 검수를 도왔지만, 직접 발표한다는 것은 생각해 본 적이 없었기 때문이다. 다만 이전에 박씨와 관련해 회사

By Jennybe