Orca IDE를 쓰면서 기여도 해보기

나온 지 얼마 안 된 도구로 갈아탔습니다

https://www.onorca.dev/

Orca는 AI 코딩 에이전트를 여러 개 동시에 돌리기 위해 만들어진 데스크톱 앱입니다. 에이전트마다 작업 공간을 따로 띄우고, 여러 개가 각자 일하는 걸 한 화면에서 관리할 수 있어요.

제가 그때 일하던 방식과 정확히 맞아떨어졌습니다. 그래서 잠깐 써보다가 Warp도 VS Code도 접고 주력 도구로 갈아탔어요.

주력으로 쓰니 문제가 눈에 들어왔습니다

편집기를 갈아타면 처음 며칠은 손에 안 익어서 불편한 게 당연한데, 그것과는 다른 종류의 걸림이 있었어요. 경계 조건에서 화면과 실제 상태가 어긋나는 것들이었습니다.

나온 지 얼마 안 된 프로젝트라 그럴 만하다고 생각했습니다. 그리고 어차피 제가 매일 쓸 도구니까, 걸리는 걸 그냥 고쳐서 올려보기로 했어요.

12일 동안 이렇게 됐습니다.

이 중 첫 기여였던 #8570을 자세히 적어보겠습니다.

커밋을 했는데 화면이 안 바뀝니다

터미널에서 git commit을 했는데, 파일 탐색기의 변경 표시와 Source Control 패널에 변경사항이 그대로 남아 있었습니다. 새로고침해도 안 되고, 앱을 재시작해야만 풀렸어요.

되짚어 보니 조건이 하나 있었습니다. 파일이 아주 많은 프로젝트에서 “변경 사항이 너무 많이 감지되었습니다. 처음 10,000개만 표시됩니다” 배너가 뜬 다음부터였어요.

업스트림에 관련 이슈도 PR도 없어서 코드부터 읽었습니다.

자기 자신을 가둔 자물쇠

Orca는 변경사항을 알아내려고 주기적으로 git status를 실행합니다. 그런데 결과가 10,000개를 넘으면 성능을 지키려고 “이 프로젝트는 너무 크다”는 플래그를 세워요.

이 플래그가 서 있는 동안에는 상태를 갱신하는 모든 경로가 막힙니다. 3초 주기 갱신, 30초 예비 갱신, 파일 감시, 커밋 같은 사건이 보내는 신호까지 전부요.

문제는 이 플래그를 내릴 방법이 하나뿐이라는 거였습니다. git status를 새로 실행해서 “이제 10,000개 미만”이라는 결과를 받는 것.

실행할 수 있는 경로가 다 막혔으니 새 결과가 올 방법이 없고, 그래서 플래그가 영원히 안 내려갑니다. 문을 잠근 자물쇠가 열쇠를 문 안쪽에 두고 잠긴 셈이에요.

성능 보호는 그대로 두고 고치기

여기서 그냥 “안 막게” 고치면 안 됐습니다. 갱신을 차단하는 동작 자체는 대형 프로젝트의 CPU 사용량을 잡으려고 #7983이 일부러 넣은 거였어요.

그래서 갱신 경로를 성격으로 갈랐습니다.

• 그냥 물어보는 것 — 3초마다 “바뀐 거 있어?”라고 묻기. 비싸고, 계속 막아야 함.
• 바뀌었다는 증거가 있는 것 — 커밋이 일어났거나 터미널 명령이 끝났다는 근거가 실린 신호. 두 번째만 통과시키면 됩니다. 조건을 두 개로 쪼갰어요.

// shouldPoll: huge 검사 포함 → 주기 갱신은 계속 차단 (#7983 보호 유지)
// canFetch:   huge 검사 제외 → 증거 있는 신호만 통과

커밋 한 번이 git status를 1회 실행시키고, 그 결과가 10,000개 미만이면 플래그가 내려가면서 정상으로 돌아옵니다.

파일 감시는 일부러 제외했습니다. 파일이 10,000개를 넘는 프로젝트는 파일이 수시로 바뀌기 때문에, 여기까지 열면 원래 보호가 무너지거든요.

작업하다 하나 더 걸렸어요. 앱 창이 숨겨져 있으면 이 신호가 버려집니다. 앱을 최소화한 채 AI 에이전트가 커밋하는 경우가 딱 그거죠. 그래서 “창이 다시 보이면 한 번 따라잡기”를 추가했습니다.

지적을 다 반영하지는 않았습니다

제출 전에 AI에게 일부러 트집을 잡아달라고 시켰더니 3건이 나왔습니다. 가벼운 1건은 반영했고, 심각도 높은 2건(파일 변경만 있을 때 남는 구멍, 여전히 10,000개를 넘는 상태에서 신호가 절반만 통하는 문제)은 일부러 안 고쳤어요.

