Louis is

들어가며

Chat GPT는 2022년 12월에 OpenAI에서 출시된 이후 지금까지 꾸준히 핫한 키워드인 것 같다.

다들 알겠지만 Chat GPT에 대해 간단히 설명하면 아래와 같다.
(GPT에게 "너에 대해 설명해 줘"라고 물어봐서 얻은 답변)

저는 ChatGPT라고 하며, 인공지능 기술인 GPT-3.5 모델을 기반으로 한 대화형 챗봇입니다. 사람들이 자연어로 질문하면 가능한한 정확하고 유용한 답변을 제공하는 것이 제 목적입니다. 이를 위해 저는 최신 정보와 데이터를 학습하여 사람들에게 도움을 드리고 있습니다. 제가 가진 지식은 2021년 이전부터 2021년까지의 데이터를 바탕으로 학습되었지만, 저는 지속적으로 학습을 하고 있기 때문에, 미래에는 2022년 이후의 데이터도 포함될 수 있습니다.

그리고 유료버전은 GPT 4.0을 기반으로 한다고 한다. 좀 더 자세한 내용은 인간지능으로 작성된 나무위키 <Chat GPT> 를 참조하면 좋을 것 같다.

서론

먼저, 이 글은 다양한 Chat GPT를 활용법을 설명하는 글이 아니다.

본인은 아직 구글링이 익숙한 평범한 개발자이고 GPT로는 초기에 단순한 호기심으로 몇 개 질문해 본 게 전부인 사람이다. 

업무에서 Chat GPT를 사용해 보고 인상 깊은 점들이 몇 가지 있어 그 경험과 생각을 공유해보고자 한다.

본론

1. 발단

