Claude Code 복제품이 아니다: IDE와 디버거를 연결한 오픈소스 코딩 에이전트 OMP

최근 공개된 터미널 코딩 에이전트 가운데 꽤 흥미로운 프로젝트가 있습니다.

Oh My Pi, 줄여서 OMP입니다.

OMP 공식 사이트는 이 프로젝트를 다음과 같이 소개합니다.

A coding agent with the IDE wired in.
IDE가 연결된 코딩 에이전트.

이 문장이 OMP의 특징을 가장 잘 설명합니다.

OMP는 터미널에서 AI와 대화하고 파일을 수정하는 데 그치지 않습니다. IDE가 사용하는 **LSP(Language Server Protocol)**와 실제 디버거를 에이전트에 연결해, 코드의 구조와 프로그램이 실행되는 순간의 상태까지 조사할 수 있도록 만든 오픈소스 코딩 에이전트입니다.

공식 GitHub 저장소에 소스가 공개돼 있으며 라이선스는 MIT입니다.

OMP의 핵심 기능

• LSP를 이용한 심볼 정의·참조·구현 탐색

• 심볼 단위 rename과 코드 진단

• AST 기반 코드 검색과 수정

• DAP 기반 실제 디버거 연결

• 브레이크포인트·호출 스택·변수 상태 조사

• Git worktree로 격리할 수 있는 서브에이전트

• OpenAI·Anthropic·Google 계열 및 로컬 모델 구성

• 셸·브라우저·데스크톱·SSH 작업 지원

OMP의 차별점은 단순히 어떤 AI 모델을 사용하는가에 있지 않습니다. AI가 코드를 이해하고 실행 상태를 확인하기 위해 어떤 개발 도구를 사용할 수 있는가에 있습니다.

텍스트 검색이 아니라 코드의 의미를 탐색한다

일반적인 AI 코딩 도구는 파일을 읽고 문자열을 검색한 뒤, 주변 문맥을 바탕으로 코드를 수정합니다.

작은 프로젝트에서는 이 방식도 잘 작동하지만 코드베이스가 커지면 문제가 생길 수 있습니다.

• 이름이 같은 다른 심볼을 혼동할 수 있습니다.

• 함수의 실제 호출 위치를 놓칠 수 있습니다.

• 문자열 치환 과정에서 관련 없는 코드까지 바꿀 수 있습니다.

• 수정 후 발생한 타입 오류와 진단 결과를 충분히 확인하지 못할 수 있습니다.

OMP는 LSP를 이용해 언어 서버가 알고 있는 코드 정보를 조회합니다.

• 심볼이 정의된 위치

• 해당 심볼을 참조하는 모든 코드

• 인터페이스의 실제 구현체

• 타입과 hover 정보

• 컴파일 및 정적 진단

• 코드 액션

• 심볼 단위 rename

예를 들어 C 프로젝트에서 함수 이름을 바꾼다고 가정해보겠습니다.

단순 문자열 치환은 주석이나 같은 이름의 다른 텍스트까지 변경할 수 있습니다. 반면 clangd와 연결된 LSP rename은 언어 서버가 식별한 실제 심볼과 참조를 기준으로 변경합니다.

OMP는 AST 기반 구조 검색과 수정도 지원합니다. 텍스트가 어떻게 배치돼 있는지가 아니라, 코드가 어떤 문법 구조로 구성됐는지를 기준으로 찾고 바꾸는 방식입니다.

AI가 코드를 읽고 추측하는 데서 그치지 않고, IDE가 알고 있는 코드의 의미를 직접 질의합니다.

실제 디버거까지 에이전트에 연결한다

OMP에서 특히 눈에 띄는 부분은 실제 디버거를 연결한다는 점입니다.

대부분의 코딩 에이전트는 다음 과정으로 오류를 해결합니다.

1. 코드를 수정합니다.

2. 테스트나 프로그램을 실행합니다.

3. 터미널에 출력된 오류 메시지를 읽습니다.

4. 원인을 추측해 다시 수정합니다.

