micro-editor/micro — Go 기반 터미널 텍스트 에디터

원문: micro-editor/micro · 조사 기준: master / 756bcc183d89fd9a00d948e450262a92ad0d3c66 · 조사일: 2026-08-30

핵심 요지

micro-editor/micro는 AI 에이전트나 GUI IDE가 아니라, 터미널에서 바로 실행하는 Go 기반 텍스트 에디터다.[1][6]

README는 이를 “modern and intuitive terminal-based text editor”이자 설치 의존성이 없는 batteries-included 단일 정적 바이너리로 소개한다.[6] README는 nano의 후계자에 가까운 쉬운 사용성을 목표로 설명한다.[6]

소스는 github.com/micro-editor/micro/v2 Go module이며 MIT 라이선스다.[7][8]

따라서 제품의 “의존성 없음”은 배포된 사전 빌드 바이너리의 사용 경험에 관한 표현으로 읽어야 한다.[6] 소스 빌드 자체는 Go module 의존성을 다운로드한다.[8][9]

핵심 가치는 작은 실행면, 마우스·탭·분할 창·구문 강조·diff gutter·자동완성·영속 undo·lint 알림·Lua plugin을 하나의 터미널 앱에 묶은 점이다.[6][19]

README는 130개가 넘는 언어의 syntax highlighting도 제공한다고 설명한다.[6][32]

재현 가능한 조사 범위

2026-08-30 공개 GitHub REST metadata snapshot에서 저장소는 public, 기본 브랜치 master, Go, MIT, non-archived로 확인됐다. 당시 지표는 29,469 stars, 1,353 forks, 986 open issues였으며, 이 수치는 변하는 운영 지표이지 품질 보증이나 조사 기준이 아니다.[2]

최신 공개 release는 v2.0.15 / 2.0.15이고 2025-12-31 12:02:53 UTC에 공개됐다.[3][4]

해당 tag commit은 6a62575bcfdf4965f187eedafceb3400316e612b이다.[4][5] 이번에 고정한 master HEAD는 그 release commit 이후 76개 commit인 756bcc183d89fd9a00d948e450262a92ad0d3c66이다.[5]

git ls-remote https://github.com/micro-editor/micro.git refs/heads/master와 local checkout HEAD가 일치하는 것을 확인했다.[5]

git describe --match 'v[0-9]*'는 v2.0.15-76-g756bcc18을 반환했다.[5] pinned checkout을 make build한 결과의 개발 버전은 2.0.16-dev.76이었다.[41]

이번 raw capture는 전체 repository mirror가 아니라 README·라이선스·module/build·CI/release·startup/config·buffer·plugin/Lua·shell·highlight·runtime help·내장 plugin 예시를 담은 38개 선택 파일이다.[5]

38/38개 commit-pinned raw URL이 HTTP 200, local과 동일한 byte 수, SHA-256을 보였고, raw body SHA-256은 5ab10c16a353c92b047d37b642b52801222d37c31eae0bc8ee38d55d5cda80dc이다.[5]

선택하지 않은 전체 syntax corpus·generated header와 binary artifact는 raw 문서에 복사하지 않았다.[5] pinned checkout inventory 자체는 tracked file 335개, Go 파일 95개, _test.go 파일 12개, Lua 파일 7개, runtime/syntax의 YAML 정의 158개로 확인했다.[5]

사용자 표면

README가 약속하는 기본 표면은 터미널 편집에 필요한 기능을 한 바이너리에 넣는 것이다.[6]

mouse support에는 drag selection, double-click word selection, triple-click line selection이 포함된다.[6]

cross-platform 실행·Lua plugin·내장 plugin manager·diff gutter·간단한 autocomplete·persistent undo·자동 lint 알림·color scheme도 함께 제시된다.[6]

구문 강조는 pkg/highlight의 region/state·line match 모델로 구현된다.[32]

highlighter는 줄마다 색상 변경 지점을 기록하고, multi-line region이 다음 줄에 이어지는 상태를 유지하는 구조다.[32]

CLI는 -version, -config-dir, -options, -debug, -profile, -plugin, -clean, 반복 가능한 -exec를 제공한다.[12][34]

파일을 열 때 +LINE[:COL] 또는 +/REGEX로 초기 위치·검색식을 지정할 수도 있다.[12]

plugin 관련 CLI 명령은 install, remove, update, search, list, available이다.[17][34]

실제 command registry에도 set, toggle, run, bind, save, replace, vsplit, hsplit, tab, help, term, textfilter 등이 등록돼 있다.[17]

사용자 설정은 settings.json과 bindings.json으로 나뉜다.[22][23]

bindings.json은 command, buffer, terminal pane별 map과 JSON5 파서를 사용해 키·마우스·raw escape sequence를 재정의한다.[16][35]

