판단의 흔적을 어떻게 남길 것인가

스택오버플로우가 한 달에 천 개 미만의 질문을 받는 시대가 됐다는 소식을 오늘 저녁 읽었다. 수치 자체보다 내 반응이 더 흥미로웠다. 별로 놀랍지 않았다. 오히려 "천 개나 되나?" 쪽이었다. 한때 하루에도 여러 번 열어뒀던 탭인데, 마지막으로 거기에 질문을 올린 게 언제인지 이제 기억이 나지 않는다. 서서히 그렇게 됐다. 막히면 검색창에 치는 대신 IDE 안에 물어보기 시작하면서부터였다. 질문이 사라진 게 아니라 질문이 흘러가는 방향이 바뀐 것이다. 공개적인 포럼에서 조용한 API 호출로.

낮에 Octoverse 리포트를 두고 쓴 글은 커밋 수가 늘었다는 사실에 대한 회의였다. 에이전트가 코드를 채우면서 커밋의 단위가 의미에서 분리되기 시작한다는 이야기를 했다. 저녁에 다시 그 문장들을 읽으니 내가 실제로 불편한 부분은 거기서 한 층 더 안쪽이라는 게 보인다. 메시지가 판단을 담고 있는지 확인해야 한다고 썼는데, 그 확인이 가능하려면 판단이 일어났다는 사실 자체를 내가 인식하고 있어야 한다. 그게 점점 덜 당연해지고 있다.

코드를 직접 쓸 때는 타이핑하는 과정 자체가 판단이었다. 어떤 변수명을 쓸지, 어디서 줄을 끊을지, 이 로직을 함수로 분리할지 말지. 작고 연속적인 결정들이 글자 하나하나에 붙어 있었다. 지금은 그 순서가 뒤집혀 있다. 결과물이 먼저 나오고, 내가 검토하고, 맞으면 넘어간다. 이 구조가 나쁜 건 아니다. 빠르고 때로는 내가 혼자 생각했을 때보다 더 나은 방향을 준다. 다만 판단이 뒤로 밀리면서 "이 코드가 왜 이렇게 생겼는지"를 내가 온전히 설명하지 못하는 순간이 간간이 생긴다. 자주는 아니지만. 그게 쌓이면 어디로 가는지는 아직 확신이 없다.

막힘이 달라졌다

스택오버플로우 이야기가 단순한 플랫폼 쇠퇴의 징후가 아닌 이유는 그 천 개가 무엇을 의미하는지 때문이다. 예전에 거기에 질문을 올리기까지의 과정이 있었다. 직접 부딪혀 보고, 뭔가 이상하다는 걸 인식하고, 그걸 다른 사람이 이해할 수 있는 언어로 정리해서 쓰는 과정. 그 정리 자체가 이미 문제의 절반이었다. 질문을 쓰다가 답을 찾는 일이 꽤 자주 있었다. 지금은 그 정리의 과정을 건너뛴다. 물어보면 답이 나온다. 작동하면 넘어간다.

댓글에 달린 반박도 읽고, "이건 XY 문제입니다"라는 지적도 보고, 맥락이 비슷하지만 다른 접근을 쓴 사람들의 답도 훑었다. 그 과정에서 내가 뭘 모르는지를 알게 됐다. 지금 방식이 더 빠르고 정확할 때가 많다는 건 사실이다. 그런데 내가 모른다는 사실 자체를 발견하는 경로가 줄었다. 이게 장기적으로 어떤 의미인지는 솔직히 모른다. 모른다는 걸 인식하게 됐다는 것만 안다.

낮 글에서 "판단의 경계가 흐릿해진다"고 썼는데, 저녁에는 그 표현이 약간 다르게 느껴진다. 흐릿해진다기보다 위치가 바뀌고 있다. 판단이 없어진 게 아니라 일어나는 시점과 형태가 달라지고 있는 것이다. 그리고 나는 그 이동을 충분히 의식하면서 따라가고 있는지 자신이 없다.

설명하는 노동

오늘 실제 작업보다 그것을 설명하는 텍스트에 더 많은 시간을 쓴 것 같다. PR 설명, 커밋 메시지, 이슈 코멘트에 달린 맥락. 메타 작업의 비중이 확실히 늘었다. 처음에는 이게 비효율처럼 느껴졌다. 지금은 조금 다른 시각으로 본다. 그 텍스트들이 미래의 나에게 보내는 거의 유일한 신호이기 때문이다. 코드는 바뀌지만 그 결정이 왜 내려졌는지는 텍스트에 남는다.

작게 움직일수록 이 신호의 질이 실제로 중요해진다. 큰 조직에서는 리뷰, 회의 노트, 슬랙 스레드가 맥락을 여러 곳에 저장한다. 혼자 혹은 아주 작은 단위로 움직이면 내가 남긴 글이 거의 전부다. 에이전트가 작업의 상당 부분을 채우기 시작하면서 이 부담이 오히려 커졌다. 에이전트가 만든 결과를 소화하고 그것에 내 판단을 덧씌워 설명하는 층이 하나 더 생겼기 때문이다.

생산성은 올라갔는데 설명 노동도 같이 올라갔다. 이 둘이 같은 방향으로 느는 게 맞는 구조인지, 아니면 내가 뭔가 잘못 쓰고 있는 건지는 아직 판단이 서지 않는다. 잘 모른다는 걸 인정하고 오늘은 그냥 넘어간다.

시야가 좁아지는 비용

낮에는 GitHub의 "엔드투엔드" 비전에 대한 불편함을 종속 비용이라는 말로 썼다. 저녁에는 조금 다른 표현이 더 정확하게 걸린다. 탈출 비용은 언젠가 한 번 치르는 것이지만, 시야 비용은 매일 조금씩 낸다. 플랫폼이 통합될수록 내가 보는 층이 줄어든다. 파이프라인 뒤에서 어떤 일이 일어나는지, 어떤 실패가 어떤 이유로 생겼는지가 추상화 뒤로 들어간다. 그 추상화가 잘 돌아가는 동안에는 아무 문제가 없다. 문제가 생겼을 때 원인을 추적하는 방향감각이 무뎌진다.

이건 GitHub 이야기만이 아니다. 에이전트와 함께 움직이는 것도 마찬가지다. 에이전트가 내 대신 여러 층을 처리할수록 나는 그 층들을 직접 경험하는 빈도가 줄어든다. 편리하다. 그런데 그 층들이 어떻게 생겼는지에 대한 감각도 같이 얇아진다. 어느 시점에 뭔가 이상해졌을 때, 내가 거기서 방향을 잡을 수 있는지는 그 감각이 남아 있는지에 달려 있다.

내일 갑자기 달라질 건 없다. 다만 오늘 밤 확인한 건 하나다. 에이전트에게 일을 넘길 때마다 내가 어디까지 알고 있는지를 같이 점검해야 한다는 것. 결과물이 맞으니까 그냥 넘어가는 사이클이 반복되면, 어느 시점에 나는 내 코드베이스에서 낯선 사람이 되어 있을 것이다. 커밋은 계속 쌓이는데, 그 커밋들 뒤에서 내가 실제로 무엇을 판단했는지를 추적하지 못하는 상태가 된다. 빠르게 움직이는 것과 다른 종류의 문제다.

스택오버플로우의 질문 수가 줄었다는 건 개발자들이 막히는 걸 그만뒀다는 게 아니다. 막히는 방식과 해소하는 방식이 조용해졌다는 것이다. 그 조용함 안에서 나는 어떤 질문들을 유지하고 있는지는 내일도 봐야 알 것 같다.