터미널 램 71GB 폭주, 범인은 오르카 아닌 '고아 프로세스'
터미널이 램 71기가를 잡아먹는다는 하소연에서 시작된 오르카 좀비 프로세스 논쟁이 방에서 다시 불거졌다. 도구 탓이라는 의심과 관리 실패라는 반론이 오간 끝에, 한 참여자가 직접 점검해 고아 프로세스를 확인했다. 편리한 도구일수록 뒤처리 책임은 결국 쓰는 사람에게 돌아온다는 걸 보여준 사례다.
오후 3시가 넘어가던 시각, 방에는 터미널이 램을 71기가바이트까지 삼켰다는 하소연이 올라왔다. 몇몇은 대뜸 AI 코딩 에이전트 도구인 오르카(orca)를 의심했다. 오르카를 켜두면 작업이 끝난 뒤에도 뒤에 죽지 않고 남는 프로세스가 있다는 이야기가 그 전부터 오갔던 터라, 낯익은 용의자였다. 컴퓨터가 갑자기 버벅이기 시작하면 사람들은 대개 가장 최근에 새로 깔았거나 가장 눈에 익은 도구부터 의심하게 마련이다.
"그냥 거기서 떠 있는 프로세스들이 뭐가 정신없이 커진거 아닌가요"
여기서 오간 좀비 프로세스, 고아 프로세스는 컴퓨터 용어로, 실행이 끝났는데도 시스템에서 완전히 정리되지 않고 계속 메모리를 붙들고 있는 상태를 가리킨다. 원래 작업을 지시한 부모 프로그램이 먼저 꺼지면, 그 밑에서 돌던 자식 프로세스가 어디에도 속하지 못한 채 홀로 남는데 이를 '고아(orphan)'라 부른다. 이런 상태가 쌓이면 아무 작업을 하지 않아도 시스템 자원을 계속 잠식한다. 화면에는 어떤 프로그램도 켜져 있지 않은 것처럼 보여도, 뒤에서는 정리되지 못한 프로세스들이 계속 메모리를 붙들고 있으니 사용자 입장에서는 원인을 짐작하기 쉽지 않다.
다만 오르카를 곧장 지목하는 목소리에는 반론이 바로 붙었다. 오르카가 뭔가 잘못하는 게 아니라 사실상 프로세스 관리 실패일 뿐이라는 지적이었다. 원인을 특정 도구 탓으로 돌리기보다, 여러 작업을 동시에 돌리면서 프로세스를 정리하는 방식 자체를 되짚어야 한다는 취지였다. AI 코딩 도구들이 애초에 백그라운드에서 여러 작업을 한꺼번에 처리하도록 만들어진 만큼, 그 뒤처리는 결국 도구를 쓰는 사람의 몫으로 돌아온다는 뜻이기도 했다.
논쟁이 오가는 동안 한 참여자는 오르카를 쓰면서 오히려 워크트리(같은 작업 저장소를 여러 폴더로 나눠 동시에 다루는 방식)와 브릿지(서로 다른 프로그램을 연결해주는 통로) 같은 개념이 이해되기 시작했다고 전했다. 도구를 향한 불만이 오가는 와중에도, 그 도구 덕분에 배운 게 있다는 반응이 섞여 나온 셈이다. 잠시 뒤 논쟁을 지켜보던 다른 참여자가 자신의 컴퓨터를 직접 점검한 결과를 들고 왔다.
"감사합니다. 저에게 하는 말씀이셨군요 ㅎㅎ 방금 걸어봤습니다. 고아 천지가 된게 맞았습니다. ㅜ"
도구를 향한 의심으로 시작된 소동은 결국 각자의 작업 환경을 직접 확인해보라는 결론으로 마무리됐다. 특정 프로그램 하나를 범인으로 지목하기보다, 여러 작업을 동시에 돌릴 때 뒤처리가 제대로 되고 있는지가 더 근본적인 문제였던 셈이다. 오르카를 둘러싼 이 논쟁이 이번이 처음이 아니라 다시 불거진 주제였다는 점에서, 도구 하나의 결함보다 여러 프로세스를 동시에 다루는 작업 환경 자체가 방의 반복되는 고민거리로 자리 잡은 모습이다.