개발자를 위한 정보 검색 팁

✍🏻

Editor 선미's comment

제가 데이터리안 캠프 수강생 분들을 초대해드리는 슬랙 커뮤니티에서 종종 하는 말로 코멘트를 대신하겠습니다. 질문에 대한 이야기입니다.

“질문을 하시기 전에 이 슬랙 채널이나, 구글에 검색을 해보시는 것도 추천합니다. 육아의 최종 목표가 자녀의 독립이듯이(오은영 박사님의 팬입니다), 교육의 최종 목표는 여러분들이 독립적으로 분석을 할 수 있게 되는 것입니다. 검색을 통해 원하는 결과를 찾아내고 적용하는 것을 반복하다보면 앞으로 문제 해결력을 키우는데 큰 도움이 될거예요. 검색이 막연하다면 1. 구글에 검색하기 2. 영문으로 검색하기 이렇게 두 가지 규칙만 지키셔도 이전 검색보다 훨씬 좋은 결과물을 보실 수 있을거예요. 검색을 잘 하는 방법에 대한 좋은 글이 있어서 첨부합니다. (첨부. 개발자를 위한 정보 검색 팁)”

여기에 첨부한 글이 바로 지금 여러분들이 읽고 있는 글의 원문입니다. 글이 길게 느껴진다면 1, 2, 4.1, 5.1, 6.4, 6.6 만 먼저 읽어보고 적용해보세요.

프로그래밍을 하다 보면 종종 당면한 문제를 해결하기 위해 인터넷 검색을 합니다. 검색만 잘해도 문제 해결 시간을 크게 단축할 수 있을 뿐 아니라 개발 역량 향상에도 큰 도움이 된다고 생각합니다. 당연한 얘기지만, 검색만 해서는 검색을 잘 할 수가 없습니다. 검색을 잘 하려면 검색을 잘 하기 위해 갖춰야 할 습관을 형성하기 위해 꾸준히 연습해야 합니다. 이 글에서는 검색을 잘 하는 방법과 그와 관련한 습관을 기르고 연습하는 방법을 소개합니다.

제가 평소 검색을 할 때 어떤 식으로 하는지 돌아보며 도움이 될 만한 습관들을 정리해봤습니다. 프로그래밍을 처음 배울 때 알았더라면 좋을만한 내용이 무엇인지를 고민하며 적었습니다. 숙련된 개발자들에겐 식상한 이야기들일 수 있습니다.

나는 검색을 잘 하는걸까

0. 나는 검색을 잘 하는걸까

내가 검색을 잘 하는지 어떻게 알 수 있을까요? 주관적이기는 하지만 이런 기준들을 떠올려 봤습니다.

코딩을 중단하고 검색 엔진을 연 시점부터 원하는 답을 찾아서 코딩을 재개하기까지의 시간이 대체로 1분 미만이다.

검색을 하면서 알게 된 정보를 “새로 학습했다”는 느낌보다는 “검색 힌트 덕분에 이미 알던 정보를 다시 떠올렸다(재인; recognition)”는 느낌이 들 때가 많다.

검색을 하는 행위가 인지적으로 너무 자연스러워서 “코딩하다가 막혔다”는 느낌이 들지 않을 때가 많다.

본인이 스스로 생각하기에 위와 같은 상황이 아직 아니라면, 이 글이 도움이 될 수 있습니다.

어떻게 하면 더 잘 할 수 있을까

1. 구글에서 검색하기

분야별로 더 나은 검색 엔진이 존재합니다. 기술 문서를 검색하는 경우엔 대체로 구글이 다른 검색 엔진에 비해 월등하게 뛰어납니다. 심지어는 네이버 API를 이용하는 방법을 찾는 경우에도 네이버보다 구글에서 찾으면 더 양질의 결과를 얻을 수 있습니다.

초심자들이 가장 많이 하는 실수 중 하나가 평소에 맛집이나 영화 정보를 찾던 검색 엔진으로 프로그래밍 관련 정보를 검색하는 것입니다. 수십 년 전 정보, 다른 초심자가 작성한 정보, 이유는 모르겠으나 프로그래밍을 모르는 사람이 적은 답변이 질문자에 의해 채택된 질답 문서, 각종 개발자 커뮤니티의 잡담 게시판 등이 높은 빈도로 검색 결과 상위에 노출됩니다. 이런 출처에서 얻은 코드 조각 또는 방법을 이용하면 문제가 해결되기보다는 새로운 문제가 발생하는 가능성이 더 높고, 검색할 일이 점점 더 많아지는 악순환에 빠지기 쉽습니다.

