# Go fix를 사용해 Go 코드를 현대화하기 > Clean Markdown view of GeekNews topic #26781. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26781](https://news.hada.io/topic?id=26781) - GeekNews Markdown: [https://news.hada.io/topic/26781.md](https://news.hada.io/topic/26781.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-18T21:33:09+09:00 - Updated: 2026-02-18T21:33:09+09:00 - Original source: [go.dev](https://go.dev/blog/gofix) - Points: 7 - Comments: 1 ## Summary Go 1.26에서는 **완전히 새로 구현된 `go fix` 명령어**가 도입되어, 코드베이스를 최신 Go 스타일로 자동 변환할 수 있습니다. 수십 개의 분석기가 구식 패턴을 탐지해 `minmax`, `rangeint`, `stringscut` 같은 **모더나이저**를 적용하며, 여러 번 실행할수록 상호 보완적인 개선이 이어집니다. 또한 Go 팀은 개발자가 직접 분석기를 정의해 배포할 수 있는 **셀프서비스(Self-service) 패러다임**을 예고하며, 언어 진화에 맞춘 자동화된 코드 현대화를 본격화하고 있습니다. ## Topic Body - Go 1.26 버전에서 **완전히 새로 작성된 `go fix` 명령어**가 도입되어, 최신 언어 및 라이브러리 기능을 활용해 코드를 자동으로 개선할 수 있음 - 이 도구는 **수십 개의 분석기(analyzer)** 를 통해 코드 패턴을 탐지하고, `minmax`, `rangeint`, `stringscut` 등 다양한 **모더나이저(modernizer)** 를 적용해 반복적이거나 구식 코드를 최신 형태로 변환함 - 새 기능인 `new(expr)` 지원을 위해 **`newexpr` 분석기**가 추가되어, `newInt` 같은 헬퍼 함수를 자동으로 단순화할 수 있음 - `go fix`는 **여러 번 실행 시 시너지 효과**를 내며, 서로 다른 분석기가 연속적으로 개선을 제안할 수 있고, 충돌 시 자동 병합 및 불필요한 import 제거 기능을 포함함 - Go 팀은 향후 **‘셀프서비스(Self-service)’ 분석 패러다임**을 통해 개발자들이 자체 API용 모더나이저를 정의하고 배포할 수 있도록 확장할 계획임 --- ### go fix 명령어 개요 - Go 1.26에서 `go fix`가 **완전히 새로 구현**되어, 코드베이스를 최신 Go 스타일로 자동 변환하는 기능 제공 - `go fix ./...` 명령으로 현재 디렉터리 이하 모든 패키지를 수정 - `-diff` 옵션으로 변경 사항 미리보기 가능 - 등록된 분석기 목록은 `go tool fix help`로 확인 가능하며, `any`, `forvar`, `mapsloop`, `minmax` 등 다양한 변환 규칙 포함 - 특정 분석기만 실행하려면 `-any` 같은 플래그 사용, 제외하려면 `-any=false` 지정 - 플랫폼별 코드 차이를 고려해 `GOOS`, `GOARCH` 조합별로 여러 번 실행 가능 ### Modernizers — 코드 현대화 도구 - Go 1.18 이후 **제네릭 도입**으로 코드 단순화 가능성이 커짐 - 예: `maps.Keys`로 map 키 수집, `strings.Cut`으로 문자열 분리 - LLM 기반 코드 생성 도구들이 구식 패턴을 유지하는 문제를 해결하기 위해, **최신 Go 관용구를 반영한 오픈소스 코드 갱신 필요성** 강조 - `go fix`와 `gopls`에 포함된 모더나이저는 코드 가독성과 학습 효과를 높임 - 예시 모더나이저: - **minmax**: `if` 문을 `min`/`max` 함수로 대체 - **rangeint**: 3절 `for`문을 `range`-over-int로 변환 - **stringscut**: `strings.Index` 기반 코드를 `strings.Cut`으로 단순화 ### Go 1.26의 new(expr) 기능 - `new` 함수가 **값 인자를 허용**하도록 확장되어, `new("go1.26")` 형태로 초기화 가능 - `newexpr` 분석기가 `newInt` 같은 헬퍼 함수를 찾아 `return new(x)`로 단순화하고, 호출부를 `new(expr)`로 교체 - 최소 Go 버전(예: `go 1.26` 지시문) 충족 시에만 적용 - `$ go fix -newexpr ./...` 명령으로 전체 코드베이스에 적용 가능 - 사용 후 불필요한 헬퍼 함수는 `deadcode` 도구로 식별 가능 ### 시너지 및 충돌 처리 - 한 번의 수정이 다른 수정 기회를 만드는 **시너지 효과** 존재 - 예: `minmax` 적용 후 추가 변환 제안 - `stringsbuilder` → `fmt.Fprintf`로 이어지는 연속 최적화 가능 - `go fix`는 **3-way merge 알고리듬**으로 수정 충돌을 자동 병합 - 구문 충돌 시 수정 건을 건너뛰고 경고 표시 - 의미적 충돌(예: 변수 제거, import 미사용)은 수동 조정 필요 - 불필요한 import는 자동 제거 ### Go 분석 프레임워크 통합 - `go vet`과 `go fix`가 **공통 분석 프레임워크**를 공유하도록 통합 - `vet`은 오류 탐지 중심, `fix`는 안전한 자동 수정 중심 - 분석기는 `unitchecker`, `multichecker`, `gopls`, `staticcheck`, `Tricorder` 등 다양한 드라이버에서 실행 가능 - **팩트(fact)** 시스템을 통해 패키지 간 정보 공유 가능 - 예: `log.Printf`가 `fmt.Printf`의 래퍼임을 추론 - `gopls`는 실시간 진단 및 자동 수정 제안 기능 제공 ### 분석 인프라 개선 - **inspector 패키지** 확장으로 AST 탐색 효율 향상, `Cursor` 타입으로 상하좌우 탐색 지원 - **typeindex**를 통한 함수 호출 인덱싱으로 분석 속도 최대 1000배 향상 - 추가 개선 사항: - 표준 라이브러리 **의존성 그래프** 제공 - 파일별 **Go 버전 쿼리** 지원 - **리팩터링 프리미티브** 확충으로 주석 처리 등 안전한 코드 수정 가능 - 일부 모더나이저는 미묘한 동작 변화로 제외됨 (`append([]string{}, slice...)` → `slices.Clone(slice)` 사례) - 향후 **패턴 매칭 엔진**, **자동 테스트 하네스**, **정확한 수정 연산자 라이브러리** 개발 예정 ### Self-service 패러다임 - Go 1.26부터 **셀프서비스 분석 모델** 도입 예고 - 개발자가 자체 API용 모더나이저를 정의하고 배포 가능 - 중앙화된 승인 절차 없이 프로젝트 수준에서 실행 가능 - 첫 단계로 **주석 기반 인라이너(Annotation-driven inliner)** 기능이 미리보기 형태로 포함 - 향후 계획: - **동적 로딩**을 통한 사용자 정의 분석기 실행 (`go fix` 또는 `gopls` 내) - **제어 흐름 기반 체크 일반화**, 예: “open 후 close”, “lock 후 unlock” 등 불변 조건 검증 - 목표는 유지보수 효율 향상과 최신 Go 기능의 빠른 도입 지원 ## Comments ### Comment 51345 - Author: neo - Created: 2026-02-18T21:33:09+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47049479) - 2024년 말 LLM 코드 어시스턴트가 급속히 확산될 때, 이런 도구들이 학습 데이터의 **기존 Go 코드 스타일**을 그대로 재현하는 경향이 있다는 점이 흥미로웠음 최신 문법을 쓰라고 지시해도 무시하거나, 심지어 존재하지 않는다고 부정하는 경우도 있었음 앞으로의 모델이 최신 **Go 1.25 관용구**를 반영하려면, 오픈소스 코드 전체가 그 스타일로 업데이트되어야 함 - PHP도 예전에 Stack Overflow의 **낡은 조언**(예: magic_quotes)을 정리하려는 시도가 있었음 하지만 LLM은 한 번 잘못된 데이터가 들어가면 수정이 거의 불가능함 모델이 어떤 근거로 결론을 내렸는지 추적하기 어렵고, 차기 모델에서 수정되길 바라는 수밖에 없음 - LLM이 생성하는 **Go 동시성 코드**는 특히 위험함 단순해 보여서 리뷰를 통과하지만, 실제로는 에러 처리와 엣지 케이스가 빠져 있음 리뷰 후 LLM에 다시 넣으면 겉보기엔 수정된 코드가 나오지만, 그 안에 **데이터 레이스**나 **데드락**이 생김 거의 모든 모델에서 반복되는 문제임 - 나도 이런 문제를 자주 겪었음 Go는 하위 호환성이 좋아서 컴파일은 되지만, 코드 스타일이 너무 달라짐 Python은 API 변경으로 실제 **호환성 깨짐**이 발생함 그래도 Go는 언어 안정성과 표준 라이브러리 덕분에 **코드 생성용 언어**로는 매우 훌륭함 - LLM 사용은 결국 **획일적이고 평범한 코드**를 양산하게 될 것임 - LLM으로 코드를 작성하는 발상 자체를 버려야 한다고 생각함 Rob Pike의 경고처럼, 이런 기술은 **소프트웨어 생태계의 오염**임 많은 사람들이 ‘편리함’이라는 **슬롭(slop)** 을 원하지만, 그게 문제의 본질임 - 소스 코드를 자동으로 **최신 스타일로 변환**해주는 도구는 정말 멋짐 Java의 OpenRewrite가 대표적이지만, 다른 언어에는 비슷한 게 잘 떠오르지 않음 Go처럼 이런 기능이 언어에 내장되어 있다면 **언어 성숙도**가 크게 높아짐 앞으로 새 언어들이 Go의 이런 통합적 접근을 참고할 것 같음 - C 언어에는 **Coccinelle**이 있고, [2009년 LWN 기사](https://lwn.net/Articles/315686)에서도 소개됨 JetBrains IDE들은 수백만 줄의 코드를 한 번에 **리팩터링**하거나 새 문법으로 자동 변환할 수 있음 [ConvertToPrimaryConstructor](https://www.jetbrains.com/help/rider/ConvertToPrimaryConstructor.html) 같은 기능도 있음 또 [Structural Search and Replace](https://www.jetbrains.com/help/idea/structural-search-and-replace.html)는 단순 텍스트가 아닌 **언어 구문 수준**에서 작동함 .NET의 Roslyn 분석기도 IDE에서 코드 수정 제안을 제공함 [튜토리얼 링크](https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/tutorials/how-to-write-csharp-analyzer-code-fix#write-the-code-fix) - Rust의 **clippy**는 최신 문법을 권장하고 일부는 자동 수정도 가능함 덕분에 코드가 훨씬 깔끔해졌음 - Haskell의 **hlint**도 오래전부터 존재했음 `concat`과 `map`을 `concatMap`으로 바꾸거나, 불필요한 `if` 표현을 단순화해줌 - TypeScript 코드베이스를 이런 식으로 변환해본 사람 있는지 궁금함 LSP 서버는 기능이 부족하고, 인자 제거 같은 기본 리팩터링도 지원 안 함 **jscodeshift**나 **Claude**를 조합하면 가능할지 고민 중임 - 이런 **자동 수정 도구(go fix)** 덕분에 Go는 정말 뛰어난 언어임 새 기능인 rangeint도 go fix로 자동 반영될 예정이라 기대됨 Go 팀에게 찬사를 보냄 - 다른 언어를 쓰고 싶을 때도 많지만, Go의 **빌드·테스트·린트 도구**가 너무 좋아서 결국 Go를 쓰게 됨 컴파일 속도도 믿을 수 없을 만큼 빠름 - 예전엔 직접 정규식으로 `for` 루프를 찾아 수정했는데, 이제는 이 도구가 훨씬 **세련된 방식**으로 처리해줌 - 기사에는 언급되지 않았지만, 내가 가장 좋아하는 기능은 `//go:fix inline` 지시어임 한 줄짜리 함수를 호출자에 **인라인**으로 삽입해줌 라이브러리 작성자가 구버전 함수를 새 버전으로 자연스럽게 **자동 마이그레이션**할 수 있게 해줌 semver가 달라져도 `go fix`로 자동 업그레이드가 가능함 - 최근 본 [Wes McKinney 팟캐스트](https://www.youtube.com/watch?v=1VfzDXeQRhU)에서 Go가 **빠른 컴파일-실행 주기**, **강한 타입 시스템**, **멀티스레드 안정성** 덕분에 **코딩 에이전트**에 이상적이라고 함 그 말 듣고 Go에 다시 흥미가 생김 - Go의 확립된 **도구 체계와 관습**은 에이전트 기반 개발에 큰 도움이 됨 `go run main.go`로 개발 환경을 바로 띄우고, 여러 워크트리와 중앙 설정, 마이그레이션된 DB까지 지원함 [housecat-inc/cheetah](https://github.com/housecat-inc/cheetah)에서 이런 툴을 공유함 `go generate`, `go build`, `go test`, `go vet`까지 포함된 빠른 루프에 `go fix`를 추가할 생각임 - **초고속 컴파일 속도**는 LLM 반복 실험에도 큰 이점임 - Python을 배우다 보니 같은 일을 하는 방법이 **너무 많고 일관성이 없음** C처럼 한 가지 방식만 있는 게 오히려 그립더라 Go는 이런 단계에 도달했는지 궁금함 LLM 도움 없이도 **베스트 프랙티스**를 따를 수 있는 언어인지 알고 싶음 - Go는 꽤 **의견이 분명한 언어**라 대부분 한 가지 방식만 있음 복잡하지 않고 단순함을 유지하려는 노력이 인상적임 Python의 혼란스러움에 지친 사람에게 추천함 - **Self-service analyzer** 개념이 정말 흥미로움 대형 라이브러리나 인프라 팀에서 적극 활용될 것 같음 - 이런 도구가 있다면 **하위 호환성 없는 언어**도 가능하지 않을까 하는 생각이 듦 - TypeScript 세계에서는 **biome**이 이런 역할을 함 예를 들어 `forEach` 대신 `for...of`를 권장하고, **ultracite**와 함께 쓰면 워크플로우가 훨씬 매끄러워짐 `agents.md` 파일에 “수정 후 biome fix 실행”을 명시해두었고, 덕분에 코드 품질이 자동으로 유지됨 eslint보다 훨씬 **가볍고 효율적인 경험**임