요즘 밖을 나가면 매일 하늘이 푸르고 맑아 참 높다. 전 세계를 뒤덮은 질병이 이러한 맑고 높은 하늘을 만들었기에 아이러니하다. 질병은 전 세계를 뒤덮고 가족과 지인,  모두를 이간질하며 거리두게하였고 질병은 오프라인 기반 사업하던 우리 회사를 속되게 표현하여 쫄딱 망하게 하였다. 결국 우리 팀원도 20명에서 3명으로 줄었으며 큰 짐을 짊어지게 되었다.

아이러니하게 높고 맑은 하늘의 시원한 봄날에 이 조직은 더 이상의 유지가 불가능하다는 통보를 받았다. 그렇지만 그만두기에는 그날은 너무나 맑고 푸른 하늘이 우리를 위로했다.

야속하다, 만약 마지막이 될뻔한 날이 이전처럼 누런 하늘이였다면 아무런 미련 없이 그곳에서 빠져나왔을 것 이다. 하지만 그날은 - 그달은 - 그해는 봄날이 참 맑고 푸르렀다.

맑고 푸르른 높은 하늘이 내일의 희망을 주었다.

전 회사에서 무엇을 해야 하는지 애매한 상황에 난 담담하게 내 할 일을 했다. 당연하다고 생각했던 react + webpack 도입이나 인프라 정리, 테스트 코드 기반 작업, 공통 모듈 라이브러리화, 레거지와 주석 코드 정리를 했다. 생각보다 오랜기간동안 진행했고 그때 스트레스를 많이 받았다.

다시 당연하다고 생각했던 것들을 해야 할 시간이다. 하지만 과거에 내가 했던 것들을 알아주는 사람이 있을까? 란 고민이 깊어져 가며 내가 굳이 해야 할까 싶은 마음이 크다. 다른 사람이 해결했다면 짧은 기간에 더 안정적으로 했을 텐데.

어느 순간부터 IntelliJ에서 .properties 파일 인코딩이 깨지는 이슈가 생겼습니다. 원래는 하단 메뉴바에 인코딩 옵션을 선택해서 파일 인코딩을 수정할 수 있었지만 하단 메뉴바에서도 수정할 수 없게 되었습니다.

message.properties 파일 인코딩은 utf-8 이지만 ISO-8859-1 으로 수정이 불가능 합니다. 이럴 경우 맥 OS 기준으로 ⌘ command + ⇧ shift + a (Find Actions) 혹은 ⌘ Command + , (Preferences) 에서 file encodings를 검색하면 아래와 같은 메뉴가 나옵니다.

아래 Properties Files에 Default encoding for properties files: 옵션을 Default(ISO-8859-1) 에서 utf-8로 변경하면 됩니다.

"이게 안돼요.", "오류가 나요" 같은 질문을 많이 받아봤다. 이러한 질문은 상당히 피곤한 질문이다. 왜 피곤하냐면 모든 과정을 역으로 질문하고 결과를 재차 확인해야 그 다음에 원인과 해결책, 답을 고민할 수 있기 때문이다.

이런 문제들을 해결하는 방법은 보통 뻔하다. 에러 로그를 자세히 읽어보지 않았지만 브라우져 탭들과 에러 stacktrace를 대강 보면 어떤 문제가 있는지 감이 오는 경우가 많다. 하지만 정해진 답을 주는 것 보다 함께 해결하는 것이 중요하다고 생각한다. 내가 틀릴 수도 있고 더 나은 답을 함께 찾을 수 있기 때문이다.

생산적인 질문을 하기 위해선 목적과 과정 그리고 결과를 함께 설명해라. 문제가 무엇인지 거시적으로 이해하고 설명할 수 있는 것이 우선이다. 그리고 역질문을 하기 전에 최대한 많은 정보를 공유해야 빠른 해결에 도움이 된다.

자신이 생각한 해결 방법도 함께 말해주면 좋다. 해결 방법은 추상적이여도 좋다. 이는 문제 해결 능력에 도움이 되고 질문을 받은 사람도 새로운 답을 발견할 수 있어 함께 문제를 해결한다는 의미가 있다.

"이런걸 하고 싶고 이런걸 했고 이런 상황에서 이런 오류가 생깁니다. 이렇게 하면 될거 같지만 잘 안돼요." 가 내가 생각하는 제일 좋은 질문이라고 생각한다.

나도 "어디야?" "뭐해?" "이거 어떻게 할까요?" 같은 추상적이고 목적없는 질문을 가끔 하기에 이 글은 스스로에게 하는 충고이다.

20대 남성에게 선물하면 80% 확률로 좋아하는 선물 TOP 2

지갑

10 ~ 60만원 사이로 지갑을 선물하면 99% 만족할 것이다. 만약 명품 지갑이 있다면 애매할지 모르니 미리 어떤 지갑을 쓰는지 알고 선물하는 것이 좋다. 금액은 관계의 깊이에 맞게 설정하면 된다.

