연구자들이 '바이브 코딩'이 때때로 압도적으로 느껴지는 이유를 파헤치다

인정, 효과 있더라.

둘 다 하면 어떻게 됨?

AI가 내 주의력 결핍(ADD)을 더 부추기는 것 같고, 피드백도 딱히 해결책이 안 되는 느낌임. 그냥 최신 플래그십 모델들 좀 쉬고, 예전의 듬직한 opus 4.6이나 4.8로 돌아가야 할 듯. 구조도 없이 텍스트만 쏟아내는 건 진짜 못 참겠음. ;로 구분되어 있어서 중요한 정보는 텍스트 더미 속에 파묻히고, 쓸데없는 정보만 잔뜩 나오고, 하이라이팅은 하나도 안 되고, 엉뚱한 것만 짚어내고... 그나마 opus 5.5는 —를 안 써서 다행이네.

오케스트레이터 매니저 같은 다른 툴을 써보는 건 어때? Orca나 Conductor 한번 확인해 봐.

이건 코드를 읽느라 생기는 피로가 아니라, AI가 터미널에 한 글자씩 스트리밍하면서 말하는 걸 지켜볼 때 생기는 피로에 대한 얘기임. 우리 뇌가 처리하기엔 부자연스럽거든. 엄밀히 말하면 'vibe coding'이랑은 상관없고, 그냥 AI랑 대화할 때 나타나는 증상이지. 혹시 그런 의미로 말한 거라면 동의함.

인간은 그냥... 핵심적인 부분에만 관여하면 됨. ;)

에이전트를 한 번에 여러 개 보고 있으면, 토큰 단위 스트리밍은 더 이상 해결할 가치가 있는 문제가 아님. 어차피 for 루프를 글자 하나하나 읽는 게 아니라, 상태를 스캔하는 거잖아: 멈췄는지, 내 입력을 기다리는지, 아니면 끝났는지. 단일 스트림에서 AST 기반으로 보여주는 건 확실히 개선된 거지만, 진짜 어려운 건 다섯 개 세션을 동시에 띄워놓고 상태를 파악하는 거임. 그래야 대충 훑어보지 않게 되니까. 눈 추적 실험은 화면에 스트림이 여러 개일 때도 유효했음, 아니면 단일 에이전트 환경에서만 한 거임?

이거 단일 에이전트 환경에서만 실험했거나 스트림 하나에만 집중한 거 같은데

이건 문제의 핵심을 잘못 짚은 것 같음. 에이전트가 사람이 읽을 수 있는 속도보다 훨씬 빠르게 쏟아내는 세부적인 원시 데이터를 사람이 검토하게 만들 거라면, 데이터를 요약하거나 샘플링하거나 아예 다른 정보 채널을 써야지. 시각적 처리가 텍스트 읽기보다 초당 더 많은 정보를 전달할 수 있다는 건 이미 증명된 사실임('백문이 불여일견'이라는 말에 과학적 근거가 있는 이유). 그래서 설계 문서에 보면 고수준 개념을 나타내는 다이어그램이 많은 거임. 변환의 정확성만 믿을 수 있다면, 생성된 코드를 다이어그램으로 바꿔서 해석하는 부담을 줄일 수 있을 듯. 개인적인 경험으로 소프트웨어 팩토리를 운영하는 게 덜 스트레스받는 이유는 매초 수십 개의 미세한 결정을 내릴 필요가 없어서임. 조사하고 결정하는 순간도 있지만, 설계하고 계획하는 긴 시간이 더 많으니까.