omp, 터미널 AI 코딩에 LSP와 디버거를 연결했어요

omp, 터미널 AI 코딩에 LSP와 디버거를 연결했어요

omp 터미널 AI 코딩 에이전트 썸네일

터미널 AI 코딩 도구는 빠르지만, 코드 편집기가 알고 있는 심볼 관계나 실시간 진단을 충분히 활용하지 못할 때가 있어요. omp는 오픈소스 코딩 에이전트 Pi를 바탕으로 LSP와 디버거, 코드 리뷰, 작업 분산 기능을 한 TUI 안에 묶었어요. 명령줄의 가벼운 사용감은 유지하면서 IDE에 가까운 코드 이해 도구를 붙인 프로젝트예요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
코드 이해	파일을 쓸 때 LSP 진단과 심볼 정보를 연결해요	문자열 검색만으로 놓치기 쉬운 참조와 이름 변경 범위를 확인할 수 있어요
디버깅	DAP를 통해 실제 디버거를 조작해요	출력문을 추가하는 방식보다 중단점·스택·변수를 직접 조사하기 쉬워요
작업 분산	격리된 작업 공간에서 서브에이전트를 실행해요	여러 조사와 수정 작업을 나누고 구조화된 결과로 받을 수 있어요
진행 표시	읽기·검색·수정·검증 상태를 TUI에 보여줘요	긴 작업이 실행 중인지 멈췄는지 판단하기 쉬워요

1. 터미널 안에서 IDE의 코드 지도를 활용해요

omp는 Mario Zechner가 만든 Pi를 기반으로 확장한 오픈소스 프로젝트예요. 공식 사이트는 40개가 넘는 모델 제공자와 32개 내장 도구를 지원한다고 설명해요. macOS와 Linux, Windows에서 쓸 수 있고 설치 스크립트와 Homebrew, Bun, 사전 빌드 바이너리를 제공해요. 특정 모델 하나에 묶이기보다 사용하는 계정과 환경에 맞춰 코딩 모델을 선택하는 구조예요. 2

핵심은 LSP가 파일 수정 과정에 직접 들어온다는 점이에요. 일반적인 터미널 도구도 파일 검색과 편집은 할 수 있지만, 다른 파일의 참조나 재노출된 심볼, 별칭으로 가져온 모듈까지 함께 바꾸려면 추가 확인이 필요해요. omp는 참조 검색과 심볼 이름 변경, 진단, 정의 이동 같은 LSP 작업을 제공해요. 파일 이름을 바꿀 때는 `workspace/willRenameFiles`를 거쳐 관련 임포트와 배럴 파일도 함께 갱신할 수 있어요.

728x90

출력문 대신 실제 디버거를 다뤄요

DAP 연동도 눈에 띄어요. C 프로그램은 LLDB, Go 서비스는 Delve, Python 프로세스는 debugpy 같은 어댑터를 연결할 수 있어요. 코딩 에이전트가 중단점을 걸고 실행을 멈춘 뒤 스택 프레임과 지역 변수, 표현식 값을 읽는 방식이에요. 오류 위치를 추측해 출력문을 반복해서 넣는 대신 실행 상태를 직접 확인할 수 있어요.

다만 디버거 연동이 곧 정확한 원인 분석을 보장하지는 않아요. 네이티브 바이너리의 디버그 심볼, 실행 권한, 컨테이너 경계처럼 프로젝트 환경에 따라 준비할 항목이 달라져요. 실제 저장소에 적용하기 전에는 언어별 어댑터와 실행 설정이 맞는지 작은 재현 사례로 먼저 확인하는 편이 안전해요.

작업을 나누고 결과를 구조화해요

서브에이전트는 각각 격리된 작업 트리에서 실행할 수 있어요. 조사와 수정 범위를 나눠 동시에 처리하고, 부모 작업에는 스키마로 검증한 결과를 돌려주는 방식이에요. 형제 작업이 같은 파일을 건드려 충돌하는 일을 줄이고, 긴 자유 형식 보고서를 다시 해석해야 하는 부담도 낮춰요.

