search는 늘어나는데 try는 늘지 않는다 —— AI 시대에 「직접 확인하는 경험」이 줄어드는 것에 대하여

독학으로 본격적으로 프로그래밍을 시작한 지 약 1년 반이 되었다.

배운 내용은 나만의 규칙으로 메모를 남기고 있다.

원래 취미가 많고 다양한 분야에 손을 대는 타입이라, 시간이 어느 정도 흐른 뒤에도 기억해낼 수 있도록 배운 내용은 나만의 규칙으로 메모를 남기고 있다.

이 메모를 하는 습관을 프로그래밍에도 적용하여, 무언가를 구현할 때는 날짜나 깨달은 점, 의문점 등을 메모로 남기려고 노력한다.

계기는 과거에 했던 일을 다시 할 기회가 왔을 때, 내용을 잘 기억하지 못해서 또 비슷한 검색을 하며 같은 경로를 따라가는 것이 번거롭다고 느꼈기 때문이다.

메모로 남겨두면 나중에 다시 읽었을 때 빠르게 떠올릴 수 있다. 특히 그 개념을 이해했을 때의 문장이나, 나만의 비유로 바꿔 설명한 내용을 남겨두면 기억해내는 속도가 빠르고, 거기서부터 더 깊이 파고들 수도 있다. 그래서 메모를 남기려고 한다.

프로그래밍에 있어서 그 메모를 대략 「조사한 것(search)」과 「시도한 것(try)」의 두 종류로 나누어 관리하고 있는데, 최근 어떤 편향성을 발견했다.

search 메모는 계속 늘어나는데, try 메모는 거의 늘어나지 않는다.

처음에는 「내가 게을러서」 혹은 「구현이 귀찮아서 미루고 있는 것뿐」이라고 생각했다. 하지만 잘 생각해보니 그것만으로는 설명이 되지 않았다. 이 글은 그 편향성의 정체를 고민해본 기록이다.

기술적인 노하우를 다루는 글이 아닌, 고찰에 가까운 내용이다.

학습 메모를 남길 때, 나는 행동을 나타내는 동사로 파일을 분류하고 있다. 그중에는 크게 두 가지 카테고리가 있다.

search… 조사하다. 「〇〇의 구조를 조사하다」 -
try… 시도하다. 「〇〇를 구현해 보다」 「〇〇를 구동하여 검증하다」

와 같은 제목으로 정하고, 그 안에 내용이나 의문, 결과 등을 기술하고 있다.

이 분류 방식의 장점은 자신의 학습 상태가 그대로 가시화된다는 점이다. search가 많으면 인풋(Input) 과다, try가 많으면 직접 손을 움직이고 있다는 것을 한눈에 알 수 있다. 말하자면 학습의 대시보드(Dashboard) 역할을 한다. 그리고 시간이 흐른 뒤에도 파일명을 보고 어떤 내용/결과였는지 즉시 확인할 수 있다.

또한, 테마를 정함으로써 조사하는 내용이 너무 탈선하는 것을 방지할 수 있고, 능동적으로 정보 수집이나 현상 파악을 하는 느낌을 개인적으로 좋아하기 때문이다.

그리고 그 대시보드를 보니, 명확하게 「search에 편향되어 있음」을 나타내고 있었다.

try보다 search 폴더에 파일 수가 압도적으로 편중되어 있었다.

처음에 생각한 이유는 search는 착수가 가볍기 때문이다. 검색하고, 읽고, 자신의 언어로 정리한다. 바로 시작할 수 있으니까.

반면 try는 무겁다. 구현은 세부 사항을 다듬는 작업이 필요하며, 직접 손을 움직여 에러를 잡아내고, 정상적으로 작동할 때까지 가져가야 한다. 그리고 경우에 따라서는 시간이 엄청나게 걸릴 때도 있다.

그래서 가벼운 search만 하고, 무거운 try는 뒤로 미루고 있는 것이다.

이것은 부분적으로 맞다.

과거 취미 범위 내에서 프로그래밍을 했을 때의 일을 떠올려 보았다.

• 어떤 게임의 보스를 최단 몇 턴 만에 쓰러뜨릴 수 있는지 시뮬레이션을 작성하여 검증했다.
• 어떤 게임의 몬스터 포획 확률을 가상으로 계산하여 확인했다 (드래곤 퀘스트 쥬카)

이것들의 공통점은 인터넷을 찾아봐도 잘 정리된 답이 나와 있지 않았고, 검색해도 거의 검색 결과가 나오지 않을 법한 내용이었다. (검색 능력이 부족했을 가능성도 있다)

답이 존재하지 않기 때문에, 스스로 가설을 세우고 코드를 작성하여 구동하며 확인할 수밖에 없었다. 검증하는 것 외에는 답에 도달할 방법이 없었다.

실제와 맞는지 알 수 없지만 그럴듯한 것을 만들려고 노력하는 과정에서, 그에 필요한 지식이 부수적으로 얻어졌다.

처음으로 개체값이나 종족값 등을 포함하여 포켓몬의 스테이터스를 출력하는 프로그램을 작성했을 때, 에러가 발생했을 때

「이렇게 하면 에러가 없어지지 않을까?」 「이 내용을 바꾸면 어떻게 될까?」 등을 try하며 해결했던 적이 몇 번 있었다.

미지의 것을 하려고 하면 검증과 결과가 필요해지며, 자연스럽게 try가 늘어난다.

미지를 향할 때, search와 try는 반드시 세트가 된다. 찾아봐도 답이 나오지 않기 때문에 try로 확인할 수밖에 없다. try는 「구조적으로 필수」가 된다.

답이 있기 때문에 search만 하면 도달할 수 있다. try로 검증할 필요가 없다. 그래서 search만 늘어난다.