대신 PR 설명에 한계와 다음 방향으로 적었습니다. “지금은 영원히 안 풀리는데, 이 수정 후엔 대부분 풀린다”는 게 근거였어요. 첫 기여에서 2파일 수정을 200줄로 불릴 이유가 없었습니다.

테스트는 고치기 전에 먼저 썼습니다. 실패하는 걸 확인하고 수정한 뒤 통과시키니, 원인을 제대로 짚었는지 스스로 검증이 됐어요.

정직하게 쓴 부분도 있습니다. 전체 테스트에서 17개가 실패했는데, 확인해 보니 제 머신의 git 버전 문제였고 수정 전 원본에서도 똑같이 실패했어요. 이걸 숨기지 않고 PR에 명시했습니다.

2파일에 +112/−11. AI 리뷰가 지적 없이 통과했고, 첫 포크 기여라 CI가 승인 대기로 멈춰 있다가 메인테이너 승인 후 전부 통과. 제출 약 10시간 뒤에 머지됐습니다.

나머지 버그들

나머지는 짧게만 적어둡니다.

이슈 목록 6페이지 이후로 못 넘어감 (#8658) — 목록을 “마지막 항목의 수정 시각” 기준으로 다음 페이지를 불러오는데, 정작 목록을 요청할 때 정렬을 지정하지 않고 있었습니다. 순서가 어긋나니 항목이 새어나가서 실제 데이터가 먼저 바닥났어요. gh CLI의 기본 정렬을 직접 돌려서 확인한 게 근거가 됐고, 588개 이슈를 스크립트로 순회해 “5페이지에서 멈춤 → 585개 순회”를 PR에 넣었습니다. 당일 머지.

모든 터미널이 키 입력을 삼킴 (#9797) — 앱을 방치했다 돌아오니 모든 터미널이 입력을 안 받는데 출력은 정상이었습니다. 이미 이슈 #8104가 있었지만 아무도 재현을 못 해서 11일째 멈춰 있었어요. 저는 그 순간 고장난 앱을 켜 두고 있었기에, 재시작하지 않고 실행 중인 프로세스에 디버거를 붙였습니다. 원인은 파일 쓰기를 맡는 일꾼 스레드가 굳어서 키 입력이 무한정 줄을 서던 것 — 출력은 다른 경로라 멀쩡했던 겁니다. 지금까지 한 기여 중 가장 깊었고(+768/−44), 같은 문제를 node-pty에도 올렸습니다.

시간 표시만 OS 언어로 나옴 (#8662) — 앱 언어를 English로 뒀는데 “그저께”, “5일 전”만 한글이었습니다. 이 단어는 번역 파일이 아니라 브라우저 내장 기능이 즉석에서 만드는 거라, 언어를 지정하지 않으면 OS 언어를 따르더라고요.

사용량 초기화 시각이 사라짐 (#8643) — 이건 다른 PR을 준비하다 곁가지로 찾은 버그입니다. 그 PR은 하루 먼저 올라온 중복 PR이 있어서 제가 닫았고, 겹치지 않는 이 버그만 따로 올렸어요.

후기

직접 쓰는 도구가 제일 좋은 출발점이더라고요. 재현 절차가 이미 손에 있고, 고쳤는지도 직접 확인할 수 있습니다. 여기 적은 것 중 절반이 “쓰다가 걸린 것”이었어요.

남이 올렸는데 아무도 못 잡은 이슈가 의외로 좋은 자리입니다. #9797이 그랬어요. 간헐적으로만 나는 버그는 제보자도 재현을 못 해서 오래 방치되는데, 마침 그 상태를 만난 사람이 재시작만 참으면 답을 낼 수 있습니다.

리뷰를 통과시킨 건 코드가 아니라 직접 돌려본 숫자였습니다. gh CLI 기본 정렬, 588개 이슈 순회 결과, 굳은 프로세스에서 확인한 내부 상태 — “이럴 것 같습니다”보다 “돌려봤더니 이랬습니다”가 리뷰어 일을 줄여줍니다.

범위는 좁게 잡고, 못 고친 건 PR에 적어두면 됩니다. #8658에서 남은 구멍과 고치는 방향을 적어뒀더니, 메인테이너가 제 커밋 위에 그 방향대로 구현한 커밋을 올리고 머지했어요. 커밋 메시지가 “Builds on the sort-pin fix”로 시작했습니다.

나온 지 얼마 안 된 프로젝트는 손댈 곳이 남아 있고 반응도 빠릅니다. 다만 그 속도가 양방향이더라고요. 제 PR이 빠르게 읽히는 만큼 제가 손댄 코드도 빠르게 남이 건드려서, #8727은 리뷰를 기다리는 동안 다른 PR이 같은 함수를 고치고 먼저 들어갔습니다. 리베이스하고 “제 수정 범위는 그대로입니다”를 확인해 준 뒤에야 머지됐어요.

쓰는 도구에서 “이거 좀 이상한데” 싶은 게 있다면, 이미 이슈로 올라와 있는지 검색해 보세요. 없으면 그건 여러분 자리입니다.