오류 원인이 로그에 명확하게 나타난다면 이 방식으로도 충분할 수 있습니다. 하지만 세그멘테이션 폴트, 메모리 상태에 따라 달라지는 오류, 특정 호출 순서에서만 발생하는 문제는 로그만으로 추적하기 어렵습니다.

OMP는 **DAP(Debug Adapter Protocol)**를 이용해 실제 디버거를 에이전트에 연결합니다. 관련 문서에서 다루는 디버깅 환경에는 C·C++ 계열의 GDB·LLDB, Python의 debugpy, Go의 Delve 등이 포함됩니다.

에이전트는 다음과 같은 실행 상태를 직접 조사할 수 있습니다.

• 브레이크포인트 설정

• 프로그램 실행과 중단

• 단계별 코드 실행

• 현재 호출 스택 확인

• 지역·전역 변수 조사

• 스레드 상태 확인

• 예외와 크래시 발생 위치 추적

• 특정 표현식의 실행 시점 값 평가

예를 들어 포인터 오류가 발생했다면 크래시 메시지만 읽고 원인을 추측하는 데서 끝나지 않습니다. 문제가 발생하는 위치에 브레이크포인트를 설정하고, 호출 스택과 포인터 값을 확인한 뒤, 원인으로 의심되는 코드를 수정하고 다시 실행할 수 있습니다.

가설 수립 → 브레이크포인트 설정 → 실행 상태 관찰 → 원인 추적 → 코드 수정 → 재실행 → 검증

소프트웨어 개발의 본질은 코드를 작성하는 데만 있지 않습니다. 프로그램의 실행 결과를 관찰하고, 잘못된 가설을 수정하며, 다시 검증하는 과정도 중요합니다.

LSP와 디버거의 결합이 중요한 이유

LSP와 디버거는 서로 다른 정보를 제공합니다.

LSP가 제공하는 정적 정보

• 이 함수는 어디에 정의됐는가?

• 어느 코드가 이 심볼을 참조하는가?

• 타입이나 문법 오류가 있는가?

• 이름을 변경하면 어디까지 영향을 받는가?

디버거가 제공하는 동적 정보

• 실제로 어느 조건문과 분기를 통과했는가?

• 크래시 직전 변수 값은 무엇인가?

• 어떤 호출 경로를 거쳐 현재 함수에 도달했는가?

• 어느 스레드에서 예외가 발생했는가?

두 도구가 결합되면 에이전트는 코드의 정적 구조와 실제 런타임 상태를 함께 볼 수 있습니다.

OMP를 단순한 터미널 챗봇이 아니라 IDE와 디버거가 연결된 개발 에이전트로 봐야 하는 이유입니다.

서브에이전트는 별도의 Git worktree에서 작업할 수 있다

OMP는 복잡한 업무를 여러 서브에이전트에 나눠 맡길 수 있습니다.

중요한 점은 여러 프롬프트를 동시에 실행하는 것만이 아닙니다. 서브에이전트의 작업을 별도의 Git worktree로 격리할 수 있다는 점입니다.

예를 들어 하나의 기능 개발을 다음과 같이 나눌 수 있습니다.

• 에이전트 A: 기존 아키텍처와 관련 코드 분석

• 에이전트 B: 기능 구현

• 에이전트 C: 테스트 작성

• 에이전트 D: 오류 재현과 디버깅

• 에이전트 E: 변경 내용 리뷰

각 에이전트가 독립된 작업 공간에서 일하면 같은 파일을 동시에 덮어쓰는 문제를 줄일 수 있습니다. 완료된 결과를 검토한 뒤 메인 작업 공간에 반영하는 것도 가능합니다.

멀티 에이전트 시스템에서 중요한 것은 에이전트의 숫자가 아닙니다. 작업을 어떻게 격리하고 결과를 어떻게 검증·통합하는가가 더 중요합니다.

역할별로 서로 다른 AI 모델을 배치할 수 있다