만약 가족이 선물하는 경우 비쌀수록 잃어버릴 확률이 낮고 매일 들고 다니기 때문에 오래 기억된다. 노트북 선물보다 높은 기대 효과를 볼 수 있다.

지포 라이터

흡연 여부와 상관없이 라이터는 은근히 필요한 경우가 많다. 강한 임팩트를 준다. 더군다나 선물하기 최적화된 상품이다. 가령 카카오 Gift라던가 선물패키지 라던가. 금액대는 1만원에서 10만원까지 다양하다.

꼭 라이터 기름도 함께 선물해야 한다. 편의점에서 쉽게 구매할 수 있지만 구하기 은근히 귀찮고 지포 라이터는 가만히 있어도 기름이 닳기 때문에 함께 선물해야지 오래간다.

지금 우리 팀이 개발하고 있는 서비스에 iOS를 제외한 백엔드, 백오피스 프론트, 안드로이드를 전부 Kotlin으로 개발하고 있다. Kotlin을 선택한 이유는 2가지인데 첫째는 개인 선호고 두 번째는 적은 리소스로 빠르게 개발하기 위한 전략적 이유였다. 정말 빨랐는가? 묻는다면 처음은 빠르지 않았다. 지금은 Spring Boot와 Kotlin은 어느 정도 성숙한 조합이지만 KotlinJS와 Kotlin Multiplatform은 아직 알파버전에 실험적인 스펙이라 프론트를 KotlinJS로 개발하는데 많은 삽질이 있었다. 이미 Wrapping된 UI Component(MUI나 RingUI)를 사용해도 되지만 Ant를 사용하기 위해 모든 컴포넌트를 Kotlin으로 정의하기도 하고 Gradle과 씨름 한판을 하며 많은 우여곡절이 있었다.

그리고 서비스를 런칭하고 작은 업데이트를 진행하며 느낀 점은 단단하단 느낌이었다. 이 감정의 시작은 Kotlin의 Null-Safety다. !! 와 같은 operator를 최대한 사용하지 않고 Nullable을 고려하니 NullPointException은 보지 못했고 프론트엔드에서도 자바스크립트를 사용했다면 느슨한 null check로 버그가 발생할 위험이 있지만 KotlinJS를 사용하니 서버 Response가 NotNull에서 Nullable로 바뀌는 특수한 경우가 아니면 자주 발생하는 위험 요소가 사라진 것이 단단한 느낌을 주었다.

Spring, KotlinJS(React), Android 코드 스타일이 다르다. Spring은 블로킹, KotlinJS는 { } 로 마크업 언어와 같이 표현하고 Android의 경우 Extension, Listener와 Courutine으로 논블로킹 방식으로 개발하게 되는데 이에 익숙해진다면 각 코드 스타일에 영감을 주는 형태로 발전한다. 플랫폼을 넘나들며 개발하는데 혼란스러움이 없고 긍정적인 효과를 주는 것은 단단해진다는 느낌을 느끼게 해준다.

KMM 또한 시도하였지만 일정상 문제로 우선은 Draft 시켜두었다. 앞으로 틈틈이 준비해서 최소한 DTO와 같은 것들은 iOS포함해서 모든 플랫폼에서 공유할 수 있게 설정하는 것이 목표다. 이에 장점은 생략하겠다. 슬슬 채용도 해야 해서 이 글을 작성하며 떠올린 우리가 원하는 개발자를 간략하게 적어둘 필요가 있겠다.

• Gradle/Maven과 씨름해도 절대 지지 않는 사람.
• Kotlin 코드를 아름답고 이해하기 쉽게 작성할 수 있는 사람.
• 아직 도전자가 적은 이 환경에서 살아남을 수 있는 강인한 모험가.

나는 7년 동안 일하면서 휴가가 항상 남았다. 내년으로 이월할 수 없다면 그냥 12월은 자체적인 주 4일 근무를 하고도 2~3개 정도의 휴가가 남았었다. 주변 사람들 이야기와 나 스스로 느끼기에도 나는 일하는 것을 좋아한다. 의미 없는 시간을 보내며 쉬는 것은 주말이면 충분하다고 생각한다. 평일에 의미 없이 쉬게 된다면 항상 스트레스받았다. 백신 3차를 맞고 몸이 무겁고 머리가 어질어질해서 오후 반차를 쓰고 온 지금도 상당한 스트레스를 받고 있다. 그래서 두통약을 먹고 조금 진정된 지금 이런 글이나 쓰면서 나를 위로하려고 한다.