2. 영문으로 검색하기

한글, 한국어, 한국에 특화된 문제를 검색하는 경우를 제외하고는, 영문으로 검색을 하면 더 좋은 결과를 얻을 수 있습니다. 국내 기술 수준이 낮다거나 하는 문제는 절대 아니고요. IT 관련 분야의 대부분의 정보는 영어로 생산되는 점, 정보가 한국어로 바뀌어 전파되기까지 걸리는 시간 지연, 잦은 오역, 한국어 화자가 영어 화자에 비해 상대적으로 적은 점 등 여러 한계가 있습니다.

한글에 특화 된 문제로 보이는 경우라도 사실은 그렇지 않을 때가 많습니다. 예를 들어 한글 문자열 처리에 대한 문제 중 상당수는 유니코드에 관련된 문제이므로 “unicode”, 또는 “cjk” (Chinese-Japanese-Korean의 줄임말) 등으로 검색하는 편이 나은 경우가 많습니다.

구글에서 영문 키워드로 검색을 하더라도 언어 설정이 한국어로 되어 있으면 국문 문서들이 상위에 나오곤 합니다. 어차피 개발자는 영어 읽기에 익숙해질 필요가 있으므로 되도록 운영체제의 언어 설정을 영문으로 해놓기를 추천합니다. 이게 어렵다면 브라우저의 기본 언어 설정을 영문으로 해놓아도 좋습니다. 이것도 어렵다면, 구글 검색의 언어 설정만이라도 영문으로 해놓기를 추천합니다.

3. 검색 엔진의 기능을 잘 쓰기

특정 시점의 정보를 찾고 싶다면 Tools에서 “Any time” 대신 검색 기간을 설정하면 좋습니다. 아주 정확하진 않지만 상당히 잘 걸러줍니다. 대체로 어떤 라이브러리나 운영체제의 최신 버전에서 발생하는 문제를 검색하는 경우에 유용합니다.

정확한 문장을 찾으려면 검색 문장을 큰따옴표에 넣습니다. 에러 메시지에서 핵심적인 부분을 복사하여 큰따옴표 검색을 하면 내가 겪는 문제와 동일한 문제를 찾기 쉽습니다. 단 큰따옴표 안에 내가 만든 심볼(내 프로젝트에만 존재하는 파일명, 변수명, 함수명 등)은 넣지 말아야 합니다.

python.org 내의 문서만 검색하려면 “site:python.org”이라고 입력합니다. 그 밖에도 논리 연산자 등 구글 검색창에 입력할 수 있는 다양한 문법들을 익히면 좋습니다. 예를 들어 DOM 관련 API를 검색하고 싶은데 자꾸만 jQuery를 이용하는 방법에 대한 문서들이 나오는 경우가 있습니다. 검색어에 “-jquery”를 넣으면 jQuery가 포함된 문서는 빼고 찾을 수 있습니다.

검색과 코딩 사이를 물 흐르듯 오가려면 마우스를 쓰지 않는 편이 좋습니다. 크롬 확장 기능을 이용하면 키보드 J/K로 검색 결과를 탐색할 수 있어서 흐름이 깨지지 않습니다. 맥OS 라면 대략 이런 흐름입니다.

Cmd+Tab, Cmd+L (편집기에서 브라우저로 전환하고 주소창으로 포커스 옮기기)

검색어 입력 후 Enter

J, K로 내비게이션하다가 적절한 문서가 있으면 Cmd+Enter (새 탭으로 열기)

Ctrl+Tab, Shift+Ctrl+Tab 으로 브라우저 탭 전환

Space, Shift-Space로 페이징하며 읽기

불필요한 탭은 Cmd+W로 닫기

4. 검색 키워드 잘 넣기

키워드만 잘 넣으면 거의 대부분의 상황에서 원하는 검색 결과가 첫 페이지 상단에 나옵니다.

4.1. 적절한 범위의 검색 결과 얻어내기

검색 결과를 내가 원하는 영역으로 적절하게 제한해야 합니다. 예를 들어 파이썬에서 쓸 데이터 시각화 라이브러리를 찾고 있다면 검색어에 반드시 python을 포함시키는 게 좋습니다.

