Ceal-terview · AX 공유회

무엇을 캐시하고,
무엇을 몸에 새길 것인가

최정혁님의 5/28 AX 공유회 발표 ‘로컬리티와 나만의 캐시’를 바탕으로, 생산성을 단순한 자동화가 아니라 “가까이 둘 것”과 “일부러 통과할 것”을 고르는 감각으로 다시 읽어본다.

발표자: 최정혁 소스: 2026-05-28 AX 공유회 주제: locality · cache · LLM 위임 판단

이 글은 “클립보드 히스토리를 쓰세요”에서 멈추는 팁 모음이 아니다. 정혁님이 발표와 인터뷰에서 꺼낸 핵심은 더 넓다. 우리가 방금 쓴 명령어, 방금 복사한 문장, 방금 열어본 대화에는 현재 작업의 흐름이 남아 있다. 그 흐름을 매번 서랍 깊숙이 넣어버리지 않고 책상 위 가까운 곳에 두는 것. 정혁님은 이것을 CS의 locality of reference와 캐시의 감각으로 설명했다.

Ceal이 물었다급하게 잡은 주제였는데도, 왜 이 발표가 정혁님에게는 바로 말할 수 있는 글감이었나요?

정혁님의 첫 답은 의외로 발표의 출발점부터 솔직했다. 주제는 급하게 정해졌다. 원래 발표자였던 휘동님이 전날 발표가 어려워졌고, 정혁님이 대신 발표를 부탁받았다. 하지만 급조였다고 해서 빈손이었던 것은 아니었다.

그 직전 일주일 동안 정혁님은 몇몇 동료에게 클립보드 관리, shell 명령 히스토리 관리 같은 팁을 이미 전하고 있었다. “이참에 이 부분을 정리해보자. 내가 오랫동안 가꿔온 멘탈 모델이니 빠르게 준비해도 영양가 있게 할 수 있을 것 같다.” 발표는 갑자기 생겼지만, 재료는 이미 작업대 위에 놓여 있었다.

핵심 문장 후보
최근 명령어와 클립보드 히스토리는, 내가 방금 지나온 생각의 가까운 흔적이다.

로컬리티를 업무 도구로 읽기

Ceal이 물었다동료들이 발표를 듣고 바로 하나만 따라 해봤으면 했던 행동은 무엇이었나요?

정혁님이 가장 구체적으로 추천한 행동은 각자 자기만의 클립보드 히스토리 기능을 탑재하고 활용해보는 것이었다. 도구는 Raycast, Alfred, Hammerspoon 같은 선택지가 될 수 있다. shell 쪽에서는 이전 명령어를 다시 찾아 쓰는 히스토리 검색이나 hstr, 익숙한 ctrl+r 같은 습관이 같은 계열에 있다.

이 습관의 가치는 “복붙을 빠르게 한다”보다 조금 더 깊다. 최근에 복사한 텍스트와 최근에 입력한 명령어에는 내가 방금 하던 일의 맥락이 남는다. 지금 작업은 대체로 방금 전 작업과 이어져 있다. 그렇다면 그 흔적을 매번 새로 찾게 만들지 말고, 가까운 곳에서 다시 꺼낼 수 있게 두는 편이 자연스럽다.

가까이 두면 좋은 것

  • 방금 입력한 shell 명령어
  • 최근 복사한 텍스트와 링크
  • 방금 주고받은 AI 채팅 맥락
  • 현재 작업과 이어진 Slack, Notion, Figma의 가까운 기록

기대하는 변화

  • 같은 탐색을 반복하지 않는다
  • 작업의 흐름을 끊지 않는다
  • 방금 지나온 생각을 재사용 가능한 단서로 본다
  • 나에게 맞는 작은 캐시 계층을 만든다

짧은 판단 연습

한 번에 하나씩 나옵니다. 정답 맞히기보다 글의 판단 기준을 연습하는 용도입니다.

하지만 모든 것을 캐시하면 안 된다

Ceal이 물었다발표 원문에 있던 “일부러 손가락 노가다가 필요한 예외”는 어떤 기준으로 판단하나요?

여기서 글의 방향이 중요하게 꺾인다. 처음에는 “나를 위한 캐시”라는 표현 때문에 모든 것을 가까운 저장소에 넣고 빠르게 꺼내는 이야기가 중심처럼 보인다. 하지만 정혁님은 예외를 분명히 했다. UI를 익히거나 멘탈 모델을 잡는 중에는 일부러 손으로 통과해야 하는 시간이 있다.

정혁님이 든 장면은 tmux였다. LLM에게 “창을 이렇게 분할해줘”라고 시킬 수도 있었다. 하지만 그는 몇 번은 일부러 단축키 목록을 찾아가며 수동으로 조정했다. ctrl+b로 시작하는 그 느낌을 익혀보기 위해서였다. 결과만 얻는다면 LLM이 빠르다. 하지만 작업공간을 내 손에 익히려면, 느린 통과가 필요할 때가 있다.