초등학교 때 가정에 문제가 있어 학교가 가기 싫은 날이 종종 있었다. 어울리지 못하거나 따돌림을 받은 것도 아니었고 그냥 가기가 싫은 날은 학교에 가지 않았다. 그때 느낀 감정은 혼나거나 앞으로 일어날 일에 두려움이 아닌 따분함이었다. 그래서 어느 순간부터 학교에 가는 것이 즐거웠다. 그곳엔 공부도 해야 하고 싫은 친구들도 있었지만, 그냥 무언갈 한다는 것이 즐거웠다. 내가 하고 싶은 일을 하고 밥벌이하게 되었을 때 야근도 재미있었다. 일정 때문에 새벽까지 집에 못 가고 있을 때 직장동료와 편의점에 가기 위해 걸었던 새벽 거리에 공기는 날 살아있다고 느끼게 해주었다.

올해는 특별했다. 운전면허를 따기 위해 6개월 동안 10개의 휴가를 사용했다. 10개나 쓴 이유는 너무 많이 떨어져서다. 시험에서 떨어질 때마다 든 생각은 또 휴가를 써야 하는 데에서 시작하는 스트레스였다. 주말에 연습과 시험을 볼 수 있지만 한 달 뒤 일정밖에  없어서 고민을 많이 했다. 이른 오전에 보는 것은 운전 후 피로도가 너무 심했고 퇴근 후 저녁 시간은 불확실 했다.

남은 연차가 사라질 때마다 눈치 보이고 스트레스를 받기 시작했다. 지금 상황에서 내가 면허를 따는 게 맞을까? 싶은 생각도 들었고 포기하고 싶다는 생각도 들었다.

몸에서 열이 난다. 부작용이 아닌 쉬고 있다는 생각에 스트레스로 열이 난다. 뻔뻔함으로 식힐 필요가 있다.

2주 전에 청담동에 위치한 스타벅스 청담스타R점을 방문했습니다. 압구정로데오역에서 나와 언덕 위에 있는 이곳을 바라보았을 때 첫인상은 어색함이었다. 저곳에 스타벅스가 있다고? 라는 생각과 언덕을 올라가며 장소에 가까워질수록 어색함은 호기심으로 바뀌었다. 왜 이곳에 스타벅스가 있을까?

청담스타R이 어색했던 이유는 큰길에서 접근성이 매우 떨어지는 언덕 위에 있기 때문이었다. 상당히 가파른 언덕 위에서 보이는 스타벅스 로고는 말로 표현할 수 없는 오묘한 느낌을 주었다. 이곳은 다른 스타벅스 매장에 비해 크기가 커서 그런지 주말 인데도 빈자리가 있었다. 자리에 앉아 음료를 주문하고 이곳 리뷰를 찾아보았다. 많은 사람들이 이곳에 접근성이 매우 떨어진다고 리뷰를 남겼는데 내가 어색했던 것은 바로 그러한 이유였다. 이곳은 매우 접근성이 떨어진다. 가파른 언덕 위에 있어 걸어서 올라가기 힘들고 다른 매장에서 보기 힘든 주차장이 있지만, 가격은 매우 비싸고 기계 주차라는 제한도 있다. 그런데 왜 이곳에 스타벅스가 있을 수 있는 것일까?

단순하게 이곳이 청담이라고 하기에는 모든 것을 설명해주지는 못한다. 아무리 스타벅스가 어느 매장이건 주말에 앉을 수 있는 자리를 찾기가 힘들 정도로 인기가 많아 “사람이 많은 곳에 스타벅스가 있는 것이 아니라 스타벅스가 있는 곳에 사람이 많은 것이다.” 할 정도로 인기가 많지만, 접근성이 정말 떨어지는 곳에 있는 것은 나로서 많은 호기심을 가지게 했다.

검색을 해보니 신세계 회장 건물이라 입점했다는 기사도 찾을 수 있었지만 정말 단순하게 그러한 이유에서 입점했을까? 라는 의문과 함께 가설을 생각해보았다. 단순하게 큰길가는 청담 임대료가 너무 비싸서 그나마 저렴한 언덕 위에 입점한 게 아닐까 생각했다. 리저브 매장이라 고가에 프리미엄 음료와 푸드를 판매하지만, 가격은 결국 고정 가격이고 같은 상품은 어딜 가던 똑같은 가격이다. 결국 많이 팔아야 유지가 되는 게 아닐까? 그럴수록 접근성이 제일 좋은 곳에 입점해야 하지 않을까? 라고 고민한 순간 내가 큰 착각을 하고 있다는 것을 깨달았다.

나는 지하철을 타고 와서 역에서 출발했다. 나의 기준에서 청담스타점은 접근성이 z축으로 +n만큼 위에 있어서 접근성이 떨어진다고 생각했다. 그곳에 접근성 기준점은 나의 기준보다 z축으로 +n위에 있어서 그곳에 있는 것이 어쩌면 너무 당연할 수도 있다.