반대로 검색 결과를 지나치게 제한해서도 안됩니다. 예를 들어 두 점 사이의 직선 거리를 구하는 문제 등 간단한 수식을 파이썬으로 구현하다가 막혀서 검색을 하는 경우라면 검색어에 굳이 python을 포함시키지 않는 편이 더 좋을 수 있습니다. 다른 언어로 된 풀이를 보더라도 쉽게 파이썬으로 옮길 수 있기 때문입니다.

되도록이면 본인이 풀고자 하는 문제를 정확히 기술하는 키워드를 포함시키면 좋습니다. 예를 들어 동일한 “원소가 2개 이상 담길 수 있는 집합“을 표현하는 자료구조를 구현한 파이썬 함수를 찾고자 한다면 multiset과 python이라는 키워드를 넣으면 좋습니다.

4.2. 정확한 키워드를 알아내는 방법

문제는 “multiset”처럼 정확한 용어를 항상 잘 알기가 어렵다는 점입니다. 두 가지 팁이 있습니다.

하나는 (당연하게도) 어떤 분야를 공부하더라도 항상 권위 있는 교과서 또는 공식 문서를 읽으며 정확한 용어를 평소에 눈여겨보려고 의도적으로 노력을 하는 것입니다. 되도록이면 원서로 읽길 추천합니다. 언젠가 넘어야 할 산이므로 느리더라도 계속 연습을 하시길 권합니다.

다른 하나는, 내가 찾으려는 문제에 대한 정확한 용어를 모르겠고 그래서 원하는 검색 결과가 잘 안 나온다는 느낌이 들면 해당 용어를 알아내기 위한 목적으로 별도로 검색을 하는 것입니다. 예를 들어 “multiset”이라는 용어를 어떻게 찾을 수 있을까요? 저는 “set allowing multiple elements”(큰따옴표 없이 입력하세요)라고 입력해봤는데 첫 결과로 영문 위키백과의 multiset 문서가 나왔습니다. 집합은 영어로 “set”이고, 집합의 원소는 영어로 “element”임을 미리 알고 있어야 한다는 점에서 재귀적인 문제입니다. 하지만 “multiset”에 비해 “set”이나 “element”는 더 쉬운 단어라는 점에 있어서도 여타 재귀 알고리즘과 유사한 면이 있습니다. 내가 알고 있는 일반적인 단어를 조합하여 좀 더 희소한 단어에 근접해갈 수 있습니다.

제 생각에 이 문제와 관련하여 도움이 될 만한 습관은 이겁니다. 문제를 풀었으면 그냥 넘어가지 말고 해당 문제를 내가 잘 이해하고 있는지 확인을 하려고 노력하세요. 그리고 그 문제가 내가 알고 있는 어떤 분야와 관련이 있는지도 대충 살펴보며 지식을 연결하려고 노력합니다. 이렇게 연결하다보면 의외로 자주 마주치는 지식의 덩어리 및 이와 관련된 용어들을 알게 됩니다. 이런 지식과 용어들은 상대적으로 중요할 가능성이 높습니다.

5. 검색 결과 중 클릭할 문서 잘 찾기

정보 검색에 익숙하지 않은 사람들의 행동을 관찰해보면, 검색 결과 페이지에 적절한 문서가 나왔음에도 불구하고 엉뚱한 문서를 클릭해서 읽는 경우가 잦습니다. 어떤 문서가 적절한 문서인지를 알아보는 몇 가지 방법들이 있습니다.

아래의 기준으로 읽어볼 문서를 추려내되, 하나의 가장 좋은 문서를 찾으려고 시간을 쓰기보다는 cmd+click(윈도는 ctrl+click)으로 후보 문서 여러 개(보통은 2~4개 정도)를 열어두고 하나씩 읽으면 편리합니다.

5.1. 분야별로 신뢰할 수 있는 사이트가 어디인지 파악하기

