D'story

오늘까지(최신순)

• 오늘은 배포를 하기로 되어 있는 날이었다. 거의 모든 작업이 다 완료된 상태였고, 마지막 남은, 지난 금요일에 해결했다고 생각한 문제가 유감스럽게도 QA 단계에서 다시 돌아왔다. 문제 현상이 뭔지는 알겠는데 원인을 모르겠고 버그를 재현하는 것조차 잘 안 되는 날이었다. 하루종일 붙잡고 있다가 결국 배포 직전에 탐탁지 않게 임시방편 식으로 해결되었다. 그래서 어쩐지 기분이 좀 찝찝하다. 이 찝찝함을 블로그 재시작으로 털어버리자
• 지난 4월 중순, 새로운 업무분장에 따라 나는 팀을 옮기게 되었다. 이번 팀은 저번 팀에 비해 뭔가를 해결해 나가는 과정에서 내가 비교적 더 좌충우돌 하게 되는 경향이 있긴 한데 그래도(그래서?) 재미있다. 프레임워크도 Vue로 돌아오게 되었다. 완전히 새롭게 접하는 건 아니지만 예전 기억이 사실 가물가물하긴 해서, 옛 기억을 더듬어 가며 구글링을 해 가며 공식문서를 뒤져 가며 온갖 방법을 동원해서 하나씩 풀어 나가는 중이다.
• 지난 2월부터 2개월간 몸과 마음이 많이 지쳐서 휴가를 냈었다. 길다면 긴 기간인데 감사하게도 회사에서 병가를 낼 수 있게 해주었다. 잘 만큼 자고, 쉴 만큼 쉬고, 약 잘 먹고, 밥 잘 먹고, 그 기간 중 특별하게 더 한 것은 없지만 그 덕분에 지금 다시 정상적으로 궤도에 오를 수 있었다고 생각한다.
• 내가 잠수를 타기 전 썼던 마지막 블로그 글을 보면, 나는 재작년 10월 내가 애착을 가졌던 회사를 떠나게 되었고 다른 회사로 옮겼었다. 그리고 작년 2월에 나는 다니던 회사를 다시 떠났다. 이전 회사에서 겪었던 비슷한 문제를 그 회사도 겪고 있었기 때문이었다. 겨우 다시 마음에 드는 회사를 찾았다고 생각했는데 또 비슷한 이유로 떠나게 될 수도 있다니 황당하고 당황스러워서, 이제야말로 좀 더 안정적인 곳을 찾아봐야겠다고 생각했다. 그러던 중 이전 회사의 일부가 남아 다른 이름으로 물론 그 사이에 많은 일이 있었겠지만 여전히 서비스를 운영해 나가고 있다는 소식을 접했다. 나름대로 뒤도 돌아보지 않고 떠났다고 생각했는데, 사람 마음이라는 게 참 그렇지가 않았다. 이전 회사를 다닐 때보다 많아진 연봉을 다소 삭감하는 조건이었지만 그래도 좋았다. 옛 사랑에게 돌아가는 사람 마음이 이런 걸까 싶었다.

오늘 한 일

• 2주에 한 번씩 월요일은 한 스프린트의 마지막날이 된다. 오늘이 그날이었고, 따라서 지난주 금요일에는 이번 스프린트에서 개발한 기능들이 제대로 돌아가는지 내부 테스트와 마무리 작업을 거쳤다.
• 그러나 항상 그렇듯, 꼭 거의 마지막이 되어서야 급하게 해야 하는 작업이 생긴다거나, 그동안 풀리지 않던 것이 그제야 실마리를 내보인다거나, 또는 평소와는 다른 집중력이 발휘되어 일의 효율이 높아지기 일쑤지만 이건 내가 평소 게을러서인 것 같다. 아무튼 금요일 업무 시간이 끝나기 1~2시간 전에 여러 pr들이 올라갔고 동시다발적으로 각 피쳐 브랜치에서 dev로 머지 되었다.
• 그리고 그렇게 잘 마무리된 줄 알았지만, 주말 내내 푹 쉬고 가볍게 시작한 월요일 아침에 지난 주까지의 작업들이 개발 서버에 잘 올라갔는지 확인하던 찰나 뭔가 이상하다는 걸 깨달았다. 별다른 특이사항은 없었던 것 같은데 해당 기능이 반영되지 않은 것이었다.
• 급히 민에게 확인을 부탁했고, 그래서 aws elastic beanstalk 로그를 확인해 보니 헬스 체크에 문제가 있었고, 이것저것 찾아보다가 덴마에게 여쭤본 결과 아무래도 pr이 동시에 올라가 똑같은 워크플로우가 여러 개 돌다 보니 충돌이 일어난 것 같다는 결론을 주셨다.

