AI 피로감

ㅋㅋ 찔리네 :) 그래도 내 말은 틀린 게 아님

걔들은 속도랑 퀄리티 둘 다 원하거든. 투자 마일스톤 달성하려는 회사에서 뭘 기대하겠어. 어떻게 되나 보자고.

너는 노련한 개발자들이 계속 주장하던 점을 증명하고 있는 거야. 다들 개발자가 필요 없고 더 빨리 끝낼 수 있다고 생각하지.

소프트웨어 개발에서 더 빠른 게 더 좋은 건 아님.

그 기분 진짜 잘 앎. Anthropic 5x Ultra 구독에 Gemini랑 OpenAI Max/Ultra 플랜까지 쓰고 있는데, 계속 작업 사이를 오가며 검토하느라 바쁨. 어떤 프로젝트에서는 내가 쓸모없게 느껴져서 권한 문제나 해결하고 '네 알겠습니다, 계속하세요'라고 말하는 게 전부일 때도 있음.

참 좋은 세상임.

공장이 문제가 아니라, 검사자가 너 혼자라는 게 문제임. 나 같으면 진행 중인 티켓을 두 개로 제한하고 나머지는 대기열로 돌리겠음. 서류상으로는 느려 보이겠지만, 모든 상태를 파악할 수 있을 거고, 지금 너를 미치게 만드는 '상태를 모르는 상황'에서 벗어날 수 있을 거임.

그래. 이 방식대로 한번 해봐야겠어.

맞음, 이건 전체 소프트웨어 업계가 받아들여야 할 현실임. 스타트업 CEO가 피치 데모를 위해 '바이브 코딩'을 하는 건 멋진 일이지만, 우리는 여전히 누적된 허용 오차 문제에 부딪히고 있음. '전원 인간'으로 구성된 팀에서도 시니어 엔지니어들이 놓치는 게 많은데, 인간 QA 팀이 제대로 된 적이 언제인지 기억도 안 남. TDD는 에이전트 작업에 이론적으로는 좋지만 규율이 필요함. 반면 경영진은 부작용 없이 '더 더 더' 버튼만 누르면 된다고 생각하지.

누군가 WIP(진행 중인 업무) 제한을 언급했는데, 인간 팀뿐만 아니라 에이전트 보조 팀에도 좋은 아이디어임. 반대하는 사람도 많겠지만, 팀원들이 <13811개 중 128번째 멋진 기능>이 실제로 운영 환경에 적합한지, 부정 테스트를 포함해 제대로 준비되었는지 집중할 수 있게 해줌. 단순히 AI라는 불길에 석탄을 계속 퍼붓는 것과는 다르지.

이상적인 오케스트레이션 시스템이 있더라도, 특히 지속적 배포 환경에 있다면 가끔은 '빨리 가기 위해 속도를 늦춰야' 함. 다른 사람들은 어떻게 관리하는지, 아니면 다들 여전히 합리적인 중간 지점을 찾으려 싸우고 있는지 궁금함.

이게 내가 영원히 돌아가는 스웜이나 100% 자동화된 흐름에 완전히 동의하지 않는 이유 중 하나임. 스웜이나 서브 에이전트는 토큰을 너무 많이 잡아먹고, 오케스트레이터부터 서브 에이전트까지 누적된 오차와 반복적인 압축 등이 합쳐져서 작업이나 기능 하나하나의 '미세한 오차'를 증폭시킴. 그래서 뭔가 발견했을 때는 이미 걷잡을 수 없이 꼬여버린 상태일 수도 있음.

참고로 나는 리뷰어 역할 등에 별도의 에이전트를 쓰긴 하지만, 대부분의 작업 항목은 내가 직접 검토를 거쳐서 배포함. '그냥 배포해버리기'보다는 최소한 주기적인 검토를 함. 예전 시니어 팀원들과 점심을 먹으면서 비슷한 고민을 나눴는데, 초기 단계에서 '맞다'고 가정했다가 나중에 큰 고통을 겪은 사례가 있었음. 시스템의 근간이 되는 요소가 근본적으로 잘못된 경우였지. 다들 어떻게 조정하고 있는지 비교해보는 건 항상 흥미로움.

오케스트레이터 봇이 있다면, 뇌가 터지는 걸 막기 위해 너에게 어떤 정보를 줘야 하고 어떤 정보를 주지 말아야 할까?

일을 잘못된 방식으로 하고 있네. 마치 빗자루를 손잡이 쪽으로 잡고 일하는 거나, 수레를 밀지 않고 짊어지고 가는 거랑 같아. 모든 개발자에게서 이런 경향을 보게 되네.