처음 만난 토큰 한계와 의도적인 속도 조절
아내를 위한 오름 깨기 앱 개발 연재
<바이브가 커다란 파도로 진행되기 시작하다>에 이어서 쓰는 글입니다.
토큰 한계를 만난 김에 한숨 돌리며 구상을 해 보다
가장 낮은 요금제였지만, 처음으로 토큰 한계를 만났습니다.
⎿ You've hit your limit · resets 3am (Asia/Seoul)
다행히 속도 조절에 대한 감이 있었습니다. '속도 조절에 대한 감'은 주관적인 표현이라 풀어서 설명하면 대략 세 가지인데요. 하나는 개발자 출신이지만 지금 회사에서 역할이 개발이 아닌지라 지나치게 여기 빠지면 안 됩니다. 개발자가 아닌 분들은 모를 수있겠네요. 개발은 직업으로 하는 일이기도 하지만 몰입하는 습관이기도 합니다. 마치 게임처럼 중독되거나 푹 빠져 버리면 몸이 축나거나 다른 일을 하는데 지장을 주기도 하거든요.
두 번째는 여유를 가질 필요성입니다. 그냥 한 번 해 본 것이긴 하나 내적 만족감도 있고, 효용성도 느껴져서 이를 지속하려면 전략적으로 접근할 필요가 있을 것 같습니다. 그걸 위한 기본 바탕이 바로 여유를 가지고 한 발 떨어져서 보는 행동이라 생각합니다.
마침 이러는 중에 메일링을 받은 글 <속도를 늦춰야 빨라진다>가 눈에 띕니다. 일단, 긱 뉴스에서 요약한 내용 중에서도 앞부분에 나열한 항목을 인용해 봅니다.
AI 시대에 가장 반직관적인 실천은 언제 속도를 늦출지 아는 것이며, 실행이 저렴해질수록 그 앞 단계의 의사결정이 더 중요해짐
Daniel Kahneman의 System 1(빠른 패턴 매칭)과 System 2(느린 분석적 사고) 프레임워크를 AI 시대 소프트웨어 개발에 적용
잘못된 요구사항이나 설계 가정은 AI가 더 빠르게 전파하므로, 실행 전 느린 단계의 비용 대비 효과가 극대화됨
AI를 실행뿐 아니라 사전 검토·프리모텀·엣지 케이스 탐색 등 숙고 단계를 가속하는 데도 활용 가능
"AI 쓰면 되잖아?"라는 새로운 속도 압박 문화에 대응하려면, 느린 단계를 명시적으로 드러내고 타임박싱하는 전략이 필요
토큰 한계보다 중요한 것은 내가 설정한 단계들
현재 시점에서 가장 와닿는 부분은 코드 생산 속도가 빨라졌다가고 무작정 쫓지 말고, 단계를 잘 설계해서 생산성을 통제 안에 두고 누리는 절차를 만들고 습관화하는 일로 보였습니다. 이는 두 가지 의미를 담고 있고, 어쩌면 아직 경계가 불투명한 말 같기도 합니다. 먼저는 숨 가쁘게 쫓아가느라 돌아볼 문제를 놓치지 말자는 것입니다. 프로그래밍 개념인 IoC를 삶에 응용하는 느낌도 드는데, 개발은 코딩 에이전트가 하더라도 무엇을 (어떤 호흡으로) 할 것인지는 내가 결정하게 틀을 잡아 두는 것이죠.
이는 또 기능 구현 수준을 떠나서 제 삶의 시간을 어떻게 구성할 것인가와도 관련이 있습니다. 얼마 전 대화를 나눈 후배가 모든 코드 작성을 에이전트에 맡겼더니 몰입이 주는 즐거움은 사라지고, 산만하게 많은 일을 처리하게 되었다고 말한 내용이 떠올랐습니다. 꽤나 인상 깊게 들었던 이야기죠.
더군다나 생업이 별개로 있는 제 경우에는 일상의 소중한 순간들을 헤치지 않도록 끌고 갈 장치가 필요했습니다. 그런 점에서 2년 동안 <내 일상을 차릴 알고리듬> 연재를 하며 생각을 기록하며 행동에 작은 변화를 만들어 온 일은 도움이 되는 듯합니다.
문제부터 분명히 정의하는 Thinking First protocol
한편, 이하 내용을 훑어보면 생각부터 한다는 'Thinking First protocol'이라는 표현이 눈에 띄었습니다.
Thinking First 프로토콜: AI에 작업을 넘기기 전에 실제로 원하는 것을 명확히 하는 시간을 투자하는 것이 가장 저렴한 실수 포착 지점
원문에서도 해당 내용을 찾아봅니다.
In a previous article, I called this the thinking first protocol: before offloading work to AI, spend time clarifying what you actually want. This isn’t unnecessary process; it’s the cheapest possible place to catch mistakes.
다행히 인생책 <대체 뭐가 문제야>를 읽으면서 저를 포함한 대부분의 사람들이 문제에 대한 정의 없이 허겁지겁 풀고 있고, 기존 교육 시스템 자체가 빠르게 문제를 푸는데 급급하게 설계되어 있다는 사실을 알 수 있었습니다.
회고를 통해 파트너와 호흡을 맞춰가는 휴식기
아무튼 일부러 휴지기를 맞이하면서 클로드 코드와 회고를 했습니다. 이렇게 말이죠.
❯ 지금까지 제가 작업을 요청하는 방식에 있어서 개선해야 할 사항이 있나요? 중요한 것만 골라서 제안을 주세요.
클로드 코드는 아주 공손하게 피드백을 해 주었습니다.
이 앱을 개선하고 유지하는 일의 문제 정의
하지만, 진정한 고비는 그다음에 왔습니다. 368개에 이르는 오름 데이터 중에 일부에 오류가 있는 것을 지적 받자 감정이 생겼습니다. 아내를 위하겠다는 마음으로 만든 것인데, 여기에 쓰는 내 노력을 무시하고 작은 실수에 대해 비난할 때 감정이 상한 것이죠.
이후에 이를 해소하면서 나도 모르게 몰입을 하고 집착하게 된다는 사실을 알게 되었습니다. 개발자라면 당연한 감정입니다. 그 몰입의 경험과 집착하는 마음이 바로 오너십(주인의식)이 되고, 아무도 알아주지 않는 노력을 통해 정합성Integrity를 달성하게 된다는 사실은 어쩌면 경험으로만 알 수 있는 문제입니다.
우발적으로 시작한 이 일에서 결국 내적 만족을 위해 몇 시간을 더 투자해서 데이터 정합성을 맞추고 사용자에게 오류 제보를 받아 수정할 수 있는 피드백 루프를 구현하게 되었습니다.
그 과정에서 스스로 '과연 이 일은 어떤 일인가?' 묻고 답하게 되었습니다. 그렇게 데이터 클렌징을 다 한 후에는 사용자가 이를 확인할 수 있게 공지를 등록합니다. 그러고 나서 아내와 말다툼 과정에서 아내에게 남긴 감정도 해소합니다.