오늘 배운 것

• 배포할 때 깃헙 액션에서 사용하는 워크플로우 yaml 파일에 concurrency라는 설정을 넣으면, 같은 그룹으로 묶인 워크플로우는 한 번에 하나만 실행된다. 이미 같은 워크플로우, 또는 같은 그룹의 워크플로우가 실행되고 있는 경우, 실행 중인 워크플로우를 취소하고 새로운 워크플로우를 실행할 수도 있다.

concurrency:
	group: ${{ github.ref }} # 또는 github.base_ref, github.head_ref를 넣기도 한다.
    	cancel-in-progress: true

• 공식문서에 나와 있는, concurrency 설정에 대한 자세한 설명.

• concurrency 이외에도, 효율적이고 경제적인 github CI workflow 설정에 대해 정리한 블로그 글이다.

• 많은 일이 있었다.
• 사랑하려고 노력한 적은 없었지만 사랑할 수밖에 없는 회사였다. 직장 생활 경험이 없는 것도, 짧은 것도 아니었는데 진심으로 사람을 사랑하듯 회사를 사랑하게 될 줄은 몰랐다. 일을 하는 하루하루가 행복했고, 주말은 평일을 기다리는 시간에 불과했다.
• 그런 회사가 없어졌다. 이제 좀 업무에 익숙해지고, 생활 패턴도 그에 맞게 바꿔 나가고 있던 와중에 하루 아침에 마음이 공허해졌다. 내가 곧 백수가 될 예정이므로 구직을 다시 해야 한다는 것은 오히려 아무것도 아니었다. 그건 번거롭긴 해도 그냥 하면 되는 일이었다. 심지어 나 혼자만 해야 하는 일도 아니었다. 그저 유일한 문제는, 이 회사가 없어진다는 것이었다.
• 책상을 정리하기 위해 간만에 출근한 사무실에서 누군가 그랬다. 세상에 완벽한 회사란 있을 수 없으니 이 회사도 없어지는 거라고. 그 말에 공감했다. 이런 얘기는 영화나 드라마에 나와도 비현실적이라고 손가락질 당할 소재였다. 하지만 현실은 위대했다.
• 고용 계약 종료를 한 달 앞둔 시점부터 이직 준비를 시작했다. 사람들과 아무리 회사에 대해 섭섭한 점, 아쉬운 점을 끝없이 늘어 놓으며 마음을 털어 버리려고 애써도 혼자가 되면 어김없이 밑바닥까지 가라앉았다. 닥쳐올 현실에 채찍질 당하면서 이력서를 쓰고 면접을 봐도 그때뿐이었고 자꾸 힘이 들었다. 어떤 새로운 회사에 가도 회복할 수 없을까 봐 걱정도 됐다.
• 한편으로는 내가 선택할 수 있는 범위 내에서 최대한 비슷한 분위기, 비슷한 문화를 가진 회사에 가고 싶어서 수많은 구인 공고를 보며 일말의 유사성을 찾겠다고 기를 썼다. 사실 그렇게 한다고 해도 유의미한 성과가 있을지는 미지수였다. 들어가서 근무해 보는 당사자가 되기 전에는 알 수 없는 것들이니까.
• 아등바등 바쁘게 한 달을 보낸 덕에 운 좋게도 업무일 기준 계약 종료 다음날 바로 새 회사에 출근하게 되었다. 내 나름대로 고르고 골라서 지원한 회사였고 면접에서도 느낌과 인상이 좋았지만, 혹시나 내 기대치를 충족하지 못하더라도 이제는 어쩔 수 없다고 생각했다. 하지만 출근 첫날 바로 알았다. 설마 나를 여기 오게 하려고 코드브릭이 없어진 걸까.
• 입사 9일차, 하지만 공교로운 공휴일 탓에 뭐했다고 벌써 3주차, 현재 온보딩 중인 뉴비다. 회사 자체나 구성원들, 시스템, 문화, 코드에 이르기까지 배울 것들이 넘쳐나서 정신없이 지내고 있다. 블로그에 코드브릭이 없어졌다고 아무렇지 않게 쓸 수 있게 될 날이 이렇게 금방 올 줄은 몰랐다. 회사는 회사로 잊어야 하나 보다.

