요즘 터미널 안에서 개발하는 시간이 점점 늘고 있어요. 코드 편집은 에디터에서 하지만, 실제로 문제를 추적하고, 파일을 읽고, 테스트를 돌리고, 검색하고, 브라우저까지 열어보는 흐름은 거의 터미널 중심으로 돌아가거든요.
그러다 최근에 오마이파이(Oh My Pi, OMP)를 꽤 써봤습니다. 한 줄로 말하면, 원래 있던 Pi라는 터미널 코딩 에이전트를 기반으로 이것저것 정말 많이 붙인 물건이에요. 그냥 포크라기보다는, 제 표현으로는 거의 마개조 버전에 가깝습니다.
써보기 전에는 “또 하나의 터미널 AI 코딩 도구인가?” 싶었는데, 며칠 굴려보니 생각보다 괜찮더라고요. 특히 터미널 도구인데도 이미지가 터미널 화면에 바로 붙어서 보이는 경험은 꽤 인상적이었습니다.
오마이파이가 뭐냐면#
오마이파이는 공식 설명을 빌리면 IDE가 연결된 코딩 에이전트 쪽에 가까운 도구입니다. 터미널에서 실행하지만, 단순히 셸 명령만 던지는 챗봇은 아니에요.
공식 저장소 기준으로 보면 이런 쪽을 강조합니다.
- 40개 이상 모델/프로바이더 지원
- 32개 내장 도구
- LSP 기반 코드 탐색/이름 변경/진단
- 디버거 연동
- 브라우저 제어
- 서브에이전트 병렬 실행
- 해시 앵커 기반 편집
- 웹 검색, 문서 읽기, 이미지 처리
- 세션, 메모리, 스킬, 내부 URL 체계
원래 기반이 된 건 Mario Zechner가 만든 Pi고, 오마이파이는 그 위에 실전 개발 작업에 필요한 도구들을 잔뜩 붙인 형태입니다. 그래서 이름도 Oh My Pi인 듯해요. “Pi인데, 뭐가 이렇게 많이 붙었지?” 하는 느낌이 실제 사용감하고도 꽤 잘 맞습니다.
터미널 안에 IDE를 끌고 온 느낌#
오마이파이를 써보면서 제일 먼저 느낀 건, 이게 단순한 터미널 채팅 도구가 아니라는 점이었어요.
보통 코딩 에이전트가 코드를 고칠 때 불안한 지점이 있습니다. 문자열 검색으로 대충 찾고, 파일을 통째로 읽고, 바꿀 부분을 눈대중으로 찍어서 수정하는 흐름이죠. 작은 파일이면 괜찮은데, 프로젝트가 커지면 이 방식이 금방 삐끗합니다.
오마이파이는 이 부분을 꽤 집요하게 파고듭니다.
예를 들어 read는 파일을 무작정 전부 쏟아내기보다 구조 요약을 먼저 보여주고, 필요한 줄 범위만 다시 읽게 만듭니다. edit는 해시가 붙은 앵커를 기준으로 수정해서, 파일이 바뀐 상태에서 엉뚱한 곳을 덮어쓰는 일을 줄입니다. lsp는 에디터가 아는 심볼 정보, 참조, 정의, 이름 변경을 그대로 활용하게 해주고요.
이런 구조가 좋았던 이유는 단순합니다. 모델이 똑똑해도, 도구가 허술하면 결국 실수를 많이 하거든요. 오마이파이는 “모델에게 더 많은 자유를 주자"보다는 “모델이 실수하기 어려운 도구 표면을 만들자” 쪽에 가까워 보여요.
특장점 1: 도구가 꽤 많이 들어 있다#
오마이파이의 장점은 기능 하나가 특출나다기보다, 개발 중 필요한 도구들이 한 덩어리로 잘 묶여 있다는 점입니다.
파일 읽기, 쓰기, 검색, 구조적 코드 검색, LSP, 디버거, 브라우저, 웹 검색, 이미지 생성/분석, 서브에이전트, 작업 목록, 백그라운드 작업, SSH 같은 것들이 같은 세션 안에서 돌아갑니다.
이게 별거 아닌 것 같지만, 실제로는 꽤 큽니다. 개발하다 보면 흐름이 이렇게 가잖아요.
- 에러 로그를 본다.
- 관련 코드를 찾는다.
- 정의와 참조를 따라간다.
- 문서를 검색한다.
- 브라우저에서 화면을 확인한다.
- 테스트를 돌린다.
- 수정한다.
- 다시 확인한다.
기존에는 이 과정에서 에디터, 브라우저, 터미널, 검색엔진, 문서 탭이 계속 왔다 갔다 했습니다. 오마이파이는 이걸 최대한 한 대화 흐름 안에 넣으려는 도구에 가까워요.
특장점 2: 서브에이전트가 자연스럽다#
task 기반 서브에이전트도 인상적이었습니다.
큰 작업을 하다 보면 한 모델이 모든 걸 들고 가기 버거울 때가 있어요. 한쪽에서는 테스트를 봐야 하고, 다른 쪽에서는 UI를 봐야 하고, 또 다른 쪽에서는 문서를 확인해야 하는 식이죠.
오마이파이는 이런 작업을 서브에이전트에게 나눠줄 수 있습니다. 각 서브에이전트는 별도 역할을 받고, 필요한 도구를 써서 결과를 돌려줍니다. 단순히 “너는 이것 좀 조사해” 수준이 아니라, 작업 산출물을 다시 부모 에이전트가 읽고 이어가는 흐름이 비교적 자연스럽습니다.
개인적으로는 이 부분이 앞으로 코딩 에이전트들이 가야 할 방향에 가깝다고 봐요. 한 모델이 모든 컨텍스트를 끌어안고 끙끙대는 방식보다, 작은 작업 단위로 나누고 결과만 합치는 쪽이 더 오래 버틸 수 있으니까요.
특장점 3: 이미지가 터미널 화면에 바로 보인다#
제가 써보면서 가장 “오, 이건 좋다” 싶었던 건 이미지 처리 쪽이었습니다.
요즘 개발할 때 이미지를 모델에게 보여줄 일이 생각보다 많아요.
- UI 스크린샷
- 디자인 시안
- 에러 화면
- 차트 이미지
- 브라우저 캡처
- 앱 화면 비교
- 생성된 이미지 결과물
일반적인 터미널 도구에서는 이미지를 다루는 순간 흐름이 깨집니다. 파일 경로를 복사해서 브라우저나 이미지 뷰어로 열고, 다시 터미널로 돌아와야 하죠. 그런데 오마이파이는 이미지 파일을 읽으면, 모델이 그 이미지를 분석할 뿐 아니라 터미널 화면에도 바로 보여줍니다.
이게 생각보다 체감이 큽니다. “모델은 이미지를 봤는데, 나는 따로 열어봐야 하는” 상황이 줄어들거든요. 같은 화면을 보고 이야기하는 느낌이 생깁니다.
터미널 개발도구에서 이미지가 자연스럽게 보이는 건 사소한 편의 기능처럼 보이지만, 실제로는 작업 흐름을 꽤 많이 바꿉니다. 특히 UI나 디자인, 차트, 앱 스크린샷을 자주 다루는 사람에게는 꽤 큰 장점이에요.
특장점 4: 웹과 로컬을 같은 방식으로 읽는다#
오마이파이에서 좋았던 또 다른 점은 read 하나가 처리하는 범위가 넓다는 겁니다.
로컬 파일만 읽는 게 아니라, 디렉터리, 압축 파일, PDF, 웹 URL, 깃허브 이슈, 풀 리퀘스트, 내부 스킬 문서 같은 것들을 비슷한 방식으로 다룹니다. 도구 이름이 여러 개로 쪼개져 있지 않고, “읽을 수 있는 건 읽는다"는 식에 가까워요.
모델 입장에서는 이게 꽤 중요합니다. 도구 표면이 단순할수록 실수할 여지가 줄어드니까요. 사용자 입장에서도 “이건 어떤 도구로 봐야 하지?“를 덜 생각해도 됩니다.
예를 들어 깃허브 풀 리퀘스트를 파일처럼 읽고, 문서 URL을 마크다운처럼 읽고, 이미지도 같은 흐름으로 확인할 수 있으면 작업 리듬이 훨씬 덜 끊깁니다.
특장점 5: 모델 선택 폭이 넓다#
오마이파이는 특정 모델 하나에 묶여 있는 도구가 아닙니다. 공식 문서에서는 여러 API 제공자와 코딩 플랜, 로컬 모델까지 폭넓게 지원한다고 설명합니다.
이건 장단점이 같이 있어요.
장점은 당연히 선택지가 많다는 겁니다. 가벼운 작업은 작은 모델로 보내고, 깊은 추론이 필요한 작업은 비싼 모델로 보내고, 서브에이전트는 다른 모델로 돌리는 식의 운영이 가능합니다.
반대로 단점은 설정과 운영 난도가 조금 올라간다는 점입니다. “그냥 하나 켜서 쓰면 끝"인 제품보다는, 자기가 어떤 모델을 어떤 역할에 쓸지 어느 정도 정해야 제맛이 나는 도구에 가까워요.
저는 이걸 단점이라기보다 성격이라고 보는 편입니다. 오마이파이는 초보자용으로 모든 결정을 숨겨주는 도구라기보다, 개발자가 자기 작업 흐름에 맞게 조정하는 쪽에 더 어울립니다.
아쉬운 점: 컨텍스트를 꽤 먹는다#
물론 좋은 점만 있는 건 아닙니다.
제가 쓰면서 제일 먼저 느낀 단점은 컨텍스트를 꽤 많이 쓴다는 점이었어요. 도구가 많고, 규칙이 많고, 세션 안에서 유지해야 할 상태도 많다 보니 기본적으로 들고 다니는 정보량이 작지 않습니다.
특히 GPT5.5처럼 컨텍스트를 많이 쓰는 모델로 돌릴 때는 컨텍스트창이 생각보다 빨리 차는 느낌이 있었습니다. 그러면 컴팩션이 자주 일어나요.
컴팩션 자체가 나쁜 건 아닙니다. 긴 세션을 요약해서 이어가게 해주는 장치니까, 없으면 오히려 더 빨리 망가졌을 거예요. 다만 너무 자주 발생하면 작업 흐름이 살짝 끊깁니다. 방금까지의 미묘한 맥락이 요약문으로 압축되면서 감각이 조금 달라지는 순간도 있고요.
그래서 오마이파이를 쓸 때는 작업을 너무 무작정 길게 끌고 가기보다, 중간중간 산출물을 명확히 남기고 작업 단위를 나누는 게 좋아 보였습니다. 큰 작업은 서브에이전트로 쪼개거나, 체크포인트를 잘 잡는 쪽이 더 맞습니다.
누구에게 맞을까#
오마이파이는 이런 사람에게 잘 맞을 것 같아요.
- 터미널 중심으로 개발하는 사람
- AI 코딩 에이전트에게 실제 파일 수정까지 자주 맡기는 사람
- LSP, 검색, 브라우저, 문서 읽기까지 한 흐름에서 쓰고 싶은 사람
- UI 스크린샷이나 이미지 기반 작업을 자주 하는 사람
- 서브에이전트로 조사/수정/검증을 나눠보고 싶은 사람
- 모델과 도구 설정을 직접 만지는 걸 싫어하지 않는 사람
반대로 이런 경우에는 조금 과할 수 있습니다.
- 간단한 질문 답변만 필요한 경우
- 설정이 많은 도구를 싫어하는 경우
- 컨텍스트 사용량에 매우 민감한 경우
- 에디터 안에서 완전히 통합된 경험만 원하는 경우
설치는 간단한 편#
공식 README 기준으로 설치 방법은 여러 가지가 있습니다.
# macOS / Linux
curl -fsSL https://omp.sh/install | sh
# Homebrew
brew install can1357/tap/omp
# Bun
bun install -g @oh-my-pi/pi-coding-agent
윈도우용 PowerShell 설치 명령도 제공됩니다.
irm https://omp.sh/install.ps1 | iex
저장소와 공식 사이트는 여기입니다.
정리하면#
오마이파이는 “터미널에서 쓰는 AI 코딩 에이전트"라는 말로는 조금 부족한 도구였습니다. Pi를 기반으로 했지만, 실제 모습은 파일 시스템, LSP, 브라우저, 웹 검색, 이미지, 서브에이전트, 디버거까지 한데 묶은 개발 작업 환경에 가깝습니다.
제가 좋게 본 지점은 세 가지예요.
첫째, 도구가 모델의 실수를 줄이는 방향으로 설계돼 있습니다. 해시 앵커 편집, 구조 요약 읽기, LSP 연동 같은 부분이 그렇습니다.
둘째, 터미널 안에서 다루는 정보의 폭이 넓습니다. 파일과 웹, 이미지, 풀 리퀘스트, 문서가 같은 흐름 안으로 들어옵니다.
셋째, 이미지가 터미널에 바로 보이는 경험이 생각보다 좋습니다. 모델만 보는 게 아니라 사용자도 같은 화면을 바로 확인할 수 있다는 점이 작업 몰입감을 꽤 높여줍니다.
아쉬운 점은 컨텍스트 사용량입니다. 기능이 많은 만큼 세션이 무거워지고, GPT5.5 같은 모델에서는 컴팩션이 자주 오는 느낌이 있습니다. 이 부분은 앞으로 더 가벼워지면 좋겠어요.
그래도 전체적으로는 꽤 마음에 듭니다. “Pi를 마개조한 물건"이라는 표현이 딱 맞고, 그 마개조가 그냥 기능 과시가 아니라 실제 개발 흐름을 꽤 편하게 만들어주는 쪽으로 붙어 있다는 점이 좋았습니다.
터미널에서 AI 코딩 도구를 진지하게 써보고 싶은 분이라면 한 번 만져볼 만합니다. 이미 Claude Code나 Codex CLI 같은 도구를 쓰고 있다면, 오마이파이는 꽤 다른 방향의 재미가 있을 거예요.
써보신 분 있으면 댓글로 경험도 알려주세요. 특히 컨텍스트 사용량이나 컴팩션 빈도는 모델별로 체감이 다를 것 같아서, 다른 환경에서는 어떤지 궁금하네요.