OMP는 특정 모델 공급자 하나에 종속된 구조를 지향하지 않습니다.

OpenAI, Anthropic, Google 계열 모델을 비롯해 여러 공급자와 로컬 모델을 연결할 수 있습니다. 사용자 정의 에이전트마다 서로 다른 모델과 도구를 배치하는 구성도 가능합니다.

• 코드베이스 탐색: 빠르고 비용이 낮은 모델

• 아키텍처 설계: 추론 능력이 높은 모델

• 코드 구현: 코딩 성능이 검증된 모델

• 코드 리뷰: 구현에 사용하지 않은 다른 모델

• 민감한 코드 분석: 외부 전송을 줄일 수 있는 로컬 모델

모든 작업에 가장 비싼 모델을 사용하는 대신 역할별로 적합한 모델을 배치하는 방식입니다. 비용을 조절할 수 있고 서로 다른 모델이 결과를 교차 검토하도록 구성할 수도 있습니다.

다만 모델을 여러 개 연결한다고 자동으로 품질이 높아지는 것은 아닙니다. 작업 범위, 전달할 문맥, 완료 기준과 검증 절차가 불분명하면 여러 에이전트가 비슷한 실수를 반복하거나 서로 충돌할 수 있습니다.

임베디드와 OpenWrt 개발에서 흥미로운 이유

OMP의 구조는 웹 서비스 개발에도 유용하지만, 임베디드와 OpenWrt 개발 관점에서도 상당히 흥미롭습니다.

임베디드 개발에서는 보통 다음과 같은 도구와 환경을 오가야 합니다.

• 대규모 C·C++ 코드베이스

• Make·CMake·OpenWrt 빌드 시스템

• 크로스 컴파일러와 SDK

• clangd 등 정적 분석 환경

• 실제 테스트 장비와 SSH

• gdbserver와 원격 GDB

• 코어 덤프와 크래시 로그

• 호스트와 장비 사이의 파일 전송

OMP의 도구를 연결하면 다음과 같은 개발 과정을 하나의 에이전트 루프로 구성할 가능성이 있습니다.

1. OpenWrt·C 코드 분석

에이전트가 코드베이스를 읽고 관련 패키지, 함수, 설정 파일과 빌드 규칙을 찾습니다.

2. clangd 기반 참조 추적

문자열 검색에만 의존하지 않고 함수 정의와 실제 참조 관계를 추적합니다. 구조체와 매크로가 많이 사용되는 C 프로젝트에서 특히 유용할 수 있습니다.

3. 크로스 빌드 오류 수정

OpenWrt SDK나 기존 빌드 환경에서 대상 아키텍처용 바이너리를 빌드합니다. 오류가 발생하면 컴파일러 진단과 관련 심볼을 함께 조사해 코드를 수정합니다.

4. SSH를 통한 원격 장비 접근

테스트 장비에 접속해 바이너리와 설정 파일을 배포하고 실제 환경에서 프로그램을 실행합니다.

5. GDB를 이용한 크래시 추적

장비에서 gdbserver를 실행하거나 코어 덤프를 확보한 뒤 호스트의 크로스 GDB를 연결합니다. 에이전트는 브레이크포인트, 호출 스택과 변수 상태를 조사합니다.

6. 코드 수정과 재검증

관찰한 실행 상태를 근거로 코드를 수정하고 다시 빌드·배포·실행해 문제가 해결됐는지 확인합니다.

OpenWrt·C 코드 분석 → clangd 참조 추적 → 크로스 빌드 → SSH 배포 → GDB 디버깅 → 수정·재검증

각각의 도구가 새로운 것은 아닙니다. clangd, SSH, GDB와 크로스 컴파일러는 오래전부터 사용해온 도구입니다.

새로운 점은 하나의 에이전트가 여러 도구의 결과를 연속적으로 관찰하고 다음 행동을 결정할 수 있다는 것입니다.

OpenWrt 환경이 자동으로 완성되는 것은 아니다

여기서 주의할 점이 있습니다.