검색 결과를 훑을 때 문서의 URL만 보고도 신뢰할 수 있는 사이트인지 아닌지 걸러 낼 수 있으면 좋습니다. 돌이켜보면 저는 초기엔 의도적으로 이런 노력을 하진 않았었고 오래 하다 보니까 차츰 알게 되었는데요, 최근 대략 15년 정도는 의도적으로 노력을 하고 있습니다. 여러분들은 처음부터 의도적으로 노력을 하길 권합니다. 일단 검색 결과에 공식 문서가 있으면 그걸 우선 읽으려고 노력합니다. 예를 들어 Python 관련 정보는 python.org, Go 관련 정보는 golang.org, AWS 문서는 docs.aws.amazon.com, 각 라이브러리에 대한 문서는 해당 라이브러리 공식 문서 등.

공식 문서가 아니더라도 신뢰할 수 있는 사이트들이 있습니다. 웹 관련 기술이라면 w3.org가 가장 공식적이지만 읽기에 친절한 편은 아닙니다. w3.org가 아니더라도 mozilla.org, css-tricks.com, caniuse.com 등 신뢰할 수 있는 사이트들이 있습니다. 리눅스 관련 각종 가이드는 digitalocean.com 등이 친절하고 신뢰할만합니다. stackoverflow.com는 분야를 막론하고 대체로 괜찮고, en.wikipedia.org도 그럭저럭 괜찮은 편입니다. 특히 위키백과 문서 말미의 “References” 섹션에서 신뢰할 수 있는 정보로의 링크를 종종 발견할 수 있습니다.

✍🏻

Editor 선미's comment

저도 공식 문서를 우선적으로 읽습니다. MySQL의 경우 dev.mysql.com, GA는 support.google.com 입니다. dev.mysql.com 은 영어로 읽어야 하는데 쉽고 명확하게 쓰여져 있어 어렵지 않습니다. support.google.com 은 한글 번역을 지원하지만 번역이 매끄럽지 않아 오히려 영어로 읽었을 때 명확하게 이해가 되는 경우가 많았습니다. 이럴 때에는 한글로 전반적인 내용과 구조를 빠르게 파악하고 정확한 이해가 필요한 부분은 영어로 다시 읽는 방법을 추천합니다.

5.2. 정보 가치가 낮은 사이트 파악하기

정보 가치가 낮거나, 잘못된 정보가 많거나, 오래된 정보가 많은 사이트들을 알아두고 피하는 것도 좋습니다. d2.naver.com 등 믿을만한 국내 소스들도 분명히 많지만 이런 경우를 제외하고는 국내 자료는 앞에서 설명한 이유(IT 관련 분야의 대부분의 정보는 영어로 생산되는 점, 정보가 한국어로 바뀌어 전파되기까지 걸리는 시간 지연, 잦은 오역, 한국어 화자가 영어 화자에 비해 상대적으로 적은 점)에서 의식적으로 피하려고 노력하는 편입니다. 이는 또한 영어 기술 문서 읽기에 익숙해지기 위한 훈련의 일환이기도 합니다.

5.3. 정보의 시의성을 따져보기

검색 결과에 해당 문서가 작성된 날짜가 표시되는 경우가 종종 있습니다. 내가 찾고자 하는 문제의 맥락에 비추어 시의성이 적절한지 판단할 필요가 있습니다.

예를 들어 자바스크립트 Array와 관련된 검색을 했는데, 2010년 문서와 2019년 문서가 각각 나왔다면 2019년 문서의 제목을 더 눈여겨 봅니다. 자바스크립트는 최근 10년 사이에 많이 변했기 때문입니다. 반면 정렬 알고리즘에 대해 찾는 맥락이었다면 문서의 최신성이 크게 중요하지 않습니다. 물론 특정 정렬 알고리즘의 변형에 대한 최근 자료를 찾는다거나 하는 맥락이라면 당연히 최신성이 중요해지겠으나 대체로는 그런 경우가 아닙니다.

이런 판단을 하려면 내가 검색하려는 정보가 대략 어느 시기에 얼마나 변했는지 등을 알고 있어야 합니다. 대략적인 휴리스틱은 이럴 것 같습니다.

라이브러리, 프레임워크 (수개월)

각종 표준, 프로그래밍 언어, 운영체제 (수개월~수년)

각종 프로세스, 설계 방법론 등 소프트웨어 공학에서 다루는 주제들 (수년~수십년)

알고리즘, 자료구조, 프로그래밍 언어론, 운영체제론 등 주로 전산학에서 다루는 주제들 (수십년)

