코틀린 코드 품질의 시작, ktlint 완벽 정복 가이드: 설정부터 실전 활용까지

https://github.com/teamterning/Terning-Server-Kotlin

기존에 운영하던 자바 프로젝트는 테스트 코드가 없고 코드 스타일이 통일되지 않아 유지보수 비용이 계속해서 증가하는 문제를 안고 있었습니다. 작은 기능 하나를 수정해도, 이 변경이 다른 API에 어떤 영향을 미치는지 파악하기 위해 매번 Postman과 Swagger로 수많은 API를 수동으로 테스트해야 하는 비효율적인 과정이 반복되었습니다.

최근 안드로이드 개발자와의 협업을 통해 서버를 코틀린으로 전환하면서, 저희 팀은 이를 묵혀왔던 기술 부채를 청산할 절호의 기회로 삼았습니다. 여러 개선 과제 중에서도 가장 먼저 해결하고자 했던 두 가지 문제는 바로 (1) 부재했던 테스트 코드 작성과 (2) 일관성 없는 코드 스타일의 통일이었습니다.

이 글에서는 두 번째 문제, 즉 코드 스타일을 해결하기 위해 저희 팀이 ktlint를 도입하고 적용했던 경험을 공유하고자 합니다. ktlint를 통해 팀의 코드 스타일을 성공적으로 통일하며 생산성을 높일 수 있었지만, 때로는 기본 규칙이 오히려 가독성을 해친다고 느껴지는 아쉬운 순간도 있었습니다.

물론 이런 부분은 팀원들과의 논의를 통해 우리 팀만의 컨벤션을 정립하며 해결할 수 있었습니다. 이 과정을 통해 ktlint가 매우 유용한 도구임은 분명하지만, 모든 상황에 맞는 완벽한 만능 해결책은 아니라는 점을 다시 한번 깨달았습니다.

이에 ktlint를 적용하면서 놓치기 쉬운 부분은 무엇인지, 그리고 앞으로 팀의 컨벤션에 맞게 효과적으로 변경하여 사용하는 방법은 무엇인지 등을 학습하고 공유해보고자 합니다.

서론: 우리는 왜 코드 스타일에 대해 논쟁하는가 (그리고 어떻게 멈출 수 있는가)

소프트웨어 개발팀에서 흔히 발생하는 소모적인 논쟁 중 하나로 코드 스타일(Code Style)에 관한 것을 꼽을 수 있습니다. 중괄호({})를 같은 줄에 둘 것인가, 다음 줄로 내릴 것인가와 같은 논쟁은 종종 '자전거 보관소 효과(bikeshedding)'에 비유되곤 합니다. 이는 중요한 핵심 문제보다 사소하고 비본질적인 문제에 더 많은 시간과 에너지를 쏟는 현상을 의미한다고 알려져 있습니다.

흔히 코드 스타일은 개인의 취향 문제를 넘어 팀의 생산성과 직결되는 문제로 여겨집니다. 일관되지 않은 코드는 가독성을 떨어뜨리고 개발자의 인지 부하(Cognitive Load)를 높이며, 코드 리뷰 과정을 더 복잡하게 만들 수 있기 때문입니다. 이는 결국 유지보수 비용의 증가로 이어질 수 있습니다.

이러한 소모적인 논쟁을 줄이고 팀 전체가 일관된 코드 스타일을 유지하도록 돕는 유용한 해결책 중 하나로 정적 분석 도구(Static Analysis Tool)가 꼽힙니다. 코틀린 생태계에서는 ktlint가 널리 알려진 도구 중 하나입니다. ktlint는 스스로를 "자전거 보관소 논쟁을 막는(anti-bikeshedding) 코틀린 린터(linter)이자 포맷터(formatter)"라고 소개한다고 합니다. 이 도구의 목표는 코드를 깨끗하고 읽기 쉬우며 일관성 있게 만들어, 개발자가 더 중요한 로직 구현에 집중할 수 있도록 돕는 것이라고 할 수 있습니다.