최근 ktLint를 이용한 코딩 컨벤션을 프로젝트에 적용하는 작업(https://j-louis.tistory.com/14)을 진행중 구글링에 한계를 느꼈다.  

Ktlinst 플러그인에 대한 개념과 이를 활용해서 컨벤션을 적용한 예시와 방법은 알 수 있었지만, 대부분 매우 간단한 튜토리얼 정도 였고 서비스에 적용하기엔 약간 부족했다. 그리고 대부분 영어로 된 많은 정보들을 계속 보다 보니 조금씩 헷갈리게 하더라. (ㅠ.ㅠ)

좀 더 상세한 활용, 그리고 서비스에 어떻게 적용하는 게 좋을지 고민해다가 Chat GPT한테 물어보기로 했다.

2. 전개

처음 질문은 이렇게 시작했다.

그러니 GPT는 ci 설정파일 생성법 & ktlintCheck 적용까지 상세하게 설명해 주더라. 친절했다..! 

이 내용을 바탕으로 build 시점에 컨벤션 체크 방식으로 작업을 하였지만, 아래와 같은 이유로 다른 방식을 고민하게 되었다.

Push 이전에 체크 할 수 있는 게 있는지 다시 물어봤다. 

(지금 생각해보면 pre-push 관련 내용을 설명해 줘야 되지 않았나 싶긴 한데...) pre-commit 관련 내용을 설명해 주었다.
pre-push도 있는지 물어보았고 관련 예제 스크립트 알아서 작성해 주었다.

스크립트 내용도 내가 원하는 방식으로 수정도 요청할 수 있었기 때문에 문법에 대한 스트레스를 줄일 수 있었다.

        1. 특정 브랜치가 아니라 모든 브랜치에서 검사할 수 있게 스크립트 수정 요청.

        2. ktlint를 시스템 설치해서 사용하는 게 아니라 gradle 라이브러리 적용한 명령어로 수정 요청.

하지만 이 방식도 도중에 아래의 이유로 다른 방법을 생각해야 했다.

결국 commit 시점에 컨벤션 체크 하는 방식을 선택했고 다시 한번 gpt한테 도움을 요청했다.

스크립트 작성 & 스크립트 실행 권한 수정까지 섬세하게 알려준다는 느낌을 받았다.
물론 ./gradlew addKtlintCheckGitPreCommitHook    명령어를 이용해서 기본 스크립트를 이용할 수 있었지만 GPT가 작성해 준 script가 훨씬 도움이 되었다.(프로젝트 환경에 맞게 여러 번 수정해서 물어봐야 하는 게 약간 귀찮긴 했음)

그리고 작업 중 궁금한 사항들에 대해서도 답을 얻을 수 있어서 매우 편리했다. (다른 레퍼런스를 활용해서 했었다면 귀차니즘 때문에 지나쳤을 것 같은 질문들이다.)

3. 위기

중간에 삽질도 많이 했지만 결국 원하는 작업물을 얻을 수 있었다. 

로컬 환경에서 테스트를 진행 후 팀에 공유할 예정이었다.

하지만 곧 문제가 발생하더라. ㅎ_ㅎ

프로젝트 빌드 과정 중 전체 파일을 대상으로 컨벤션 체크 task가 수행되었고 빌드는 실패가 되었다.

생각했던 프로세스에는 없던 과정이었다.

팀 내 컨벤션 체크를 강제화 하기 위해 해당 플러그인을 적용했던 것이었지만 우선 작업한 소스에 대해서만 컨벤션 강제성을 두고 싶었다.

그래서 다시 한번 gpt한테 도움을 요청했다.

4. 절정 - 결말

GPT는 여러 가지 해결책을 제시해 주었다.

그래서 희망을 갖고 시도를 했지만 프로젝트에 적용되지 않았고 오류만 발생했다. ㅠ.ㅠ

한 이틀 동안 비슷한 질문과 답변을 주고받았지만 해결책은 찾지 못했다.

(좀 더 시간을 투자했다면 해결책을 찾을 수 있을지 모른다. 하지만 개인 프로젝트가 아니었고 회사 업무였기 때문에 적정선에서 타협했다 ㅠ)  

결국 전체 소스에 대해 컨벤션 리펙토링을 진행한 뒤에 ktlint plugin과 pre-commit 작업을 추가함으로써 마무리하는 것으로 했다.

(컨벤션 리펙토링 때문에 생각지 못한 시간을 쏟았지만 전체적으로 컨벤션을 통일하고 나니 기분은 깔끔해서 좋았다.)

결론

업무를 처리하는 과정에 Chat GPT를 사용해 보고 느낀 점을 나열해 봤다.

1. 생각보다 많이 친절하다.
   단순히 스크립트 작성해 달라고만 했지만 작성 후 간단한 설명까지도 해준다.
   쉽게 놓칠 수 있는 주의사항까지도 알려준다.
   
   
2. 구글링을 해도 잘 나오지 않는 마이너 한 개념, 지식, 적용방법이 궁금할 때 활용하면 좋을 것 같다고 생각했다.
3. 최대한 상세하게 배경을 설명하면서 질문을 해야 한다.
   배경지식이 1도 없는 기계와 대화하기 위해선 상세한 배경을 설명해 주는 게 필요하다고 느꼈다.
   (여러 번의 질문 & 답변 을 하다 보니 약간 면접과도 비슷하다고 느꼈다. 말 잘하는 ai 부럽다…)
   
   
4. 나는 분명 컴퓨터와 대화를 주고받았지만 이런 경험이 쌓이면 협업에서도 많은 도움이 될 것 같다고 생각했다.
5. 너무나 즉답이 나오기 때문에 휘발성이 좀 강하다. 의식적으로 기억하려는 노력이 많이 필요할 것 같다.

재밌었다.

삽질도 하긴 했지만 매우 유용한 도구라는 생각이 들었다. 

함께 일을 하는 데 있어서 소프트 스킬이 중요하다고 느끼고 있는 요즘, Chat GPT를 사용하면서 협업 그리고 대화에 대한 스킬을 기를 수 있지 않을까라는 생각도 들었다.

아직은 본능적으로 익숙한 구글링을 먼저 하고 있지만 점점 사용할 일이 많아질 것 같다.

곧, GPT를 이용한 업무처리가 자연스러워질 것 같은 느낌적인 느낌이 든다!

코드 품질을 향상시키기 위해선 컨벤션, 단위테스트, 정적 분석 등 여러 가지를 고려해야 한다.

이번 글에서는 팀에서 코딩 스타일을 공통으로 관리하기 위해 고민했던 내용, 적용한 사례, 그리고 느낀 점까지 기록해보려 한다.

배경

프로젝트를 시작할 땐 BE 개발자가 3명이었다. 3명의 코딩스타일을 맞추기 위해 깊게 고민할 필요는 없었고 단순히 intelliJ 플러그인 중 하나인 ktlint를 각자의 IDEA에 설치해서 최소한으로 컨벤션을 맞추고 프로젝트를 진행했다.

그 후 동료들이 늘어났지만 변한 건 없었다. 각자의 담당영역이 나뉘어 있었고 코드리뷰를 할 때 코딩스타일 컨벤션까지는 세세하게 보지 않았다. 

그러다 최근 서비스에 대규모 리뉴얼 작업을 진행하게 되면서 여러 사람들이 엮인 로직을 작업하게 되었는데 내가 작업할 코드가 빨간 줄 투성이거나 혹은 작업한 코드의 코딩스타일이 바뀌어져 있는 경우가 많았다.

원인이 무엇일까 고민했고 내린 결론은 다음과 같았다.

첫 번째로 '코딩스타일 컨벤션 체크'를 안 하는 사람도 있었다.

하지 않더라도 (분명 ide에선 빨간 줄로 보일 텐데...) 코드가 동작하는데 문제는 없기 때문에 신경 쓰지 않는 건가 싶었다.

두 번째는 명확하진 않지만 ide 설정에서 변경했거나 ktlint 버전 차이 때문에 standard rule이 변경되어서 코딩 스타일이 차이가 있는 게 아닐까 싶었다.

그렇기 때문에 코딩스타일을 공통관리하고 컨벤션 체크에 강제성을 부여할 필요성을 느꼈다.

Ktlint

ktlint이 뭔지부터 다시 한번 집어봤다. 

ktlint는 kotlin 코드 스타일을 검사하고 적용하기 위한 정적 분석 도구로서 ktlint는 코드의 일관성과 가독성을 높이기 위해 kotlin 코딩 컨벤션을 적용하고 코드에서 발견된 문제점을 지적하고 수정하는 데 도움을 줍니다.

ktlint는 Gradle, Maven, Ant 및 Command Line Interface(CLI)와 같은 다양한 빌드 시스템과 통합할 수 있으며, IntelliJ IDEA, Android Studio, Visual Studio Code 등 다양한 통합 개발 환경에서도 지원됩니다.

Kotlin 프로젝트에서 ktlint를 사용하면 코드의 일관성과 가독성을 향상시키고, 코드 리뷰 과정에서 발견되는 문제를 줄일 수 있다.

위에서 언급한 것과 같이 ktlint는 빌드 환경에서 사용할 수 있도록 libarary 형태가 있고 에디터에서 쉽게 사용할 수 있도록 만든 플러그인 형태가 있었다. 

Gradle을 이용해서 build pipeline에 적용한다면 공통의 코딩스타일 컨벤션을 가지고 코드를 체크할 수 있고, 강제성을 추가할 수 있어서 코드의 품질을 유지하는데 효과적일 것이라고 생각이 들었다.

도입기

1.  특정 브랜치 (Develop , Master)에 build 할 때 CI에서 ktlint 컨벤션 체크  

방식: develop or master 브랜치에 push 후 build 될 때 컨벤션을 체크해서 실패 처리

결론: 실패된 작업을 수정하기 위해서 작업 브랜치부터 다시 진행을 해야 하는 불편함이 있고 혹시나 다른 사람들이 작업한 소스의 영향도 받을 수 있기 때문에 포기했다.

2.  작업 브랜치 Push 시점에 체크

방식: git hook pre-push를 이용해서 브랜치 push 시점에 체크, 컨벤션 오류일 경우 push 실패처리

결론: 코딩 스타일 컨벤션을 맞추기 위한 불필요한 commit 로그가 많아질 것으로 보임, 좀 더 빠른 시점에 체크하는 게 나을 것 같다고 판단함.

3.  Commit 시점에 체크

방식: git hook pre-commit을 이용해서 coomit 시점에 체크, 컨벤션 오류일 경우 commit 실패처리

결론: 결국 가장 작은 단위인 commit 할 때부터 컨벤션 체크를 하는 게 맞다고 생각, 이 방식으로 작업 진행

작업 

1. IntelliJ Plugin: https://plugins.jetbrains.com/plugin/15057-ktlint-unofficial-  (version "0.10.0")

• 작성한 코드의 코딩 스타일 컨벤션을 실시간으로 확인해서 알려주는 기능.
• Preferences > Plugins > Ktlint 설치

• https://github.com/nbadal/ktlint-intellij-plugin/blob/main/TODO.md 의 내용으로 봐선 플러그인에 pre-commit hooks까지 세팅할 수 있도록 추후 개발 예정으로 보인다. 

2. gradle 플러그인 https://github.com/JLLeitschuh/ktlint-gradle (version "11.3.1") + git hook pre-commit 세팅 

• gradle 플러그인: 전체/부분 로직에 대한 코딩스타일 정적검사를 진행할 수 있음
• pre-commit 스크립트: commit 이전에 진행되는 작업이 적힌 스크립트. - 해당 스크립트에 코딩스타일 컨벤션 검사 로직을 추가

• gradle 플러그인 설치 & build

plugins {
		id("org.jlleitschuh.gradle.ktlint") version "11.3.1”
}



apply(plugin = "org.jlleitschuh.gradle.ktlint")

• pre-commit 작성방법 
  • 1. ./gradlew addKtlintCheckGitPreCommitHook - 기본적으로 컨벤션 체크해 주는 pre-commit 스크립트를 만들어준다.
  • 2. .git/hooks/pre-commit 스크립트를 직접 생성하기. (feat. 킹갓제너럴 ChatGPT )
         컨벤션 불일치하는 라인을 표시하는 작업을 추가함.

#!/bin/sh
######## KTLINT-GRADLE HOOK START ########

CHANGED_FILES="$(git --no-pager diff --name-status --no-color --cached | awk '$1 != "D" && $NF ~ /\.kts?$/ { print $NF }')"

if [ -z "$CHANGED_FILES" ]; then
    echo "No Kotlin staged files."
    exit 0
fi;

echo "Running ktlint over these files:"
echo "$CHANGED_FILES"

diff=.git/unstaged-ktlint-git-hook.diff
git diff --color=never > $diff
if [ -s $diff ]; then
  git apply -R $diff
fi

echo "KTLINT CHECK START"
ktlint_output=$(./gradlew ktlintCheck -PinternalKtlintGitFilter="$CHANGED_FILES")
if [ $? -ne 0 ]; then
  echo "KTLINT CHECK FAIL"
  echo "check these files:"
  while read -r line; do
    if [[ "$line" =~ ^.*\.kt:[0-9]+:[0-9]+.*$ ]]; then
      echo "$line"
    fi
  done <<< "$ktlint_output"
  exit 1
fi


  echo "KTLINT CHECK SUCCESS"


if [ -s $diff ]; then
  git apply --ignore-whitespace $diff
fi
rm $diff
unset diff

  echo "KTLINT CHECK FINISH"
exit 0
#exit $gradleCommandExitCode
######## KTLINT-GRADLE HOOK END ########

3. .editorconfig 파일 설정

• ktlint 기본 컨벤션 외에 프로젝트에 적용되는 예외 규칙들 작성 리스트 
• 자세한 내용은 EditorConfig 참조. 
• .editorconfig 파일이 없는 경우 기본룰 Ktlint 버전에 따라서 Standard rules를 기본적으로 따르지만 버전이 변경이 되면 Standard rules로 변경이 될 수 있기 때문에 root 디렉터리에 .editorconfig파일을 설정하는 것을 권장.

결과

commit 요청 클래스가 코딩스타일 컨벤션에 일치하는 경우: 정상적으로 커밋 성공

commit 요청 클래스가 코딩스타일 컨벤션에 일치하지 않는 경우: console에 에러 표시 & 불일치 라인과 이유 표시

추가적으로 고민해 볼 내용

표시되는 코딩 스타일 컨벤션 오류에 대한 고민 

코드 수정이 아니라 컨벤션 수정을 고려해야 할 수도 있음.

max-line-length가 70으로 설정되어 있어서 작성된 코드들을 줄 바꿈 해야 한다고 알려준다.

하지만 제안에 맞게 코드를 바꾸게 된다면 프로젝트 내 다른 코드들도 전부 변경해줘야 하기 때문에 max-line-length을 늘리는 것을 고려해 볼 수 있다.

ktlint 버전 차이에 의한 rule 차이

ktlint 버전은 계속 변하면서 kotlin standard rule도 바뀐다.

한 예로 ktlint 0.42.1 버전에선 rule에 걸리지 않았던 내용이 0.47.1 버전에서는 rule에 잡힘.

그렇기 때문에 꾸준한 버전 관리를 통해서 코딩스타일 컨벤션을 꾸준히 Update 해주는 것이 필요하다고 느꼈다.

마무리

간단할 줄 알았던 코딩 스타일 컨벤션 세팅을 작업하고 나니 생각보다 고려할게 많았고, 작업량에 비해서 시간도 많이 소요되었다. (대부분이 고민, 삽질 등..)

또한, 코딩스타일 규칙을 강제했더니 error를 해결하기 위해 코드 리펙토링을 진행할 수 밖에 없는 환경도 생겼다. (물론 제약이 생겨서 답답한면도 많았다.) 

하지만 명확한 정책을 세우고, 나뿐만 아니라 팀원들이 좀 더 나은 품질의 코드를 볼 수 있겠다는 생각에 뿌듯...

지속적으로 팀원들간에 협의를 통해서 개선해 나갈 예정이다.

함께 관리해야 하는 코드는 공통으로 관리할 수 있는 규칙과 그 규칙을 지킬 수 있는 환경을 만들어 주는 게 중요하다는 점을 배운 시간이지 않나 싶다.