가장 위에 적은 범주가 상대적으로 빠르게 변하고, 아래로 갈수록 상대적으로 천천히 변합니다. 따라서 라이브러리나 프레임워크 관련 정보를 검색할 때는 최신 정보인지를 파악하는 편이 좋습니다.

5.4. 검색어 바꿔보기

검색 결과를 훑으며 첫 페이지 하단까지 내렸는데 딱히 마음에 드는 문서가 없으면 두 번째 페이지로 넘어가기보다는 검색 키워드를 바꿔보길 추천합니다. 검색어만 제대로 넣으면 대체로 첫 페이지의 최상단에 원하는 결과가 나옵니다. 검색 결과 하단에 있는 “Searches related to…” 부분을 참고하여 관련 키워드를 찾아보는 것도 좋습니다.

6. 문서 잘 읽기

적절한 문서를 열어놓고도 엉뚱한 곳만 읽고 문서를 닫거나, 꼭 필요한 중요한 내용을 빼먹고 읽는 경우를 자주 봅니다. 문서를 잘 읽는 요령을 몇 가지 소개합니다.

6.1. 찜해놓기

읽다 보면 (당면한 문제 해결과 도움이 되건 안되건) 의외로 좋은 문서 또는 좋은 사이트를 발견하는 경우가 있습니다. 이런 운 좋은 경우엔 해당 문서를 어딘가에 따로 저장해둡니다. 저는 개인 위키에 기록을 하는데요, 브라우저 즐겨찾기나 노션 등 어디든 상관없을 것 같습니다.

6.2. 코멘트 읽기

방문한 사이트가 블로그나 커뮤니티 보드라면 본문 뿐 아니라 코멘트도 꼼꼼하게 읽는 게 좋습니다. 본문만 봤으면 놓쳤을 중요한 대화가 오가는 경우가 상당히 많습니다.

6.3. 버전 확인하기

라이브러리나 운영체제 등은 버전에 따라 적절한 답변이 다릅니다.

파이썬의 경우 특히 버전 2와 버전 3 사이에 제법 큰 간극이 있으니 본인이 사용하는 버전을 정확히 확인하면 좋습니다. 라이브러리의 경우 해당 라이브러리가 Semver를 쓰는지, 만약 그렇다면 현재 읽고 있는 문서가 호환되는 버전에 대한 문서인지 확인하면 좋습니다. 리눅스에 도커 설치하는 방법을 검색하더라도 어떤 배포판의 어떤 버전인지에 따라 조금씩 차이가 있습니다.

6.4. stackoverflow.com 잘 읽기

이 사이트는 특히 자주 가게 되니까 좀 더 자세히 써보려고 합니다.

보통은 해당 문서를 클릭하기 전에 이미 검색 결과 화면에서 제목을 읽고 내가 원하는 문제와 관련이 있다는 판단을 했기 때문에, stackoverflow.com의 글을 읽을 때 질문 섹션은 넘어가고 답변을 먼저 읽습니다. 답변을 읽다가 뭔가 맥락이 다른 것 같으면 그때 질문을 살핍니다.

채택된 답변이 없거나, 답변이 채택되었으나 투표 수가 너무 적거나, 채택된 답변이 아닌 답변에 투표수가 더 많거나, 채택된 답변이 지나치게 오래되었다면, 다른 답변들도 함께 읽어보면 좋습니다.

답변을 읽을 때 반드시 코멘트를 함께 읽습니다. 중요한 정보들이 있는 경우가 많습니다.

내용이 약간 의심스러우면 답변을 한 사람이 누구인지도 살펴보면 좋습니다. 분야별로 권위 있는 사람이 직접 답변을 다는 경우가 제법 있습니다. 예를 들면 d3js 관련 질문에 Mike Bostock이 답변을 달았거나, Alloy Analyzer 관련 질문에 Daniel Jackson이 답을 달았으면 거의 확실하게 가치 있는 답이므로 꼼꼼하게 읽습니다. 누구인지 모르더라도 평판 점수(reputation score)를 확인하면 좀 더 안심할 수 있습니다. 자주 사용하는 라이브러리라면 해당 라이브러리 공식 저장소에서 주요 기여자를 확인해두면 내 분야의 유명인들이 누구인지 조금씩 알아갈 수 있습니다. https://github.com/trending 같은 곳을 주기적으로 구경 다니는 것도 좋습니다.