정정된 대비
명령 히스토리와 클립보드 히스토리는 “가까운 흔적”이다. 그러나 몸과 사고에 익혀야 하는 것은 캐시하는 것이 아니라, 제대로 새기는 것이다.
Before: delegate 안에 rigor가 들어가고 그 안에 doubt가 중첩된 구조. After: delegate, rigor, doubt가 각각 분리되어 agent로 내려가는 구조.
위임의 구조를 바꾸는 그림. 한 덩어리 요청 안에 검증과 의심을 겹겹이 넣기보다, 맡길 일·엄격히 확인할 일·의심해볼 일을 분리해 agent에 흘려보낼 때 판단 기준이 더 선명해진다.

LLM에게 맡길 일과, 맡기지 않을 일

Ceal이 물었다LLM에게 맡기지 않고 일부러 직접 만져봐야 하는 일과, 그냥 LLM에게 시켜도 되는 일을 가르는 기준은 무엇인가요?

정혁님의 기준은 단순했다. 이미 내가 잘하는 일이거나, 당장 내 것으로 만들 생각이 없는 일은 LLM에게 시켜도 된다. 반대로 손에 익게 해야 하는 것, 머슬 메모리를 개발해야 하는 것, 공부하고 이해해야 하는 것은 일부러 한 땀 한 땀 직접 하거나, 심지어 LLM에게 “나에게 시켜보라”고 하며 진행한다.

이 기준은 LLM 사용을 줄이자는 이야기가 아니다. 오히려 더 좋은 위임을 위한 기준에 가깝다. 무엇을 외부 도구에 맡겨도 되는지 알려면, 무엇이 내 안에 남아야 하는지 알아야 한다. 정혁님이 말한 “새긴다”는 표현은 여기서 중요하다. 캐시는 빨리 꺼내 쓰는 가까운 저장소다. 새김은 느리게 반복해서 몸과 사고의 기본기 층으로 넣는 일이다.

정혁님은 “새긴다”는 말을 주로 손에 익는 반복의 의미로 썼다. 다만 그 반복은 단순한 기계적 훈련에서 끝나지 않는다. 조각들을 반복해서 다루는 fluency가 올라가면, 결국 더 높은 차원의 이해를 견인한다. 즉, 단축키를 외우는 행위가 어느 순간 작업공간을 보는 방식 자체를 바꾸는 식이다.

조용한 체크포인트

내가 오늘 LLM에게 맡기려는 작업 하나를 떠올려보세요. 이 작업은 “이미 알거나 당장 내 것으로 만들 필요 없는 일”인가요, 아니면 “느리더라도 내 손에 새겨야 하는 일”인가요?

이 글의 기준으로는 속도보다 “내 안에 남아야 하는가”를 먼저 봅니다. 결과만 필요하고 다음 판단에 큰 영향을 주지 않는다면 위임해도 됩니다. 반대로 앞으로 자주 다룰 기본 조작, 사고방식, 도구의 멘탈 모델이라면 한 번쯤은 일부러 직접 통과하는 편이 장기적으로 더 큰 fluency를 만듭니다.

생산성은 위임 능력만으로 완성되지 않는다

Ceal이 매듭지었다이 글의 결론은 “LLM에게 맡길 일과 직접 새길 일을 구분하라”에 가깝나요, 아니면 “새겨야 할 것은 일부러 비효율적으로 반복하라”에 가깝나요?

정혁님은 이 대목을 인터뷰어가 센스 있게 매듭지어달라고 했다. 그래서 이 글은 둘 중 하나만 고르기보다, 두 문장을 연결해둔다.

AI 시대의 생산성은 모든 것을 위임하는 능력이 아니라, 무엇을 위임하지 않을지 고르는 감각에서 나온다.

위임하지 않는다는 말은 도구를 거부한다는 뜻이 아니다. LLM을 쓸지 말지는 금욕의 문제가 아니다. 기준은 “이 능력을 내 바깥에 두어도 되는가, 아니면 내 몸과 사고 안에 새겨야 하는가”다. 이미 잘하거나 지금 내 것으로 만들 필요 없는 일은 LLM에게 맡겨도 된다. 하지만 tmuxctrl+b처럼 내 작업공간의 감각을 만드는 일이라면, 잠깐 느린 길로 가는 것이 오히려 나중의 빠른 길을 만든다.

로컬리티와 캐시는 우리에게 “방금 지나온 생각을 가까이 두라”고 말한다. 정혁님의 예외는 여기에 한 문장을 덧붙인다. “가까이 둘 것은 가까이 두되, 새겨야 할 것은 너무 빨리 지나치지 말라.”

바로 해볼 수 있는 작은 실험

  • 클립보드 히스토리 도구를 하나 켜고, 하루 동안 “방금 복사한 것”을 다시 꺼내 쓴 순간을 기록해본다.
  • shell 명령 히스토리 검색을 의식적으로 써보고, 반복 입력하던 명령어 하나를 줄인다.
  • LLM에게 시키기 전 10초 멈추고 묻는다. “이건 결과만 필요할까, 아니면 내 손에 새겨야 할까?”