다시 생각해보니 언덕 위에서 보이는 커다란 스타벅스 로고의 이질감은 거기에서 나오는 것이 아닐까 생각한다.

“OO분은 검도 4단에 칼이 정말 바르고 주변에 많은 분들이 칭찬하는데 늘 겸손하게 자신은 아직 부족하고 잘 못 한다고 하셔. 정말 잘하시는데 가끔 보면 교만한거 같기도 해.”

라는 얘기를 들었을 때 순간 많은 생각이 들었다. 나도 검도를 8년 정도 하고 소년 초단에 중학생 때는 검도 특기를 고민했던 적도 있다. 청소년부를 마치고 성인부까지 2타임을 운동하고 그 당시 수련하시는 어른분들에게 빠르고 자세가 좋다는 칭찬을 많이 들었다. 칭찬은 나를 2타임을 운동하게 할 수 있는 원동력이 되었다. 나이가 들고 많은 칭찬을 듣고 칭찬하며 겉치레와 진심 사이에서 칭찬은 조금 부담스러운 것이 되었다.

검도는 예를 중시하여 시합에서 이기더라도 승리의 기합이나 동작하지 않고 묵묵하게 인사하고 나와 끝까지 예를 갖추고 겸손하여지도록 한다. 더 넓게 아시아권에서는 겸손하도록 가르치고 겸손하여지도록 하는 사회적 분위기가 조성되어 있다.

내가 생각하는 겸손에는 무지의 겸손, 겸손, 교만한 겸손 3단계가 있다고 생각한다. 무지의 겸손은 실제로 부족해서 나오는 겸손이다. 하지만 부족하다는 사실도 모르고 겸손해야 한다는 사회적 분위기로 겸손한 자세를 취하는 것이다. 진짜 겸손은 자신의 부족함을 알고 있지만 장점은 모르고 겸손한 자세를 취하는 것이다. 교만한 겸손은 부족함을 아는 것과 상관없이 장점을 스스로 잘 알고 있지만 사회적 분위기에 맞춰 겸손한 자세를 취하는 것이다.

일을 한지 얼마 되지 않았을 때는 잘 모르기 때문에 칭찬도 겉치레라고 생각하고 의심했다. 어느정도 경력이 쌓였을 때는 나보다 대단한 사람들이 정말 많다는 것을 알기에 겸손한 자세를 가지려고 했다. 더 좋은 리더, 나보다 실력 좋은 팀원들에게 배우고 싶다는 욕심이 생기고 내가 대단하다고 생각했던 사람들에게 그런 욕심을 얘기하면 돌아오는 답은 전부 비슷했다. 그런 사람들은 나와 같은 사람이고 이제는 내가 그런 사람이 되기위해 노력해야 한다고, 그런 사람들을 만나도 결국 성에 차지 않을 것이라고. 그런 말들을 듣고선 혹시 내가 정말 대단한 사람을 만나지 못했던 건가라는 의심을 하게 되었고 만약 그런 말들이 맞더라도 “나는 이제 충분한 실력을 가지고 있어”라고 말했을때 누군가 비웃고 교만하다고 생각할까 두렵다. 이러한 생각들이 교만한 겸손일 것이고 이는 나와 팀원들에게 있어 긍정적이진 않을 것이다. 결국 이를 해결하는 위해선 스스로 성장하고 증명하고 나 자신을 인정하며 당당해지는 방법밖에는 없을 것이다.

최근 Spotify에서 연말 결산 기능이 출시되어서 한번 사용해 보았습니다. 연말 결산 기능은 페이스북, 구글포토 등에서 많이 경험해보았지만, Spotify는 조금 달랐습니다. 타 서비스에서 제공하는 연말 결산 기능은 시각적인 요소가 대부분이고 사용한 감상은 "올해는 이런 일들이 있었지" 정도였던 것 같습니다. 하지만 Spotify는 연말 결산은 시각과 청각 모든 요소를 활용해 노래를 들었던 당시의 감정을 더욱 생생하게 떠올릴 수 있었습니다.

Spotify에 메인 기능은 관심사 기반 큐레이션이지만 이 기능은 다른 서비스들과 차별점도 없고 더 좋다고 생각하지 않습니다. 다만 제가 주로 이용했고 지금도 많이 사용하는 유튜브/유튜브 뮤직과의 차이는 유튜브는 채널을 구독해야지 비슷한 음악들을 추천해주고 더 많은 음악을 들을 수 있지만 Spotify는 초반에 관심 아티스트와 장르를 픽하면 그것을 기반으로 추천해주기 때문에 저의 구독 피드를 어지럽힐 필요 없다는 것입니다.