질문만 있고 답이 아예 없으며 질문에 대한 투표수(votes)도 낮은 경우라면, 보통은 질문이 안좋다는 뜻이고 다시 말하면 해당 질문에 도달한 원인인 검색 키워드가 애초에 안좋았다는 뜻일 수 있습니다.

6.5. 다른 문서와 비교하기

얻어낸 정보가 맞다는 확신이 안 들면 열어둔 다른 탭들을 읽어봅니다. 모든 탭을 다 읽어도 확신이 안들면 키워드를 바꿔가며 다시 검색을 합니다.

6.6. 원하는 결과가 잘 안나오면…

5분에서 10분 이상 찾았는데도 모르겠으면 아마도 이 문제에 대해 지나치게 모르고 있기 때문일 가능성이 있습니다. 그렇다는 판단이 들면 무턱대고 검색을 더 하기보다는, 공식 가이드라인, 공식 레퍼런스, 좋은 교과서, 논문, 위키백과 등을 찾아 읽으며 맥락 파악을 하는 편이 좋습니다.

사실은 애초에 이런 상황에 마주칠 가능성을 낮출수록 좋습니다. 어떤 라이브러리나 프레임워크를 이용하기 전에 반드시 공식 사이트에서 제공하는 기본적인 문서(레퍼런스 제외)를 꼼꼼하게 읽어두어야 합니다. 대부분의 경우에는 다음과 같은 문서들이 있습니다.

Getting Started: 아주 짧게 요약한 안내 문서입니다. 꼼꼼하게 읽으세요.

User Guides: 좀 더 긴 안내 문서입니다. 꼼꼼하게 읽으세요.

Tutorials: 좀 더 친절하고 “따라하기” 방식으로 익히기 좋은 형태로 정리된 안내 문서입니다. 어느 정도 익숙한 분야라면 대충 훑어보면서 주의할 점이 없는지 정도만 살펴보면 좋습니다. 익숙하지 않은 분야라면 훑어 읽지 말고 직접 코드를 입력하며 착실히 따라해보면 좋습니다.

Examples: 다양한 활용 예시. 대충 훑어 읽으며 주의할 점이 없는지 살피면 좋습니다. 당면한 문제에 부합하는 예시가 있으면 꼼꼼하게 봅니다.

References: 보통은 미리 읽지 않습니다. 단어 사전처럼 모르는 게 있거나 정확한 내용이 알고 싶으면 해당 부분만 찾아서 읽습니다.

어쩌면 이게 가장 중요한 습관 중 하나인데 많은 개발자들이 이 단계를 부실하게 하는 바람에 불필요하게 많은 고생을 하고는 합니다. 상당수의 문제는 “Getting Started”와 “User Guides”를 꼼꼼하게 읽으면 미리 피할 수 있습니다.

7. 구글 이외의 사이트에서 검색하기

때론 구글보다 다른 사이트에서 검색을 하는 편이 더 나은 경우도 있습니다.

어떤 CSS 기능이 얼마나 다양한 브라우저에서 지원되는지 궁금하다면 https://caniuse.com에서 찾아보면 좋습니다.

또는, 원래 잘 작동하던 코드였는데 외부 라이브러리를 업데이트한 후에 갑자기 오류가 난다면 라이브러리 자체에 새로운 버그가 생겼기 때문이거나 해당 라이브러리와 다른 라이브러리 사이에 충돌이 일어나고 있기 때문일 수 있습니다. 이런 상황이 의심된다면 구글에서 검색하기보다는 깃헙에서 해당 라이브러리에 등록된 이슈를 검색하는 편이 좋습니다. 특히 아직 해결되지 않은 이슈인 경우 이 문제를 임시로 피해가는 방법(workaround)에 대한 논의 등을 볼 수 있어서 유익합니다.

언제 검색을 할까

8. 언제 검색을 할까

8.1. 검색을 안하면 개발을 못하는 개발자, 검색을 안하며 개발하는 개발자

종종 “검색을 안하면 개발을 못하는 개발자”는 가짜 개발자라며 비판하는 글을 접합니다. 인터넷을 뒤져서 본인이 이해하지도 못한 코드를 복붙하는 상황을 비판하려는 의도인 것 같습니다. 이런 비판을 접하면 마치 검색을 하는 게 부끄러운 일이라는 생각이 들 수도 있습니다.