OMP가 OpenWrt 전용 개발 환경이나 원격 GDB 설정을 자동으로 완성해준다는 의미는 아닙니다. OMP의 LSP·셸·SSH·디버거 구조를 OpenWrt 개발 과정에 활용할 가능성이 있다는 뜻에 가깝습니다.

실제 적용을 위해서는 다음 환경을 별도로 준비해야 합니다.

• 대상 아키텍처에 맞는 크로스 툴체인

• clangd가 읽을 수 있는 compile_commands.json

• 정확한 헤더와 sysroot 경로

• 디버그 심볼을 포함한 바이너리

• 타깃 장비의 SSH 접속 환경

• gdbserver 또는 코어 덤프 수집 환경

• 호스트와 타깃의 소스 경로 매핑

• 네트워크·포트·계정 권한 정책

특히 OpenWrt처럼 빌드 플래그와 생성 파일이 많은 프로젝트에서는 컴파일 데이터베이스가 정확하지 않으면 LSP의 진단과 참조 탐색도 부정확해질 수 있습니다.

OMP는 기존 개발 환경을 대체하는 제품이라기보다, 잘 구성된 개발 도구를 AI가 사용할 수 있게 만드는 상위 실행 계층으로 보는 편이 정확합니다.

셸을 넘어 브라우저·데스크톱·SSH까지 다룬다

OMP는 코드 편집과 로컬 셸에만 머물지 않습니다. 공식 사이트는 브라우저, 데스크톱과 SSH를 활용하는 작업도 제시합니다.

• 웹 문서와 이슈 확인

• 브라우저에서 실제 화면 테스트

• 데스크톱 애플리케이션 조작

• 원격 서버와 개발 장비 접속

• 배포 이후 실제 동작 확인

코딩 에이전트가 코드를 수정하는 데서 끝나지 않고 실제 실행 환경까지 다룰 수 있다는 뜻입니다.

하지만 능력이 커진 만큼 에이전트에 허용되는 권한 면적도 넓어집니다.

가장 큰 위험은 넓어진 권한 면적이다

OMP가 셸과 파일 시스템뿐 아니라 브라우저, 데스크톱과 SSH까지 조작한다면 다음과 같은 정보와 시스템에 접근할 수 있습니다.

• 소스코드와 설정 파일

• 환경변수와 API 키

• SSH 키와 원격 서버

• 브라우저 로그인 세션

• 내부 관리 페이지

• 실제 서비스와 데이터베이스

• 임베디드 장비의 시스템 영역

잘못된 명령 하나가 파일 삭제, 운영 환경 변경 또는 비밀정보 유출로 이어질 수 있습니다.

프롬프트 인젝션도 고려해야 합니다. 에이전트가 읽은 웹페이지, README, 이슈 또는 로그에 악의적인 지시가 포함돼 있을 수 있기 때문입니다. 외부 콘텐츠와 도구 출력은 실행할 명령이 아니라 신뢰할 수 없는 데이터로 취급해야 합니다.

OMP에는 승인 정책을 설정하는 기능이 있지만 승인 모드의 존재만으로 안전이 보장되는 것은 아닙니다. 높은 자율성을 부여할수록 실행 환경 자체를 격리해야 합니다.

실사용을 위한 보안 원칙

1. 개발용 컨테이너나 VM에서 실행합니다.

2. 운영 서버와 개발 서버의 인증정보를 분리합니다.

3. SSH 계정과 키에는 최소 권한만 부여합니다.

4. 민감한 환경변수 전달을 최소화합니다.

5. 삭제·배포·권한 변경 명령은 별도 승인을 요구합니다.

6. 접근 가능한 명령, 경로와 네트워크를 제한합니다.

7. 웹과 외부 문서의 내용을 비신뢰 입력으로 처리합니다.

8. 에이전트가 수행한 명령과 변경 내용을 기록합니다.

9. 실제 장비보다 에뮬레이터와 테스트 장비에서 먼저 검증합니다.