try가 늘어나지 않는 것은 게으름을 피우는 것이 아니라, 지금 있는 곳이 「답이 있는 영역」이기 때문이었다.

여기서부터가 내가 가장 걸렸던 부분이다.

조금 전까지만 해도, "만약 이렇게 작성하면 어떻게 동작할까"를 알기 위해서는 검색을 하거나 직접 구현해서 실행해 보는 수밖에 없었다.

검색해도 걸리지 않는다면, 제대로 작동하는지 검증할 필요가 있었다.

하지만 지금은 다르다. AI가 그 "만약"에 대해 앞서서 답해버린다.

만약 이렇다면 어떻게 될지를 AI에게 물음으로써, "이 코드는 이렇게 동작한다", "이 경우의 거동은 이렇게 된다"를 내가 try(시도)하기 전에 AI가 출력한다. 검증하기 전에 답이 돌아온다.

게다가 실제로 동작하는 경우가 많고, 동작하지 않더라도 AI가 수정을 해주며, 무슨 일이 일어났는지도 AI가 알려준다 (search(검색)가 늘어난다).

그러니 굳이 손을 움직여 확인하려는 동기가 사라진다. try가 발생하지 않는다.

정리하자면, 이런 구조로 되어 있다고 생각한다.

검색과 AI의 발달은 과거에 "미지였던 것"을 "답이 있는 것"으로 바꾼다.

그 결과, 인간이 try(스스로 확인하는 경험)를 할 기회 자체가 줄어든다.

search는 늘어나는데 try는 늘지 않는다는 내 메모의 편향. 이것은 개인의 나태함에 대한 이야기가 아니라, 도구의 진화가 학습의 구조 그 자체를 바꾸고 있다는 것의 작은 나타남일지도 모른다.

검색해도 AI에게 물어도 답이 나오지 않는 것을 한다.

과거에 몰두해서 try했던 게임 시뮬레이션은 바로 그것이었다. 정비된 답이 존재하지 않았기에 스스로 확인할 수밖에 없었고, 그렇기에 재미있었다.

역으로 말하면, 지금 try가 늘지 않는 것은 내가 "답이 있는 영역"에 있기 때문이다.

지도를 펼쳐 놓고 횡단적으로 지식을 모으고 있는 단계라면 그것으로 괜찮을지도 모른다.

하지만 정말로 손을 움직여 확인하고 싶어지는 질문은, 지도 밖에만 있다. 검색과 AI가 답할 수 없는 곳이다.

그곳에 가기 위해서는 방대한 search와 인풋(input)이 필요하다고 생각한다.

여기까지 쓰면서 든 생각인데, try가 늘어나기 어려운 것은 어쩌면 프로그래밍 관계에 국한된 이야기일지도 모른다. 예를 들어 스포츠나 요리에서 AI에게 물어본 것을 따라 해도 미묘한 결과로 끝나는 경우는 흔하다.

나는 테니스를 치고 있는데, AI가 "이렇게 하면 좋은 공을 칠 수 있다"라고 말한 대로 해도 실제로는 잘 안 될 때가 많다. 그리고 몇 번이고 쳐본 결과로서 겨우 "내 경우에는 이렇게 하는 편이 좋다"라는 답을 얻을 수 있다.

즉 프로그래밍 이외의, 신체나 물리적 요소가 얽힌 분야에서는 AI의 답이 그대로 통용되지 않기 때문에 스스로 확인할 필요가 생긴다. AI에게 묻는 것이 오히려 try를 늘리는 계기가 될지도 모른다.

반대로 말하면, 프로그래밍에서 try가 줄어들기 쉬운 이유는 답이 정보나 코드만으로 완결되어 버리는 영역이기 때문이다. AI의 출력이 그대로 정답이 될 수 있다. 그래서 스스로 확인하는 수고를 덜 수 있게 된다.

똑같은 "AI에게 묻기"라도 분야에 따라 try에 미치는 작용이 반대가 된다는 것은 나에게 의외의 발견이었다.

미숙한 글이지만 끝까지 읽어주어서 고맙다. 평소 무심코 메모를 남기다 보면 "단어의 의미를 모으고만 있구나"라는 지점에서 시작해, 능동적으로 학습을 하려고 하니 "search는 늘어나는데 try는 늘지 않는다"라는 단순한 메모의 편향에서 시작된 이야기였다. 파고 들어가 보니 그것은 "답을 먼저 손에 넣을 수 있는 한, AI가 try를 대신해 버린다"라는 구조에 도달했고, 나아가 "그것은 프로그래밍처럼 답이 정보로 완결되는 분야에 특유한 것일지도 모른다"라는 지점까지 왔다.

효율만 생각한다면 스스로 확인하는 것보다 AI에게 묻는 것이 더 빠르다. 그것은 틀림없다. 그러니 "왜 효율을 희생하면서까지 스스로 try하는가"라는 이야기도 당연히 있겠지만, 그것은 그것대로 이야기가 길어지므로 여기서는 접어두겠다.

한 가지 말할 수 있는 것은, search가 늘어나는 것은 나쁜 일이 아니라는 것이다. 철저히 조사한 끝에야 스스로 확인할 수밖에 없는 질문이 나온다. try가 필요한 것은 그 너머라고 생각한다.

내 메모가 우연히 그것을 가시화해 주었다. 기록하는 메커니즘은 어쩌면 지식을 쌓는 것뿐만 아니라, 자신의 학습 방식의 구조까지 비춰주는 것일지도 모른다. 마찬가지로 학습 메모를 남기는 사람이 있다면 search와 try로 나누어 그 비율을 살펴보고 어느 쪽으로 치우쳐 있는지 확인해 보길 바란다. 무언가 보일지도 모른다.