옵션 help에는 tab size, autosave, backup, syntax, colorscheme, statusline 등 설정 가능한 값과 기본값이 정렬되어 노출된다.[36]

내부 구조와 데이터 흐름

핵심 경로는 다음과 같이 읽을 수 있다.

flags/input → config/runtime files → tcell screen → Tabs/BufPane → Buffer/LineArray/EventHandler → Lua callbacks·jobs·shell

cmd/micro/micro.go는 flag와 입력 파일·line/column·regex를 해석하고, 설정·runtime·screen·action 계층을 연결한다.[12]

화면 계층은 tcell/v2 기반 terminal screen을 사용한다.[29]

pane/tab 구조는 여러 buffer와 split/tab 전환을 편집 command에 연결한다.[14][15][18]

runtime 자료는 internal/config/rtfiles.go의 //go:embed로 colorschemes, help, plugins, syntax를 binary에 포함한다.[27]

runtime/runtime.go와 Makefile의 go generate ./runtime 단계가 source tree의 runtime 자료와 generated syntax header를 build 경로에 연결한다.[9][33]

buffer 계층은 line array·cursor·path·settings를 관리한다.[19]

event handler는 insert/delete와 undo/redo 기록을 처리한다.[20]

backup 계층은 설정된 backup directory에 주기적으로 저장하고, crash나 저장 오류로 남은 backup을 recover·ignore·abort 선택지로 복구하게 한다.[21]

BufPane는 buffer와 화면 pane을 결합한다.[15]

command registry와 tab list는 파일 열기·저장·검색·replace·split·terminal·plugin 작업을 같은 action 표면으로 보낸다.[14][17][18]

Plugin·runtime 설계

plugin은 ~/.config/micro/plug 아래 디렉터리로 설치한다.[37]

각 plugin에는 적어도 하나의 Lua 파일과 repo.json이 있어야 한다.[37]

문서화된 lifecycle callback은 init(), 전체 plugin 초기화 후의 postinit(), unload/reload 시의 deinit(), buffer open 시의 onBufferOpen(buf) 등이다.[37]

plugin은 help·colorscheme·syntax·runtime file도 추가할 수 있다.[37]

설정의 pluginchannels·pluginrepos에서 channel/repository URL을 읽고, plugin manager는 JSON5 metadata, semver version, dependency range를 모아 설치 가능성을 resolve한다.[23][24][26]

command layer는 이를 install/update/remove/list/search/available 명령으로 노출한다.[17][26]

설치 구현은 plugin version URL을 http.Get으로 내려받아 메모리에 읽고 zip.NewReader로 푼 뒤 ConfigDir/plug/<plugin>에 파일을 생성한다.[25]

현재 구현은 plugin archive의 URL·version metadata를 소비하지만, 이 경로에서 checksum/signature 검증을 수행하는 코드는 확인되지 않는다.[25]

이번 isolated HOME의 ./micro -plugin list 실행 결과에는 autoclose, comment, diff, ftoptions, linter, literate, status 7개 built-in plugin이 표시됐다.[5]

선택 capture에는 autoclose, comment, linter의 실제 Lua 파일도 포함했다.[38][39][40]

보안 경계와 도입 주의점

Lua plugin은 sandbox가 아니다.[13][28]

cmd/micro/initlua.go는 micro/shell에 ExecCommand, RunCommand, RunBackgroundShell, RunInteractiveShell, JobStart, JobSpawn, JobStop, JobSend를 노출한다.[13][30]

Lua bridge는 editor pane·buffer·config·runtime 파일에도 접근하게 한다.[13]

더 낮은 계층의 Lua import에는 os, net, net/http, io/ioutil, archive/zip과 파일·프로세스 조작 함수가 등록돼 있다.[28]

따라서 설치·활성화한 plugin은 편집기와 같은 사용자 권한의 trusted code로 취급해야 한다.[28][31]

AI agent가 자동으로 plugin을 설치·실행하도록 연결할 때도 별도 승인·검토·격리 계층이 필요하다.[28][31]

정적 코드 검토상 DownloadAndInstall은 zip entry 이름을 filepath.Join으로 target path에 결합한다.[25]

선택한 함수 안에는 ../absolute path containment를 확인하는 명시적 검사가 보이지 않는다.[25]

이는 이 조사에서 보고된 CVE가 아니라 현재 source의 검토 관찰이다.[25]

신뢰하지 않는 plugin archive를 설치하지 말고, 설치 전 archive·URL·target path를 검토하는 편이 안전하다.[25]

-clean과 plugin remove/update는 설정 디렉터리와 plugin 파일을 변경하는 state-changing 명령이다.[12][34]

특히 UninstallPlugin은 plugin directory를 os.RemoveAll로 삭제하므로, 자동화에서는 대상 config directory와 plugin 이름을 먼저 표시하고 사람 승인을 거치는 운영 계약이 적절하다.[25]

