D'story

임시보관함 1개로 버티기

• 이 작업, 저 작업 왔다 갔다 진행하고 있을 때라면 더더욱 진행 상황을 보관할 곳이 필요하다. 그럴 때 쓰는 명령어가 `git stash`이다. 아직 커밋을 하기는 좀 부족한데 당장 다른 것과 섞이게 하고 싶지는 않을 경우에, 간단하게 `git stash`로 보관하고, `git stash apply`로 가져올 수 있다.
• 물론 stash의 인덱스를 활용해서 골라 가져오는 방법도 있지만, 그게 아니고서는 한 번에 하나만 보관해야 한다는 단점이 있었다. 처음부터 그 단점을 느낀 건 아니었지만, 이 명령어를 하도 사용하다 보니 가끔 아쉬웠다. A라는 작업에서 이미 `git stash`를 한 번 썼는데 B라는 작업으로 잠깐 옮겨 가서 또 다른 일을 벌이던 중에, 다시 A로 돌아가야 할 일이 생긴다거나. 한 번에 한 가지 일을 진득하게 해서 끝내버린다면 필요 없을 일이겠지만...(머쓱)

임시보관함 여러 개 쓰기

• `git stash`를 하는 순간부터 내가 이 stash에 이름을 정해주고 싶을 때는 이렇게 해 주면 된다. 예를 들어 stash_name이라는 이름을 넣어주고 싶다고 하면 이런 모양새가 될 것이다.

git stash push -m stash_name

• 나중에 이 stash를 가져올 때는 이렇게 가져오면 된다.

git stash apply stash^{/stash_name}

• 그런데 여기서 만약 stash에 띄어쓰기를 포함한 이름을 정해줬다면, 따옴표로 한 번 묶어줘야 한다. 예를 들면 다음과 같다.

git stash push -m 'I want to push this sentence'

• 가져올 때도 마찬가지이다.

git stash apply stash^{/'I want to push this sentence'}

오늘은

• 너무 오랫동안 방치되어 있던 블로그를 다시 살려내 봐야겠는데, 뭐부터 시작하면 좋을지 아주 짧게 고민하다가 그냥 두서없이 간단하게 시작하기로 했다. 시작이 반이니까
• 그런데 놀랍게도 나조차도 간만에 찾은 내 블로그에는 꾸준히도 방문자가 유입되고 있었다. 의아하기도 하고 한편으로는 부끄럽다.
• 아무튼 오늘은 시간을 되돌려 내 과거를 살짝 고칠 수 있는 방법을 소개하겠다. 별 거 아닐 수 있지만, 나로서는 자주 활용하지는 않다 보니 필요할 때마다 잊어버려서 자꾸 다시 검색하곤 하는.. 그래서 블로그에 짧게나마 남기면 나한테 좋을 내용이다.

한참 지난 커밋 수정하기

• 방금 작성한 커밋을 수정하는 것은 밥 먹듯이 있는 일이라 별로 두렵지 않은데, 가아아끔씩 지지난, 혹은 지지지지지난 커밋에서 뭔가 잘못되었다는 것을 불현듯 깨닫는 경우가 있다. 지금 생각해 보면 그건 도대체 어떻게 깨달은 걸까, 심지어 그렇게 늦게.. 그렇다고 그 뒤의 커밋들은 돌이키고 싶지 않은데, 나 분명 이거 해결하는 방법 아는데, 그 방법을 기억을 못 해서 결국 다시 구글링하게 된다. 블로그에 쓰면 그래도 적은 가능성으로나마 기억에 남을 수도 있지 않을까..?

1. 고치고 싶은 commit hash를 알아낸 후, 터미널에 다음과 같이 입력한다.

git rebase --interactive [commit hash]^​

2. vim을 이용하여, 터미널에 나타난 해당 commit의 `pick`을 `edit`으로 바꿔준 후 저장, 종료한다.
3. commit을 수정한다.
4. 수정이 끝났다면, 터미널에 다음과 같이 입력한다.

git rebase --continue​

• vim에도 git에도 익숙하지 않던 시절, 세훈님이 이 interactive 옵션을 사용하시는 걸 처음 봤었는데 그땐 왜 이걸 편하다고 말씀하시는 건지 이해할 수가 없었다. 지금은 나도 편하다. 그런데 이유는 아직도 모른다.

오늘까지(최신순)

• 오늘은 배포를 하기로 되어 있는 날이었다. 거의 모든 작업이 다 완료된 상태였고, 마지막 남은, 지난 금요일에 해결했다고 생각한 문제가 유감스럽게도 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