지금까지 한 일

• 지난달 말이 SSO 릴리즈였기 때문에 지난달에는 기능을 개발하고 에러를 잡는 데 거의 모든 시간을 썼다. 애초에 로그인에 관련된 것들을 다루는 프로젝트였던 만큼 스코프가 아주 크지 않았기 때문에, 내가 괜히 이유 없이 혼자 걱정하고 안절부절 못한 것과는 별개로 업무적으로 부담이 크진 않았다.
• 프로젝트 성격상 시한부(...) 팀이었던 게 어느 정도 명확했던 만큼, 이후에 팀 배정은 어떻게 되며 이 프로젝트는 어떻게 되는지에 대해 얘기가 슬슬 나오기 시작했다.
• 그러다 릴리즈를 열흘 정도 앞둔 시기에, 케이트님의 퇴사로 프론트엔드가 빠지게 되는 스토어싱크 팀에 가면 적당할 것 같다는 결론이 나왔다. 그리고 스토어싱크는 8월 말에 릴리즈 예정... 릴리즈 전문?
• 그렇게 해서 SSO 릴리즈 주간에 살짝살짝 인수인계를 받으며 스토어싱크 쪽 업무에 발을 담그게 되었고, 이번주부터는 본격적으로 팀을 옮겨서 일을 시작하는 중이다.
• 개인적으로 뷰티파이를 좋아하지 않아서 SSO가 Vue 3인 게 참 마음에 들었었는데, 스토어싱크로 와 보니 여긴 Vue 2라서 뷰티파이를 쓰고 있다. 간만에 보는 Vue 2+뷰티파이 조합의 코드라 눈에 잘 익지 않았는데, 엊그제는 세훈님과 6시간짜리 페어 프로그래밍 덕에 프로젝트 디렉토리 구조를 좀 익힐 수 있었다. 어제는 세훈님이 주신 태스크를 혼자서 삽질해 보면서 연습하는 시간을 가졌고, 오늘 드디어 pr을 날릴 수 있었다. 근데 여기는 리뷰를 영어로 달아주시네요 엉엉 세훈님 말씀처럼 릴리즈 이후에라도 조만간 전체적으로 리팩토링을 할 수밖에 없는 상황이라 일단은 동작하는 코드를 만드는 데 우선순위를 뒀다.
• 지금까지 코드 읽는 것만으로도 삐걱대느라 시간이 걸렸지만 앞으로는 조금 더 속도가 붙지 않을까, 희망회로를 돌려본다.

오늘 한 일

