D'story

오늘 한 일

• 요즘 그냥 계속 이유가 있어서든 없어서든 늦게 자고 피곤한 와중에 오늘(어제라고 해야 하나 싶다가도 오늘이 맞지)도 새벽까지 css와 씨름을 했다. 원래 단일 input이었던 걸 4개로 쪼개놓은 거라 css가 제대로 동작해야 무리없이 다음 기능을 확인해 볼 수가 있는데, 4개로 쪼갠 v-text-field 안에 실제로 들어 있는 각 input의 너비가 v-text-field를 초과해서 말도 안 되게 넓게 나오는 상황이었다. 그래서 기껏해야 너비 60px짜리 v-text-field에 입력한 값은 input이 너무 넓어 화면에 나오지를 않았다ㅠㅠ 뭐가 잘못돼서 이렇게 된 건지 selector를 하나하나 타고 들어가서 고쳐보고 v-deep도 붙여보고... 지금 생각해 보니 selector를 일일이 만져보기까지 한 상황에서 v-deep이 안 먹는 건 사실 당연. 잠이 부족해 이성적 판단이 불가했다. ㅋㅋ
• 그러다 어느 순간 깨닫기를, input의 최소 너비가 생각보다 구체적으로 지정되어 있었다. min-width: 143px이던가. 아니, 세상에 어느 시스템이 140도 아니고 145도 아니고 143으로 디폴트 설정을 한단 말인가. 이건 분명 사람 손을 탄 것이렷다. 심지어 !important였다. 그럼 디렉토리 전체에다 대고 검색을 하면 되겠다 싶었다. 그리고 찾았다. 찾았는데...
• 다이얼로그를 sign-in, sign-up 전용으로 띄우기로 해서 일반적으로 내용 보여주고 버튼만 누르는 다이얼로그는 공통 컴포넌트를 활용하고, 휴대폰 번호 인증을 하는 다이얼로그는 다른 페이지에서도 사용 중인 것을 그대로 복붙해서 고쳐 쓰기로 했었다. 그대로 복붙. 복붙하면서 클래스명도 복붙한 거고, 하필 복사 대상이었던 원래의 컴포넌트의 css는 scoped가 아니었다. 복사해서 고치면서 scoped를 넣으면 뭐하나, 이미 scoped가 아닌 상태로 적용된 동일한 클래스명이 있었던 것을.
• 이 문제로 시간을 많이 끌어서 대부분의 작업이 오늘 낮으로 밀려버렸다. 그리고 오늘은 휴대폰 번호 인증을 내 번호로 너무 많이 해서(같은 번호가 인증 코드를 문자로 받았음에도 계속해서 틀린 코드를 넣으면 차단되고 있다는 사실을 새로이 알았다) 밴 당했다...😩  그래서 다른 휴대폰을 급히 빌려 시도하면서 sign-in에서는 어찌저찌 진행했는데, sign-up에서는 sign-up인 만큼 완전히 새로운 번호가 필요하다는 사실을 깨달았다. 머리 터진다 🤯
• 결론: 여러 모로 나는 바보다.

오늘 한 일

• 어제는 집에서 아침 7시에 출발해서 병원에 갔다가 2시까지 사무실로 출근하고 저녁에 회식을 하고 돌아왔더니 오늘은 고민의 여지도 없이 재택을 할 수밖에 없었다.
• UI 변경 작업이니만큼 처음에는 단순하게 기존 코드에서 UI만 바꿨었다. 하지만 창현님의 제안으로 시작해서 회의도 거치고 하면서 공통 컴포넌트를 만들고 사이드이펙트를 최소화하는 쪽으로 가다 보니 결국 다시 한 번 더 같은 내용의 작업을 진행하게 되었다. 몇 번 엎으면서 하다 보니 가끔씩 코드 속에서 허우적대는 것 같은 느낌을 받고 있다..ㅠㅠ그러다 보니 진척 속도도 느리고..
• 범용적으로 쓸 수 있는 부분만 적용해 만든 공통 다이얼로그 컴포넌트를 사용하니 전체적으로 코드의 흐름이 보다 직관적으로 바뀌고 있는 것 같다. 코드의 양 자체가 이미 방대한 상태에서 시작한 작업이었기 때문에 결국에는 또 다시 비슷한 상황을 맞이할 수도 있겠지만 말이다. 그래도 최대한 그런 일을 피해 보고자(늦추고자?) 기획한 방향이니 가급적 용도에 맞게 잘 사용해야겠다.

오늘 배운 것

• Vue에서는 nextTick이라는 함수를 제공하는데, 이 함수는 DOM이 업데이트 될 때까지 기다리기 때문에 업데이트 된 DOM을 인식하지 못하고 변경된 데이터를 즉각 반영하지 못할 때 사용할 수 있다.