ktlint의 진정한 가치는 단순히 코드 스타일을 검사하는 것을 넘어, 팀에 검증된 모범 사례를 즉시 도입할 수 있게 한다는 점에서 찾아볼 수 있습니다. ktlint는 JetBrains가 제안하는 공식 코틀린 코딩 컨벤션(Kotlin Coding Conventions)과 안드로이드 코틀린 스타일 가이드(Android Kotlin Style Guide)를 기본 원칙으로 삼는다고 합니다. 이는 팀이 별도의 스타일 가이드를 정의하는 데 많은 시간을 들이지 않고도, ktlint를 도입하는 것만으로 커뮤니티에서 검증된 표준을 적용할 수 있음을 의미합니다. 결과적으로 새로운 팀원이 프로젝트에 적응하는 시간을 단축시키고, 코드 리뷰에 드는 노력을 줄여주는 효과를 기대할 수 있습니다. 이 글에서는 ktlint를 단순한 린터를 넘어, '상자 안에 담긴 스타일 가이드'처럼 활용하는 방법을 좀 더 깊이 있게 다뤄보고자 합니다.

ktlint 철학: '설정 불필요'에서 실용적인 제어로의 진화

ktlint의 핵심 설계 원칙과 그 철학이 어떻게 발전해왔는지 이해하는 것은 이 도구를 효과적으로 사용하는 데 큰 도움이 될 수 있습니다.

ktlint의 주요 특징은 다음과 같이 알려져 있습니다.

• '설정 불필요(No Configuration)' 원칙: 초기 ktlint의 가장 큰 특징은 gofmt와 같은 도구에서 영감을 받은 '설정 불필요' 정책이었다고 합니다. 단 하나의 표준을 제공함으로써 스타일과 관련된 모든 논쟁을 원천적으로 차단하려는 의도였다고 볼 수 있습니다.
• 내장 포맷터(Built-in Formatter): ktlint는 단순히 문제를 찾아내는 데 그치지 않고, 대부분의 위반 사항을 자동으로 수정할 수 있는 강력한 포맷터를 내장하고 있습니다. ktlint -F 명령어 하나로 코드 스타일을 교정할 수 있어 개발자의 시간을 크게 절약해준다고 합니다. 다만, 일부 모호하거나 결정적이지 않은 위반 사항은 자동으로 수정하기 어려워 개발자의 수동 개입이 필요할 수 있습니다.
• 실행 가능한 JAR 파일: 모든 의존성이 포함된 단일 실행 가능 JAR 파일로 배포되어, 어떤 환경에서든 비교적 쉽게 이식하고 실행할 수 있습니다.
• 규칙 세트(Rule Sets): 기본적으로 standard 규칙 세트를 제공하며, 새롭거나 변경될 수 있는 규칙들을 모아놓은 experimental 규칙 세트도 있습니다. experimental 규칙은 명시적으로 활성화해야만 적용된다고 합니다. 또한, 프로젝트별 특수 규칙을 정의할 수 있는 사용자 정의 규칙 세트(custom rule sets)도 지원하는 것으로 알려져 있습니다.

'설정 불필요'라는 초기 이념은 매우 이상적이었지만, 실제 프로젝트 환경에서는 때때로 한계에 부딪히기도 했습니다. 공식 가이드와 약간 다른 기존 프로젝트의 컨벤션을 따르거나, 특정 규칙을 비활성화해야 할 필요성이 제기된 것입니다.

이러한 요구에 부응하여 ktlint는 점진적으로 진화해왔습니다. ktlint 개발팀은 독자적인 설정 파일을 만드는 대신, 이미 많은 IDE와 편집기에서 지원하는 산업 표준인 .editorconfig 파일을 설정 메커니즘으로 채택했다고 합니다. 이는 현명한 선택이었다고 평가받습니다. 이로 인해 ktlint_standard_rule-id나 ktlint_code_style과 같은 ktlint 전용 속성들이 .editorconfig 파일 내에서 사용되기 시작했습니다.

따라서 현대의 ktlint 철학은 "별도의 설정 없이도 훌륭하고 표준화된 경험으로 시작하라. 하지만 필요하다면, 표준 .editorconfig 파일을 통해 명시적이고 목표 지향적인 제어를 하라."와 같이 요약해 볼 수 있습니다. 이는 ktlint의 초기 문서나 오래된 정보만 접한 사용자들이 가질 수 있는 오해를 바로잡는 중요한 지점입니다. ktlint는 여전히 설정 없이도 강력하지만, 팀 환경에서의 진정한 잠재력은 .editorconfig를 이해하고 활용할 때 발휘된다고 할 수 있습니다.

직접 사용해보기: 커맨드 라인에서 ktlint 다루기

모든 통합 방식의 기초가 되는 커맨드 라인 인터페이스(CLI)를 설치하고 사용하는 방법을 단계별로 알아보겠습니다.

설치

• Homebrew (macOS/Linux): 가장 간단한 설치 방법으로 알려져 있습니다. 터미널에 다음 명령어를 입력하면 됩니다.

  brew install ktlint