• 요 근래 나에게 할당되었던 지라 카드는, 나 혼자서만 처리할 수 있는 게 아닌 걸 제외하고는 오늘까지 어느 정도 쳐낼 수 있었다.
• 그런데 기존 서비스에서는 회원가입할 때 비밀번호가 대소문자, 숫자, 특수문자 상관 없이 8자리 이상이면 무조건 통과되는데, sso에서는 영소문자와 숫자 8자리만 통과되게 해놓았다. 과거의 나 도대체 무슨 짓을... 이러닝 서비스 관련해서 API 문서 정리의 필요성이 대두되던 찰나 어차피 한 번은 손 봐야 하는 비밀번호 규칙을, 일단은 기존 서비스와 동일하게 맞춰 놓았다. 유효성 검사 파일을 따로 플러그인으로 빼놓는 작업을 할 때부터 비밀번호 규칙을 (딱히 존재하지 않더라도 상식적인 선에서 적당히) 염두에 두고 했을 텐데 이렇듯 엉망인 결과가 뒤늦게 나오기도 하는 거였다...어메이징 주니어 아무튼 아직은 selected for development 되지는 않은(하지만 나에게 배정된) 카드에 현황을 간단히 남겨 두었다.
• 스스로도 당연히 그럴 리 없을 거라고 생각하지만, 혹시나 어디서 이 규칙과 관련한 걸 보고 내가 그렇게 작업을 했었던가, 싶어서 피그마부터 여기저기 뒤져보았는데 그러다 점점 달라지고 있는 디자인을 목격해 버리고 말았다. 아직 많은 부분이 바뀌지는 않았지만 역시 UI에서 벗어날 수 없는 운명인가 보다. 😂

오늘 배운 것

• ㅋㅋ지금 보니 제목 너무 어그로인 것 같다. vue-i18n으로 번역을 하다 보면, 번역 대상인 텍스트 안에 태그나 컴포넌트를 통째로 넣어줘야 할 때가 있다. 예를 들면, 궁극적으로 번역하고 싶은 건 p 태그로 감싼 'Hi, my friend {name}'인데 이 name 부분에 단순 string이 아닌 b 태그를 넣고 싶다거나 하는 경우다.

<p>Hi, my friend {name}</p>

<b>{name}</b>

• vue에서는 v-html directive를 사용해서 HTML 태그를 직접 불러오게 할 수도 있다. 하지만 아래 링크에도 나와 있듯이 XSS(Cross-site Scripting) 공격에 취약한 방법이다.

• 이럴 땐 i18n-t 컴포넌트를 사용할 수 있다.

<i18n-t keypath="HI_NAME" tag="p">
	<b>{{ t("MY_FRIEND"), {name} }}</b>
</i18n-t>

en: {
	HI_NAME: 'Hi, {0}'
    	MY_FRIEND: 'my friend {name}'
},
ko: {
	HI_NAME: '안녕, {0}',
    	MY_FRIEND: '내 친구 {name}'
}

• 그래서 만약 name이라는 변수에 'Jane'이라는 문자열이 할당되었다면 출력 결과는 다음과 같을 것이다.

<p>
Hi, my friend <b>Jane</b>
</p>

또는

<p>
안녕, 내 친구 <b>Jane</b>
</p>

• 자세한 내용은 아래 링크 참고

지금까지 한 일(기억 나는 대로)

• 구글 로그인은 API 변경 이후로, 가장 최신 버전을 적용하면 버튼에 커스텀 디자인을 입힐 수 없다. API 하나하나 분해(ㅋㅋㅋ)해서 입혀 보려고도 해봤으나 쉽지 않았다. 그래서 커스텀 디자인을 넣을 수 있다는 라이브러리를 찾아서 그 코드를 뜯어 보았지만 내가 라이브러리 없이 했을 때 맞닥뜨리는 문제를 똑같이 만나게 되어서 라이브러리도 별 수 없구나 하는 것을 배웠다. 물론 문제가 다른 데 있을 수도 있지만
• 구글을 가지고 이렇게나 헤맨 것치고 페이스북 로그인은 붙이기 쉬웠다. 반나절 만에 기능을 작동시킬 수 있었고, 커스텀 디자인도 물론 페이스북의 디자인 가이드를 따르긴 해야겠지만 기술적으로는 어떤 디자인이든지(심지어는 디폴트 버튼 그 회색 그것마저도...) 적용할 수 있었다. 하지만 지난 4월쯤? 페이스북은 한 번 붙이려다가 실패를 맛본 경험이 있었는데, 그건 페이스북 API가 까다로워서라기보다는 페이스북 API는 구글과 달리 테스트조차도 무조건 https 환경에서만 가능한데, 그땐 로컬호스트를 https로 돌리는 방법을 제대로 실행하지 못했기 때문이었다. 저번에 영봉님을 통해 알게 된 caddy를 이용해서 의외로 손쉽게 이 부분을 해결하고 나니 나머지 문제는 일사천리로 해결되었다.
• 요즘은 SSO 릴리즈 일정이 잡힌 후 개발 속도를 내고 있는 주간이어서 승진님이 만들어 두신 지라 카드 작업을 하고 있다. 그 와중에 구글 로그인과 관련해서 현지 팀과 계속해서 얘기를 할 일이 생겨서 이제까지 안 쓰던 영어를 어제부터 잔뜩 쓰려니 골이 아프다. 인도네시아어 번역이 누락된 부분이라든지, 구글 로그인 버튼 자체에 언어 설정을 적용하는 것이라든지, 어쨌든 브랜치를 하나 따서 관련된 작업을 하다가 연락이 뜸한 시점에는 또 다른 카드의 작업을 하는 식으로 진행하고 있었다.
• 그 다른 카드의 작업이 마무리되어서 push를 하기 전에 git log를 한 번 확인해 봤는데, 브랜치를 새로 안 따고 구글 브랜치에 그대로 작업한 것을 깨달았다. 터미널에서 브랜치 이름 그렇게 봐 놓고도 몰랐다니 😞
• 그래서 이번에 정확히 어떨 때 사용하라는 건지 와 닿지 않았던 git cherry-pick을 처음 써 보게 되었다.