제가 Spotify에 감탄하는 것들을 작은 디테일입니다. 플레이리스트에서 다음 곡으로 자연스럽게 넘어가는 효과, 그리고 외부 Third-Party와 연동이 저에게 큰 감동을 주었습니다. 연말 결산으로 감동을 한 당일에 필립스 휴 조명이 택배로 도착했습니다. 조명을 설치하고 Spotify와 연동하고 진짜 깊은 감동을 받았습니다. 음악 분위기에 따라 조명 온도가 바뀌고 박자에 맞춰 색이 바뀌는 것을 보며 나도 누군가를 감동하게 하는 디테일이 있는 무언가를 만들고 싶다고 생각했습니다.

중학교 1학년 때 팔이 부러진 친구를 도와준 명분으로 반장이 되었다. 2학년 3학년에도 반장을 할 수 있었던 이유는 1학년 때 반장을 했기 때문이었다. 앞서 말한 친구와 운 좋게 3년 동안 같은 반이었던 것도 큰 도움이 되었다. 고등학교  입학 후에도 "중학교 1학년 2학년 3학년 전부 반장을 했습니다." 이 한마디로 반장이 될 수 있었다. 사실 고등학교에서는 중학교와 다르게 반장을 자원하는 수와 적극도가 많이 떨어진다. 반장이란 권한은 없고 책임만 있는 역할이라 대학 입시에 도움이 된다는 얘기를 듣고 자원하는 경우가 아니면 자발적으로 후보에 지원하는 경우는 드물다.

리더쉽은 리더의 지식에서 나오는 경외심에서 시작한다고 생각한다. 나는 내가 생각하는 리더의 조건에 부합하지 않지만 "나는 리더인가"를 계속 고민한다. 자의 반 타의 반으로 반장이 된 경험을 시작으로 다음에도 반장을 할 수 있었고 4년간에 반장의 역할로 "리더"라는 프레임을 가지게 되었다. 그러한 나를 통해 개인의 강점이 드러날 수 있는 역할이나 칭찬이 얼마나 긍정적인 효과를 가져오는지 알게 되었고 프레임에 힘을 알기에 사람을 단순하게 분류하려는 MBTI를 별로 좋아하지 않는다.

만나면 서로의 MBTI를 물어보고 자신을 소개할 때나 이력서에 적을 정도로 MBTI는 대중적으로 퍼졌다. 자신을 간결하게 소개하고 어떠한 행동에 이유를 대변할 수 있는 장점도 있다. 하지만 너무 몰입한 일부는 행동의 이유를 MBTI에서 찾으려 하고 일부는 MBTI로 타인을 정의하려고 한다. 스스로 프레임을 씌우고 MBTI가 자신을 설명하는 것이 아니라 자신이 MBTI에 맞춰 가는 것을 경계해야한다.

2021년 9월과 10월은 강남스타일과 BTS 다음으로 한국에서 만든 문화에 전 세계 사람들이 열광하고 소비했던 2달이였다. 남녀노소 구분 없이 전 세계 사람들이 오징어 게임을 소비하고 2차 창작을 통해 바이럴되어 문화작품으로서 한 획을 그었고 한국을 세계에 널리 알리는 역활을 하였다. 문제는 해당 작품이 잔인한 요소가 포함되어 19세 미만 청소년 관람 불가란 사실이다.

최근 이모를 통해 초등학교 저학년생들 사이에서도 오징어 게임이 유행이라 넷플릭스를 구독할지 고민이란 얘기를 들었다. 유튜브에서도 아동-청소년을 대상으로 한 영상들에서 오징어 게임을 소재로 한 영상들을 어렵지 않게 찾을 수 있다. 오징어 게임 덕분에 넷플릭스에 가입자가 늘었다고는 하지만 모든 아동, 청소년들이 오징어 게임을 직접 시청한 경우는 많지 않을 것으로 생각한다. 그렇게 생각한 이유는 호흡이 긴 컨텐츠를 시청하는 데 익숙하지 않은 아동-청소년들이 장편에 오징어 게임을 처음부터 끝까지 볼 정도로 내용이 아동-청소년들에게 재미있는 내용은 아니라고 생각하며 컨텐츠를 선택할 수 있는 아동-청소년은 자신이 좋아하거나 즐겨보는 크리에이터가 만든 2차 창작물을 통해 오징어 게임을 접했을 것이다. 이는 19세 미만 친, 사촌 동생들과 얘기하며 내린 결론이라 실상은 다를 수 있다.

내가 하고 싶은 얘기는 청소년관람 불가 영화에 나오는 건전한? 요소들로 구성된 2차 창작물도 청소년관람 불가로 해야 하는가와 같은 현상을 비판하고 싶진 않다. 진지하고 무거운 얘기보다 내가 왜 주류문화반골기질, 속된 말로 홍대병을 가지게 되었는지 얘기해보고 싶었다. 앞서 사회문제로 서두를 쓴 이유는 대중들이 열광하는 문화에 거부감을 느끼는 나를 변호하기 위한 일종의 장치라고 생각해주면 고맙겠다.