• 수동 다운로드: 다른 운영체제에서는 curl 명령어를 사용하여 실행 가능한 JAR 파일을 직접 다운로드하고 시스템 경로에 추가할 수 있습니다. wget과 같은 대체 도구도 사용 가능하다고 합니다.

  curl -sSLO https://github.com/pinterest/ktlint/releases/download/1.6.0/ktlint && chmod a+x ktlint && sudo mv ktlint /usr/local/bin/

  (위 명령어의 버전 1.6.0은 최신 버전으로 변경하여 사용하는 것이 좋습니다.)
• 설치 확인: 설치가 완료되면 다음 명령어로 버전을 확인하여 성공 여부를 알 수 있습니다.

  ktlint --version

핵심 명령어

• 위반 사항 검사 (ktlint):
  별도의 인자 없이 ktlint를 실행하면 현재 디렉토리와 그 하위의 모든 .kt 및 .kts 파일을 재귀적으로 검사한다고 합니다. 위반 사항이 발견되면 파일경로:줄:열: 에러 메시지 (규칙ID) 형식으로 출력됩니다.
• 자동 포매팅 (ktlint -F 또는 ktlint --format):
  이 명령어는 자동으로 수정 가능한 모든 스타일 위반 사항을 교정해준다고 알려져 있습니다. 예를 들어, 다음과 같은 코드가 있을 때,

  // Before
  fun main () { println("hello") }

  ktlint -F를 실행하면 아래와 같이 수정됩니다.

  // After
  fun main() {
      println("hello")
  }

  다만, 일부 복잡한 들여쓰기 문제처럼 자동으로 해결할 수 없는 오류는 수동으로 수정해야 할 수 있습니다.

고급 CLI 활용법

• Glob 패턴 사용: .gitignore 스타일의 패턴을 사용하여 특정 파일만 검사하거나 특정 디렉토리를 제외할 수 있다고 합니다.

  # src 디렉토리 내의 모든 .kt 파일을 검사하되, Test.kt로 끝나는 파일은 제외
  ktlint "src/**/*.kt" "!src/**/*Test.kt"

• 리포터(Reporters): 검사 결과를 다양한 형식으로 출력할 수 있습니다. plain, json, html, checkstyle, sarif 등의 리포터를 지원하는 것으로 알려져 있습니다. 예를 들어, 결과를 HTML 파일로 생성하려면 다음 명령어를 사용하면 됩니다.

  ktlint --reporter=html,output=ktlint-report.html

Table 1: ktlint 커맨드 라인 치트 시트

자주 사용되는 CLI 명령어를 빠르게 참조할 수 있도록 정리한 표입니다.

명령어	단축 명령어	설명	예시
ktlint		코드 스타일 위반 사항을 검사합니다.	ktlint "src/**/*.kt"
ktlint --format	-F	코드 스타일 위반 사항을 자동으로 수정합니다.	ktlint -F "src/**/*.kt"
ktlint --reporter=...		검사 결과의 출력 형식을 지정합니다.	ktlint --reporter=html,output=report.html
ktlint --experimental		실험적인 규칙을 포함하여 검사합니다.	ktlint --experimental
ktlint --disabled_rules=...		특정 규칙을 비활성화합니다. (CLI 사용은 권장되지 않음)	ktlint --disabled_rules=standard:no-wildcard-imports
ktlint generateEditorConfig		.editorconfig 파일에 추가할 수 있는 기본 설정을 생성합니다.	ktlint generateEditorConfig >.editorconfig

완벽한 통합: 빌드 프로세스에 ktlint 심기

수동으로 CLI 명령어를 실행하는 단계를 넘어, 프로젝트의 표준 빌드 도구에 ktlint를 통합하여 검사를 자동화하는 방법을 알아봅니다. 이는 대부분의 프로젝트에서 ktlint를 사용하는 가장 일반적인 방식 중 하나로 알려져 있습니다.