오늘 한 일

• 아침에 또 공사 소음 때문에 일찍 깼다. 안 그래도 늦게 잤는데 기분도 나쁘고 아침부터 컨디션이 영 별로였다. 그래도 다행히 스크럼 때는 조용해져서 무사히 끝낼 수 있었다.
• 오늘은 드디어! 페어 프로그래밍이라는 것에 참여해 보았다. 감사하게도 창현님이 먼저 제안해 주셔서 조금은 걱정스러운 마음을 안고 시작했다. 저번에 승규님이 페어를 말씀하셨을 때에는 상황도 상황이긴 했지만 (그때도 공사 소음 때문에...) 어쨌든 작업을 다른 사람과 같이 한다는 게 약간 어색하게 느껴진 것도 있었다. 상대방이 내가 코딩하는 것을 다 보고 있는데 내가 너무 버벅거리지나 않을까 솔직히 두려웠다.
• 하지만 그건 기우였다. 물론 내가 실력이 부족한 건 맞으니 내가 드라이버였건, 내비게이터였건 효율이 아주 좋았다고 하기는 어렵겠지만 그래도 페어 작업하는 시간 자체가 즐거웠다. 창현님 덕분에 스토리북 사용법도 알게 되고, 처음 접해보는 개발 툴들도 구경하고, 작업하는 내내 서로 의견을 나누면서 진행하다 보니 오히려 집중도 잘 되는 것 같았다. 처음에는 일단 오전에만 2시간 하기로 했다가 오후에도 2시간을 했다.
• 페어가 끝난 직후에는 서비스 전체를 통틀어 다이얼로그의 흐름을 어떻게 기획할 건가에 대해 프론트엔드 담당자들의 회의가 있었다. 나는 거의 듣기만 했지만. 애초에 답이 정해져 있는 문제가 아니라 더 나은 방향을 찾고자 하는 거였어서 다른 분들이 각자 자유롭게 의견을 피력하시는 걸 듣고만 있어도 흥미로웠다.
• 그러고 나서는 멘토링이 있었다! 갓 입사해서 팀 스크럼 잠깐 참여했을 때 뵌 것과 어쩔살롱에서 말씀하시는 걸 본 것 외에는 정말로 처음 뵙는 지완님과 1시간 가량 이것저것 많은 얘기를 나눴다. 요즘 나의 태도(?방향?)와 관련하여 계속 고민하고 있었던 것도 말씀 드리니 해결책을 주셨고, 그 덕에 마음도 조금 편해졌다. 지완님 말씀처럼 '나만 힘든 게 아니라는 걸 알면 좀 나으니까'ㅋㅋ 일단 일주일에 한 번씩 뵙기로 했는데 다음 번 이 시간이 벌써부터 기다려진다 😊

오늘 배운 것

• 말로만 듣던 스토리북, 한 번도 써본 적은 없었는데 오늘 창현님 작업하실 때 구경 잠깐 했다고 한 번 써보기까지 했다. 스토리북 대시보드 같은 게 어디 링크에 있나 했었는데 그게 아니라 npm run storybook 명령어로 로컬호스트에서 돌리는 거였다.

• 어느 분이 vscode 테마도 핑크핑크하게 바꾸고 싶어하셔서 한 번 해볼까 하다가 테마를 만들었다. 애초에 가이드 문서도 있고 생각보다는 많이 까다롭지 않았다. 중간중간 마이크로소프트에서 인증 토큰을 생성한다든가 하는 잡다한 일들이 조금 끼어서 헷갈리기도 했지만... 괜찮았다. 나쁘지 않은 경험이었다. 마켓에 검색해서 나왔을 때의 그 기분이란

오늘은

• 다이얼로그 작업은 아직도 끝나지 않았다. 깃 컨플릭인데 컨플릭만 해결한다고 사라지지 않는 어떤 문제가 생겨서 끙끙대다 어찌어찌 간신히 처리 완료한 줄 알았더니 아니었고...
• 내가 푸시한 깃을 풀 받은 승규님이 화면 공유로 확인시켜 주시는데 '내가 작업한 게 안 올라감 + 무슨 이유에선지 로컬에만 남아 있음' 상태여서 적잖이 당황. 내가 손을 댄 파일이 애초에 몇 개 없었기 때문에 일단 전부 스테이지에서 내린 후 stash 해놓고 작업하던 로컬 브랜치 삭제하고 아까 푸시한 브랜치 다시 풀 받아서 git stash apply로 겨우 살렸다. 
• 그러고 나니 뭐 많은 걸 한 게 아닌데도 그동안 차곡차곡 쌓여 왔던 온갖 생각이 한꺼번에 몰려왔다. 모르는 게 너무 많고, 아는 건 제대로 못 쓰고, 사실 저 바깥에 뭐가 있는지도 잘 모르고, 알려면 알 수 있고 보려면 볼 수 있는데 왜 항상 뭔가 부족한 상태에서 무작정 나아가려고만 하는 거지.
• 구멍이 많은데 그걸 메우기보다 일단 구멍을 피해서 가기만 하는 게 과연 상책일까. 구멍을 메우는 행동 자체가 당장에는 시간을 많이 쓸 것 같아도 어쩌면 결과적으로는 목적지까지 나를 빠르게 안내할 지도 모를 일이고, 설령 그 순간이 당장 지금이 아닐지라도 이게 쌓이고 쌓이면 나중에 구멍이 하나라도 적은 길을 가게 될 수도 있다.
• 앞으로 아무리 열심히 나아가려 한들 그 속도에 향상이 없다면, 반대의 경우에 비해서는 제자리걸음을 하고 있는 거나 마찬가지 아닌가.