코딩 에이전트의 경쟁력이 실제 시스템을 얼마나 잘 다루는지로 이동한다면, 권한 관리와 실행 검증도 핵심 기능이 될 수밖에 없습니다.

일반적인 터미널 코딩 에이전트와 무엇이 다른가?

이 비교가 모든 코딩 에이전트에 똑같이 적용되는 것은 아닙니다. 주요 코딩 에이전트도 LSP, 브라우저와 병렬 작업 기능을 계속 도입하고 있습니다.

그럼에도 OMP가 IDE의 정적 분석과 실제 디버거를 핵심 기능으로 전면에 내세운다는 점은 분명한 특징입니다.

OMP가 보여주는 코딩 에이전트의 다음 단계

OMP가 흥미로운 이유는 또 하나의 Claude Code 대체재가 등장했기 때문만은 아닙니다.

지금까지 많은 코딩 에이전트는 강력한 언어모델에 셸과 파일 편집 도구를 붙이는 데 집중했습니다. OMP는 여기서 한 단계 더 나아가, 개발자가 IDE와 디버거를 통해 얻던 정보를 에이전트의 관찰 수단으로 연결합니다.

• AI 모델은 무엇을 확인하고 다음에 무엇을 할지 판단합니다.

• LSP는 코드의 정적 구조와 진단을 제공합니다.

• 디버거는 프로그램의 실제 실행 상태를 보여줍니다.

• 테스트와 빌드는 수정 결과를 검증합니다.

• Git worktree는 서브에이전트의 병렬 작업을 격리합니다.

더 나은 코딩 에이전트에는 더 큰 모델만 필요한 것이 아닙니다.
코드를 이해하고 실행 상태를 관찰할 수 있는 더 좋은 도구 연결이 필요합니다.

실제 대규모 프로젝트와 임베디드 환경에서 어느 정도까지 안정적으로 작동하는지는 추가 검증이 필요합니다. 멀티 에이전트의 병합 충돌, 언어 서버와 디버거 어댑터의 호환성, 장시간 작업의 상태 관리, 권한 통제도 확인해야 합니다.

그럼에도 OMP는 충분히 주목할 만합니다.

코드를 생성하는 AI에서 한 걸음 더 나아가, 코드를 탐색하고 실행하고 멈춰 세운 뒤 내부 상태를 관찰하며 문제를 수정하는 AI가 어떤 모습일지 보여주기 때문입니다.

핵심 요약

• OMP는 LSP와 실제 디버거를 에이전트에 연결한 오픈소스 터미널 코딩 에이전트입니다.

• 심볼 정의·참조·rename과 AST 기반 코드 수정을 지원합니다.

• DAP 기반 디버거를 통해 브레이크포인트, 호출 스택과 변수 상태를 조사할 수 있습니다.

• 서브에이전트의 작업을 Git worktree로 격리하고 여러 AI 모델을 역할별로 구성할 수 있습니다.

• OpenWrt와 임베디드 개발에서는 코드 분석, 크로스 빌드, SSH, GDB를 연결한 폐쇄 루프를 구성할 가능성이 있습니다.

• 다만 크로스 툴체인, 컴파일 데이터베이스, 디버그 심볼과 원격 디버깅 환경은 별도로 준비해야 합니다.

• 셸·브라우저·데스크톱·SSH까지 다루는 만큼 샌드박스, 최소 권한, 승인 정책과 감사 로그가 중요합니다.

참고 자료

• OMP 공식 사이트 — A coding agent with the IDE wired in

• Oh My Pi 공식 GitHub 저장소

• OMP LSP 도구 문서

• OMP Debug 도구 문서

• OMP Approval Mode 문서

• Better Stack Community — Oh My Pi AI Coding Agent Guide

검토 기준일: 2026년 8월 30일
OMP는 빠르게 개발되는 오픈소스 프로젝트이므로 설치 방법, 지원 도구와 모델 목록은 이후 변경될 수 있습니다. 사용 전 공식 사이트와 GitHub 저장소의 최신 내용을 확인하는 것이 좋습니다.