ktlint를 빌드 도구에 통합할 때는 크게 두 가지 선택지가 있다고 합니다. 하나는 ktlint 전용으로 만들어진 플러그인을 사용하는 것이고, 다른 하나는 여러 언어의 포매팅을 지원하는 범용 플러그인을 사용하는 것입니다. 예를 들어 Gradle에서는 jlleitschuh/ktlint-gradle과 spotless가 대표적입니다. jlleitschuh/ktlint-gradle은 코틀린 프로젝트에 특화되어 안드로이드 빌드 구조 등을 깊이 이해하고 최적의 통합을 제공한다고 알려져 있습니다. 반면 spotless는 코틀린뿐만 아니라 자바, XML 등 다양한 파일 형식을 하나의 설정 블록 안에서 관리하고 싶을 때 유용할 수 있습니다. 프로젝트가 주로 코틀린으로 구성되어 있다면 전용 플러그인인 jlleitschuh/ktlint-gradle을 사용하는 것이 효과적인 방법으로 알려져 있으며, 이 글에서도 이를 중심으로 설명하고자 합니다.

4.1. Gradle 통합 (권장 경로)

가장 널리 사용되며 기능이 풍부하다고 알려진 jlleitschuh/ktlint-gradle 플러그인을 중심으로 살펴보겠습니다.

• 설정:
  1. 프로젝트 최상위 build.gradle.kts (또는 build.gradle) 파일의 plugins 블록에 플러그인을 추가합니다.

     // build.gradle.kts
     plugins {
         id("org.jlleitschuh.gradle.ktlint") version "12.3.0"
     }

  2. 멀티 모듈 프로젝트의 경우, 최상위 build.gradle 파일의 allprojects 또는 subprojects 블록에 플러그인을 적용하여 모든 모듈에 ktlint를 활성화할 수 있습니다.
• 주요 Task:
  플러그인을 적용하면 ktlintCheck와 ktlintFormat이라는 두 가지 핵심 Gradle Task가 생성된다고 합니다.
  • ./gradlew ktlintCheck: 린터를 실행하여 코드 스타일 위반 사항을 검사합니다. 위반 사항이 발견되면 빌드가 실패하게 됩니다.
  • ./gradlew ktlintFormat: 코드 스타일 위반 사항을 자동으로 수정해 줍니다.
• 안드로이드 프로젝트 설정:
  안드로이드 프로젝트에서는 ktlint 설정 블록에 android = true 옵션을 추가하여 안드로이드 코틀린 스타일 가이드 규칙을 적용할 수 있다고 합니다.

  // build.gradle.kts
  ktlint {
      android.set(true)
  }

4.2. Maven 통합

Maven 프로젝트에서는 전용 플러그인인 gantsign/ktlint-maven-plugin을 사용하는 것이 권장됩니다.

• 설정:
  1. pom.xml 파일에 다음과 같이 <plugin> 설정을 추가합니다.

     <plugin>
         <groupId>com.gantsign.maven</groupId>
         <artifactId>ktlint-maven-plugin</artifactId>
         <version>1.16.0</version>
         <executions>
             <execution>
                 <id>check</id>
                 <phase>validate</phase>
                 <goals>
                     <goal>check</goal>
                 </goals>
             </execution>
         </executions>
     </plugin>

  2. 위 예시처럼 check goal을 Maven 빌드 생명주기의 validate 단계에 바인딩하면, 빌드 초기에 코드 스타일을 검사하여 빠르게 실패를 감지하는 데 도움이 될 수 있습니다.
• 주요 명령어:
  • mvn ktlint:check: 코드 스타일 위반 사항을 검사합니다.
  • mvn ktlint:format: 코드를 자동으로 포매팅합니다.
  • mvn validate: validate 단계에 바인딩된 check goal을 실행합니다.
• Java 17+ 주의사항:
  Java 17 이상을 사용하는 경우, JVM 인자에 --add-opens java.base/java.lang=ALL-UNNAMED를 추가해야 정상적으로 동작한다고 하며, 이는 플러그인 공식 문서에도 명시되어 있다고 합니다.

제어판: .editorconfig로 ktlint 맞춤 설정하기

현대의 ktlint를 설정하는 가장 표준적이고 권장되는 방법으로 .editorconfig 파일을 사용하는 것이 알려져 있습니다. 이 섹션에서는 관련 내용을 상세히 다뤄보겠습니다.

.editorconfig 파일

.editorconfig는 다양한 IDE와 편집기에서 코드 스타일을 일관되게 정의하기 위한 표준 파일로 알려져 있습니다. 프로젝트 최상위 디렉토리에 이 파일을 생성하여 ktlint를 제어할 수 있습니다.

가장 중요한 점은 ktlint 관련 속성들이 반드시 [*.{kt,kts}] 섹션 아래에 위치해야 한다는 것입니다. 간혹 IntelliJ IDEA의 특정 버전 문제로 [*.{kt, kts}]처럼 Glob 패턴 사이에 공백이 추가될 수 있는데, 이는 ktlint의 파싱 오류를 유발할 수 있어 주의가 필요하다고 합니다.