오늘은

• 아랫집 인테리어 공사가 아직 끝나지 않았나 보다. 그 소음에 소스라치게 놀라며 강제로 기상해서 하루를 시작했다. 어제도 소음 때문에 카페로 나가면서 분명히 봤던 공사 안내문에 소음 심한 날은 어제가 마지막이라고 적혀 있었으니, 오늘은 이러다 말겠지 생각했다. 그런데 10시가 넘어서 스크럼이 시작됐는데도 소음은 잦아들 줄을 몰랐다. 스크럼도 제대로 못하고 이렇게 된 거 안내문에 나와 있는 업체에 전화라도 해볼까 해서 나가봤더니 그새 오늘 날짜를 펜으로 적어놨다.

• 도저히 안되겠다 싶어서 뒤늦게나마 출근을 하기로 했다. 도착하니 거의 점심시간이었지만 아무튼 회사는 조용했다. 2월 둘째 주에 4일 출근한 게 다였고, 오늘이 5번째 출근이었다. 기념비적이다. 오랜만에 출근한 회사에는 여전히 사람은 별로 없었지만, 그래도 다른 분들과 같은 공간에서 근무한다는 것 자체가 알게 모르게 많은 힘이 된다. 그치만 오늘 일을 많이 못해서 내일은 출근을 못할 것 같다...ㅎㅎ

특이사항

• 드디어 나도 멘토님이 생겼다! 이제 다른 사람 안 부럽다구 후후 첫 얘기는 다음주 월요일에 나눠 보기로 했다. 두근두근...

오늘 한 일

• 어제 가뜩이나 늦게 잤는데 오늘은 아침 일찍부터 어느 집 공사 소음 때문에 잠을 설쳤다. 소음의 진원지가 하필 일하는 방 바로 옆인 건지 유난히 더 크게 들렸다. 스크럼 때도 드릴 소리가 들어가고 나니, 문득 오늘 페어 작업에 방해가 될 것 같아 결국 집 근처 카페로 자리를 옮겼다. 근데 카페 음악 소리도 너무 커서 결국 페어는 물 건너 갔다...
• 페어 대신 각자 파트를 나눠서 작업하기로 했다. 공교롭게도(?) 나는 또 다이얼로그 작업을 하게 되었는데 vms에 이미 들어가 있는 UI를 만져서 고치는 것은 새로 만드는 것과는 차원이 다르게 복잡했다. 그 와중에 식사하러, 식사 후 다시 일하러 계속 자리를 옮기게 되니 진득이 집중하기가 힘들었다. 차라리 늦게라도 출근을 할 걸 그랬다. 다행히 4시 반쯤 공사가 끝난다고 해서 집에 돌아오긴 했는데 지금 생각해 보니 괜히 또 중간에 움직였나 싶다.
• 집에 온 직후 오늘 작업한 부분을 공유했는데 내 쪽에서는 한 게 별로 없어서 내일은 오늘 못 다 한 작업부터 시작하기로 했다.

오늘 배운 것

• 어제 대강 살펴봤던 타입 추론과 타입 단언을 한번 더 찾아보았다. "컴파일러는 타입 추론을 통해 명시적인 타입 표기 없이도 타입 정보를 이해할 수 있다." "타입 단언을 통해 컴파일러에게 특정 타입 정보의 사용을 강제할 수 있다." 그러니까 value as Type 또는 <Type>value 형태로 쓰는 타입 단언은, value: type의 형태로 쓰는 단순한 타입 표기와는 완전히 다른 개념인 것이다. 

오늘 한 일