우리 집에는 TV가 없었다. 컴퓨터도 또래보다 늦게 생겼고 그로 인해 학창 시절에는 친구들과 얘기할 수 있는 공통관심사가 없었다. TV에서 나오는 영화도 드라마도 연예인도 몰랐다. 스타 세대이지만 스타는 해본 걸 손에 꼽을 정도로 게임도 몰랐다. TV에서 나오는 아이돌이나 가수를 보고 음악을 듣던 친구들이 미니홈피에 배경음악을 설정할 때 나는 산울림 음악이나 POP TOP 100 같은 음악을 어디선가 구해서 들었다. 당시에는 최신 가요나 예능을 모르면 이야기를 나눌 수 없어 어울리기 힘들었다. 다행스럽게 나와 비슷한 친구들을 만나서 큰 문제는 없었지만 그렇지 않았다면 아마 겉돌게 되었을 것이다. 그렇게 주류문화에 필요성을 크게 느끼지 못한 나는 자유롭게 마이너 문화에 빠질 수 있었고 주류문화를 몰라 겪었던 상황이나 감정들이 마이너 문화를 만나 강한 반골 기질이 생겼다.

과거에는 대중들이 TV를 통해 동일한 컨텐츠를 소비했지만, 기술이 발달해 컨텐츠를 생산하고 소비하기가 무척 쉬워졌다. 그로 인해 개인 맞춤형 컨텐츠가 많아지고 대중들 사이에서 컨텐츠 간 문맥이 다른 것은 매우 당연한 일이 되었다. 한편으론 누군가는 어떠한 컨텐츠로부터 소외되거나 소외돼야만 하는 경우도 과거보다 극단적으로 바뀌게 된 것 같다. 그래서 만약 소외된 것 같아 외로움을 느끼는 사람이 있다면 나와 같은 사람도 있으니 안심하라고 용기를 주고 싶다.

오징어 게임은 아직 보지 않았다. 절대 보지 않을 것이다. 왜냐하면 너무 사람들이 좋아하기 때문이다. 매달 80~100GB 데이터를 소모하며 마이너 컨텐츠와 메이저 컨텐츠를 모두 섭렵하기에 모르고 싶어도 모를 수 없는 오징어 게임이 특히 싫다.

나는 왕이 될 MBTI인가?

중학교 1학년 때 팔이 부러진 친구를 도와준 명분으로 반장이 되었다. 2학년 3학년에도 반장을 할 수 있었던 이유는 1학년 때 반장을 했기 때문이었다. 앞서 말한 친구와 운 좋게 3년 동안 같은 반이었던 것도 큰 도움이 되었다. 고등학교 입학 후에도 ”중학교 1학년 2학년 3학년 전부 반장을 했습니다.” 이 한마디로 반장이 될 수

Life is a Beautiful Sport박 건

dev-tips/hibernate.hbm2ddl.auto 위험 헷지.md at master · HomoEfficio/dev-tips

개발하다 마주쳤던 작은 문제들과 해결 방법 정리. Contribute to HomoEfficio/dev-tips development by creating an account on GitHub.

GitHubHomoEfficio

스프링에서 spring.jpa.hibernate.ddl-auto=update 설정으로 Entity 객체의 변화에 따른 데이터베이스 스키마를 반영시키고 있습니다.

spring:
  jpa:
    # TODO: 실제 배포할 때 잘 설정해주자.
    database: postgresql
    ...
    hibernate:
      # TODO: 당분간은..
      ddl-auto: update
    ...

spring.jpa.hibernate.ddl-auto=update설정의 위험성은 서비스 개발 초기 단계에서 인지 됐습니다. migration 기능에 필요성을 느꼈지만, 스프링 migration 경험 부족으로 서비스 오픈 이후에 챙기기로 했습니다. 서비스가 오픈되고 관련 기능을 찾아보았지만, 만족스러운 결과를 얻지 못했습니다.

자동으로 migration 코드가 생성되는 기능이 필요했습니다. 기존에 회사에서 운영하던 서비스는 django로 개발되었고 grails를 사용해본 경험을 기반으로 스프링에도 비슷한 기능이 있으리라 생각했지만 아쉽게 그러한 기능은 찾을 수 없었습니다. 직접 쿼리를 작성하고 Flyway로 migration을 해도 되지만 migration 코드가 올바른지 테스트 할 수 있는 방법이 필요했고 기본 spring jpa naming convention을 사용하고 싶었습니다.

https://www.baeldung.com/spring-data-jpa-generate-db-schema

스키마 생성 쿼리 파일을 만드는 기능을 활용해 문제를 해결하기로 했습니다. 해당 기능을 테스트해 보며 디버거로 내부 로직을 보면 힌트를 얻을 수 있을 것 같았습니다.