규칙 비활성화 (올바른 방법)

• 과거의 방법 (Deprecated): 과거에는 disabled_rules 속성을 사용하여 비활성화할 규칙들을 쉼표로 구분하여 나열했다고 합니다. 이 속성은 현재 사용되지 않으며(deprecated) 최신 버전에서는 제거되었으므로, 기존 설정을 마이그레이션하는 경우 이를 인지하고 있는 것이 좋습니다.
• 현대의 방법 (권장): 최신 ktlint에서는 각 규칙을 개별 속성으로 제어하는 것으로 알려져 있습니다. 보통 ktlint_standard_<rule-id> = disabled 형식을 사용합니다.
  • 예시 1: 와일드카드 임포트 비활성화
    ktlint_standard_no-wildcard-imports = disabled
  • 예시 2: 파일 끝 개행 문자 규칙 비활성화
    ktlint_standard_final-newline = disabled

전체 규칙 세트를 비활성화하려면 ktlint_standard = disabled와 같이 설정할 수 있으며, 특정 디렉토리에 대해서만 규칙을 다르게 적용하는 것도 가능하다고 합니다.

코드 내에서 위반 사항 무시하기

드물게 특정 규칙을 예외적으로 위반해야 할 경우, 코드 내에서 직접 위반 사항을 무시할 수 있습니다. 이는 일종의 '비상 탈출구'와 같다고 볼 수 있습니다.

• 한 줄 주석: // ktlint-disable standard:rule-id
• 블록 주석: /* ktlint-disable */... /* ktlint-enable */
• 어노테이션: @Suppress("ktlint:standard:rule-id")

Table 2: ktlint 맞춤 설정을 위한 주요 .editorconfig 속성

주요 .editorconfig 속성들을 정리한 ktlint 설정 참조 표입니다.

속성	목적	예시 값	참고
root	이 파일이 최상위 설정 파일임을 명시합니다.	true	항상 true로 설정하는 것이 권장됩니다.
indent_size	들여쓰기 크기를 설정합니다.	4, 2	indent 규칙 등에서 사용됩니다.
max_line_length	한 줄의 최대 길이를 설정합니다.	100, 120, off	기본값은 off로 알려져 있습니다.
insert_final_newline	파일 끝에 개행 문자를 강제합니다.	true, false	true 사용이 권장됩니다.
ktlint_code_style	기본 코드 스타일을 설정합니다.	ktlint_official, android_studio	안드로이드 프로젝트에서는 android_studio를 사용하는 경우가 많습니다.
ktlint_experimental	모든 실험적인 규칙을 활성화합니다.	enabled, disabled	기본값은 disabled입니다.
ktlint_standard_<rule-id>	특정 규칙을 활성화/비활성화합니다.	enabled, disabled	예: ktlint_standard_import-ordering = disabled.
ij_kotlin_allow_trailing_comma	선언 위치에서 후행 쉼표 사용을 강제/비허용합니다.	true, false	ktlint는 이 설정에 대해 IntelliJ IDEA보다 엄격하게 적용할 수 있습니다.

최대 생산성을 위한 '심층 방어' 워크플로우

ktlint의 이점을 극대화하려면 개발 프로세스의 여러 단계에 이를 통합하는 것이 중요하다고 할 수 있습니다. ktlint 공식 문서에서 권장하는 접근법 중 하나는 일관성 없는 코드가 프로젝트에 유입되는 것을 막기 위한 다층적 방어 전략, 즉 '심층 방어(Defense in Depth)' 모델을 구축하는 것입니다.

이 전략은 각기 다른 개발 단계에서 오류를 감지하는 여러 개의 방어선을 구축하는 개념으로 볼 수 있습니다.

1. 1차 방어선 (개발자): IDE 플러그인
   개발자가 코드를 작성하는 순간 즉각적인 피드백을 제공하여 가장 빠른 피드백을 얻을 수 있는 단계입니다.
2. 2차 방어선 (로컬 저장소): Git Hook
   로컬 커밋의 게이트키퍼 역할을 합니다. 포매팅되지 않은 코드가 개발자의 로컬 커밋 기록에 포함되는 것을 방지해준다고 합니다. 특히 IDE에서 열려있지 않은 파일에 대한 변경 사항을 잡아내는 데 유용할 수 있습니다.