코드 리뷰 기능은 발견한 문제에 우선순위와 판정을 붙여요. 별도의 검토 모델을 연결하면 주 작업의 각 턴을 살펴보고 참고 의견이나 차단할 문제를 전달할 수도 있어요. 구현과 검토를 분리하고 싶은 팀에는 유용하지만, 리뷰 모델의 판단도 코드와 테스트로 확인해야 해요. 모델을 하나 더 쓰면 호출 비용과 처리 시간도 늘어나요.

무엇을 하는지 화면에서 계속 보여줘요

긴 코딩 작업에서는 결과만큼 현재 상태가 중요해요. omp의 TUI는 파일 읽기, 검색, 편집, 검증, 서브에이전트 실행 상태를 구분해 보여줘요. GeekNews 소개자는 직접 사용했을 때 작업이 멈춘 것인지 실행 중인지 파악하기 쉬웠다고 평가했어요. 1

세션 공유 기능으로 다른 터미널이나 브라우저에서 작업을 함께 볼 수도 있어요. 읽기·쓰기 권한을 준 협업 모드와 보기 전용 모드를 나눠요. 공식 설명에 따르면 전송 프레임은 클라이언트 쪽에서 암호화해 중계 서버가 키를 읽지 못하게 설계했어요. 그래도 회사 코드나 비밀 정보가 있는 세션이라면 공유 링크의 권한과 만료 방식, 조직 보안 정책을 먼저 확인해야 해요. 2

Pi 확장 호환성은 확인이 필요해요

omp는 파일 기반 Skills를 탐색하고 기존 Pi 확장을 함께 쓸 수 있도록 설계됐어요. 하지만 모든 설치 방식과 확장 조합이 안정적인 것은 아니에요. GeekNews에는 npm이나 소스 링크 방식으로 설치했을 때 CommonJS 의존성이 있는 일부 Pi 확장이 로드되지 않는 사례가 함께 소개됐어요. 사전 컴파일 바이너리는 해당 문제의 영향을 받지 않는 것으로 정리돼 있어요. 3

기존 Pi 확장을 많이 쓰고 있다면 현재 설치법을 바로 바꾸기보다 필요한 확장 목록으로 호환성을 먼저 시험해 보는 편이 좋아요. 릴리스 노트와 관련 이슈의 수정 상태도 함께 확인해야 해요. 새 프로젝트라면 LSP 진단, 이름 변경, 디버거 연결처럼 실제로 필요한 기능부터 작은 저장소에서 점검하면 도입 판단이 빨라져요.

왜 중요한가요

AI 코딩 도구가 수정할 수 있는 파일 수보다 더 중요한 것은 변경 범위를 얼마나 정확히 이해하고 검증하느냐예요. LSP는 코드에 이미 존재하는 심볼 관계와 진단을 제공하고, DAP는 실행 중인 프로그램의 상태를 보여줘요. omp는 이 두 표준을 터미널 코딩 흐름에 붙여 모델이 추측에만 기대는 구간을 줄이려 해요. 2

터미널과 IDE 가운데 하나만 골라야 했던 경계도 옅어지고 있어요. 명령줄에서 빠르게 작업하면서 참조 검색과 안전한 이름 변경, 디버깅, 리뷰를 같은 화면에서 처리할 수 있기 때문이에요. 다만 기능이 많아질수록 설치 방식과 확장 호환성, 모델 비용, 세션 공유 권한까지 확인할 항목도 늘어요. omp를 평가할 때는 기능 목록보다 실제 저장소에서 편집 정확도와 진단 처리, 디버거 연결, 기존 Pi 확장 호환성을 차례로 보는 편이 현실적이에요. 1

참고 자료

1. omp - Pi를 IDE 수준으로 확장한 터미널 AI 코딩 에이전트 — GeekNews
2. omp — a coding agent with the IDE wired in — omp 공식 사이트
3. CommonJS dependencies break in linked Pi extensions — GitHub
4. can1357/oh-my-pi — GitHub
5. badlogic/pi-mono — GitHub