Build·CI·release surface

Makefile의 일반 Linux build는 먼저 go generate ./runtime을 실행한다.[9]

그 뒤 version·commit hash·compile date를 linker flag로 주입하고 CGO_ENABLED=0 go build -trimpath -ldflags "-s -w ..." ./cmd/micro를 수행한다.[9][41]

macOS 분기에서는 native build를 위해 cgo와 추가 plist linker flag를 사용하는 예외가 있다.[9]

공개 CI는 Go 1.19.x와 1.23.x를 Ubuntu·macOS·Windows matrix로 조합한다.[10]

CI는 make build와 make test를 실행한다.[10]

release workflow는 현재 자동 tag trigger가 주석 처리된 manual workflow_dispatch다.[11]

release workflow는 tools/cross-compile.sh로 binaries/*를 만든 뒤 GitHub Release에 업로드하도록 되어 있다.[11][42]

이 release workflow와 target OS artifact는 이번 Linux checkout에서 실행하지 않았다.[11][42]

이번 환경에서 실행한 검증

검증	실제 결과
source pin	성공 — local `master` HEAD와 public `refs/heads/master`가 `756bcc183d89fd9a00d948e450262a92ad0d3c66`로 일치
selected raw manifest	성공 — 38/38 HTTP 200·byte·SHA-256 일치, errors 0
citation strict	성공 — 87 prose sentence 중 69 cited (79%), distinct source 42/42
`make build`	성공 — 격리 Go 1.23.12 linux/arm64, `CGO_ENABLED=0` build
`make test`	성공 — internal 및 cmd test와 Makefile의 gofmt gate 통과
`go test ./...`	성공 — 테스트가 있는 `cmd/micro`, `internal/buffer`, `internal/config`, `internal/util`, `internal/views` 및 runtime package를 통과; 나머지는 compile/no-test package
`gofmt -l`	성공 — unformatted Go file 0개
`./micro -version`	성공 — `Version: 2.0.16-dev.76`, `Commit hash: 756bcc18`, `Compiled on August 30, 2026` 출력
`./micro -options`	성공 — 150 lines 출력, `tabsize` option marker 확인
`./micro -plugin list`	성공 — 7개 built-in plugin 목록 출력
`go vet ./...`	실패/비차단 관찰 — 37 warnings: unkeyed composite literal 31건, copylocks 6건

go vet 결과는 build/test 실패가 아니라 현재 main의 정적 품질 debt다. 특히 buffer.Line의 mutex copy 경고와 Loc·SLoc 등의 unkeyed literal 경고가 남아 있으므로, 새 기능을 올릴 때 vet clean을 별도 품질 목표로 삼을 만하다.

실행하지 않은 항목은 Go 1.19 matrix 재실행, interactive TTY에서의 화면·mouse·clipboard QA, Windows/macOS 실제 runtime, remote plugin install/update, 악성 zip archive test, release cross-compile artifact와 package manager 설치다. 이 결과는 Linux arm64에서의 source build·unit/package test·CLI smoke 범위로만 해석했다.

평가와 도입 가이드

강점. SSH/remote host에서도 배포하기 쉬운 단일 binary, 낮은 인지 비용의 CLI, mouse·tab·split·persistent undo·backup·syntax·plugin을 한 실행면에 둔 점이 명확하다. source build도 runtime asset을 embed하고 version 정보를 넣으므로, release binary와 같은 기본 경로를 재현하기 쉽다.[6][9][27]

한계. 이 프로젝트의 중심은 terminal editor이지 LSP 중심 IDE나 AI coding agent가 아니다. rich IDE navigation, language server orchestration, project-wide refactor, GUI accessibility가 필요하면 별도 도구를 함께 선택해야 한다. 이는 “기능이 없다”는 보편적 결론이 아니라 README와 source surface가 약속하는 범위에 대한 도입 판단이다.[6][12]

운영 순서. 먼저 공식 release와 pinned source 중 어느 것을 쓸지 결정하고, Linux에서는 checksum이 확인된 배포 binary 또는 source build를 선택한다. plugin은 trusted source만 설치하고, pluginchannels·pluginrepos를 검토한 뒤 archive와 Lua code를 읽는다. AI agent workflow에 연결할 때는 plugin install/remove/update를 자동화하지 말고 config backup·human approval·명시적 target path를 앞에 둔다.[25][28]

관련 개념은 moc-dev-tools, moc-ai-coding에서 함께 볼 수 있다.

Sources

description	Go로 구현한 단일 정적 바이너리·Lua 플러그인·구문 강조를 제공하는 크로스플랫폼 터미널 텍스트 에디터.
tags	dev-tools, ai-coding, golang, cli, open-source
aliases	Micro, micro editor, 마이크로 에디터

LLM Wiki

탐색기