• 스크럼 끝나고 나서 한참을 기억 저편에 묻어두었던 깃훅에 대한 카드를 케이님이 다시 상기시켜 주셨다. 나 너무 부지런하지 못하다..😢  기억을 다시 되돌리기 위해 빠르게 빠르게 husky와 git hook pre-commit 문서를 펼쳐 놓고 스크립트를 짜 보려고 하며 오전 시간을 보냈다.
• 그리고 오후에는 스프린트 미팅 - 승규님과의 페어 작업을 앞두고 사전 허들 - 셀러그로스 retrospective까지 해서 정신이 없었다ㅋㅋ.. 하루 웬종일 머릿속에 정보가 쏟아져 들어오는 느낌이었다. 물론 그거 다 흡수했다고는 안 했음
• 스프린트 미팅에서는 SSO와 다른 서비스들과의 관계를 시각적으로 보여달라는 소연님의 말에 승진님이 관계도를 그리기 시작하셨고... 미팅은 1시간을 채웠다...
• 카드가 나왔고 작업 estimation도 정했으니 승규님과는 내일부터 페어 프로그래밍을 진행하기로 했다. 일단 하기로 한 거고, 혹시 또  이런 프론트 작업에 페어 방식이 맞지 않는다면 작업 방식을 아예 바꿀 수도 있다. 드라이버는 페어 프로그래밍에 익숙한 승규님부터 시작하지만 나는 어떤 식으로 작업을 하는 건지 전혀 모르는 상태라 걱정 반 기대 반인 상태다.
• retrospective는 처음 참여해 봤는데 너무 재미있었다. 나는 거의 한 마디도 안 하고 참관만 했지만 재미있었다. 혹시 그래서 더 재미있었을까..!? 다음 번에는 나도 조금 더 주도적으로 참여할 수 있길.

오늘 배운 것

• 어제 썼듯이, 어제까지 작업한 모달, 그 모달에 이메일을 입력하면 비밀번호 초기화 페이지 링크 받는 것까지 확인해서 pr을 올렸다. 사실 작업 내용 자체는 별 게 없긴 했는데, 생각지도 못했던 부분에서 리뷰를 받았다. 타입스크립트 변수에 대한 타입 선언과 타입 추론 때문이었는데, 어차피 ""와 같이 값의 타입이 string이라는 걸 추론할 수 있는 변수인데 굳이 타입 선언이 들어갈 필요가 없다는 내용이었다. 타입스크립트니까 타입을 명시해줘야겠다고만 생각했을 뿐, 추론은 생각해 본 적이 없었다. 아래 링크에서 타입 추론 부분만 읽어 보았다. 머리에 들어올 것 같을 때 나머지도 마저 읽어봐야겠다.

오늘 한 일

• SSO 쪽에서는 특별히 당장 배정된 작업은 아직 없다. 대신 약 3개월 가량의 작업 시간 여유가 생겼다고 한다. 시간이 자꾸 늘어나는 것 같은 건 기분 탓일까!?
• 하지만 그렇게 되면서 토코톡 로그인, 회원가입 페이지 UI 변경을 진행하게 되었다. 승규님과 함께 피그마 디자인을 보면서, 솔직히 얼마나 걸릴지 모르겠지만 일단 1주일 정도 작업 기간으로 잡고 시작하기로 했다. 예전에 승규님이 한 번 언급했던 것처럼, 이번에 드디어 카드가 할당되고 나면 페어로 작업하기로 했는데 페어 프로그래밍이 어떤 식으로 이루어지는지 전혀 모르는 나로서는 걱정이 앞선다. 대략적인 흐름 정도만 대강 공유하고 일단 카드를 기다리기로...
• 그동안 나는 지난 번까지 틀만 겨우 작업한 모달에 추가 작업을 했다. 모달에 이메일 주소를 입력하면 그 주소를 백엔드에 보내고, 보낸 후에는 확인 모달을 띄웠다. 그리고 해당 이메일 주소로 비밀번호 초기화를 안내하는 링크가 담긴 메일이 오는 것까지 확인했다. 하지만 아직 링크 타고 넘어간 페이지에는 아무것도 없다. 디자인도 나온 건 없는 듯...?
• 그리고 다행히도, 저번 주에 나의 무지함으로 인해 8일이나 늦게 시작된 QA는 다른 추가적인 문제 없이 넘어간 듯하다.

오늘 배운 것

• git add는 보통 git add . 로 변경 파일 전체를 스테이지에 올리지 않고 골라서 진행하더라도 어쨌든 파일 단위로 처리를 하는 명령어이다. 만약 파일 안에서도 라인별로 따로 스테이지에 올리고 싶다면 git add -p를 이용하면 된다. 그러면 터미널에 변경 사항이 찍히고, Stage this hunk? 하면서 어떻게 처리할 건지 묻는다. [y: 스테이지에 올린다 / n: 올리지 않는다 / q: 이 hunk 포함 나머지를 올리지 않고 끝낸다 / s: 이 hunk도 한 번 더 나눈다] 다른 명령어들은 아래 링크 참고!