@DataJpaTest(
    showSql = true,
    properties = [
        "spring.jpa.properties.javax.persistence.schema-generation.scripts.action=create",
        "spring.jpa.properties.javax.persistence.schema-generation.scripts.create-target=create.sql",
        "spring.jpa.properties.javax.persistence.schema-generation.scripts.create-source=metadata",
   ],
)
@ContextConfiguration(classes = [BookConfiguration::class])
class SchemaGenerateTests {

    @Test
    fun `test generate create sql`() {

    }

}

@EntityScan
@EnableJpaRepositories
@Configuration
class BookConfiguration

@Entity
class Book(
    var title: String,

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    var id: Long = 0L
)

create table book (id  bigserial not null, title varchar(255), primary key (id))

스키마 생성 파일이 정상적으로 생성되었습니다. 컬럼을 추가 할 수 있는지 테스트해 보기 위해 Book 엔티티에 author를 추가하고 테스트를 실행했습니다.

@Entity
class Book(
    var title: String,

    var author: String,

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    var id: Long = 0L
)

create table book (id  bigserial not null, title varchar(255), primary key (id))
create table book (id  bigserial not null, author varchar(255), title varchar(255), primary key (id))

컬럼 추가 기능은 지원하지 않는 것 같습니다. spring.jpa.show-sql=true 일 때 create table.., alter table.. 쿼리가 로그에 출력되는 것을 보면 hibernate에서 쿼리문을 생성하고 반영을 하는 것으로 추측되어 내부 코드를 찾아보았습니다. 쿼리문을 생성하는 기능은 Dialect 인터페이스 구현체에서 하기에 PostgreSQL81Dialect.java 코드를 찾아보았습니다. 새로운 컬럼이 생기는 로직을 탐색하기 위해 PostgreSQL81Dialect.java::getAddColumnString 함수에 브레이크포인트를 찍고 디버그 모드로 테스트 코드를 실행했습니다.

PostgreSQL81Dialect.java::getAddColumnString 함수 호출 스택을 탐색하고  SchemaManagementToolCoordinator.java를 찾을 수 있었습니다.

performDatabaseAction에서 스키마가 생성 및 반영되는 것을 확인하고 performStringAction 함수와  spring.jpa.properties.javax.persistence.schema-generation.scripts.action=create가 연관되었다는 것을 알 수 있었습니다. 추가로 spring.jpa.properties.javax.persistence.schema-generation.scripts.action=create으로 설정하게 되면 hibernate ddl auto 기능이 작동하지 않는다는 것도 SchemaManagementToolCoordinator.java에서 확인할 수 있었습니다. 스키마 반영을 위해서는 spring.jpa.properties.javax.persistence.schema-generation.database.action 값도 설정해줘야 합니다.  ...<script|database>.action=에는 create뿐만 아니라 update, validate도 있다는 것을 확인하고 테스트 코드를 수정했습니다.

String HBM2DDL_DATABASE_ACTION = "javax.persistence.schema-generation.database.action";

@DataJpaTest(
    showSql = true,
    properties = [
        "spring.jpa.properties.javax.persistence.schema-generation.database.action=update",
        "spring.jpa.properties.javax.persistence.schema-generation.scripts.action=update",
        "spring.jpa.properties.javax.persistence.schema-generation.scripts.create-target=update.sql",
        "spring.jpa.properties.javax.persistence.schema-generation.scripts.create-source=metadata",
        "spring.jpa.properties.hibernate.hbm2ddl.delimiter=;",
        "spring.jpa.database=postgresql",
   ],
)
@AutoConfigureTestDatabase(replace = NONE)
@ContextConfiguration(
    classes = [BookConfiguration::class],
)
class SchemaGenerateTests {
    ...
}

alter table if exists book add column author varchar(255);

테스트를 실행하니 컬럼 추가 쿼리가 생성되었습니다. migration 테스트를 위해 Testcontainer를 설정 후 spring.jpa.properties.javax.persistence.schema-generation.database.action 설정을 validate로 변경하고 다시 테스트를 실행했습니다.

@Testcontainers
@DataJpaTest(
    showSql = true,
    properties = [
        "spring.jpa.properties.javax.persistence.schema-generation.database.action=validate",
        "spring.jpa.properties.javax.persistence.schema-generation.scripts.action=update",
        "spring.jpa.properties.javax.persistence.schema-generation.scripts.create-target=src/main/resources/db/migration/update.sql",
        "spring.jpa.properties.javax.persistence.schema-generation.scripts.create-source=metadata",
        "spring.jpa.properties.hibernate.hbm2ddl.delimiter=;",
        "spring.jpa.database=postgresql",
        "spring.flyway.enabled=true",
   ],
)
@AutoConfigureTestDatabase(replace = NONE)
@ContextConfiguration(
    classes = [BookConfiguration::class],
    initializers = [SchemaGenerateTests.Initializer::class],
)
class SchemaGenerateTests {

