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를 사용해 보고 인상 깊은 점들이 몇 가지 있어 그 경험과 생각을 공유해보고자 한다.
이 내용을 바탕으로 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도 없는 기계와 대화하기 위해선 상세한 배경을 설명해 주는 게 필요하다고 느꼈다. (여러 번의 질문 & 답변 을 하다 보니 약간 면접과도 비슷하다고 느꼈다. 말 잘하는 ai 부럽다…)
나는 분명 컴퓨터와 대화를 주고받았지만 이런 경험이 쌓이면 협업에서도 많은 도움이 될 것 같다고 생각했다.
너무나 즉답이 나오기 때문에 휘발성이 좀 강하다. 의식적으로 기억하려는 노력이 많이 필요할 것 같다.
재밌었다.
삽질도 하긴 했지만 매우 유용한 도구라는 생각이 들었다.
함께 일을 하는 데 있어서 소프트 스킬이 중요하다고 느끼고 있는 요즘, Chat 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 등 다양한 통합 개발 환경에서도 지원됩니다.
1. 기존 로직에 대한 테스트 (DB) 2. 새로운 로직에 대한 테스트(Redis + DB)
테스트 설정은 다음과 같이 하였다.
Target 서버: Local 환경, 개발서버 Vuser(virtural user로 동시에 접속하는 유저수를 의미) : 500명 테스트 시간: 10분
테스트 진행 시 겪은 시행착오
테스트를 진행했는데 생각보다 결과에서 차이가 없었다. 문제의 원인을 찾다가 redis를 잘못 적용했나 생각하며 꽤 오랜 시간 삽질을 했었다. 약간 창피하지만 혹시나 나와 같은 실수를 하는 사람을 위해 확인한 내용을 공유해 본다.
첫 번째는 테스트 데이터의 양이였다. API가 수행되는데 조회할 데이터 자체가 작다 보니 캐시 적용효과를 테스트에서 확인하기 어려웠다. 그래서 운영환경과 비슷하게 많은 데이터를 모집단으로 설정하는 게 필요하다 판단했고 테스트 관련 데이터는 운영환경에서 가져와서 처리했다.
두 번째는 API 로직 이해 부족이었다. 첫 번째 원인을 수정하였는데도 두 가지 테스트에서 차이가 눈에 띌정도로 보이지 않았다. 확인해 보니 해당 API는 페이징 처리를 해두었는데 request에 paging 관련 값은 default 던지고 있었다. 그래서 계속 같은 데이터만 return 하는 구조였다. 이 원인은 테스트 스크립트의 api 호출 부분을 수정해서 처리하였다.
테스트환경, 데이터, 로직에 대한 정확한 이해를 기반으로 테스트를 진행해야겠다는 점을 다시 한번 느꼈던 상황들이었다. 😭😭
테스트 스크립트는 기본 template을 약간 수정해서 작성했다. 전체 코드는 아래 더보기로 확인하길 바란다.
import static net.grinder.script.Grinder.grinder
import static org.junit.Assert.*
import static org.hamcrest.Matchers.*
import net.grinder.script.GTest
import net.grinder.script.Grinder
import net.grinder.scriptengine.groovy.junit.GrinderRunner
import net.grinder.scriptengine.groovy.junit.annotation.BeforeProcess
import net.grinder.scriptengine.groovy.junit.annotation.BeforeThread
// import static net.grinder.util.GrinderUtils.* // You can use this if you're using nGrinder after 3.2.3
import org.junit.Before
import org.junit.BeforeClass
import org.junit.Test
import org.junit.runner.RunWith
import org.ngrinder.http.HTTPRequest
import org.ngrinder.http.HTTPRequestControl
import org.ngrinder.http.HTTPResponse
import org.ngrinder.http.cookie.Cookie
import org.ngrinder.http.cookie.CookieManager
/**
* A simple example using the HTTP plugin that shows the retrieval of a single page via HTTP.
*
* This script is automatically generated by ngrinder.
*
* @author admin
*/
@RunWith(GrinderRunner)
class TestRunner {
public static GTest test
public static HTTPRequest request
public static Map<String, String> headers = ["x-balcony-id":"BOMTOON_COM"]
public static Map<String, Object> params = ["groupMenu":"SCHEDULE_ALL","isIncludeAdult":"true","contentsThumbnailType":"MAIN","isIncludeTen":"false","isIncludeTenComplete":"false","sort":"POPULAR"]
public static List<Cookie> cookies = []
@BeforeProcess
public static void beforeProcess() {
HTTPRequestControl.setConnectionTimeout(300000)
test = new GTest(1, "http://localhost:8080")
request = new HTTPRequest()
grinder.logger.info("before process.")
}
@BeforeThread
public void beforeThread() {
test.record(this, "test")
grinder.statistics.delayReports = true
grinder.logger.info("before thread.")
}
@Before
public void before() {
headers.put("Authorization", "Bearer eyJhbGciOiJIUzI1NiJ9.eyJlbWFpbCI6Im1DbnNLTWhGNFZiMGJZK0g0amlwNWVSNHF4QTJwaHhQaDA3SlNwTm1Oc1pCZXJGS2Vkcmpidm05aVY2RzVkZkgiLCJzbnNQcm92aWRlciI6IkgxK3RUdU9EQ1lBQ3ZFKzdwNGJNR1E9PSIsImlzQWR1bHQiOiJjYUZmRU00Z0VIUmZXd215VDNCMXlnPT0iLCJ1c2VySWQiOiJYR3k1c1ByQmxFWmxpZXVNenp2cDZBPT0iLCJ1dWlkIjoiUERnelE3NVR5S3UzQWhpb2gzQTZtRHBheDhmQk10cUdnT3ZOL3hBa0VRVGN3V1QxQ1MyQVk3bmx6WWNtQ3dMQSIsImlhdCI6MTY3OTk2ODEzMywiZXhwIjoxNjgwMDU0NTMzfQ.ezMtHPpfpXEeQlF0aYxfyC8dZFgPGMfYMaeQkT6pl6Q")
request.setHeaders(headers)
CookieManager.addCookies(cookies)
grinder.logger.info("before. init headers and cookies")
}
@Test
public void test() {
int page = (int)(Math.random()*500)
params.put("page", Integer.toString(page))
HTTPResponse response = request.GET("http://localhost:8080/v2/contents/group/new", params)
if (response.statusCode == 301 || response.statusCode == 302) {
grinder.logger.warn("Warning. The response may not be correct. The response code was {}.", response.statusCode)
} else {
assertThat(response.statusCode, is(200))
}
}
}
import static net.grinder.script.Grinder.grinder
import static org.junit.Assert.*
import static org.hamcrest.Matchers.*
import net.grinder.script.GTest
import net.grinder.script.Grinder
import net.grinder.scriptengine.groovy.junit.GrinderRunner
import net.grinder.scriptengine.groovy.junit.annotation.BeforeProcess
import net.grinder.scriptengine.groovy.junit.annotation.BeforeThread
// import static net.grinder.util.GrinderUtils.* // You can use this if you're using nGrinder after 3.2.3
import org.junit.Before
import org.junit.BeforeClass
import org.junit.Test
import org.junit.runner.RunWith
import org.ngrinder.http.HTTPRequest
import org.ngrinder.http.HTTPRequestControl
import org.ngrinder.http.HTTPResponse
import org.ngrinder.http.cookie.Cookie
import org.ngrinder.http.cookie.CookieManager
/**
* A simple example using the HTTP plugin that shows the retrieval of a single page via HTTP.
*
* This script is automatically generated by ngrinder.
*
* @author admin
*/
@RunWith(GrinderRunner)
class TestRunner {
public static GTest test
public static HTTPRequest request
public static Map<String, String> headers = ["x-balcony-id":"BOMTOON_COM"]
public static Map<String, Object> params = ["groupMenu":"SCHEDULE_ALL","isIncludeAdult":"true","contentsThumbnailType":"MAIN","isIncludeTen":"false","sort":"POPULAR"]
public static List<Cookie> cookies = []
@BeforeProcess
public static void beforeProcess() {
HTTPRequestControl.setConnectionTimeout(300000)
test = new GTest(1, "http://localhost:8080")
request = new HTTPRequest()
grinder.logger.info("before process.")
}
@BeforeThread
public void beforeThread() {
test.record(this, "test")
grinder.statistics.delayReports = true
grinder.logger.info("before thread.")
}
@Before
public void before() {
headers.put("Authorization", "Bearer eyJhbGciOiJIUzI1NiJ9.eyJlbWFpbCI6Im1DbnNLTWhGNFZiMGJZK0g0amlwNWVSNHF4QTJwaHhQaDA3SlNwTm1Oc1pCZXJGS2Vkcmpidm05aVY2RzVkZkgiLCJzbnNQcm92aWRlciI6IkgxK3RUdU9EQ1lBQ3ZFKzdwNGJNR1E9PSIsImlzQWR1bHQiOiJjYUZmRU00Z0VIUmZXd215VDNCMXlnPT0iLCJ1c2VySWQiOiJYR3k1c1ByQmxFWmxpZXVNenp2cDZBPT0iLCJ1dWlkIjoiUERnelE3NVR5S3UzQWhpb2gzQTZtRHBheDhmQk10cUdnT3ZOL3hBa0VRVGN3V1QxQ1MyQVk3bmx6WWNtQ3dMQSIsImlhdCI6MTY3OTk2ODEzMywiZXhwIjoxNjgwMDU0NTMzfQ.ezMtHPpfpXEeQlF0aYxfyC8dZFgPGMfYMaeQkT6pl6Q")
request.setHeaders(headers)
CookieManager.addCookies(cookies)
grinder.logger.info("before. init headers and cookies")
}
@Test
public void test() {
int page = (int)(Math.random()*500)
params.put("page", Integer.toString(page))
HTTPResponse response = request.GET("http://localhost:8080/v2/contents/group", params)
if (response.statusCode == 301 || response.statusCode == 302) {
grinder.logger.warn("Warning. The response may not be correct. The response code was {}.", response.statusCode)
} else {
assertThat(response.statusCode, is(200))
}
}
}
테스트 결과
테스트 결과는 다음과 같았다.
DB Test 결과
Redis Test 결과
TPS와 테스트시간만 체크했다.
TPS는 초당 트랜잭션 완료수이다. 높을수록 성능이 높다는 것을 의미한다.
테스트 시간은 user가 request 한 시점에서 시스템이 response 한 시점, 즉 API 수행시간이다.
두 개의 결과에 대한 차이는 10배이상난 것을 확인할 수 있었다.
결론
DB만 사용할 때보다 캐싱을 도입했을 때 성능적인 차이를 구체적인 수치로 확인할 수 있어서 좋았다.
나와 같은 멍청한 실수를 하지 않으려면 몇 가지만 신경 쓰고 테스트를 진행하길 바란다.
구현한로직프로세스, 모집단의데이터의양, 서버성능에따라서테스트의결과는확연하게달라질수있다는 점을 인지하는 게 중요할것같다.
사람들은 보통 ‘회사+사람’으로 본인을 소개하는데 그중 나에게 인상 깊은 인사이트를 준 사람들은 ‘회사’가 없어도 ‘사람’이 누구인지 분명히 알수 있는 사람들이었다. 그들을 보면서 나도 저렇게 되고 싶다고 생각했었지만 막연한 생각은 바쁜 회사업무 속에서 금방 잊혔다.
그러던 중 개발자를 위한 교육 플랫폼인 NEXTSTEP에서 ‘개발자 퍼스널 브랜딩 워크숍’이라는 과정의 모집글을 보았다. 소개된 커리큘럼은 ‘회사+나’에서 ‘나’가 되는 방법을 알려주는 수업처럼 보였다. 그리고 깊게 생각해보지 않았던 개발자로서의 향후 N 년을 고민해 볼 수 있는 시간이 될 것 같아서 신청하게 되었다.
교육 과정
교육은 리딩해주시는 문수민 님, 김민석 님과 참여자 7명으로 진행되었다. 단방향의 수업이 아니라 참여형 수업이었다. 낯을 가리는 것도 잠시뿐 6주 동안 서로 많은 피드백을 주고받으면서 과정을 즐겼던 것 같다.
6주동안 이 과정에서 추상적인 많은 것들을 구체화할 수 있었다. ‘나는 누구인가, 내가 가진 특,장점은 무엇인가, 목표 설정, 목표를 이루기 위한 plan은 어떻게 세울 것인지’ 혼자였다면 막막했을추상적인 질문들에 대해 함께 이야기하는 시간을 가지면서 구체적이고 최선의 답을 얻을 수 있었다.
답을 얻는 과정을 기억을 더듬어 주차별로 정리해 보았다.
1️⃣ 나는 어떤 사람인가 생각해 보기.
첫 번째 시간은 ‘나는 어떤 사람인가’에 대한 브레인스토밍으로 시작했다. 다양한 역할로서의 나를 생각해 보고 이를 조금씩 구체화하는 시간이었다. (사실 개발자로서의 ‘어떤’ 사람인가 보다 그 외적인 면(여행가, 러너, 테린이, 다이빙 마스터 등)이 더 많이 떠올라서 약간 민망, 뜨끔했다. 나는 개발을 별로 안 좋아하는 사람인가 싶은 생각이 들었다.)
수업의 마지막 즈음엔 불완전한 문장이 완성되었다. (불완전하다고 한 이유는 계속 발전시켜야 하기 때문이다.)
‘넓고 다양한 생각과 시야를 가진 백앤드 개발자’ ‘문제가 해결될 때까지 집중해서 파고드는 백앤드 개발자’
2️⃣ 특장점을 이용해서 나만의 브랜드 문구 만들기.
두 번째 시간에는 나의 특징, 장점을 알아보고 첫 번째 시간에 했던 문장을 조금 더 발전시키는 시간이었다.특장점을 알아보기 위해 인터넷에서 무료로 할 수 있는 강점 찾기와 주변 지인들에게 나에 대한 질문을 던졌다. 그렇게 정리된 강점은 창의성, 호기심, 학구열, 친절 등이 있었다. 이를 바탕으로 다시 한번 문장을 작성해 보았다. (이번엔 너무 길다고 느꼈다...)
‘동료들과 소통, 공감을 잘하고 가끔은 남들이 생각하지 못한 방향으로 문제를 해결하고 강한 책임감을 가지고 맡은 업무를 하는 백앤드 개발자’
3️⃣ 브랜드와 대외 활동에 관련된 특강.
세 번째 시간은 특강이었다. 송요창 님과 이야기를 나눠보는 시간을 가졌다. 먼저 왜(WHY) 개발자가 퍼스널 브랜딩을 해야 하는지 이유를 구체적인 예시(금전적인 도움, 커리어적인 도움 등)와 함께 말씀해 주셨다. 그리고 지금까지 본인이 했던 과정들(토이프로젝트, 블로그, 출판 등등)에 대한 설명과 어떻게(HOW) 브랜딩을 시작하면 좋을지 구체적인 방법까지 제시해 주셨다. 특강을 한 문장으로 표현하자면 ‘Just Do It’ 이였다.
4️⃣ 나만의 단/중/장기 목표를 고민.
네 번째 수업에선 다시 한번 나를 표현하는 문장을 다듬었다. 그리고 커리어적으로 단기, 중기, 장기 의 목표를 설정해 보는 시간과 목표를 위한 활동을 고민해 보는 시간을 가졌다. 생각해 보니 개인적으로도, 커리어적으로도 목표를 세워본 게 오래전 일이라는 것을 하면서 깨달았다. 짧은 시간에 목표를 도출하긴 어려웠다. 떠올린 목표들도 많이 추상적이었다. 함께 나눈 이야기를 바탕으로 구체화하는 시간을 갖기로 했다.
이번 시간엔 수민 님의 피드백을 받아 문장을 다듬어보았다.
‘ 다양한 시각으로 문제를 바라보는 백앤드 개발자.’ ‘새로운 해결책을 발견하여 제시하는 것을 좋아하는 문제해결사’
5️⃣ 대외 활동에 대해 컨설팅 특강.
다음 수업은 두 번째 특강이었다. 특강의 연사는 임동준 님과임성현 님이었다.이번시간엔 단/중기 목표를 바탕으로 생각해 본 대외활동을 어떻게 해야 하는지가 주된 내용이었다. 그리고 질의응답 형식으로 진행되었고 두 분의 많은 이야기 중에 기억에 남는 두 가지만 써본다면 다음과 같다.
‘무대가 나를 찾아오게 하라’
무대는 준비된 사람에게 찾아오는데 준비는 수많은 과정 속에서 완성된다고 말씀하셨다. 그렇기 때문에 시행착오의 과정을 기록하는 것은 매우 중요하다고 했던 게 마음에 와닿았다.
‘준비가 덜된 상태에서 받은 피드백이 나를 바꾼다’
스스로 완벽하다고 생각하는 사람은 어떤 피드백도 잘 받아들이지 않기 때문에 불완전한 지금의 모습에서 여러 피드백을 통한 발전이 중요하다고 말씀하셨다. 항상 준비가 덜 된 모습은 창피해서 꼭꼭 숨기기 바빴던 예전의 나를 떠올리면서 내게 필요한 문장이라고 생각했다.
이것 말고도 현실적인 이야기들도 많이 해주셔서 정말 도움이 많이 되는 시간이었다. 이번 특강도 한 문장으로 표현하자면 ‘Just Do it’이었다. 특강을 듣고 얼마 후 블로그에 짧은 글 한편을 쓰면서 배움을 실천해 보았다. <일단 쓰고 생각하기>
동준님, 성현님과 함께 찍은 단체 사진
6️⃣ 올해 나만의 대외 활동 계획 작성.
마지막 시간엔 서로 고민해서 작성해 온 브랜딩 차트, 목표, 그리고 2023년 대외활동 계획을 공유하고 피드백받는 시간을 가졌다.
나는 계획이 추상적이라는 피드백을 받았는데 스스로도 동의하는 부분이었다. 목표가 추상적이다 보니 계획도 추상적인 느낌이었다. 그래서 목표부터 최대한 구체적으로 작성해보려고 했고 다른 분들의 공유내용도 벤치마킹하면서 계획을 다시 세워보았다.(작성한 내용은 다음 글에 공유해 보도록 하겠다.)
그리고 과정의 마지막에 작성한 문장은 아래와 같다.
창의적이고 다양한 방법을 이용해서 문제를 효율적으로 해결하는 생각하는 개발자 긍정적인 에너지를 가지고 동료들과 협업, 공유를 통해 성장을 도모하는 팀원 배움을 어려워하지 않고 적용해 보는 것에 희열을 느끼고 공유를 할 줄 아는 개발자
이렇게 작성했다. 처음과 비교하면 많이 구체화된 느낌이 든다. 쓰고 나니 나를 소개하는 문장이기도 하지만 내가 되고 싶은 모습 같기도 했다.
이 문장의 내가 되기 위해 많이 노력해야겠다 생각했다.
마무리
6주의 과정을 통해 추상적인 솔루션이 아닌 구체적인 액션플랜을 얻었다. 그리고 나에 대해 깊게 생각해 보는 시간을 가지면서 어떤 색으로 브랜딩을 할지 방향성을 세울 수 있었다. 퍼스널 브랜딩이란 ‘긴 연대기적 과정’이기 때문에 액션플랜들을 실천하다 보면 언젠가 나도 ‘회사+나’가 아니라 ‘나’라는 브랜드를 만들 수 있지 않을까? 생각했다.과정은 끝났지만 이제 시작인 느낌이다 ㅎㅎ
마지막 날 민석 님이 이런 질문을 했다.
‘2023년 마지막에 어떤 사람으로 기억되고 싶나요?’
먼저 2023년을 어떻게 기억하고 싶은지부터 정리해 봤다.
개발자라는 업을 시작한 뒤 (2017년) 처음으로 커리어에 대한 깊은 고민을 했고 목표를 세운뒤 이를 이루기 위해 구체적인 많은 활동을 한 2023년.
얼마 전 기획팀에서 쿠폰 기능에 개수 제한 기능을 추가하고 싶다는 요청이 들어왔다. 로직 설계는 심플했다.
갯수에 대한 상태 프로퍼티를 추가한 뒤 요청이 올 때마다 상태 변경한 뒤 쿠폰을 지급 또는 exception 처리를 하면 되었다.
비즈니스 로직 설계
하지만 이 경우, 동시성 이슈가 발생해서 간헐적으로 설정한 갯수보다 더 많은 쿠폰을 발급할 가능성이 있었다.
결국 이 요청사항의 핵심은 동시성 이슈를 해결하는 것이었고 이에 대한 방법을 찾아보고 도입해 보기로 했다.
동시성 이슈를 해결하는 방법
1. Synchronized 키워드
synchronized 키워드
가장 먼저 떠오른 방법이었다. 멀티스레드 환경에서 동기화 처리를 위해 자바에서 제공하는 키워드로서 synchronized 블록 단위로 Lock을 걸기 때문에 동시성을 보장할 수 있었다.
하지만, 어노테이션이 적용되는 범위가 메서드이다보니 불필요한 로직들도 lock이 잡히고, 성능상 오버헤드가 심하다고 한다. 또한 단일서버가 아닌 멀티서버 환경에서는 동시성을 보장받지 못하는 점 때문에 이 방법은 적용해보지 않았다.
2. Optimistic Lock(낙관적 잠금)
낙관적 잠금의 프로세스 ( https://sabarada.tistory.com/175 블로그 참고)
데이터의 버전을 체크하면서 데이터의 정합성을 유지하는 방법이다. 실제로 lock을 잡는 방식이 아니기 때문에 성능적으로도 좋다고 한다.
하지만, 정합성 체크를 커밋 시점에 하기 때문에 충돌이 발생한 경우 해당 트렌젝션에 대한 롤백 처리가 필요하다.
여러 트렌젝션으로 묶인 로직이라면 롤백 처리가 복잡해질 수 있고 충돌이 자주 발생한다면 롤백으로 인한 오버헤드가 크게 발생할 수 도 있다고 한다.
쿠폰 발급 처리의 경우 보통 이벤트로 인해 요청이 몰리게 되는 경우가 많다. 그렇기 때문에 해당 방식도 적합하지 않다고 판단하였다.
3. Pessimistic Lock(비관적 잠금)
비관적 잠금의 프로세스 ( https://sabarada.tistory.com/175 블로그 참고)
비관적 잠금은 트렌젝션이 시작할때 lock을 거는 방식이다.
배타락(Exclusive Lock), 공유락(Shared Lock) 두 가지 옵션이 있다.
배타락은 하나의 쓰레드에서 lock을 획득했으면 해제되기 전까지 다른 스레드에서 읽기/쓰기가 모두 불가능한 방식. (쿼리로 표현하면 select for update)
공유락은 하나의 쓰레드에서 lock을 획득했으면 해제되기 전까지 다른 스레드에서 읽기는 가능 쓰기는 lock을 획득해야 가능한 방식.
비관적 잠금은 작업 처리 과정 중 데드락이 발생할 가능성이 있다는 단점이 있고 처리시간이 길 경우 대기시간에 따른 성능이 저하될 수 있다고 한다.또한, JPA와는 달리 R2DBC에서는 낙관적 락만 지원, pessimistic lock은 지원하지 않았기 때문에 다른 방식을 찾아보았다.
4. DB Internal Lock
MySQL internal Lock은 데이터의 동시성 처리를 위해 MySQL 서버에서 제공하는 방법이다. 총 3가지로 제공하고 있다.
Row-Level Locking
Table-Level Locking
User-Level Locking
Row-Level Locking은 Row 수준으로 Locking을 하는 것이고, Table-Level Locking은 개별 테이블 단위로 설정되는 Locking이다. User-Level Locking은 사용자가 지정한 문자열에 대해 키를 생성하고 해당 키로 잠금을 거는 방식이다.
보통 서비스에서 db 연동은 해두고 쓰기 때문에 초기구축이나 작업 비용이 적다는 장점이 있었다. 하지만 동시에 여러 프로세스가 접근한다면lock을 얻기위한 시도로 인해 부하 발생이 가능했고 트랜잭션에 대한 connection pool 관리가 필요했다.
5. Redis를 활용한 방법
lettuce를 활용한 방식
set when not exists(setnx) 방식으로 cache setting을 통해 lock을 거는 방법이다.
만약 spring framework에서 이미 redis를 사용한다면 라이브러리 추가 없이 사용가능하다.
lettuce는 spring-data-redis 라이브러리에서 제공하는 클라이언트이다. 또한 트랜잭션에 대한 connection pool 관리 필요 없다.
하지만 스핀락 방식이기 때문에 동시에 많은 스레드가 대기 상태라면 redis에 부하를 줄 수 있다고 한다.
redisson을 활용한 방식
Pub-Sub 기반이라서 thread의 재시도에 따른 redis 부하가 발생하지 않는 방식이었다.
별도의 라이브러리를 사용해야 한다는 점이 걸리긴 했지만 생각보다 구현이 간단했다.
DB와 redis의 부하를 신경 쓰지 않으면서 비즈니스 로직에 좀 더 집중할 수 있는 이 방식을 선택해서 서비스에 적용해 보았다.
Redisson 도입기
Redisson dependency 설정(gradle)
implementation("org.redisson:redisson:3.16.3")
redission client 객체를 생성을 위한 설정 로직
fun redissonClient(): RedissonClient {
val config = Config()
config.useSingleServer().address = "redis://${redisWriteProperties.host}:${redisWriteProperties.port}"
return Redisson.create(config)
}
1. "limitCoupon"이라는 name으로 lock을 생성한다. 2. tryLock method를 이용해서 락 획득을 시도하다.
3. 락을 획득한 상태에서 비즈니스 로직(쿠폰발급)을 수행한다.
4. 명시적으로 lock을 해제한다.
락을 요청하는 횟수를 정할 수 있다. 소스에서는 총 3번 요청하고 그 사이에 획득을 하지 못한다면 emptyList를 return 하도록 했다.
요청할 때 파라미터를 지정할 수 있다. tryLock method의 파라미터를 살펴보면 첫 번째는 waitTime(락을 기다리는 시간)이다. 두 번째는 leaseTime(획득한 락을 자동으로 해제하는 시간)이다. 세 번째는 시간단위를 나타낸다.
waitTime동안 lock을 획득하지 못한다면 tryLock 함수는 false를 리턴하게 된다. 참고로 waitTime을 명시하지 않으면 즉시 값을 return 하게 되고, leaseTime이 명시되어 있지 않으면 watchDogTimeout값이라는 것을 이용하는데 default로 30초이다.
waitTime과 leaseTime을 적절하게 setting 하는 것은 중요하다.
만약 비즈니스 로직이 leaseTime보다 오래 걸린다면 처리과정 중 lock이 해제되고 해당 락은 다른 thread에 의해 선점될 수 있다. 그리고 락이 해제되었기 때문에 unlock() 메서드를 실행할 때 예외가 발생하게 된다.
동시성 테스트
1. Test1: 동시성을 고려하지 않은 로직에 coroutine을 이용해서 쿠폰 발급받기
쿠폰 제한 수량은 100개로 등록, 유저 100명의 요청을 10개의 worker로 나눠서 동시에 발급 요청했음.
test("case1 동시성 고려하지 않은 쿠폰 발급(10개 thread 동시에 처리)") {
val headerMap = mutableMapOf<String, String>()
headerMap["x-balcony-id"] = "BOOMTOON_COM"
val reactorContext = Context.of(
"BALCONY_CONTEXT",
HttpHeaders.readOnlyHttpHeaders(LinkedMultiValueMap<String, String>().apply { setAll(headerMap) })
).asCoroutineContext()
val userIds = List(100) { i -> i + 1 }
withContext(reactorContext) {
serviceOperator.execute {
userIds.chunked(10).forEach { userIds ->
launch {
userIds.forEach {
couponRedisService.notConcurrentlyReceiveLimitNormalCoupon(it.toLong(), 96)
}
}
}
}
}
}
테스트 결과 로그는 위와 같았다. 해당 값은 발급 전 남은 쿠폰의 개수를 출력한 것이다. 실제로 DB에 저장된 데이터를 확인해 보면 100명 모두 쿠폰을 발급받았지만 남아있는 쿠폰은 81개였다.
데이터 불일치 문제가 발생한 것이다.
2. Test2: redisson을 이용한 로직으로 동시에 쿠폰 발급받기
조건은 test1과 동일했다. 단지 발급로직에 redisson을 이용해서 lock 처리가 추가되었다.
test("Redis coupon 100번 동시 호출") {
val headerMap = mutableMapOf<String, String>()
headerMap["x-balcony-id"] = "BOOMTOON_COM"
val reactorContext = Context.of(
"BALCONY_CONTEXT",
HttpHeaders.readOnlyHttpHeaders(LinkedMultiValueMap<String, String>().apply { setAll(headerMap) })
).asCoroutineContext()
val userIds = List(100) { i -> i + 1 }
withContext(reactorContext) {
serviceOperator.execute {
userIds.chunked(10).forEach { userIds ->
launch {
userIds.forEach {
couponRedisService.receiveLimitCoupon(it.toLong(), 96)
}
}
}
}
}
}
테스트 결과는 다음과 같았다.
2개의 쿠폰이 남았길래 확인해 보니까 2명이 lock try timeout으로 받지 못한 것을 확인할 수 있었다. 하지만, 테스트 결과는 정상이었다. 총 98명이 받았다. 테스트를 로컬환경에서 진행 중이었는데 서버의 성능에 영향을 많이 받는 것을 알 수 있었다.
waitTime을 약간 늘려서 다시 테스트해 보았을 땐 정상으로 전부 처리된 것을 볼 수 있었다. 위에서 언급한 'waitTime과 leaseTime을 적절하게 setting 하는 것은 중요하다.'를 다시 한번 느꼈다.
100명의 유저가 80개의 쿠폰을 발급받는 테스트도 진행해 보았다.
테스트 결과, 쿠폰 발급 수는 80개였고 20명은 발급받지 못한 것을 확인할 수 있었다.
마무리
한 가지 문제를 해결하는 데는 다양한 솔루션이 있다.
동시성 이슈를 해결하는 방법도 위에서 언급한 것처럼 다양하게 있다.
어떤 솔루션이 자신의상황에 가장 적절한지 충분히 고민해 본 다음에 적용하고 테스트해 보는 습관을 들이자.