오늘 배운 것

# branch A에서 branch B로 옮기고 싶다면

# branch A에서 옮기고 싶은 commit의 hash를 적어둔다
git log

# 그리고 branch B로 바꾼다
git checkout [branch B]

# commit이 하나인 경우
git cherry-pick [hash]
# commit이 복수인 경우
git cherry-pick [hash0] [hash1] [hash2]
# 어느 범위의 commit을 통째로 옮기고 싶은 경우
git cherry-pick [older hash]^..[newer hash]

git commit

지금까지

• 개막이라도 하듯 6월의 시작과 함께 많은 일들이 있었다. 내가(또는 인간이) 참 많이 나약하다는 것을 깨달았고, 더 이상 이대로는 안되겠다고 생각했고, 병원의 힘을 빌리기로 했다. 그래서 지금까지도 병원 문턱이 닳도록 드나드는 중이다. 비록 한편으로는 약의 부작용으로 또 다른 고생을 하기도 했지만, 어찌 됐든 결과적으로 그럭저럭 상황은 이전보다는 많이 나아진 듯 보인다.
• 글을 쓸 마음의 여유가 없었는데 또 그런 것치고는 업무 시간에 알게 된, '이거 나중에 블로그에 올려야지' 하고 저장해 둔 링크들이 많다. 시간 날 때마다 조금씩 정리해봐야 할 것 같아서 오늘을 그 시작으로 할까 한다.
• 지금껏 거의 3주간 무슨 일을 했느냐 하면, ...기억이 안 난다. 이래서 기록이 중요한 건데 말이다. 계속 뭔가 해 왔고, 하면서도 '와 세상에! 나라는 바보가 이런 멍청한 실수를 한다' 하면서 자책하듯이 웃었던 적도 꽤 많았는데 진짜 하나도 기억이 안 난다. 되짚어 가면서 소급해서 적기보다는 앞으로 게을리하지 않는 게 나을 것 같다는 건 나만의 생각(합리화).

그 언젠가 배운 것

• 언젠가는 SSO에서 번역을 담당(?)하던 json 파일의 역할을 지완님이 i18n이라는 플러그인에 넘기셨었다. json 파일은 아무리 사용자가 설정한 언어에 따라서 다른 텍스트를 보여준다고 하더라도 그 과정 자체를 직접 만들어야 하고, 날것 그대로의 느낌이 있을 수밖에 없다. 하지만 i18n을 사용하면 그런 수고로움을 덜 수 있고, 상황에 따라 달라지는 변수를 넣어 텍스트를 바꿀 수도 있다.
• 그런데 이때 텍스트에 특수문자를 넣고 싶다면 이것이 말 그대로 literally string이라는 것을 알려줘야 한다(literal interpolation). 예를 들면 이메일 주소에 들어가는 @라든지. 이걸 literal 처리하지 않고 사용해 보니 콘솔에 에러가 찍히면서 화면 자체가 출력되지 않는 일이 발생했다.