    companion object {
        @JvmStatic
        @Container
        val container: PostgreSQLContainer<Nothing> = PostgreSQLContainer<Nothing>("postgres:latest")
    }

Caused by: org.hibernate.tool.schema.spi.SchemaManagementException: Schema-validation: missing table [book]
	at org.hibernate.tool.schema.internal.AbstractSchemaValidator.validateTable(AbstractSchemaValidator.java:121)
	at org.hibernate.tool.schema.internal.GroupedSchemaValidatorImpl.validateTables(GroupedSchemaValidatorImpl.java:42)
	at org.hibernate.tool.schema.internal.AbstractSchemaValidator.performValidation(AbstractSchemaValidator.java:89)
	at org.hibernate.tool.schema.internal.AbstractSchemaValidator.doValidation(AbstractSchemaValidator.java:68)
	at org.hibernate.tool.schema.spi.SchemaManagementToolCoordinator.performDatabaseAction(SchemaManagementToolCoordinator.java:192)
	at org.hibernate.tool.schema.spi.SchemaManagementToolCoordinator.process(SchemaManagementToolCoordinator.java:73)
	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:318)
	at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:468)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:1259)
	at org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:58)
	at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:365)
	at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:409)
	... 112 more

예상한 대로 hibernate validate 과정에서 오류가 발생했습니다. 생성된 update.sql 파일명을 flyway migration 파일명 형식으로 변경해주었습니다.

hibernate validate까지 완료 후 테스트에 통과하였습니다. 다시 Book 엔티티에 author 컬럼을 추가하고 테스트를 실행했습니다.

Caused by: org.hibernate.tool.schema.spi.SchemaManagementException: Schema-validation: missing column [author] in table [book]
	at org.hibernate.tool.schema.internal.AbstractSchemaValidator.validateTable(AbstractSchemaValidator.java:136)
	at org.hibernate.tool.schema.internal.GroupedSchemaValidatorImpl.validateTables(GroupedSchemaValidatorImpl.java:42)
	at org.hibernate.tool.schema.internal.AbstractSchemaValidator.performValidation(AbstractSchemaValidator.java:89)
	at org.hibernate.tool.schema.internal.AbstractSchemaValidator.doValidation(AbstractSchemaValidator.java:68)
	at org.hibernate.tool.schema.spi.SchemaManagementToolCoordinator.performDatabaseAction(SchemaManagementToolCoordinator.java:192)
	at org.hibernate.tool.schema.spi.SchemaManagementToolCoordinator.process(SchemaManagementToolCoordinator.java:73)
	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:318)
	at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:468)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:1259)
	at org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:58)
	at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:365)
	at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:409)
	... 112 more

alter table if exists book add column author varchar(255);

hibernate validate에서 오류가 발생해 테스트는 통과하지 못했지만 update.sql가 생성되었습니다. 새로 생성된 update.sql도 flyway migration 파일명 형식으로 변환하고 테스트를 실행하니 정상적으로 통과되었습니다.

.
└── src
    ├── main
    │   ├── kotlin
    │   │   └── com
    │   │       └── example
    │   │           └── book
    │   │               ├── Book.kt
    │   │               └── BookConfiguration.kt
    │   └── resources
    │       ├── application.properties
    │       └── db
    │           └── migration
    │               ├── V1__create_table_book.sql
    │               └── V2__alter_table_book_add_column_author.sql
    └── test
        └── kotlin
            └── com
                └── example
                    └── book
                        └── SchemaGenerateTests.kt

GitHub - Park9eon/hibernate-with-flyway

Contribute to Park9eon/hibernate-with-flyway development by creating an account on GitHub.

GitHubPark9eon

테스트를 실행하면 변경사항과 상관없이 update.sql 파일이 생성되는 이슈가 있긴 합니다. 처음에는 annotation processing을 이용해 migration 파일을 생성해주는 gradle 플러그인을 만들어야 하나, 번거롭지만 sql을 매번 작성해야 하나 고민이 깊었습니다. 하지만 만족스러운 방법으로 안전한 migration 파일을 생성할 수 있게 되어 기쁩니다. 정석적인 방법은 아닌 것 같지만 제가 찾아봤을 때 자동으로 migration 코드를 생성하는 기능은 찾을 수 없었습니다. 그래서  Django에 migration기능만 이용할까도 고민했습니다.

자바는 IntelliJ 디버거로 내부 코드를 탐색하기 편리하게 되어 있어 늘 궁금한 기능이 있다면 디버거로 탐색하는 것을 즐깁니다. 그래서 이번 시도도 무척 흥미롭고 즐거웠습니다. 더 좋은 방법이 있다면 알려주세요.