하지만 반대로 “검색을 안하며 개발하는 개발자”도 위험할 수 있습니다. 검색은 내가 이미 알고 있는 방법보다 더 좋은 방법이 있는지 찾을 수 있는 좋은 기회 중 하나이기 때문입니다. 경력이 많은 개발자 중, 10년~20년 전에 쓰이던 기술이나 방법만을 고집하는 분들을 종종 봅니다. 최신 기술이 항상 좋은 것은 아니지만 2020년에 새로운 사이트를 개발하면서 Python 2.7과 jQuery를 선택한다면 대체로 부적절한 판단일 가능성이 높습니다. 하지만 의외로 이런 경우가 제법 있습니다.

오랜 세월 동안 꾸준히 공부하며 최신 기술을 익히고 시도한다는 건 어려운 일입니다. 저는 게으른 편이라 따로 시간을 할애해서 진득하게 공부하는걸 잘 못하는 편입니다. 여러분도 저와 비슷하다면, 어떻게든 업무 중에 공부를 자연스럽게 병행할 방법들을 마련하시길 권합니다.

가장 좋은 방법 중 하나는, 이미 해봐서 익숙한 문제를 풀더라도 괜히 검색을 한 번 해보는 습관을 만드는 것입니다. 예를 들어 CSS로 상단 메뉴를 만들려면 float: left를 쓰면 된다는 걸 20년 전부터 알았습니다. 하지만 괜히 한 번 검색을 해보면, float을 쓰는 방법은 예전 CSS에 레이아웃 관련 기능이 부족했기 때문에 임시로 쓰던 편법이었고, 지금은 display: flex를 쓰는 게 더 적합한 방법이라는 걸 배울 수 있습니다.

지금 풀려는 문제를 모르겠으면 검색을 해야 합니다. 지금 풀려는 문제가 너무 익숙해도 검색을 하면 좋습니다. 검색을 안 하면 개발을 못하는 개발자도 위험하지만, 검색을 안 하면서 개발하는 개발자도 위험합니다.

8.2. 지식의 감가상각과 잔존가치

앞서 말씀드린 바와 같이, 라이브러리/프레임워크, 각종 표준/프로그래밍 언어/운영체제, 각종 프로세스/설계 방법론 등 소프트웨어 공학에서 다루는 주제들, 알고리즘/자료구조/프로그래밍 언어론/운영체제론 등 주로 전산학에서 다루는 주제들 순으로 최신성이 얼마나 중요한지에 차이가 있습니다. 최신성이 중요한 문제라면 더 자주 검색을 해보면 좋습니다.

지식에도 감가상각이 있습니다. 어떤 지식은 잔존 가치가 더 빠르게 줄어들고 어떤 지식은 더 오래갑니다. 오래가는 지식을 쌓아가려는 노력과 빠르게 변하는 지식을 갱신하려는 노력을 병행해야 합니다.

8.3. 당면한 문제가 없어도 그냥 검색하기

밥을 먹다가 갑자기 어제 본 드라마의 특정 장면이 궁금할 때가 있습니다. “어제 황시목이 왜 그랬지?” 네이버에서 검색을 합니다.

밥을 먹다가 갑자기 어제 짠 코드가 궁금해지는 일이 잦으면 좋습니다. “어제 그 코드에서 루프를 하나 줄이는 방법은 없나?” 구글에서 검색을 합니다.

8.4. 우연한 발견, 계획적 수집

문제에 당면해서 검색하기, 답을 이미 알고 있더라도 혹시 더 나은 방법이 있을까 싶어서 검색하기, 갑자기 궁금해져서 검색하기. 셋 모두 분명히 좋은 습관입니다. 하지만 이런 식의 검색은 업무 중 또는 일상에서 상시 공부를 하기 위한 습관 중 하나일 뿐이고 이것만으로는 충분치 않습니다.

본인의 업무 또는 관심사와 밀접하게 관련된 중요한 정보라면 이런 식으로 우연히 발견하는 방식이 아니라 원칙적으로 정보를 놓칠 수 없도록 만드는 게 중요합니다. feedly.com 같은 RSS 리더나 각종 메일링 리스트 등으로 정보가 직접 나에게 배달되는 시스템을 만들어두면 좋습니다. 이건 검색과는 약간 벗어난 주제라 다음에 다뤄보면 좋겠습니다.