요약
OpenCode 2.0은 백그라운드 서버와 새 API를 중심으로 코딩 에이전트를 다시 짰습니다.
코딩 에이전트 OpenCode를 만드는 어노멀리가 2.0 출시 소식을 알렸습니다. 매일 수백만 명이 쓰며 쌓인 경험을 바탕으로, 에이전트에 필요한 기능을 자유롭게 붙일 수 있는 구조로 바꿨다고 설명했습니다.
왜 중요한가
- 터미널, 웹, 데스크톱 앱이 한 서버에 붙으므로 다른 컴퓨터에서 세션을 돌리고 이어 쓰기 쉬워집니다.
- 핵심 기능 80여 개를 플러그인으로 만들었습니다. 그래서 외부 개발자가 쓰는 플러그인 API를 개발팀도 매일 직접 쓰게 됩니다.
- 1.0 플러그인과 서버 API는 2.0과 호환되지 않아 기존 이용자는 설정을 옮겨야 합니다.
핵심 내용
- 서버가 백그라운드 프로세스 하나로 자동 실행되고, 터미널·웹·데스크톱 앱이 모두 여기에 접속합니다.
- 예전 API는 "형편없었다"고 인정하고, 거의 모든 용도에 맞는 새 API를 처음부터 다시 만들었습니다.
- Code Mode(MCP 서버와 OpenAPI 엔드포인트를 스크립트 속 함수로 바꾸는 기능)로 여러 도구 호출을 한 번에 처리합니다.
- 서브에이전트와 셸 명령을 백그라운드로 돌릴 수 있고, Ctrl+B로 오래 걸리는 작업을 뒤로 넘깁니다.
- 플러그인은 핫 리로드(재시작 없이 다시 불러오기)를 지원해, 세션 중에 만든 플러그인을 바로 쓸 수 있습니다.
HN 반응
- 일부 이용자는 1.0의 불편이 많이 사라졌고, 서버·클라이언트 구조 덕에 원격 세션을 돌리기 좋다고 반겼습니다.
- 반면 설정 로딩의 보안 결함과 플러그인 핫 리로드를 문제 삼아 Pi로 옮겼다는 이용자와, 설치 스크립트가 지나치게 느리다는 불만도 나왔습니다.
어제 이 사람들 설치 스크립트(curl | sh)가 너무 오래 걸리더라고요.
알고 보니 진행률 표시줄을 그리느라 엄청나게 느려지는 거였어요. 말이 안 되죠. 설치가 10%에 도달하기까지 6분이 걸렸어요:
curl -fsSL https://opencode.ai/v2/install | bash
대신 이렇게 실행했더니 해결됐어요:
curl -fsSL https://opencode.ai/v2/install | bash 2>&1 | cat
그건 터미널 문제 아닌가요? stdout이 왜 그렇게 느린 거죠?
xterm 같은 데서도 제대로 안 돌아간다면, 누군가는 살아가는 방식을 진지하게 되돌아봐야 해요. htop도 잘만 돌아가는데, 터미널 에뮬레이터가 고작 이런 시시한 걸 그리자고 에니그마 암호를 풀어야 하나요?
진행률을 파싱하는 과정에서 이상한 짓을 하고 있어서 그런 것 같아요. 거의 바이브 코딩으로 만든 거라 아무도 신경 안 쓰는 거죠. curl 자체 진행률 표시를 쓰는 대신, 추적 인터페이스(--trace-ascii)로 바이트 하나하나 따라가면서 진행률 추적을 새로 발명해 놨어요 :(
https://github.com/anomalyco/opencode/issues/22998 https://github.com/anomalyco/opencode/issues/53702
아, 이건 진짜 심하네요. 그래도 사람도 이런 짓을 하긴 하죠. 저도 모르는 새에 해 본 적이 있는데, 몇 킬로바이트보다 큰 파일을 옮기려고 할 때에야 알아챘어요.
‘진행률 표시줄이 있다’와 ‘길어야 몇 초면 끝날 거라고 기대한다’가 이렇게 많이 겹친다는 게 좀 놀라워요.
저는 수백 메가 미만 파일은 진행률 표시를 넣을지 고민해 본 적도 없어요. 금방 나타날 거고, 정말 궁금하면 루프로 ls를 돌려서 파일 크기를 보면 되잖아요. 그냥 파일이 어디 있는지만 로그로 남기세요.
이런 일에 빠른 GPU 렌더링 터미널이 필수여선 안 된다고 생각해요. 그런 터미널이 필요해지는 기능을 넣을 거라면, 사용자의 터미널이 글리프를 원하는 만큼 빨리 그리지 못한다고 해서 하염없이 멈춰 서 있지 말고 합리적인 방식으로 대체되게 하는 건 어떨까요?
그게 아니면 아예 실패해 버리든가요. 제 시간 낭비시키지 마세요.
제 터미널은 VRAM을 낭비해서 GPU 가속을 꺼 놨어요. 저는 opencode를 안 쓰지만 그 스크립트를 돌려 봤을 때 CPU도 거의 안 쓰고 아무 문제 없었어요.
Nix가 있다면 이렇게 실행할 수 있습니다:
https://agent-distro.nixos.asia/ 는 Nix가 관리하는 자동 업데이트 코딩 에이전트를 제공하고, https://agent-plugins.org/ 기반 프로필도 함께 씁니다.
코드를 눈으로 제대로 보지 않고 하는 코딩이 심한 것 같습니다. 지난 한 주 동안 설정 로딩에서 생긴 큰 보안 퇴행을 그쪽에서 이해하도록 도왔는데, 이슈와 풀 리퀘스트가 두 번이나 필요했습니다. 저희 짐작으로는 AI가 지금 상태가 괜찮다고 말해 줬고, 사람의 비판적 사고가 충분하지 않았던 것 같습니다.
https://news.ycombinator.com/item?id=50075319
저는 v2가 택한 UX 방향이 마음에 들지 않아서 Pi로 갈아탔습니다. 앞으로의 보안 태도도 믿기 어렵고요. CEO가 벌이는 소셜 미디어 쇼도 저를 멀어지게 합니다.
지금은 비슷한 보안상의 이유로 Pi에 시스템 수준 설정을 도입하자고 주장하는 중입니다. 의견이 있는 HN 분은 여기에 남겨 주세요.
https://github.com/earendil-works/pi/issues/10895
제 경험으로는 OpenCode가 ‘최고’라고 할 만한 축을 한 번도 찾지 못했습니다. 다만 한동안 안 써 보기도 했는데, 주된 이유는 Codex/CC/Pi 사이에 제 사용 사례에서 비는 부분이 없기 때문입니다. 더 특수한 필요가 생기면 대개 커스텀 하니스를 만듭니다.
혹시 Go 요금제가 다른 사람들에게는 그 판도를 바꾸고 있는 걸까요?
Go 요금제는 꽤 좋아요. 어쩌면 시중에서 가장 좋은 조건일 거예요. 오픈 웨이트 모델을 써 보고 싶은 분께 추천해요(월 10달러에 할당량도 아주 넉넉해요). 어떤 하니스에서든, 직접 curl로도 쓸 수 있고요. 저는 Go 구독을 GoModel로 설정해 쓰고 있어요(관련은 없고, 제가 즐겨 쓰는 게이트웨이인데 이것도 아주 좋아요).
이게 코딩용 LLM 하니스라는 걸 알아채는 데 시간이 좀 걸렸습니다(에이전트라고도 부르는 것 같은데, 그 용어는 너무 여러 뜻으로 쓰여서 저는 모호하게 느껴집니다).
공급사가 내놓은 것 말고도 이런 게 많이 있더군요.
표준이라는 codex/claude 대신 어떤 걸 써 볼지 판단하는 데 도움이 되는 벤치마크가 있나요?
같은 모델로 서로 다른 하니스를 돌려 비교하는 벤치마크가 몇 개 있는데, 예를 들면 artficial analysis 같은 곳입니다. 하지만 솔직히 조작하기 쉽습니다.
예를 들어 SWEBench 같은 걸 생각해 보세요. 테스트 하나가 통과해야 하는 구조인데, 하니스나 스킬이 에이전트에게 테스트가 통과할 때까지 계속 시도하라고 시키면 그만입니다. 그래서 같은 모델이라도 하니스에 따라 동작이 크게 달라질 수 있습니다.
제 경험으로는(저는 50개 이상의 하니스를 지원하는 멀티 에이전트 IDE를 운영합니다) 사람들은 대개 퍼스트파티를 고수합니다. 보통 오픈AI나 앤트로픽, grok, agy입니다. 구독료를 낼 의향만 있다면 가성비를 따라올 수 없거든요. 게다가 다른 하니스를 써 보는 위험도 지지 않고요.
저도 하니스를 만들었고, 최근에 opencode와 pi를 대상으로 한 평가(eval)를 추가해서 제 것이 그 둘 사이쯤에 놓였어요. 조작은 없었고, 일부 평가에서 성적이 왜 그렇게 나쁜지 알아내려고 했을 뿐이에요(예를 들어 저는 사고 토큰을 돌려주지 않아서 캐시가 깨졌는데, 모델 계열마다 이 부분을 처리하는 방식이 많이 달라요). 아직 제 하니스로 코딩은 해 보지 못했지만, 읽혀 볼 데이터는 수 테라바이트 있어요. 빠르고 기억 유지력이 좋은 로컬 모델을 쓰고 싶긴 한데, 그렇게 돌리면 1년은 걸릴지도 몰라요 ㅋㅋ
Codex와 Claude를 ‘표준’으로 볼 필요는 없어요.
벤더가 내놓은 제품일 뿐이고, 꼭 그걸 써야 하는 건 아니잖아요.
좋습니다.
V1에서 거슬리던 점이 많이 사라졌습니다. 스킬과 플러그인이 자동으로 다시 로드됩니다(드디어). 작업을 백그라운드로 돌릴 수 있습니다(아직 자동으로 되지는 않는 것 같지만). 설정을 편집해 주는 내장 스킬이 생겼습니다(드디어 제가 만든 건 은퇴시킬 수 있겠네요). 프런트엔드도 손을 봤습니다. 듣기로는 루프를 Effect 중심으로 재설계했다고 합니다. 하위 세션과의 소통도 나아졌습니다. 설정은 서버를 시작한 곳이 아니라 세션이 만들어진 폴더에서 로드됩니다.
전반적으로 이번 업데이트는 기능 면에서 OpenCode를 요즘 수준으로 끌어올렸고, 품질 면에서도 훌륭한 정비입니다. 다른 곳으로 갈아타려던 제 시도를 막 접으려던 참에 딱 맞춰 나왔네요. 서버/클라이언트 모델이 이렇게 탄탄한 다른 하니스는 거의 모르기 때문에, 갈아탔다면 골치 아팠을 겁니다.
사용 중인 모델이 작업을 자동으로 백그라운드로 보낼 수 있어요. 수동만 되는 게 아니니 참고하세요.
네, 하지만 작업이 더 오래 걸릴 때 그걸 백그라운드로 옮기는 클릭은 저만 할 수 있습니다. 제 생각에 이건 자동으로 되어야 하고 될 수도 있는 부분입니다. 모델이 항상 그걸 판단할 수는 없으니까요. (제가 그 뜻으로 말한 게 댓글에서 충분히 드러나지 않았네요.)
전반적으로 ‘모델이 멈춰 버리는’ 식의, 막을 수 있는 불편은 아직 해결되지 않았습니다. 권한 요청에 대한 타임아웃도 적어도 기본값으로는 여전히 없습니다.
저만 그런 줄 알았어요. 이 망할 게 애플리케이션을 띄울 때 절반쯤은 멈춰 버려요
저는 V2에 거슬리는 점이 더 많아요. 너무 많아서 하니스를 Pi로 바꿨어요(일단은요?). 핫 리로드도 보안 측면에서 어긋난 설계라고 생각해요. 에이전트가 플러그인을 수정하고 그게 곧바로 다시 로드되어 쓰이게 해서는 안 되죠.
DeepSeek Harness는 사용자나 에이전트가 직접 플러그인을 만들고, 대체로 재시작 없이 실행할 수 있게 해 줍니다. 그 뒤로 Pi와 OpenCode도 각자 새 버전에서 같은 방향으로 영향을 받았고요. 어느 쪽 구현이 더 나은지는 모르겠습니다.
그 기능들을 이미 몇 달째, 그것도 더 많이 갖춘 멋진 세 글자짜리 하니스가 있어요. 다만 많은 분들이 아직 그 얘기를 나눌 준비가 안 됐을 뿐이죠.
omp?
네이티브 앱이 OpenCode 서버에 접속하는 방식은 원격 호스트에서 세션을 돌리기에 아주 좋아요!
Claude Code도 같은 모델을 채택했으면 좋겠어요. 데스크톱 앱은 별도의 엔진을 배포하는데, 재접속하면 그 엔진이 재시작되면서 오래 돌던 세션을 날려 버려요(Remote Control이 권장 해법이지만 Claude.ai 계정이 필요해요).
저는 원격 호스트에서 Claude Code를 감싸는 서버를 띄우는 네이티브 macOS Claude Code 앱을 바이브 코딩으로 만들고 있는데, UX와 기능이 늘 뒤처져요.
Claude Code 에이전트에는 같은 목적으로 쓸 수 있는 프로토콜이 있어요. 로컬에서만 수신하긴 하지만 쓸 만해요. 저는 claude, codex, pi를 고를 수 있는 claw 같은 도구를 직접 만들어 쓰고 있어요(제 구독, 아내 구독, 그리고 GLM이 쌀 때 끊어 둔 연간 구독으로요).
ACP요?
이 용도로 Paseo를 써 보고 있었어요.
Opencode 데스크톱 앱은 이미 원격 웹 세션에 연결할 수 있었는데, 이제는 서버와 직접 통신하나요?
처음으로 opencode를 써 봤어요. Claude Max에 딸려 오는 200달러어치 API 크레딧이 Claude Code에서는 못 쓰게 되어 있어서요. 좋네요. 무료 nemotron 3 모델도 꽤 쓸 만하고, 학생이나 취미로 하는 사람, 월 200달러를 못 내는 사람들도 에이전트 코딩을 쓸 수 있게 된 게 정말 좋아요.
앤트로픽 보너스 크레딧으로 ornith 1.5 35b q8을 jetson에서 돌렸어요. opus 5만큼은 아니지만 실제 코딩과 시스템 관리 작업에 쓸 만하고, opencode에서도 잘 돌아가요. 적어도 sonnet 4만큼은 해요. 초당 5토큰은 좀 답답하지만요.
이전 버전보다 크게 좋아졌어요. 지금 Codex TUI는 저한테 화면 문제가 계속 생기는데, 가장 흔한 게 밝은 글자와 어두운 글자가 무작위로 어긋나는 거예요. OpenCode에서는 지금까지 그런 문제가 없어요. 모델에 구애받지 않으니 앞으로 상시 쓰는 도구가 될 것 같아요.