3. 3차 방어선 (공유 저장소): CI/CD 파이프라인
   최종적인 품질 게이트 역할을 한다고 볼 수 있습니다. 서버에서 실행되어 로컬 훅을 우회한 코드가 메인 브랜치에 병합되는 것을 원천적으로 차단합니다.

이 섹션에서는 각 방어선의 역할과 설정 방법을 자세히 살펴보겠습니다.

6.1. 1차 방어선: IntelliJ/Android Studio 플러그인으로 즉각적인 피드백 받기

• 설치: JetBrains Marketplace에서 공식 'Ktlint' 플러그인을 검색하여 설치할 수 있습니다.
• 설정:
  • Preferences > Tools > KtLint 메뉴에서 플러그인을 설정할 수 있다고 합니다.
  • 가장 중요한 설정 중 하나로 'Distract free' 모드가 꼽힙니다. 이 모드를 활성화하면 파일을 저장하거나 IDE의 포맷 기능을 실행할 때 ktlint가 자동으로 코드를 포매팅하고, 자동 수정이 불가능한 오류만 표시해 준다고 합니다. 이는 IDE의 기본 포매터와 ktlint 간의 충돌을 해결하는 데 가장 권장되는 방법 중 하나로 알려져 있습니다.
  • 'Manual' 모드를 선택하면 모든 위반 사항이 경고로 표시되어 수동으로 처리할 수 있습니다.
• 플러그인은 프로젝트의 .editorconfig 파일을 자동으로 인식하므로, CLI나 빌드 도구와 일관된 경험을 제공한다고 합니다.

6.2. 2차 방어선: Git Hook으로 로컬 품질 게이트 구축하기

로컬 커밋 기록을 보호하기 위해 Git의 pre-commit 훅을 사용하는 방법이 있습니다.

• 설정:
  .git/hooks/pre-commit 파일을 생성하고 실행 권한을 부여한 뒤, 다음과 같은 로직의 셸 스크립트를 작성해 볼 수 있습니다.

  1. git diff --name-only --cached 명령어로 스테이징된 .kt 및 .kts 파일 목록을 가져옵니다.
  2. 해당 파일들에 대해 ktlint -F를 실행하여 포매팅합니다.
  3. 포매팅으로 변경된 파일들을 다시 git add하여 스테이징합니다.

  이 과정은 수동으로 설정하거나, pre-commit 파일을 .git/hooks 디렉토리로 복사하는 Gradle Task를 만들어 자동화할 수도 있습니다.

6.3. 3차 방어선: CI/CD로 최종 품질 게이트 구축하기 (GitHub Actions)

팀 전체의 코드 품질을 Pull Request 단계에서 강제하기 위해 CI/CD 파이프라인을 구축하는 것이 권장됩니다.

• 설정:
  GitHub Actions를 사용하는 경우, 프로젝트 루트에 .github/workflows/lint.yml 파일을 생성하고 다음 내용을 작성해 볼 수 있습니다. 아래 예시는 reviewdog과 통합하여 PR에 직접 코멘트를 남기는 ScaCap/action-ktlint 액션을 사용하는 경우입니다.

  name: Kotlin Lint
  on: [push, pull_request]
  
  jobs:
    lint:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
        - name: Run ktlint
          uses: ScaCap/action-ktlint@master
          with:
            github_token: ${{ secrets.GITHUB_TOKEN }}
            reporter: github-pr-review # PR에 리뷰 코멘트로 결과 보고

  이 워크플로우는 github_token을 사용하여 PR에 접근하고, 프로젝트에 포함된 .editorconfig 설정을 자동으로 존중하여 코드 스타일을 검사한다고 합니다. nbadal/action-ktlint-setup 이나 touchlab-lab/ktlint-action-setup 과 같은 다른 액션들도 존재하여, ktlint의 CI/CD 생태계가 활발하다는 것을 알 수 있습니다.

더 나아가기: 사용자 정의 규칙 입문

프로젝트에 특화된 고유한 코딩 컨벤션을 강제해야 할 경우, ktlint를 확장하여 사용자 정의 규칙을 만들어 볼 수 있습니다. 이는 비교적 고급 주제에 해당합니다.

언제 사용자 정의 규칙을 작성해야 하는가?

표준 규칙으로는 다룰 수 없는, 프로젝트나 팀만의 고유한 규칙을 적용하고 싶을 때 필요한 경우가 있습니다. 예를 들어, "매직 넘버(Magic Number) 사용 금지"나 " android.util.Log 직접 사용 대신 자체 로거 사용 강제"와 같은 규칙을 만들어 볼 수 있습니다.