• 이외에도 여러 변수를 한 번에 같이 출력하고 싶을 때에는 해당 부분을 {0}, {1} 하는 식으로 표현하는 list interpolation도 많이 사용하게 됐다.

오늘 한 일

• 오늘은 내 기준 두 번째 sso 스크럼이 있었다. 매주 두 번뿐인 스크럼이라 내가 무슨 일장연설할 것도 아니고 단지 참석하는 것뿐인데도 왠지 잔뜩 긴장하게 된다. 온보딩 팀에서는 겨우겨우 눈 뜨자마자 기계적으로 미로 보드를 열곤 했는데, 심지어 스크럼 시작 시간도 11시여서 맨정신(...)으로 들어갈 수밖에 없게 되었다.
• sso와 이어 붙일 이러닝 사이트가 화제에 올랐는데, 양쪽이 어떤 식으로 돌아가는지 서로 정보가 하나도 없는 상황이어서 유저 베이스를 통합해야 할 때 sso 플로우를 그쪽에서 잘 이해할 수 있을지 모르겠다는 얘기가 나왔다. 플로우 관련한 얘기는 나올 때마다 시간 순삭하는 주제여서 오늘도 시간 가는 줄 몰랐더니 어느새 50분이 지나 있었다. 온보딩 6분 컷도 했던 시절이 있었는데...
• 내가 가지고 있는 지라 카드 중에 회원가입 페이지가 이러닝 사이트 때문에 가장 다급(이라고 표현하기는 약간 민망)했던 작업이었는데, 일단 기본 기능만 돌아가게 하고 자잘한 것들이나 스타일 부분은 천천히 신경써도 된다는 주문에 따라 뒤로 미뤄놨던 것들이 있었다. 예를 들면, 왜 또 얘가 나오나 싶지만 아무튼 다이얼로그 UI를 디자인대로 안 한 거라든지, 조금씩 바뀌어가는 디자인 변경안들을 못 본 체했던 거라든지.
• pr을 올리고 나서 승진님이 리뷰해 주시면서 우리도 vms처럼 prettier 설정이 되어 있으면 좋을 것 같다고 하셨다. 예전에 vms UI 만질 때 자꾸 내 로컬에서만 코드 포맷이 망가져서 스트레스 받곤 했었는데, 이번에도 sso 쪽을 내가 어설프게 만졌다가 대참사가 날까 싶어서 잠깐 주저했다. 그렇지만 어쨌든 내가 계속해서 작업해 나갈 프로젝트인 만큼 두려움을 이겨내기로.
• prettier 설정 자체는 사실 내가 선호하는 대로(single quote: true라든지, tab width: 2라든지...) 해도 괜찮을 것 같았지만 우리 모두는 vms 스타일에 익숙할 테니 vms를 참고해서 설정했다. 모르는 건 그때그때 구글링 해가며 적용해봤더니 생각보다 많은 공수가 들지는 않았다. 이랬는데 오류 신나게 터지면 어쩌지
• 막판에 다른 카드로 QA에서 코멘트가 달렸지만 prettier pr까지 마무리하고 나서 스벨트로 방향을 바꿨다. 오늘은 어제에 이어서 튜토리얼을 훑으며 이건 뷰나 리액트와는 확실히 다르다 싶은 것들만 따로 정리중. 그 두 가지에는 그래도 어느 정도 적응한 내가 또 새로운 방법으로 코드를 짜려면 그게 더 직관적이고 쉬운 방식이라 하더라도 한동안 허둥댈 게 분명하니까 다음에 한 번 더 읽고 싶은 링크, 나중에라도 참고하면 좋을 링크도 모아놓고 있다. 지금 적어놓고 있는 것들이 전혀 필요하지 않을 만큼 익숙해지고 싶다.