Kendrick's Blog

새로운 블로그로 이전 완료

손님1(Kendrick) — Mon, 1 May 2023 05:29:31 +0900

티스토리를 떠나 새로운 보금자리로 이사해 봅니다.

주말에 급하게 작업했는데, 생각보다 신경 써야 할 것이 많네요.

첫 아티클로 블로그를 어떻게 구성하고 관리할 예정인지 정리해 볼 생각입니다.

Astro를 사용한 블로그 구축도 좋지만, 특히 Obsidian을 통한 컨텐츠 관리, 텍스트 작성, 리뷰를 위한 ChatGPT 그리고 썸네일 제작을 위한 Dall-e 연동까지 현재 트렌드에 흥미로운 내용도 있을 예정입니다.

https://dev.sonim1.com/

Home | Kendrick's Dev Blog

Kendrick's dev blog: Exploring Tech Trends

dev.sonim1.com

2022년 회고

손님1(Kendrick) — Tue, 7 Feb 2023 21:09:26 +0900

2022년 회고

회고를 12월에 써놨었는데, 이번에 카카오 다운되면서 블로그를 어떻게 할까 고민하다가 이제야 올리게 됐네요.
아무튼 2022년에 느낀 점, 한 것들 간단하게 적어보겠습니다.

일상

2022년 초에는 유튜브 채널을 만들었습니다. 뭐 유튜버가 될 거야! 이런 거창한 건 아니고, 만들어놓은 동영상을 저장하고, 개인 여행 블로그에 유튜브 영상 링크 올리 용도로 사용 중입니다.
그래서 아직 채널 이름도 아직 변경하지 않아 구글 닉네임으로 돼있네요.

재작년 말 구매한 M1 맥북에어와 고프로 10으로 촬영 및 편집을 하는데 벌써 뽕을 뽑은 것 같네요. 12편도 넘게 만든 것 같습니다.
아직 촬영 스킬 및 장비는 비루하지만, 만들고 나면 영상 보는 재미가 나름 쏠쏠하네요.

사진하고 다르게, 간헐적으로 방문해서 보면 그때의 기억이 좀 더 뚜렷하게 기억이 나는 점도 좋구요.

일

2021년이 끝날 무렵 회사에 새로운 수석 개발자가 들어왔고 그를 포함한 개인적으로 리스펙 하던 엔지니어 3인방과 함께 새로운 프로젝트를 시작했더랬죠. 팀에 엔지니어 중 당시 8-9년 차였던 제가 가장 경력이 낮을 정도였으니...
0에서부터 시작된 프로젝트라 함께 일하면서, 개발자로서의 역량을 더욱 높일 수 있었습니다.

또한, 사이드잡을 하면서 개발 외적으로도 많은 걸 배울 수 있었습니다.
Angelist CEO의 투자로 시작된 프로젝트가 실리콘밸리의 YCombinator에 조인하고 나서 까지, 서비스 개발 및 일련의 과정들을 간접적으로 느낄 수 있었죠. NDA로 인해 자세히는 공유할 순 없지만 아무튼...

두 가지를 하다 보니 개인적인 프로젝트에는 많이 소홀해졌습니다만, 이런 경험들로 인해서 견문이 넓어졌고, 앞으로 뭘 해야 할지 그림이 그려집니다.

역시 경험이 중요한 것 같습니다.

블로그 이전

2022년 말 뉴스 1면을 장식한 데이터센터 화재사건. 카카오 메신저뿐만 아니라 다음서비스 중 하나인 티스토리도 먹통이었습니다.
이 블로그 또한 티스토리를 사용하고 있고요. 설마 했는데 접속이 안되더군요. 청천벽력이랄까...

콘텐츠를 잘 안 올림에도 불구하고 다달이 커피 한잔할 정도의 광고비는 벌어주고 있음에도 불구하고 이번 기회에 진지하게 블로그를 이전을 할까 고민하게 되더군요.
그 와중에 Sitemap도 오류 나길래 문의를 남겼는데 끝까지 제대로 된 답변을 듣지 못했네요.

개인 사이트도 만든 지 5년이 넘은지라 리뉴얼을 고민 중이었는데 이참에 블로그도 같이 옮기기로 결정했습니다.
물론 이 티스토리 자체는 아직 유입이 있기에 검색엔진에 노출되게 그대로 두고 말이죠. 광고비로 커피값정도는 나오니!

그래도 그간 무료로 잘 사용했습니다. 땡큐...

앞으로의 계획

2022년을 돌아보면 스스로 무언가 이루어내기보다는 운 좋게 주변사람들의 도움을 받아 많은 발전을 이뤘습니다.
고맙다는 말로도 부족할 정도, 받은 덕만큼 저도 더욱더 베풀고 싶은 마음이 커졌습니다.

2023년은 내가 앞에서 리드하여 일신우일신 하는 한 해가 되도록 노력해야겠습니다.

2023 신년 운세

올해도 재미로 보는 신년운세.

껄껄

마치며

뉴스, 유튜브, 블로그를 보면 모두 Recession이 온다고 떠들썩합니다. 18개월간 소비를 자제하고... 현금을 확보하고... 재작년에 반짝 온 IT 버블도 지금은 가라앉고 있는 중이고요.

다들 그렇듯이 예상은 했지만 여기저기 layoff 얘기가 많이 나오고 있습니다.
이럴 때일수록 드는 생각은 더욱 단단해지고 자신의 능력을 더 키워야겠습니다.

바닐라 코딩 인터뷰 내용 정리

손님1(Kendrick) — Mon, 12 Sep 2022 02:34:46 +0900

하지못한.. 인터뷰.. 내용정리라니 웃프다..

안녕하세요 반갑습니다.

정말 오랜만에 올리는 블로그 포스트네요.

지난 6월에 한국 여행을 다녀왔습니다. [2022 | VLOG] 한국 방문 - YouTube

COVID19 발생 이후 3년 만에 처음 방문이라 한 달이 넘는 아주 긴-휴가를 즐겼습니다.

여행 소식을 바닐라코딩의 Ken님에게 전했고, 해외 경험 관련 인터뷰 요청을 받았습니다.

2017년 Ken님에게 해외취업 및 이후로도 쭉 많은 도움을 받은 터라 드디어 은혜를 갚는가 싶었는데!

아쉽게도 인터뷰 전 주에 코로나 양성 판정을 받는 바람에 취소...

너무 귀한 자리에 누추한 저를 초대해주신다길래 미리 생각해놓은 주제들이 있었는데, 전해 드리지 못한 게 너무 아쉬워 이곳에 정리해 봤습니다.

여행중에 코로나 양성판정이라니...

들어가기 전

실제 코딩 관련 내용은 바닐라코딩에서 많이 배울 수 있을 테니, 이 포스트에서는 좀 더 코딩 외적으로 중요한 부분을 이야기하고 싶었습니다.

저는 두 달 뒤면 10년 차가 되는 개발자입니다. (한국에서 5년, 캐나다에서 4년)

지금은 토론토의 Venngage라는 Online Infographic Editor를 제공하는 회사에서 테크 리드 및 시니어 엔지니어로 일하고 있으며, 또한 사이드잡으로 현재는 YCombinator에 조인한 스타트업의 시작 단계부터 2년간 개발했던 경력을 가지고 있습니다.

간단한 자기소개는 여기까지 하고, 지금까지 이 업계에서 발 담그며 코딩 외적으로 중요하다고 생각되는 그리고 공유하고 싶은 5가지 핵심 포인트를 정리해봤습니다.

물론 너무 개인적인 생각들이라 아니다 싶으시면 넘겨주세요!

1. 멘토를 찾으세요

제일 중요하지만 또한 제일 어려운 부분이 아닐까 싶습니다.

저는 "내가 지금까지 쌓고 누리고 있는 경험을 공유하고 싶어 하는 사람"을 멘토라고 생각합니다.
물론 이런 사람들을 찾기란 사실 하늘의 별따기지만 말이죠.

만약 운 좋게 그런 사람을 발견했다면 어떻게 해야 할까요?

멘토는 잘못된 길을 갈 때 올바른 길로 가도록 서포트해 준다.

1) 사실이 아닌 의도를 공개하고 접근하자

A라는 사람에게 어느날 불행해 보이는 사람이 찾아옵니다. 그리고 이렇게 말합니다.

"제가 3일을 굶었습니다.. 배가 너무 고파요.."

A라는 사람이 그 얘기를 듣고 연민을 느껴 그 사람을 도와줍니다... 하지만 몇 주 후 알고 보니 그 사람이 3일 굶은 게 디톡스 다이어트 때문이었다면 A가 느낄 배신감은 이루 말할 수 없을 것입니다.

멘토에게 내가 필요한 것이 있다면 직접 의도를 공개하고 그 후 그 사람의 반응을 보면 될 일입니다.

내가 사실을 말하더라도 의도를 숨기고 접근한다면, 단기적인 이득은 볼 수 있겠지만 이후 관계에 더 이상 진전이 없을 것입니다.

제 경험을 예를 들면, 처음 바닐라코딩의 대표이신 Ken님을 바닐라코딩 1기 세미나에서 처음 뵈었습니다.
소개를 듣자 하니 미국인이며 Nike 프론트 엔드 팀장 출신이라고 합니다. 해외에서는 타인의 Reference가 취업 시 매우 중요하기에 세미나가 끝난 후 Ken님을 찾아갔습니다.

"캐나다 워홀 가서 해외 취업하려고 하는데 Reference를 해 줄 수 있으신가요"

제 생각과는 다르게 야망이 넘쳤던 저의 의도를 듣고 Ken님이 오히려 반갑게 이야기하고 많이 알려주셨던 기억이 나네요.

좋은 사람에게 의도를 밝히고 투명하게 대화한다면 서로 도움이 되는 건강한 관계를 유지할 수 있습니다.

2) 개발자 멘토의 실력은 내가 판단할 수 있을까?

불가능합니다.

사람의 인간적인 부분이라면 같이 지내면서 알 수 있겠지만, 개발실력은 또 다른 문제입니다. 왜냐하면 이 업계는 주니어에게는 너무 불합리한 구조로 되어있습니다.
특히 시니어 개발자가 인터뷰 경험이 많다면, 30분의 대화로 그 사람의 실력을 대충 가늠할 수가 있고, 반면 똑같은 시간 동안 주니어가 시니어를 인터뷰한다면 정말 작은 일부분만 파악할 수 있습니다.

그렇다면 멘토의 실력은 어떻게 판단해야 할까요?

멘토의 실력은 주변의 다른 동급 혹은 더 높은 개발자의 평판을 통해서 이루어져야 합니다.

바닐라코딩, 그 시작 — Part 3. 포스트에 나오듯이, 처음 세미나에서 Ken 님이 우아한형제 취업 제의 관련 이야기를 하셨습니다. 그리고 그 당시 제 멘토였던 친한 Yuby라는 개발자 형님이 우연찮게도 우아한형제들 CTO분 아래에서 일하고 있었죠.

이게 무슨 운명인지 ㅋㅋ, CTO분이 생각하는 Ken님에 대한 평판과 관련 정보를 듣게 됐고 그 이후 Ken님에 대한 모든 의심이 사르르 녹는 계기가 되었습니다.

위의 경우는 굉장히 운이 좋은 케이스이므로, 제가 지금 다니는 회사의 CTO이신 Kyu형님에 대해서 이야기해보겠습니다.
저는 이 형님이 엄청 고수라는 것만 알고 있었습니다. 실력을 대충 가늠하게 되는데도 3년이 넘게 걸렸고요.

캐나다 랜딩 후 Kyu형님 덕분에 지금 회사에 입사를 한 후 같이 일도 하고 사이드 프로젝트도 했고, 친해진 이후 형님이 직접 말해주는 정보(개인 컨설팅 회사 운영 및 Product hunt에서 주목된 개인 프로젝트 등등 셀 수 없이 많음) 혹은 Kyu형님의 지인분들과 프로젝트를 하며 정보를 얻게 된 시간이 대강 3년입니다. 문제는 이게 단지 가늠했을 뿐이라서, 최근에도 이야기할때 많이 배우거나 놀라기 일수입니다.

결론적으로, 아무리 친하게 지내더라도 나보다 오래 일하고 경험이 많은 사람의 실력을 파악하기란 너무너무 힘든 일입니다. 더욱이 웹 서칭으로 얻을 수 있는 정보는 너무 한정적입니다.
자신의 그릇된 판단으로 좋은 사람을 놓치지 말고, 주변의 평판과 정보를 이용해 영리하게 판단해야 합니다.

3) 좋은 멘토는 없다, 좋은 제자가 있을 뿐이다.

저는 서바이벌로 두뇌게임을 하는 TV 프로그램인 "지니어스"의 애청자였습니다.
그중 우승자였던 장동민의 "좋은 스승은 없어, 좋은 제자만 있을 뿐이야"라는 말을 몇년전에 듣고 좋은 제자란 무엇인지 골똘히 생각에 잠겼습니다.

그리고 아래 두가지를 가진 사람이 좋은 제자가 아닐까란 결론을 냈었습니다.

첫째, 멘토의 말을 받아들일 줄 알아야 합니다.
좋은 멘토들은 사람을 가리지 않습니다. 그들은 의견을 공유하고 기회를 주려고 합니다.
하지만 내가 자존심으로 혹은 듣기 싫은 소리로 치부하고 결국 사람과의 만남을 피하려 한다면 멘토들은 다른 사람을 찾으러 떠나갑니다.

듣는 사람을 바꾸려 하기보다는 다른 경청하는 사람을 찾는 게 빠르기 때문이죠.
그렇기에, 그들에게 발가벗겨지는 기분을 느끼더라도 인정하고, 납득하고 더 깊은 대화를 하려고 노력해야 합니다.

둘째, 신세 질 줄 알아야 합니다.
타인에게 도움을 받고 나서 똑같이 갚아야 된다는 강박으로 인해, 아예 신세 지지 않고 연락조차 하지 않는 사람들이 있습니다.
하지만 당신이 신세를 진다면 혹은 먼저 연락을 한다면 상대방도 당신에게 신세를 질 기회를 가질 수 있습니다.
멘토도 함께 성장하는 사람을 찾고 있기 때문입니다.

2. 영어 공부는 어떻게 하나요?

알아서 하세요!

일반 교육과정을 잘 수료한 대부분의 대한민국 국민 2~30대라면 당연히 저보다 영어 스킬이 훨씬 뛰어날 것이기 자명하기 때문에 제가 드릴 수 있는 조언이 없습니다. 심지어 지금도 계속 영어가 부족하다고 느끼는데 다른 사람에게 조언하기가 양심에 찔립니다.

알아서 하라고는 하지만 그럼에도 불구하고, 영어공부 방법에 대해 물어보는 지인들이 있습니다.

저는 그냥 비행기 티켓을 사라고 합니다. 어찌 됐든 닥치면 하게 돼있기에...

하지만 만약! 그 당시 제 상황과 비슷한 분이 계신다면, 디테일한 가이드를 줄 수가 있을 것 같습니다.

공고 출신 영어 포기자이다.
나는 개발자 경력이 5년 정도 됐고 최신 트렌드 및 내 실력에 대한 자신감도 넘친다.
같이 일하는 나와 실력이 비슷한 사람들이 줄줄이 이름 있는 회사로 이직한다.
학력주의 사회에 지쳤다.
"내 목표는 실리콘밸리!"를 외치며 1년 뒤 해외 워홀 가서 취업하고 싶다.

돌아와서, 우리가 가장 궁금해하는 해외취업 관점에서 이야기해 보겠습니다.

취업에서 결정적인 역할을 하는 것은 그 사람의 실력과 잠재력 그리고 프로페셔널함이라고 생각합니다.

영어를 잘하는 사람이 취업에 매우 큰 강점이 있다면 모든 기회는 원어민에게 돌아가는 게 맞지 않을까요?

주니어나 인터미디엇이라면 업무를 받고 이해할 수 있는 정도면 된다고 생각합니다만...

사실 저는 시간이 갈수록 영어의 중요성을 크게 느끼고 있습니다.

입사할 당시에는 빌어먹을 영어실력이어도 위와 같은 이유로 일하는 게 크게 지장이 없었지만, 진급하고 사람들과의 커뮤니케이션이 많아질수록 영어의 필요성을 여느 때보다 많이 통감하게 됩니다.

하라는 건지 말라는 건지..?

결국은 모든 사람들이 말하다시피, 언제 올지 모르는 기회를 위해서 영어는 꾸준히 공부하길 추천드립니다.

뻔한 얘기라서 죄송합니다 ㅎㅎ...

3. 한국 경력은 타이틀이 아닌 경험을 어필하세요

한국에서의 타이틀은 해외취업에서 사실 크게 중요하지는 않습니다.

세컨잡을 하면서 있었던 경험을 말해보자면, 몇 가지 라이브러리를 조사하고 그 결과를 공유하는 미팅을 가졌었습니다.

친한 네이버 및 카카오 모빌리티 시니어 개발자 (Frontend 렌더링 및 성능 개선의 달인들)에게 자문을 구하고 나서 미팅 때 네이버 카카오 개발자에게 자문을 구했다고 설명을 하는데 갑자기 급 민망...

외국인들이 네이버 카카오를 알지 못했던 것이죠... 네이버와 카카오는 코리안 구글이라고 사족을 붙이면서 설명을 하는데 살짝 민망했던 경험이 있습니다.

한국에서야 너무 대단한 회사고 자부할만한 경력이지만 해외에서는 인지도가 아쉽게도 많이 부족합니다.
즉 한국에서의 기업 네임밸류는 해외취업에 크게 영향을 미치지 않는 것 같습니다. 아 물론 삼성을 제외하고요.
삼성 출신 엔지니어가 인터뷰 볼 때는 주변에서 저한테 물어보더라고요.. 아무래도 네임밸류가 다르다 보니 재밌는 상황이었습니다.

한편 최근에 본 흥미로운 채용 과정을 이야기해보겠습니다.

주인공은 현재 우리 회사에서 일하고 있고, 핀란드에서 살고 있는 Oskar (Venngage, 수석 엔지니어)입니다.

작년, 회사의 서비스 확장을 위해서 Oskar의 개인 프로젝트였던 비디오 에디터 관련 프로젝트를 구매하면서 컨택했습니다. 이후 Migration을 위해서 계약직으로 일하는 동안 실력을 인정받게 되었고, 회사의 수석 엔지니어로 입사했습니다.

그 후 지금까지 같은 프로젝트에서 일하고 많이 배우고 있습니다.

이 이야기를 통해 알 수 있는 건, 어느 정도 경험이 있다면 한국 회사의 네임밸류보다는 그 회사에서 본인이 쌓은 경험, 개인 프로젝트, 오픈소스 그리고 개발 블로그, 유튜브 등이 좀 더 가산점이 있을 것입니다.

4. 자기 객관화를 잘하세요

아래 짤로 요약합니다.

하룻강아지 범 무서운 줄 모른다 - 더닝크루거 효과

메타 인지 후 멘토에게 사사해달라고 부탁하는 조로

업무에 있어서 자기 객관화를 잘하기 위해 알아야 할 몇 가지 이론들이 있습니다.

- Expert Beginner

- 드레이퍼스 형제의 기술 습득 이론(model of skill acquisition)

- 더닝 크루거 효과

- 가면 증후군

추후에 올릴 포스트에서 자세히 다룰 거 같습니다만(기약 없음..), 위 내용들은 검색하면 인터넷이 워낙 많은 정보가 있으니 한번 찾아보시길.

관련 내용으로 몇 년 전에 써놓고 올리지 않은 아티클이 있는데 조만간 다시 퇴고해서 올려보겠습니다.

5. 당신의 일을 위임하세요

개발자에게 흔히 나타나는 위험한 적신호가 있습니다.

"내가 없으면 회사가 안 돌아간다"라는 생각을 가지게 되는 것인데요.

이런 생각이 든다면, 일을 전혀 위임을 하지 않고 있으시다고 보면 됩니다.

반복적인 업무, 의미 없는 수동적인 업무에 시간을 쏟아붓고 작은 성취감에 보람을 느끼지 마세요.

1) 중요하고 새로운 일은 여유가 있는 사람에게 주어진다.

입사 후 두세 달쯤 됐을 때 CTO님이 하시던 일 및 계획해놓은 일들을 저한테 넘기셨을 때 그런 생각을 했습니다.

"이분은 일을 왜 이렇게 다 넘겨주시지 ㅜㅜ"

그 후 2년 차가 됐을 때 문득 깨달았습니다. 위임을 함으로써 팀에 자연스럽게 자신이 알고 있는 지식을 공유하는 거였고 심지어 그 첫 번째가 저였다는 걸 깨닫고 너무 고마운 마음이 들었습니다.

그날 이후 적극적으로 제 일을 다른 사람들에게 넘기기 시작했습니다. 하루의 일과에 질답 시간이 많아졌지만, 알려주면서 배울 수 있고 또한 더 중요한 혹은 새로운 일에 포커스 할 수 있게 되었습니다.

물론 그들이 잠깐은 저처럼 원망을 할 수도 있다는 생각은 들지만 말이죠!

위임하지 않는 사람에게 전달되는 경우, 지식의 동맥경화가 발생할 수 있다

2) 언제든 퇴사당할 수 있다고 생각하자.

제 일을 넘기기 시작하면서 제가 시작한 게 "언제든 잘린다"라는 마인드셋입니다. (한국과 다르게 실제로 외국은 언제든 잘릴 수 있습니다)

그리고 1년이 지난 지금, 예전 작업은 거의 터치 안 하고 새로운 프로젝트에 몰입할 수 있는 환경이 되었습니다.

새로운 기능을 추가할 때 다른 누구나 작업할 수 있게 고려하다 보니, 테스트와 문서화에 조금 더 시간이 들어가지만, 추후 유지보수 및 인수인계에 들어가는 시간이 많이 절약되었습니다. 또한 당장 일을 그만두더라도 인수인계가 필요 없을 정도로 저만 알던 지식들이 대부분 문서화 혹은 위임 되었습니다. 현재는 회사에서 항상 새로운 것들을 챌린지 하는 기분으로 일하고 있습니다.

그로 인해, 자연스럽게 회사에서 가치 있는 무언가를 만들며 큰 성취감을 얻고 또한 번아웃 걱정도 자연스럽게 없어졌습니다.

뿐만 아니라, 근 1년 동안 근무시간을 9 to 5로 맞추게 되었고 남는 시간에 아내와 더 많은 시간을 보내며 세컨 잡도 할 수 있는 시간적 여유가 생겼습니다. 세컨 잡을 하면서 얻은 지식을 다시 본 업무에 활용하게 되고 모든 게 긍정적으로 흘러간다는 기분을 직접 느낄 수 있었습니다.

물론 이 과정은 혼자만이 아니고 CTO형님과 매니저 Mia 그리고 뛰어난 엔지니어팀 멤버들이 있었기에 가능한 일이었습니다.

마치며

어떻게 보면 1, 2, 3, 4, 5번 모든 항목들이 밀접하게 연결이 되어있습니다.

개인적인 경험에서 정립된 생각들이라 허무맹랑하거나 약간 중구난방일 수는 있지만, 누군가에게는 특정 내용이 분명 도움이 될 거라고 믿고 공유해 봅니다!

즉 v1 같은 느낌이라 제 생각이 바뀌면 내용은 언제든지 바뀔수 있습니다.

현재 바닐라코딩은 기수가 많아지면서 인맥 풀이 살벌하게 늘어났습니다.

1번 멘토를 찾아라가 제일 어려운 미션이긴 하지만 이런 활발한 인적 네트워크가 조성되어있는 지금의 바닐라코딩 이라면 멘토를 찾기가 어렵지 않겠다는 생각이 드네요.

https://www.vanillacoding.co/

저 또한 많은 사람들의 도움으로 운 좋게 여러 경험과 기회를 가지게 되었기에 궁금한 점이 있으면 부담없이 언제든지 물어보세요.

이메일을 통한 상담 매우 환영합니다.

E-mail: bumfoo@gmail.com

결혼 모바일 초대장 후기

손님1(Kendrick) — Wed, 2 Mar 2022 22:12:32 +0900

결혼 모바일 초대장 후기

모바일 청첩장 만든 리뷰를 쓰려고 하는데, 결혼한 지 2년이 훌쩍 지났습니다.
이제 와서 포스트를 작성하려니 기억이 가물가물 하네요. ㅋㅋ
그래도 이왕 만든 거, 다른 분들처럼 공유하고 싶어서 억지로 기억을 짜내서 작성해봤습니다.

왜 만드는데 시간을 쓰시죠?

모바일 청첩장을 만든다고 했을 주변인들에게 가장 많이 들었던 질문입니다.

결혼 청첩장을 계약할 때 보통 업체에서 공짜로 만들어주지만, 광고도 보기 싫고 개인적으로 댓글들을 소장하고 싶어서 유지 가능한 사이트를 가지고 싶었습니다. 그리고 다른 개발자 블로그에서 모바일 청첩장을 직접 만들어서 소개하는 글을 인상 깊게 보기도 했고요.

주변 친구들의 청첩장이나 온라인 샘플을 둘러보고, 이 정도면 금방 만들겠구나 싶어서 호다닥 만들어보았습니다.

소개

모바일 청첩장 바로가기

구조

헤더
인사말
연락처
오시는 길 주소
갤러리
오시는 길 지도
방명록

구성은 일반 청첩장과 같습니다.
사람들에게 가장 친숙할 것 같은 카카오 지도 API를 사용했는데, 생각보다 큰 수고 들이지 않고 만들었던 기억이 나네요.

스펙

Front-end: VueJS, Kakao Map API
CI/CD, Hosting, Storage: Firebase

심플합니다. 그리고 무료!

아쉬운 점

당시에는 Firebase에서 multi-region을 지원하지 않았기 때문에 (아닐 수도 있구요...) 그때 당시 한국과 가장 가까운 홍콩 리전을 사용했습니다.
그런 이유로 이미지를 받는데 너무 느려서 약간 속상했던 기억이 납니다. 아무래도 다른 모바일 청첩장에서는 지원하지 못하는 고화질 이미지를 제공할 수 있었습니다만 생각보다 느려서 좀 아쉽네요.

이 또한 Firebase + Google Cloud Storage Bucket을 사용했습니다.

마치며

결혼했던 이야기를 여행 블로그에 올렸었는데 다시 보니 감회가 새롭네요.

예전 시민의 숲에서 같이 살았던 룸메 삼행시 왕의 삼행시로 이 포스트를 마치겠습니다.

자바스크립트 Spreadsheet 라이브러리 추천

손님1(Kendrick) — Fri, 19 Nov 2021 06:10:01 +0900

자바스크립트 Spreadsheet 라이브러리 추천

https://jspreadsheets.com/

위 사이트에서 현재 잘 알려진 자바스크립트 기반 스프레드시트 라이브러리들을 한눈에 볼 수 있게 제공해 줍니다.

자, 이제 알려드렸으니 수많은 라이브러리 중 직접 고르시면 됩니다!

농담입니다.

사실 대부분의 라이브러리들이 유료버전에서 쓸만한 기능을 제공하거나, 또는 무료 유저에게는 기간제로 혹은 강제적인 로고가 노출되는 데모 버전만을 제공합니다.

그래서 제가 찾아본 무료 라이브러리 중 가장 쓸만하고 현재 실제로 여러 프로젝트에서도 사용 중인 라이브러리를 소개하려 합니다.

Jspreadsheet

현재 개인적으로 가장 추천하는 스프레드시트 라이브러리입니다.

최신 버전은 유료로 제공되지만, v4버전의 경우 MIT 라이선스이기 때문에 마음껏 사용하실 수 있습니다.

무료로 제공됨에서 불구하고 훌륭한 기능을 및 UI를 제공하고 있습니다. 또한 VueJS와 ReactJS에서 사용하기도 용이합니다.

Jspreadsheet v4 - 무료 버전
Jspreadsheet v8 - 최신 유료버전

The javascript spreadsheet

Jspreadsheet official website, the javascript spreadsheet. Create amazing tables with Jspreadsheet.

bossanova.uk

The javascript spreadsheet

Jspreadsheet is a JavaScript plugin to create rich online excel-like spreadsheets.

jspreadsheet.com

handsontable

아마 가장 유명한 테이블 라이브러리가 아닐까 싶습니다.

예전에는 프로버전과 무료 버전으로 나뉘어서 프리 버전의 경우 MIT 라이선스로 제공되었던 걸로 알고 있었는데...

특정 버전부터 라이선스가 변경됐나 봅니다. 하지만 유명한 만큼 기능은 출중합니다.

Handsontable

Handsontable is a JavaScript data grid that looks and feels like a spreadsheet - Available for React, Angular and Vue

Trusted by the world’s most innovative companies

handsontable.com

위 두 가지 스프레드시트 모두 간단한 데모를 제공하고 있습니다. 직접 사용해보셔요.

https://bossanova.uk/jspreadsheet/v4/examples/create-from-table

The javascript spreadsheet

Jspreadsheet official website, the javascript spreadsheet. Create amazing tables with Jspreadsheet.

bossanova.uk

https://handsontable.com/demo

Data grid demo - Handsontable data grid for JavaScript, React, Angular, and Vue.

Trusted by the world’s most innovative companies

handsontable.com

그 외의 라이브러리들은 스프레드시트로서의 기능이 뭔가 아쉽다는 느낌이 있었네요.

혹시 이외에도 괜찮은 라이브러리 혹은 추천할만한 라이브러리가 있다면 댓글로 추천 부탁드리겠습니다!

명암 대비를 고려한 디자인 - WCGA 2.1 Contrast

손님1(Kendrick) — Thu, 30 Sep 2021 21:33:45 +0900

명암대비를 고려한 디자인 - WCGA Contrast

우리가 사용하는 모든 디자인은 명암대비를 고려해서 디자인됩니다.

버튼의 배경색과 글자색, 컴포넌트의 배경색 등 우리가 알게 모르게 적용되어있습니다.

이런 명도 대비는 단순히 이쁘게 혹은 보기 좋게 만들기 위해서가 아닌, 노안, 약시 혹은 일시적으로 정상시력을 가지지 못한 사람들을 위해서 적용이 고려됩니다.

W3C에서는 이런 인식 및 시각과 관련된 요소를 WCGA 가이드라인에 명시해 놓고 있습니다.

WCGA란?

WCGA는 W3C에서 정한 웹 콘텐츠 접근성 가이드라인의 표준 권고안입니다.

하지만 이 접근성이 엄청나게 광범위한 부분을 포함하고 있기 때문에 이 포스트에서는 Contrast 카테고리에 관해서 이야기합니다.
가장 최근에는 모바일 접근성도 고려된 2.1 버전이 대중적으로 사용되고 있습니다.

WCGA에 관해서 자세히 알고 싶으시면 WCGA21 link

Contrast 명도 대비

시작할 때 명도 대비가 디자인에서 고려된다고는 했지만, 이 글을 읽고 있는 엔지니어들은 나는 고려한 적이 없다고 할 수도 있습니다.

단순한 예를 들자면, 노란색 글씨를 빨간색 배경과 함께 쓰고 있을 때, 우리는 눈이 침침함을 느끼고 색상을 수정할 것입니다.

하얀색 폰트와 진한 어두운 배경의 경우 글자 인식이 쉽다

반면 어두운 배경과 폰트 색을 가지고 있다면 인식률이 많이 떨어진다

두 색조합을 이용하여 적합성 수준을 보여줍니다. 이 적합성 수준에 관해서는 이 아티클 하단에서 따로 설명합니다.

너무 추상적인가요? 그래서 네이버는 어떻게 하고 있는지 찾아보니 웹 접근성을 위해서 명도 대비를 어떻게 정의하고 있는지 소개하는 페이지가 존재하더군요.

네이버 웹 접근성

네이버 접근성 페이지 : 명도 대비

명도 대비 저시력자, 고령자 등도 인식할 수 있도록 콘텐츠와 배경 간의 명도 대비는 4.5:1 이상이어야 합니다. 명도 대비 평가 방법 텍스트 콘텐츠 색과 배경 색을 평가 도구를 이용하여 대비 합

accessibility.naver.com

이렇게 네이버는 명도 대비를 4.5:1 이상이 나오게 정의하고 있습니다. 이는 WCGA에서 권장하는 비율과 동일하네요.

그렇다면 4.5:1 이런 숫자는 어디서 어떻게 계산되는 걸까요?

Contrast ratio(명도 대비율) 계산법

WCGA에서는 아래와 아래와 같이 계산할 수 있다고 알려줍니다.

우선 luminance(밝기)를 계산 하고 아래와 같은 공식으로 Contrast ratio를 계산합니다.

// contrast ratio 
(L1 + 0.05) / (L2 + 0.05)

// L1 is the relative luminance of the lighter of the colors, and
// L2 is the relative luminance of the darker of the colors.

javascript로 구현된 코드가 궁금하다면 이 오픈소스를 참고해주세요.

wcag-contrast - Github

적합성 수준 with Contrast Ratio

위에서 계산한 점수와 텍스의 폰트 사이즈를 시용해서 아래와 같은 다섯 가지 적합성 수준을 구할 수 있습니다.
하지만 아래 조건은 간단하게 요약한 것이니 WCGA가이드를 참고하시길 바랍니다.

AAA

Contrast ratio가 7.0 이상입니다.

AAA Large

Contrast ratio가 4.5 이상이면서 폰트 사이즈가 14pt+bold 혹은 18pt 보다 큽니다.

AA

Contrast ratio가 4.5 이상입니다.

AA Large

Contrast ratio가 3.0 이상입니다.

Fail

등급 미달. Contrast ratio가 2.9 미만입니다.

이와 같이 디자인에서 사용하는 컬러 값을 사용하여 WCGA의 기준을 바탕으로 하는 결과를 체크해볼 수 있습니다.

마치며

지금까지 Frontend 개발자라면 알면 좋고 쓸데도 많은 WCGA Contrast 관련 아티클이었습니다.

References

WCGA 2.1 - W3C
WCGA 2.1(한글)
usecontrast guide

https://contrastchecker.com/

WCAG - Contrast Checker

Check the contrast of your color design for accessibility base on Web Content Accessibility Guideline (WCAG)

contrastchecker.com

Web Content Accessibility Guidelines (WCAG) 2.1

Additional information about participation in the Accessibility Guidelines Working Group (AG WG) can be found on the Working Group home page. A.2 Other previously active WCAG WG participants and other contributors to WCAG 2.0, WCAG 2.1, or supporting resou

www.w3.org

모두를 위한 디자인

모두가 행복한 서비스를 제작하는데 노력해야 합니다.

a11y.gitbook.io

Contrast for UI

A macOS app for quick access to WCAG color contrast ratios.

usecontrast.com

독서 모임을 유지하기 위한 방법

손님1(Kendrick) — Thu, 2 Sep 2021 11:45:43 +0900

독서 모임

작년 중순부터 올해 초까지 독서모임을 진행했습니다.
+ 판데믹 관련하여 온타리오주의 모임 규정을 준수하였습니다.

이 포스트에서는 많이들 물어보는 왜 독서를 하는지와 어떻게 하는지에 대해서 적어보려고 합니다.

독서 모임을 하는 이유

독서 모임을 한다고 했을 때, 주위 사람들로부터 가장 많이 받았던 질문입니다.

현대인이라면 하루하루 시간이 부족하다는 생각이 들겠지만, 2020년은 살면서 제가 느낀 최고로 바쁜 한해였고, 문득 생각이 들었습니다. 바쁘고 시간이 없을 때 적은 시간으로 최대한의 가성비를 뽑을 수 있는 게 무엇일까? 제가 찾은 답은 독서였습니다.

허나 혼자 하기에는 제가 꾸준히 못 할 거라는 메타인지가 되어있었기 때문에(주제파악을 잘하는 편...) 자연스러운 독서 환경 설정을 하기 위해 독서 모임을 만들었습니다.

물론, 모임 초반에는 독서라는 목적이 흐려지는 게 느껴져서 없앨까도 고민했지만, 마침내 위와 같은 이유를 공감해주는 멤버들을 찾아서 꾸준히 하게 되었네요.

그 결과, 독서 모임을 통해서 3년 동안 읽고 접고 읽고 접고 못 끝내던 지긋지긋한 DevOps 관련 책을 다 봤고, 추가로 6권의 책을 더 읽었습니다.

2년넘게 나를 고통받게한 "그 책", 번역판을 읽었었는데 그... 번역퀄리티가 매우.. 곤란했다.

요약하자면, 제가 생각하는 독서가 필요한 이유는 아래와 같습니다.

짧은 시간에 책을 통해서 간접경험을 할 수 있습니다.
독서나 영화시청을 통해서 한정된 시간 내에 최대의 경험을 가질 수 생각합니다.
집중력이 향상됩니다.
요즘은 미디어의 발달로 인해서 사람들이 짧은 시간에 정보 습득하는 것에 익숙해져 있는데, 책을 읽으면서 집중력을 기를 수 있습니다.
기술 서적이라면 해당 기술 문서의 방대함을 마주하기 전, 책에서 제공되는 정제된 Practice를 통해서 쉽게 친숙해질 수 있습니다.
사실 개인적으로 몇몇 기술 서적을 제외하고 신뢰하지 않으며 구식이기 때문에, 요즘은 온라인 강의나 Youtube를 통해서 기초를 익히는 게 훨씬 좋은 거 같긴 합니다.

물론 이런 이유 말고도 장점이 많습니다.

예를 들면, 독서 모임 담당일 때 잘 안 하던 대청소를 강제로 하게 된다든지 혹은 COVID 19으로 인해서 타인과 만남의 기회가 줄었기 때문에 독서 이후 식사를 하면서 이런저런 얘기를 할 수도 있죠.

독서 모임을 유지하기 위한 방법

초집중 보장하기

독서를 강제할 필요는 없습니다! 왜냐하면 제 책을 남이 읽어주는 건 아니니깐 말이죠.
예를 들어 온라인에서 수집해놓은 아티클을 읽는다든지, 해야 할 일이 있다면 그 시간에 일을 마무리 할 수 있습니다.

하지만 이때는 절대로 다른 사람의 시간을 뺏지 않아야 합니다.
물론 독서가 다 끝나면 상관없지만, 독서 시간에는 서로가 집중할 수 있도록 보장되어야 합니다.

서로가 마냥 한가해서 책을 보는 게 아니기 때문에 내 시간이 소중하듯이 다른 사람의 시간도 소중하다는 것을 잘 알아야 합니다!
뭔가 질문이 있다면 정해진 독서시간이 끝나고 하도록 합시다.

독서 리뷰는 필요 없다

굳이 일부러 끝나고 리뷰하거나 하지 않습니다. 왜냐하면 리뷰 때문에 부담스럽게 책을 읽을 수도 있겠다 싶어서요.
하지만 어느 정도 보다 보면 자발적으로 다른 사람에게 요약을 해주거나 혹은 다른 사람이 읽는 책이 궁금할 때는 어떤지 물어보기도 하니 오히려 자연스럽게 리뷰를 하게 되더군요. 즉, 강압적인 리뷰 시간을 만들기보다는 자연스러운 리뷰를 지향합니다.

위 두 가지가 잘 지켜진다면 그 독서 모임은 훌륭하게 유지될 것입니다.

갑자기 시작한 독서모임이라 한 달도 안 갈것 같다고 생각했는데, 결과적으로 6개월간 할 수 있었습니다.
뿐만아니라, 독서모임 초반 3개월동안 무려 6권의 책을 읽었습니다.

모임을 위한 환경설정

배경음악 깔기

Cafe Music BGM channel - Youtube
카페 분위기를 만드는 데 도움이 되는 배경음을 위 유튜브에서 재생할 수 있습니다.

마치며

일이 있으면 차일피일 미루다가 끝에 가서야 마무리하는 안 좋은 습관이 있었는데, 토요일 하루는 무조건 독서 모임에 투자한다고 생각하니 주말에 여유가 없다는 압박감에 평일에 일을 더 잘 끝낼 수 있게 되었습니다.

이런저런 이유로 지금은 다시 안하고 있지만, 그 습관은 계속 남아 매주 최소 2시간은 읽고 있습니다.

홈페이지 디자인을 위한 줄 바꿈 위치 제안 - 

손님1(Kendrick) — Mon, 2 Aug 2021 02:09:22 +0900

홈페이지 디자인을 위한 줄 바꿈 위치 제안 ``

facial covering are required라는 문장을 한정된 공간에 넣는다면 어떻게 보일까요?

클라이언트에게 작업을 수주받았다고 생각해 봅시다.

작업 요청사항을 보니 Hi There라는 타이틀과 마스크 필수라는 문장이 쓰여 있는 문구가 필요하다고 합니다.

대충 CSS를 넣고 만들어보니 아래와 같이 보입니다.

물론 width를 늘리면 되지 않냐고 할 수 있지만 클라이언트가 고집부려서 Hi there와 같은 width를 가지고 싶다고 가정합니다 :)

<div className="App">
  <h1>Hi There</h1>
  <div className="text">facial cover&shy;ing are requir&shy;ed</div>
</div>

당연하게도 covering과 required라는 글자가 밖으로 삐져나오게 됩니다.
작업을 시작하자마자 생각지도 못한 Rabbit hole에 빠져버렸습니다. 머리를 굴려보니 -(hyphen)을 넣어서 줄을 분리해주면 될 것 같습니다. 이때 사용하는 게 유니코드입니다.

부끄럽다는 형용사가 아니고 soft hyphen 줄임말이더군요..!

soft hyphen이 있다면 hard hyphen(?)은 없나요? 그건 그냥 - 타이핑 하면 됩니다. ㅋㅋ
soft hyphen의 차이점은 공간이 넉넉할 경우 hyphen을 렌더링 하지 않습니다!
적절한 위치에 넣어봅시다.

<div className="App">
  <h1>Hi There</h1>
  <div className="text">facial cover&shy;ing are requir&shy;ed</div>
</div>

CSS hyphens

이를 핸들링할 수 있는 CSS 스타일도 존재합니다.

hyphens: none;
hyphens: manual;
hyphens: auto;

그러면 무조건 auto를 사용하면 되는 거 아닌가?
문제는 auto가 &shy;를 무시한다는 점에 있습니다.

예제를 예로 들면, 영어에서 일반적으로 re-use, re-create 그리고 re-build와 같이 사용되는 경우가 많기 때문에 required도 re-quired로 바꿔버립니다. 이때는 manual로 soft hyphen을 사용해 줄 필요가 있습니다.

고로 동적인 사이즈를 사용하는 웹 개발 환경에서는 알아두면 좋은 테크닉이라고 생각합니다.

Ref

hyphens - CSS: Cascading Style Sheets | MDN

The hyphens CSS property specifies how words should be hyphenated when text wraps across multiple lines. It can prevent hyphenation entirely, hyphenate at manually-specified points within the text, or let the browser automatically insert hyphens where appr

developer.mozilla.org

Demo - CodeSandbox

laughing-darwin-kdj5x - CodeSandbox

laughing-darwin-kdj5x by sonim1 using react, react-dom, react-scripts

codesandbox.io

마케팅 - 콜드 메일(Cold mail)이란?

손님1(Kendrick) — Thu, 14 Jan 2021 14:05:29 +0900

콜드 메일(Cold mail)이란?

알지 못하는 사람에게 보내는 홍보 이메일이며, Cold mail, Cold emailing 등으로 불립니다.

홍보라 해서 세일즈에만 사용하는 건 아니고 협업 및 인맥 쌓기 혹은 취업 할 때도 사용할 수 있습니다.

모르는 사람에게 메일을 보내기 때문에 언뜻 보면 스팸메일 같지만, 콜드 메일은 스팸으로 구분되지 않고 다음 단계(답신 등)로 갈 수 있게 대상에 맞춰서 내용을 전달합니다. 대신 흥미를 유발하지 못하거나 부족한 내용이라면 스팸이나 진배없겠죠?

이런 형식의 홍보를 메일이 아닌 전화로 한다면 콜드 콜(Cold Call)이라고 합니다.

가령 스타트업을 만들었을 때, 제품을 어떻게 홍보해야 할까요?

Product Hunt나 Reddit에서 글을 올려도 좋겠지만 특정 company나 타깃이 명확한 서비스라면 이런 방식을 이용해서 홍보를 할 수 있습니다.

자세한 전략은 참고할 만한 관련 링크를 아래 추가하였습니다.

Cold Email. 차가운 이메일? 콜드 메일을 통해 인맥을 늘리는 방법
답장율을 높이는 콜드 메일 작성법 - 지구나그네
바쁜 사람에게 이메일 답장을 받는 검증된 방법 - 마케팅주스
콜드 이메일이 기업가들에게 여전히 중요한 고려 사항인 이유 - 마소캠퍼스

Paywall을 위한 CSS linear-gradient

손님1(Kendrick) — Sat, 9 Jan 2021 05:44:35 +0900

paywall을 위한 CSS Gradient

Paywall이란

Paywall이란 유저가 찾는 약간의 컨텐츠만 제공하고, 전체 컨텐츠를 보고 싶을 때는 돈을 내서 구독하게 하는 방법입니다.

지난 수년동안 많은 서비스가 페이월을 사용 중입니다.. 예를 들어 뉴스 사이트들이나 Medium 그리고 Wired도 사용하고 있습니다. (지금은 안쓰는 곳도 많지만요)

이 포스트에서는 paywall에서 사용되는 팝업이나 백엔드 처리가 아닌, 단순히 linear-gradient CSS style을 통해 아래로 갈수록 사라지는 효과를 어떻게 작성하는지 설명합니다.

Gradient로 흐려지는 효과 적용하기

단순히 CSS의 linear-gradient를 통해 사라지는 효과를 어떻게 구현하는지에 대해서 알아보겠습니다.

CodePen Demo

#target {
  background: linear-gradient(rgba(255, 255, 255, 0), rgba(255, 255, 255, 0.5), rgba(255, 255, 255, 1));
}

적용 전

적용 후

이후 위와 같은 UI에 구독 팝업 혹은 구독 페이지로 넘어가는 버튼을 추가해주면 됩니다.

실제 컨텐츠를 전부 가져오면서 css를 위처럼 사용하여, 권한이 없는 사용자가 전체 내용을 못 보게 할 수도 있지만, 유저가 dev console 등을 통해서 dom을 조작할 수 있거나 네트워크에서 response를 확인하는 경우 무용지물입니다. 그러므로 반드시 벡엔드에서 권한을 체크 후에 보여줄 데이터만 반환하는 처리가 들어가야 합니다.

마치며

Paywall이 무엇인지 그리고 linear-gradient를 Paywall에 어떻게 사용하는지 간단하게 알아보았습니다.

참고

What is paywall

2020년 회고

손님1(Kendrick) — Thu, 7 Jan 2021 12:30:33 +0900

2020년 회고

지난 회고 모음

'Notice' 카테고리의 글 목록

캐나다 토론토에서 일하는 개발자 입니다. 프로그래밍 관련 아티클을 다룹니다.

blog.sonim1.com

2019년이 지나고 2020년이 마무리되었습니다.

올해도 시간이 순식간에 지나갔네요. 특히 COVID19... 세계적인 이슈로 인해서 모든 사람이 정신없고 분노하고 걱정스러운 시간을 보냈습니다.

다들 최악의 한해를 잘 넘기셨고 이제 시작되는 2021년은 좋은 이벤트 맞이했으면 합니다.

매년 회고에 블로그 글을 많이 쓰자고 했던 것 같은데...

지난 2년 동안 블로그 활동을 부지런하게 하지 못했기 때문에 메인화면에 회고가 2개가 한 번에 보이네요. ㅋㅋㅋ...

이제는 3개가 보이겠군요. 내년에는 올해 회고가 보이지 않게 꾸준히 작성해야겠습니다.

아무쪼록 지난 1년간의 행보를 간략하게 적어봅니다.

COVID... 최악의 한해

COVID19

캐나다의 경우 1월까지는 Covid19 위험에 대한 인식이 높지 않아서 다들 평소처럼 지냈습니다. 저도 그때 토론토 시청에서 진행한 푸드트럭 행사를 와이프와 갔었죠. 전체적으로 다들 독감 정도로 치부하고 크게 신경 쓰지 않는 분위기였습니다.

하지만, 코로나가 본격적으로 확산되던 2~4월부터 혼돈의 도가니였습니다.

캐나다 온타리오에서 주최하는 행사 및 회사 Retreat(워크샵)이 다 최소 되었습니다. 회사 매출 그래프는 오르락내리락하며, 당장 직장의 존폐가 불분명한 상황... 모든 서비스들이 그러하겠지만 세계 경제의 혼란이 최고조였기 때문에 여기저기 칼바람이 몰아쳤었습니다.

6월 이후, 어느 정도 안정화가 되면서 운 좋게 최악의 경우는 피했습니다. 한국에서 결혼하고 미뤄뒀던 신혼여행 그리고 다른 여행 계획들도 다 무산되었지만, 타지에서 낙동강 오리알 신세는 운 좋게 면했네요.

사실 할 말이 더 많지만, 이를 언급하는 것만으로 우울해지기 때문에 다음으로 넘어가겠습니다...

모든 분, 특히 자영업자분들 힘내세요!

원격근무

저는 개인적으로 온라인으로 하는 커뮤니케이션을 선호하지 않았기 때문에 원격근무가 자유로움에도 불구하고 매일 사무실로 출근을 했었습니다.

사무실은 집중할 수 있는 환경뿐만 아니라 식사 제공(구글 등 알만한 해외 대기업들의 식당은 모르는 사람이 없을 정도로 유명하지만, 사실 외국에 식사 제공하는 회사가 흔치 않습니다 ㅜㅜ) 그리고 간식도 제공되고, co-worker와 커뮤니케이션 및 페어 프로그래밍도 원활하게 할 수 있어서 선호했었습니다. 하지만 Covid19의 여파로 사무실이 폐쇄되었고 강제 원격근무에 돌입하게 됩니다.

초반에는 혼돈 그 자체였습니다. 보통 원격근무를 할 때 주변 시선을 의식할 수 있는 카페로 갔었는데, 락다운되서 어디로도 가지 못하는 상황. 집에서는 자꾸 딴짓을 하게 되게 때문에 시간 관리도 잘 안 되고 생산력이 최악이었더랬죠. 덕분에 올해 첫 번째 Cycle에 집중을 잘 못 해서 최악의 퍼포먼스를 보여주게 되었습니다.

하지만 나중에는 노오오오오력으로 극복 했습니다. 특히 이때 읽은 초집중이라는 책이 정말 많이 도움이 되었습니다.

지난 1년간 원격근무를 통해 어떤 문제를 겪었고 어떻게 극복했는지에 대한 원격근무 경험 관련 포스트도 조만간 올릴 예정입니다.

새로운 작업환경

회사 동료들이 올해 초 생일 때 돈을 모아서 스탠딩 데스크를 사줬습니다.
이게 한두 푼 드는게 아니라 정말 너무 고마운 마음이 큽니다! 코로나로 인해서 사무실이 닫고 나서 본격적으로 이 책상을 사용하게 되었습니다.
책상 높이 조절할 때마다 놀랍고, 항상 감사한 마음이 먼저 드네요!

책상 조립하자마자 신나서 찍었던 영상!

업무

업무에 큰 변화가 생겼습니다.

Spotify에 squad를 따랐지만, 이 모델의 실패를 인정한 이후 Basecamp의 Shape Up을 본격적으로 수용했습니다.

이에 따라 업무도 많이 변경되었습니다. 입사 후 2019년까지는 Infrastructure 및 서비스 개발을 겸업으로 했는데, 2019년 말부터 Infrastructure 팀을 따로 분리하고, 잠재력 있는 두 명의 회사 동료에게 인수인계를 하였습니다.

그 후 본격적으로 회사 서비스 개발에 집중하게 됩니다. 올 한해는 인프라스트럭쳐 회의에 참가하면서 조언을 하는 정도로만 하고, 여러 기능에 대한 Shape Up 및 개발을 진행했습니다.

작년 말 Senior Software Engineer로 진급 후, 미칠듯한 부담감 그리고 갑자기 완전히 바뀐 업무 스타일 및 원격근무 때문에 연초에는 생산성이 바닥을 달렸는데, 이후 적응하면서 모든 게 자리를 잘 잡게 되었습니다.

하지만 아직도 시니어 소프트웨어 엔지니어로서 내가 잘하고 있나? 하는 의문이 들기도 합니다.

개발자 3~4년 차에 더닝크루거 효과에 빠지면서 거만해졌던 시절도 있지만, 해외에서의 생각지 못한 빠른 진급과 매우 긍정적인 인사평가 결과는 내가 남에게 내 실력을 속이고 있는 게 아닌가 싶게 느끼는 가면 증후군에 걸리게 하는 원인이 되었습니다.

이와 관련된 포스트도 조만간 정리해서 올릴 예정이니 기대해주세요!

독서 모임

첫 취업, 첫 이직, 회사의 큰 규모의 프로젝트, 영어 공부, 캐나다 워홀 준비를 할 때도 하루하루 시간이 부족하다는 생각이 들었지만, 올해는 살면서 제가 느낀 최고로 바쁜 한해였고 그때 문득 생각이 들었습니다. 바쁘고 시간이 없을 때 적은 시간으로 최대한의 가성비를 뽑을 수 있는 게 무엇일까?

결국 생각해낸 것은 독서였습니다. 허나 혼자 하기에는 제가 꾸준히 못 할거라는 메타인지가 되어있었기 때문에 자연스러운 독서 환경 설정을 하기 위해 독서 모임을 만들었습니다.

사실 모임 초반에는 독서라는 목적이 흐려지는게 느껴져서 없앨까도 고민했지만, 어느새 위 컨셉을 공감해주는 사람들과 함께 꾸준히 하게 되었네요.

그 결과, 독서 모임을 통해서 3년 동안 읽고 접고 읽고 접고 못 끝내던 지긋지긋한 Devops관련 책을 다 봤으며, 추가로 6권의 책을 더 읽었습니다.

어느새 독서하는 습관도 자리 잡아, 매주 독서에 최소한 3시간 이상 투자하지 않는다면 불안해질 지경입니다.

연말에는 캐나다도 락다운 레벨이 많이 올라가서 오프라인 모임을 제대로 진행을 하지 못하고 있는데, 어서 빨리 백신이 잘 풀려서 다시 제대로 시작했으면 합니다.

신년운세

매년 믿고 보는 네이버 신년운세!

작년 운세는 마치 약간 제게 주의를 주는 듯 의미심장했다면, 올해는 좀 더 결과로 보상받는 듯한 좋은 운세가 나왔습니다.

2021년! 더도 말고 덜도 말고 이 운세처럼만 되길 기대해봅니다!

네이버에서 무료입니다

재미로 한번 보고 보관해 놓는 걸 추천합니다. 매년 지난 운세를 볼 때마다 억지로 끼워 맞추고 놀라는 소소한 재미가 있습니다. ㅋㅋ

마치며

좋은 일도 많았지만 안 좋은 일은 더 많은 한해였습니다.

다들 지난 한 해 고생 많으셨고, 오는 2021년 좋은 기회 많이 잡으시길!

Mac OS Big Sur 메뉴바 밝기 이슈

손님1(Kendrick) — Fri, 1 Jan 2021 07:58:49 +0900

Mac OS Big Sur 메뉴바 밝기 이슈

지난 Catalina 업데이트부터 잘 쓰고 있던 다크모드가 Big Sur를 사용하고부터 뭔가 이상해졌습니다.

전체적으로 UI가 다시 뭔가 밝아진 느낌? 저는 크롬을 사용할 때, Incognito 모드와 구분하기 위해서 크롬만 다크 모드 를 끄고 사용하기 때문에 모르고 있었는데, 메뉴바에 하얀색 아이콘이 아예 안 보이더군요.(카카오톡)

하얗게 나오는 메뉴바, 그리고 뭔가 흐리멍텅한 사파리

알고 보니 업데이트 이후, OS에서 현재 배경화면의 전체적인 색에 따라서 transparent를 조절하기 때문이었습니다.

바뀌는 건 상관없는데 contrast나 색상을 체크 안 해서 하얀색 아이콘이 아예 안 보이는 게 계속 눈에 띄어서 아래 방법으로 해결했습니다.

1. System Preferences 열기
2. Accessibility -> Display
3. Reduce Transparency 체크 해제

이제 진짜 Dark Mode로 들어간 느낌.

이게 다크모드지

참고

https://forums.macrumors.com/threads/change-background-color-for-menu-bar-macos-big-sur.2271186/
NightOwl - 특정 애플리케이션의 다크모드 설정을 변경할 수 있는 프로그램

안돈 코드 - Andon Cord

손님1(Kendrick) — Thu, 31 Dec 2020 13:06:04 +0900

안돈 코드 Andon Cord

예상치 못한 상황이 발생했을 때 문제 해결을 위해서 인력이 동원되어야 합니다.

이 포스트에서 소개하려는 도요타의 안돈코드가 무엇인지 알아보고, 이를 IT 개발 환경에서 어떻게 활용할 수 있는지 알아봅시다.

도요타의 안돈 코드

도요타의 생산공장에는 모든 근로자와 관리자가 문제 발생 시 잡아당길 수 있는 코드가 있습니다.

작업에 문제가 발생하거나 부품에 결함이 있을 때 혹은 작업 시간이 예정 시간보다 길어질 때 바로 이 코드를 잡아당깁니다.

안돈 코드가 당겨지면 팀장은 바로 문제 해결에 착수하며, 생산 라인이 중단되고 대응책이 마련될 때까지 전체 조직이 동원되기도 합니다.

하루에 1000번의 안돈코드가 발생하면 작업이 1000번 멈추는 것이 아니고 팀장이 짧은 시간 내에 판단(대략 50초) 후 상황에 따라 다시 가동하거나 전체 라인을 중지시킵니다.

배포 파이프라인을 위한 안돈 코드

위에서 언급한 안돈코드의 사용처는 도요타의 자동차 생산라인이지만, 해당 컨셉을 IT 제품의 배포 파이프라인을 위해서 사용할 수 있습니다.

항상 성공적인 배포 파이프라인을 유지하기 위해서 가상의 안돈코드를 추가하여, 릴리즈 시 배포 파이프라인이 깨졌을 때 누군가 문제를 해결하거나 롤백을 하고, 모든 팀원은 원래 상태로 되돌아가기 위해 커밋을 롤백할 수 있는 권한을 부여받아야 합니다.

문제가 발생했을 시, 해당 코드의 당사자만 오류를 확인하는게 아닌, 다른 누군가의 코드도 분석하며, 나중에 그들도 내가 놓쳤던 실수를 찾게 도와 줄 수 있습니다.
개인의 목표보다 팀의 목표, 더 나아가 회사의 목표를 우선시해야 하기 때문에, 품질 및 신뢰성의 우선순위는 항상 최고로 보장됩니다.

안돈 코드가 없고 배포 파이프라인의 문제를 바로 수정하지 않는다면, 결과적으로 발생한 문제를 점점 복구하기가 힘들어질 수밖에 없습니다.
기존 테스트가 안정적으로 실행되지 않는다는 것은 새로운 테스트를 추가하거나 유지보수가 제대로 되지 않을 가능성이 높으며, 배포에 대한 신뢰가 떨어지고, 마침내 엄청나게 기술 부채를 마주하게 될 것입니다.

참고

데브옵스 핸드북
IDEAS FOR ACTION FROM THE CULTURE CODE

Git에 공동 Author 추가하기

손님1(Kendrick) — Sun, 16 Aug 2020 23:33:26 +0900

Git에 공동 Author 추가하기

현재 저는 회사에서 새로운 기능을 추가하는 프로젝트를 진행 중입니다.

하지만 프로젝트 시작하자마자 작은 고민이 생겼습니다.

미리 설계해 놓은 문서를 바탕으로 제가 프로토타입을 만들고, 같은 팀원이 제 프로토타입 코드를 실제 서비스에 반영할 수 있게 작업해 주긴 했으나 지저분한 커밋이 많고 추가로 수정하고 싶은 부분이 생겨서 어떻게 할까 고민에 빠졌습니다.

결국 커밋을 전부 reset 후 새로 작성하기로 합니다.

Feature Flag를 통해서 추가되는 새로운 기능이기 때문에 기존 코드를 변경하지 않기도 하고, 첫 릴리즈 이전에 발생한 변경사항들이 Commit에 존재하는 의미가 없으며 또한 rebase하기에는 손이 더 많이 갈 것 같아서 말이죠.

이때 한가지 고민이 생겼는데 변경된 Commit 대한 Author를 어떻게 할지가 문제였습니다.

공동 Author 추가하기

Author를 아예 같이 작업하던 친구로 하려고 했다가 생각해보니 코드 리뷰 시 둘 다 노티가 되면 좋지 않을까 싶어서 여러 명을 Author로 등록하는 방법을 사용했습니다.

공동 Author를 추가하기 위해서 아래 3가지 방식 중 하나를 선택했습니다.

Github Desktop을 이용한 방식 Link

Git Commit 메시지에 추가하는 방식

$ git commit -m "Refactor usability tests.
>
>
Co-authored-by: name <name@example.com>
Co-authored-by: another-name <another-name@example.com>"

Github Commit 메시지에 추가하는 방식
위와 동일합니다.
내용에 Co-authored-by: name <name@example.com>를 추가해줍니다.

이후 아래와 같이 커밋메시지가 보이게 됩니다.

마치며

새로운 기능을 개발자 A(Development Prototype) -> 개발자 B(Implementation) -> 개발자 A(Refactoring) 순서로 작업한 적이 처음이라 흥미로운 경험이었습니다. 또한 회사에서 1 week 배포 싸이클을 가지고 있기 때문에 발생한 특수한 상황이라고 생각합니다.

이를 단순히 rebase 등으로 처리했다면 제가 작업한 프로토타입에 대한 모든 책임을 동료에게 위임하게 되는 모양새라서 뭔가 오묘한 기분이 들더군요.

뿐만 아니라 이 친구가 작업한 코드를 제가 정리할 겸 또 수정하려니 또 Author가 다시 제게로 오기에 이게 참 뭔가 말하지 못할 민망한 문제가 있었는데, 이런 상황에서 multiple author를 추가해서 같이 작업한 코드에 책임감도 나눌 수 있었습니다.

Reference

https://docs.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors

콘웨이의 법칙 - Conway's law

손님1(Kendrick) — Fri, 31 Jul 2020 12:54:09 +0900

콘웨이의 법칙 - Conway's law

"시스템을 설계하는 조직은 필연적으로 해당 조직의 커뮤니케이션 구조를 복제한 설계물을 만들게 된다"

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

- Melvin E. Conway

해커들의 Slang을 모아놓은 Jargon File에서는 이를 아래와 같이 설명하고 있습니다.

소프트웨어 구조는 소프트웨어 개발팀의 구조와 같아질 것이다. 일반적으로 4개의 팀이 컴파일러 작업을 하고 있다면, 4단계의 컴파일러가 만들어질 것이다.

간단히 요약하자면.

조직의 구조 = 서비스의 구조.

이해를 쉽게 하기 위해서 아래 예를 봅시다.

Monolithic architecture

Monolithic architecture 서비스를 운영하는 조직의 경우, 모든 팀이 모놀리식 아키텍쳐와 같이 큰 하나의 유기체로 돌아가게 될 것입니다. 서비스의 각각의 구성이 서로 밀접하게 연결되어 있으니 전체가 하나의 팀이 되어 언제든지 쉽게 커뮤니케이션하고 공유할 수 있는 상태여야 하기 때문입니다.

Micro service architecture

반면 Microservice architecture를 따르는 조직은 필연적으로 분리될 수밖에 없습니다. Netlify, Spotify가 대표적인 예입니다. 서비스의 결속이 느슨해진다는 의미는 결국 legacy 코드에 대한 걱정을 쉽게 떨칠 수 있고 핵심기능에 좀 더 집중할 수 있게 도와줍니다. 마찬가지로 팀 또한 기능이나 서비스별로 분리가 되므로 자연스럽게 서비스와 조직의 구조가 일치하게 됩니다.

그렇기 때문에 마이크로서비스를 운영하는 회사는 팀 간의 원활한 소통을 중요시합니다!

물론 서비스 혹은 조직 아키텍쳐에 대한 깊이 있는 고민이 이루어지지 않은 회사에서는 통용될 수 없는 법칙일 수 있습니다. 왜냐하면 서비스의 구조가 어설프게 잡혀있다면 조직도 어설프게 돌아가고 있을 확률이 높기 때문입니다. 만약 확실한 컨셉이 존재하는 회사라면 자연스럽게 느낄 수 있는 법칙입니다.

역 콘웨이 전략(Inverse Conway's maneuver)

필연적으로 조직의 커뮤니케이션 구조를 복제한 설계 물을 만든다는 콘웨이의 법칙을 전략적으로 이용해서 조직의 구조를 마이크로서비스 아키텍처에 반영되도록 설계하는 걸 역 콘웨이 전략이라고 합니다.

마치며

데브옵스나 소프트웨어 개발 방법론 이야기를 할때, Agile같은 개념들을 팀에 급하게 적용하지 말고 조직과 문화가 함계 전체적으로 변경해야 된다고 언급했었는데, 긴 설명이 필요 없이 콘웨이의 법칙으로 깔끔하게 정리가 되네요.

Ref

다양한 소프트웨어 버전 명명 (Software versioning)

손님1(Kendrick) — Fri, 3 Apr 2020 21:41:22 +0900

다양한 소프트웨어 버전 명명 (Software versioning)

세월이 흐르면서 여러 가지 방법의 소프트웨어 버전 명명이 존재했었습니다.

결국 추세는 Symantic Versioning으로 기울었고, 현재는 많은 개발자가 Semantic Versioning을 따르기를 당연 시 하며, 왜 써야 하는지도 이해하고 있습니다.

하지만 의외로 많은 서비스들이 시맨틱 버전을 따르지 않습니다. 왜일까요?

당장 제가 다니고 있는 회사만 보더라도 Semantic Versioning과 다른 방식의 버전 명명법 두 가지를 사용하고 있습니다.

이와 관련하여 예전에 고민했던 내용을 이번 기회에 정리해서 포스트를 올려 봅니다.

Semantic Versioning

Major, Minor 그리고 Patch의 의미를 담고 있는 버전 명명법입니다.

{major}.{minor}.{patch}

Major: 이전 버전과 호환이 안 되는 변경이 있다면 숫자를 올립니다
Minor: 이전 버전과 호환되는 기능 추가가 있다면 숫자를 올립니다.
Patch: 이전 버전의 버그를 수정했다면 숫자를 올립니다.

그리고 시험판(알파 베타 등) 및 추가 메타데이터들은 patch 뒤에 확장으로 제공됩니다.

공개된 라이브러리나 오픈소스라면 필수적인 Versioning 방법입니다.

가장 자주 언급되며 현재까지 매우 많이 알려진 버전 명명법이기 때문에 자세한 설명은 생략하도록 하겠습니다.

이에 대한 자세한 설명은 공식 Spec 문서를 참고해 주세요.

CalVer (날짜 기반 Versioning)

Calendar Versioning — CalVer

CalVer is a versioning convention based on your project's release calendar, instead of arbitrary numbers. Versioning gets better with time. For maintainers, versioning allows us to specify precise dependencies within an ever-expanding ecosystem. For seller

calver.org

여러 프로젝트가 CalVer라는 날짜 기반 버전 관리 체계를 사용합니다.

Ubuntu Linux를 보면 다음과 같은 버전을 가지고 있습니다.

Ubuntu 4.10 (Warty Warthog)
...
Ubuntu 19.04 (Disco Dingo)
Ubuntu 19.10 (Eoan Ermine)
Ubuntu 20.04 LTS (Focal Fossa)

우분투는 버전 명명을 연도 및 월로 사용하고 있습니다.

처음 우분투가 릴리즈 된 게 2004년도 10월이란 걸 버전명만 보고 알 수 있습니다.

이런 버저닝을 통해서 우리는 SemVer와는 다른 이점을 가질 수 있습니다.
예를 들어 우분투는 짝수년 2/4 분기에 발생하는 모든 4번째 릴리즈를 LTS 릴리즈로 지정합니다.
그리고 이런 LTS 버전의 경우 5년 정도의 지원을 해주게 됩니다.

이 말인즉 만약 제가 16.04 LTS 버전을 쓰고 있었다면, 이 버전의 지원 기간이 2021년도 4월까지인걸 패치 명만 보고도 짐작할 수 있기 때문에 이에 따른 액션을 할 수 있습니다.

날짜 번호는 마케팅으로도 사용될 수 있습니다.

Microsoft Office, Windows를 보면 쉽게 알 수 있습니다.
Microsoft Windows 95 -> MS-DOS 7.00 or Windows 4.00
Microsoft Windows 2000 Server - Windows NT 5.0

마케팅을 위해 사용자가 인식하기 쉬운 타이틀을 사용하지만, 실제로 각각의 버전은 전혀 다른 실제 버전을 따로 가지고 있습니다.

NumVersion (숫자 기반 버저닝)

Apple은 NumVersion을 기반으로 한 공식 버전 번호 구조로 되어 있습니다.

한자리 혹은 두 자리의 메이저 버전, 한자리의 마이너 버전, 한자리의 버그 버전이 있고 스테이지 단계에서 추가 suffix를 사용하고 릴리즈 할 때 추가 suffix를 제거합니다.

1.0 버전에다 다음 버전을 개발한다면, 1.1.0a0 이런 식으로 suffix를 가지고 있습니다. 그 후 1.1.0f0와 같이 개발 버전이 올라가고, 릴리즈 시에는 스테이지 단계의 suffix를 제거하여 1.1이 됩니다.

이는 최종단계에서 깔끔한 버전을 사용하게 되는 장점이 있습니다.

소프트웨어 개발 시 패치 별로 제공하려는 기능에 대한 집중이 가능하기도 합니다.

TeX

스탠퍼드대학교의 도널드 커누스(Donald Knuth) 교수가 만든 조판 언어, 시스템입니다.

markdown에서 수식 입력으로 사용하는 LaTeX가 TeX를 기반으로 만들어졌습니다.

The Art of Computer Programming 책을 집필하는데 그 당시 제공되던 출판 프로그램의 수식 표시가 마음에 들지 않아 만들었다고 합니다.

논외지만 저 책... 8년인가 전쯤에 멋모르고 읽다가 포기했었는데 언젠가 다시 도전해야겠네요.

아무튼 다시 돌아와서, TeX의 메이저 버전은 3이고 현재 최신 버전은 3.14159265입니다.

보이는 숫자처럼 어마어마한 양의 패치를 한 건 아니고, 패치가 될 때마다 원주율을 이용해 숫자를 하나씩 추가했습니다.

총 8번의 패치가 있었던 셈입니다.

도날드 커누스는 패치 번호를 원주율로 설정하고, 이 시점에서 나머지 모든 버그는 기능으로 선언되며 TeX의 출력은 영원토록 동일하게 유지되었습니다.

Java

Java는 복잡한 버전 명명법을 가지고 있습니다.

우선 마케팅 버전과 실제 버전, 즉 두 가지의 버전이 있습니다.

마케팅 버전은 또다시 아래와 같이 나뉩니다.

Standard Edition (SE)
Micro Edition (ME)
Enterprise Edition (EE)

Java의 Android 또한 Java SE와 크게 다릅니다.

실제 버전은 아래와 같이 표현됩니다.

1.8.0_101-b13

이것은 JDK 1.8.0, Update 101, Build # 13을 말합니다. Oracle은 릴리스 노트에서 다음과 같이 언급합니다.

Java™ SE Development Kit 8, Update 101 (JDK 8u101)

Java 8은 Java 1.8과 같으며 Java 8은 단지 마케팅 이름일 뿐입니다.

개발을 처음 배울 때 Java 버전이 너무 헷갈리게 되어있고 SE를 깔아야 할지 EE를 깔아야 할지 고민했던 기억이 나네요.

Eclipse

이클립스 또한 버전 명명이 특이하게 바뀐 케이스입니다.

코드네임을 공개적인 버전으로 썼는데 위성 이름을 쓰다가 갈릴레오 갈릴레이 이름을 따오고(Callisto, Europa, Galileo),

알파벳 네이밍을 하더니
Helios(2010년), Indigo(2011년), Juno(2012년), Kepler(2013년), Luna(2014년), Mars(2015년),

2018년 드디어 연도-월 버저닝으로 변경하게 됩니다.

이클립스를 써보신 분들은 공감하실 듯합니다, 알파벳 네이밍에서는 뭐가 최신 버전인지 매우 헷갈렸으나 연도-월 버저닝을 쓰고부터 인식하기가 좋아졌습니다.

BLAG Linux and GNU

리눅스의 한 종류 같습니다만 처음 들어봅니다. 각설하고 BLAG Linux는 엄청 큰 버전 번호를 제공합니다.

메이저 릴리즈에는 50000, 60000의 숫자를 사용하며, 마이너 릴리즈는 숫자를 1씩 증가시킵니다. (50001, 50002)

2014년에는 200000버전이 릴리즈 되었다고 합니다.

특이하게 알파 및 베타 릴리즈는 주 릴리즈보다 약간 적은 번호를 사용합니다.
20000의 알파 1 - 19999.00071
30000의 베타 2 - 29999.50000

숫자가 마치 워해머스럽기도 하고, 뭐랄까 따라 하고 싶진 않지만 상남자 느낌이...

멋있네요.

Windows 10

윈도우는 마케팅용으로 Windows 10이라는 버전 명을 사용하지만, 또한 실제 빌드 버전도 가지고 있습니다.

버전 Windows 10 Pro
버전 1511
OS 빌드 10586.104

1511은 15년 11월에 대규모 업데이트를 했다는 뜻입니다.

Venngage

Venngage는 수많은 포스터, 인포그래픽 템플릿을 제공하는 온라인 에디터입니다.

Venngage
Venngage LinkedIn Top Startups 2019에 선정되다

Free Infographic Maker - Venngage

Join over 1 million people creating their own professional graphics with our easy to use infographic maker. Sign up for free and choose from 1000+ infographic templates.

venngage.com

2019년 8월 - LinkedIn Top Startups 2019에 선정되다

2019년 8월 - LinkedIn Top Startups 2019에 선정되다2019년 8월 링크드인 탑 스타트업에 선정되다 LinkedIn Top Startups 2019: The 25 hottest Canadian companies to work for now 캐나다의 핫한 스타트업 25에 선정되었습니다. 해당 기사에만 언급될 뿐만 아니라 게임 업적처럼 회사 메인 배너에 메달과 텍스트를 추가해주네요. 그저 간지. LinkedIn - Venngage L

journey.sonim1.com

소소하게 여행 블로그에 올리며 자축도 했었는데요 흠흠 아무튼

제가 다니고 있는 회사에서 사용하는 버전 명명법입니다.

작년 초까지는 메인 애플리케이션에 대하여 SemVer를 따랐었습니다.

이 당시 직원들이 늘어나는 시기와 맞물려 Agile 프로세스를 Spotify의 Squad 방식으로 바꾸었고, 그에 따라 릴리즈 주기가 1주일로 변경되었습니다.

매주 마이너 버전이 1씩 올라가니 금세 세 자릿수를 돌파하려고 했더랬죠, 결국 2.98까지 올라온 버전 명을 보고 엔지니어들 간의 마찰이 생겨났습니다.
3으로 올려야 한다. 2.100으로 세 자릿수로 가야 한다. 아니면 다른 버전 체계를 사용해야 한다 등등 말이죠.

결국 많은 상의 끝에 CalVer를 수정한 버전 명을 사용하게 되었습니다.

{year}.{weeknumber}.{patch}

week number는 몇 번째 주인지를 의미합니다. 1년에 총 52까지 증가할 수 있습니다.

현재는 20.14.0 릴리즈를 앞두고 있습니다.

배포는 Github flow를 약간 개선해서 사용하고 있습니다.

이 또한 비슷한 맥락인데 10년 전에 정의되어 있는 git flow를 많은 곳에서 따르고 있습니다. 공식 문서에서도 그에 따라 최근에 업데이트되었고 github flow를 따르기를 권장하고 있습니다.
만약 Git Flow를 사용하고 있다면 Github Flow로 변경해 보는 것 또한 권장합니다.

A successful Git branching model » nvie.com

A successful Git branching model

In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.

nvie.com

Understanding the GitHub flow · GitHub Guides

Create a branch When you're working on a project, you're going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow. When y

guides.github.com

마치며

새로운 개발자나 인턴이 들어올 때 왜 SemVer를 쓰지 않는지 궁금해하는 경우가 있어서 정리도 할 겸 기억을 돌이켜 글을 작성했습니다.

현재도 사실 많은 분들이 For this system to work, you first need to declare a public API 이 부분을 간과하고 SemVer를 사용하고 있습니다. 다시 자신의 서비스를 돌아보고 적합한 방식으로 개선한다면 이 부분을 통해서 생산성을 향상할 수 있을 것입니다.

참고

Category:Software version histories - Wikipedia

Best Practices When Versioning a Release - via @codeship | via @codeship

Semantic Versioning 2.0.0 | Semantic Versioning

Software versioning - Wikipedia

Luyin : 소프트웨어 버전 규칙

이클립스(통합 개발 환경) - 나무위키

버전 번호 | 메아리 저널

Java Language - Java 릴리스 및 버전 명명 | java Tutorial

체계적인 버전 관리, SemVer

Athena를 이용한 AWS ELB Access Log 분석 - Part 2

손님1(Kendrick) — Thu, 2 Apr 2020 21:50:59 +0900

우리는 지난 포스트에서 왜 Athena를 써야 하며, 무슨 혜택이 있는지 알아보았습니다.
이제 간단한 예제와 Access Log를 분석해 보도록 합시다.

이 포스트는 AWS ELB의 기본 경로 규칙을 따르고 있습니다

데이터베이스 및 테이블 생성하기

/*
데이터베이스 생성
*/
create database alb_db

/*
테이블 생성

참고로 현재시간(2020년 3월 2일) 이후로 AWS에 의해 스키마 정보가 업데이트될 수 있으니 테이블 생성 시 아래 링크를 참고하시면 더 좋습니다.

https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html
*/
CREATE EXTERNAL TABLE IF NOT EXISTS alb_logs (
            type string,
            time string,
            elb string,
            client_ip string,
            client_port int,
            target_ip string,
            target_port int,
            request_processing_time double,
            target_processing_time double,
            response_processing_time double,
            elb_status_code string,
            target_status_code string,
            received_bytes bigint,
            sent_bytes bigint,
            request_verb string,
            request_url string,
            request_proto string,
            user_agent string,
            ssl_cipher string,
            ssl_protocol string,
            target_group_arn string,
            trace_id string,
            domain_name string,
            chosen_cert_arn string,
            matched_rule_priority string,
            request_creation_time string,
            actions_executed string,
            redirect_url string,
            lambda_error_reason string,
            new_field string
            )
            PARTITIONED BY(year string, month string, day string) 
            ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
            WITH SERDEPROPERTIES (
            'serialization.format' = '1',
            'input.regex' = 
        '([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0-9]*) ([-.0-9]*) (|[-0-9]*) (-|[-0-9]*) ([-0-9]*) ([-0-9]*) /"([^ ]*) ([^ ]*) (- |[^ ]*)/" /"([^/"]*)/" ([A-Z0-9-]+) ([A-Za-z0-9.-]*) ([^ ]*) /"([^/"]*)/" /"([^/"]*)/" /"([^/"]*)/" ([-.0-9]*) ([^ ]*) /"([^/"]*)/" /"([^/"]*)/"($| /"[^ ]*/")(.*)')
            LOCATION 's3://your-alb-logs-directory/AWSLogs/<ACCOUNT-ID>/elasticloadbalancing/<REGION>/';

잘 보시면 중간에 PARTITIONED BY(year string, month string, day string)이 추가되어 있습니다.

이를 추가하지 않는다면 우리는 번거롭게 파티션 추가할 필요 없이 모든 데이터를 즉시 쿼리 가능합니다.
데이터가 얼마 없다면 이는 매우 유용하겠지만 만약 로그가 엄청나게 많이 있다면?
돈도 많이 내고 쿼리 시간도 엄청나게 오래 걸리게 되죠.

데이터 파티셔닝

파티셔닝은 우리가 사용할 S3 bucket의 폴더를 특정해주며, 쿼리 시 해당 폴더의 로그만 스캔하게 해줍니다.
전체 데이터를 스캔하지 않으며 이로써 우리는 쿼리에 들어가는 비용과 시간을 절약할 수 있습니다.

하루의 1~2기가 정도의 로그를 쌓고 있으므로 우리의 경우 (year, month, day) 파티션을 사용하여 일별로 파티션을 관리하고 있습니다만, 만약 특정 서비스의 access 로그가 많지 않다면 파티션을 (year, month)까지만 설정하시는 것도 좋은 방법입니다.

-- 아래는 alb_logs 테이블에 하나의 파티션을로드하는 샘플 "alter table" 명령입니다.
-- 스캔하고 싶은 year, month, day를 bucket의 폴더명과 동일하게 입력하고, location에 정확한 S3 경로를 입력해줍니다.
ALTER TABLE alb_logs add PARTITION (year="2020", month="01", day="01") location "s3://your-alb-logs-directory/AWSLogs/<ACCOUNT-ID>/elasticloadbalancing/<REGION>/2020/01/01";

-- 아래 명령어로 불필요한 파티션을 제거 할 수 있습니다.
-- 이것저것 추가하여 정리가 너무 귀찮다면 DROP TABLE 후 다시 생성하는 것도 좋은 방법입니다. 
ALTER TABLE alb_logs DROP PARTITION (year="2020", month="01", day="01");

-- 테이블에 현재 추가되어있는 파티션들을 볼 수 있습니다.
SHOW PARTITIONS alb_logs;

-- 파티션 데이터 불러오기 명령어입니다
-- 파티션은 추가될 때 데이터를 불러옵니다. 하지만 최신데이터를 보고 싶을 경우 아래 명령어를 이용해 데이터를 업데이트 할 수 있습니다.
-- 이 명령은 로드할 파티션 수에 따라 실행하는 데 시간이 걸릴 수 있습니다.
MSCK REPAIR TABLE alb_logs;

데이터 쿼리 하기

SELECT * FROM alb_logs limit 10;

과정을 잘 따라왔다면 위 명령어를 통해 10개의 데이터를 확인해 볼수 있습니다.

파티션을 추가해서 사용할 경우 검색 속도가 비약적으로 빨라진 걸 느끼실 수 있습니다.
뿐만 아니라 아래 링크의 10가지 성능 향상 팁 및 쿼리 최적화를 통해 더욱더 빠른 속도로 원하는 결과를 받아볼 수 있습니다.

Example Queries for ALB Logs

Athena를 사용하여 Load Balancer 액세스 로그 분석

Amazon Athena – 10가지 성능 향상 팁 | Amazon Web Services 한국 블로그

참고

Amazon Athena(이)란 무엇입니까?

Athena를 사용하여 Load Balancer 액세스 로그 분석

Example Queries for ALB Logs

Amazon Athena – 10가지 성능 향상 팁 | Amazon Web Services 한국 블로그

Amazon Athena 요금 – Amazon Web Services(AWS)

Amazon Athena 테이블 파티셔닝

마치며

수동으로 파티션을 관리하기 전에 먼저 S3폴더와 파티션 자동 매치 기능이 있다고 해서 시도했었습니다.
또한 AWS glue라는 서비스를 통해 배치를 등록해 테이블의 파티션을 동적 생성해줄 수도 있습니다. 하지만 제가 glue로 테이블을 만들면 파티션을 제대로 못 불러오더랬죠.
결국 어느 방법도 제대로 되지 않았고 현재는 로그 분석이 필요할 경우 수동으로 파티션을 등록해서 사용하는 중입니다.

파티션 등록 자동화할 수 있는 방법 있으면 댓글 부탁드릴게요!

Athena를 이용한 AWS ELB Access Log 분석 - Part 1

손님1(Kendrick) — Tue, 31 Mar 2020 14:42:37 +0900

현재 상용서버에서 ELB(Elastic Load Banacing) 그중에서도 ALB(Application Load Balancer)를 사용하고 있는 중입니다.

근 1년간 서비스의 글로벌화로 인해 사용자 및 해킹 시도가 점점 많아져 로그 분석할 일이 늘어났습니다.
이전까지는 일반적으로 Nginx Access Log를 사용해서 관련 문제를 해결해 왔지만, 가끔 ELB 로그 확인이 불가피해지고 그때마다 S3에서 다운받아서 그 많은로그 하나하나 분석하는데 시간을 너무 잡아먹어서 결국 Athena를 이용해 보기로 합니다.

Athena란

Amazon Athena은(는) Amazon Simple Storage Service(Amazon S3)에서 표준 SQL을 사용하여 데이터를 쉽게 바로 분석할 수 있는 대화형 쿼리 서비스입니다. AWS Management Console에서 몇 가지 작업을 수행하면 Amazon S3에 저장된 데이터에서 Athena을(를) 가리키고, 표준 SQL을 사용하여 임시 쿼리를 실행하고, 몇 초 안에 결과를 얻을 수 있습니다.

Athena은(는) 서버리스 서비스이므로 설정하거나 관리할 인프라가 없으며, 실행한 쿼리에 대해서만 비용을 지불합니다. Athena에서는 쿼리를 동시에 실행하여 규모를 자동으로—조절합니다.—따라서 많은 데이터 세트와 복잡한 쿼리가 있더라도 결과를 빠르게 도출합니다.

위는 공식 문서에서 발췌한 내용입니다.

쉽게말해 S3에 압축되어 저장된 로그들을 SQL 쿼리로 분석 가능하다는 겁니다.
그리고 물론 ALB 뿐만 아니라 여러 가지 AWS 서비스들도 지원합니다.

AWS Docs

이 글을 작성하면서 알았지만 ELB로그 뿐만 아니라 여러가지 서비스를 지원하고 있습니다.
CloudTrail도 실제로 히스토리를 살펴보면 생각보다 쓰기가 까다로운데 이를 이용하면 쉽게 추적할 수 있겠네요.

사용하기 전 알아두기

서버리스

서버를 따로 관리할 필요가 없습니다.
우리는 그저 스키마와 S3에 로그가 저장된 경로를 제공하고 쿼리를 시작하면 됩니다.
ETL(Extraction, Transformation, Loading)의 번거로움을 Athena 내부에서 해결해 줍니다.
쉽게 말해 우리가 따로 서버를 설정해 줄 필요도 없고, Athena가 S3에서 데이터를 추출하고 변환하고 metastore에 로드해 줍니다.

빠른 속도

병렬방식으로 쿼리를 자동실행하기 때문에 빠른 결과 전달을 제공합니다.
물론 쿼리나 최적화가 되어있지 않거나 데이터가 너무 많으면 오래 걸리긴 하지만 그걸 감안해도 빠릅니다.

표준 SQL 실행

표준 SQL을 지원하기 때문에 러닝 커브가 획기적으로 줄어듭니다.
Amazon Athena는 ANSI SQL을 지원하는 Presto를 사용하며, CSV, JSON, ORC, Avro, Parquet 등 다양한 표준 데이터 형식과 호환됩니다. 이 서비스는 빠른 속도의 임시 쿼리에 적합하지만 대용량 조인, 창 함수, 어레이 등 복잡한 분석을 처리하는 데도 손색이 없습니다. 또한 가용성이 뛰어나기 때문에 여러 설비에서, 혹은 단일 설비의 여러 디바이스에서 컴퓨팅 리소스를 사용해 쿼리를 실행하기도 합니다. Amazon Athena는 Amazon S3를 기본 데이터 스토어로 사용하여 데이터 가용성과 내구성이 매우 우수합니다.

요금정책

Amazon Athena 요금 – Amazon Web Services(AWS)

가격이 비쌀 거라는 예상은 적중했습니다.
1년 치 access log가 40G라고 했을 때 한 번에 $0.2 정도 소모됩니다.
사실 뭐 200~300원 남짓이긴 하지만 누가 쿼링을 한 번만 하겠습니까?

돈이 많은 회사야 상관없겠지만 문제가 하나 더 있습니다.
쿼리 조건에 따라 다르겠지만 쿼리 최적화를 제대로 하지 않을 경우 모든 데이터를 검색하는 시간이 몇 분을 넘어갑니다.

그래서 위와 같은 문제를 해결하기 위해 데이터 파티셔닝을 지원합니다.
이는 이후 Part 2에서 다뤄보도록 하죠.

마치며

파트 1에서는 Athena의 특징과 가격 정책 등을 알아보았습니다.
파트 2에서는 간단한 예제를 통해서 데이터베이스를 세팅해 봅시다.

웹 서비스 Maintenance Mode (점검 모드) 지원기

손님1(Kendrick) — Tue, 4 Feb 2020 00:14:10 +0900

웹 서비스 Maintenance Mode (점검 모드) 지원기

온라인 서비스계의 유명한 4대 명검으로 유명한 점검 모드에 대해서 이야기하려 합니다.

점검 모드 지원 결정

운 좋게도 회사에서 운영하는 서비스가 2년 넘게 다운될 일이 없었습니다.
Agile모델이 잘 실행되었기 때문일까요? 매주 릴리즈 함에도 불구하고 근 몇 년간 99.99%의 가용성을 유지하고 있었습니다.

하지만 올해 초 AWS MySQL을 AWS Aurora로 Migration 하기로 합니다.

문제는 우리 회사의 서비스가 사용자에 의해서 수정이 자주 일어나는 온라인 에디터라는 것!
이러한 서비스 특성상, 실시간으로 DB에 데이터를 업데이트하는 일이 잦게 발생하고, 이를 방지하고자 readonly 페이지를 제공할까? 등등 고민을 하게 됩니다.

결국 추후에 발생할 수 있는 여러 사이드 이펙트 등을 고려하여 2시간가량 점검 페이지를 제공하기로 결정했습니다!

이 Post는 Maintenance Mode를 적용하기 위해서 고민하고 우려했던 부분들을 정리해서 올려보려고 합니다.

SEO를 헤치지 마오

점검 모드로 인해서 지금까지 쌓여있는 SEO에 문제가 생기면 안 된다고 마케팅팀에서 신신당부를 합니다. 만약 박살 나면 너도 같이 박살 날줄 알아라는 느낌적인 느낌.

저 또한 그 문제를 처음부터 고려하고 있었기에 조사를 해봤습니다.

이문제는 매우 간단하게 해결할 수 있었습니다.

점검 모드 제공 시, 503 HTTP 상태 코드를 사용하면 검색엔진이 임시 상태임을 파악하고 SEO에 죽창을 꽂지 않습니다.

503 Service Unavailable - The server is currently unavailable (this could be due to overload or maintenance). Search engines will know that this is a temporary state. This status code should be used when taking down a site for maintenance.

Retry-After 헤더 추가하기

503 (Service Unavailable) 응답이 전송된 경우, 서비스가 얼마나 오랫동안 이용 불가능한지 예측되는 시간을 가르킵니다.
301 (Moved Permanently)와 같은, 리다이렉트 응답이 전송된 경우, 리다이렉트 요청을 하기 이전에 사용자 에이전트가 대기해주길 원하는 최소한의 시간을 가르킵니다.

조사한 바에 의하면 모던 브라우저의 경우, 알아서 위 상황을 제어하긴 하지만 만약을 위하여 Retry-After 헤더를 추가해주기로 합니다. 이 또한 Nginx에서 추가할 수 있습니다.

Nginx를 수정하여 점검 페이지로 Redirect 하기

주의할 점은 파악이 끝났습니다. 점검 모드 제공을 위해 Nginx 설정을 만져봅시다.

# Nginx config file
location / {

    # 서비스의 root경로입니다. 
    # nginx로 서비스 중이라면 이미 존재할 테니 따로 수정해 줄 필요는 없습니다.
    root /usr/localhost/src/webservice

    ...

    # maintenance.html 파일이 존재하는지 확인합니다.
    # 만약 파일이 존재할 경우 503 code를 반환합니다.
    if (-f $document_root/maintenance.html) {
        return 503;
    }

    ...

    # 현재 상태가 503 경우 Retry-After header와 함께 maintenance.html 파일을 전달해줍니다.
    error_page 503 /maintenance.html;
    location /maintenance.html {
        add_header Retry-After 3600 always;
    }
}

위와 같이 변경 후 테스트 해 줍시다

# 변경한 nginx 테스트
nginx -t

# Nginx 서비스 리스타트
sudo service nginx restart

이후 점검 모드가 필요할 경우, 서비스 root 폴더에 maintenance.html 파일을 추가해주면 점검페이지로 진입하게 됩니다.

점검 모드가 끝나면 maintenance.html 파일명을 변경하거나 제거해줍니다.

참고 문서

How To Handle Downtime During Site Maintenance - Moz
HTTP 503: Handling site maintenance correctly for SEO • Yoast
Be careful to use correct HTTP status codes for maintenance pages - makandra dev
Retry-After - HTTP | MDN

마치며

2시간의 점검 시간을 예측했지만 DB migration이 생각보다 빠르게 끝나서 1시간 남짓으로 마무리할 수 있었습니다.
점검 모드는 약 한 시간이었지만 유저풀이 한국에서 경험했던 서비스들보다 훨씬 많기 때문에 매우 살 떨리는 경험이었습니다.

점검 모드 관련해서 조사하고 적용한 게 아까울지언정 다시 사용하는 일이 없기를 바랍니다.

2019년 회고

손님1(Kendrick) — Tue, 28 Jan 2020 00:03:45 +0900

2019년 회고

벌써 2019년이 지나갔습니다.

매년 회고를 같은 말로 시작하게 됩니다. 시간은 빠르게 지나가고, 안 올 것 같은 30대가 된 지 벌써 2년이나 지났다는 점이 늘 새롭네요.

다른 분들의 블로그에 비하면 수더분하지만 매일 500명의 유저가 늘 들어와 주고 있습니다. 정말 감사하게 생각하고 있습니다.
그리고 걸어둔 애드센스가 드디어 2년 만에 100불이 된 것도 신기합니다. (한 달에 커피 한잔!)

올해는 회고 쓰는 유행이 지났는지 많이 보이지는 않지만, 개인적인 리마인드를 위해 올해도 회고를 남겨 봅니다.

2019년 로드맵 리뷰

작년 2018 회고에서 언급한 2019 로드맵 얼마나 성공했을까요?

완료 및 진행 중

이사
결혼
개인적으로 진행하는 서비스 진행 (진행 중)

실패

~~IELTS 시험~~

~~영주권 취득~~

~~IT 블로그 포스트 100개~~

~~개인 사이드 프로젝트 매달 1개~~

~~3대 운동 300 하기~~

이것 말고 책 쓰기나 유튜브 하기도 있었지만, 아무튼 대실패네요. 그나마 결혼이라는 아주 큰 이벤트를 잘 마무리해서 너무 다행입니다.

로드맵에 없었지만 성공한 것들도 있습니다. 작년 말 Senior Software Engineer로의 진급이 있겠네요!

Free Infographic Maker - Venngage

Join over 1 million people creating their own professional graphics with our easy to use infographic maker. Sign up for free and choose from 1000+ infographic templates.

venngage.com

2020년 로드맵

영주권 따기

이제 진짜로 올해는 꼭 따야 하는 영주권!!
LMIA 기간이 올해 10월까지 이기 때문에 영어점수를 빠르게 확보해서 Express Entry를 올려야 합니다.
IELTS 점수가 아직도 저를 가로막고 있네요.
작년 1월에 첫 아이엘츠 시험 이후 1년간 조금밖에 발전하지 않았다는 사실에 한숨이...
영어점수 확보하기가 우선 당장 이뤄야 할 올해 상반기 목표입니다.

매주 IT 블로그 쓰기.

작년에는 블로그 글쓰기에 소홀했습니다.
지난 한 해 아무것도 안 한 건 아니고 그래도 아이디어나 쓰고 싶었던 것들을 Notion에 정리해 놓은 게 있습니다.
이를 바탕으로 매주 하나씩은 올릴 예정입니다.
이번 주는 이 2019 회고록이구요.

개인 프로젝트 진행

구상해 놓은 아이디어가 있는데 올해 만들어 보는 게 목표입니다.
올해 상반기 내로 MVP가 나오길 목표로 해봅니다.

꾸준히 여행 블로그 작성

워킹홀리데이 떠난 개발자의 해외 생존기 Archives

재작년처럼 미친듯한 분량은 아니지만 매달 꾸준히 올리고 있는 컨텐츠입니다.
페북, 인스타 같은 소셜 네트워크를 안 하는 저이기에 잘살고 있는지 궁금해하는 친인척들 보라고 만든 거였으나 이제는 하나의 취미가 되어버렸네요.
성의는 없어질지언정 꾸준히는 올리고는 있습니다. ㅋㅋㅋㅋ
사진을 요즘 잘 안 찍어 버릇하다 보니 내용도 부실해졌습니다만 앞으로는 와이프와 놀러 다닐 곳들도 추가될 테니 내용이 좀 알차질 것 같습니다.

신년운세

대놓고 나태하지 말라니 뭔가 불타오르게 하는 신년운세입니다.

2020년 역시 매우 좋은 기운이 느껴집니다.

마무리

어느새 2020년도가 왔습니다.
다들 올해도 이루시려는 목표 원만히 달성하시길!

[개발문화탐구] 데브옵스 (DevOps) - 애자일(Agile)

손님1(Kendrick) — Mon, 11 Feb 2019 07:32:43 +0900

개발문화탐구: 데브옵스 (DevOps) - 애자일(Agile)

어질? 애자일? 이노옴!

도적 키우는데 어질(agility) 만땅 찍나요?

아... 아뇨 여기서 알아볼 애자일(Agile)은 민첩하다는 뜻은 맞는데... 게임 얘기는 아니고요.

Agile이라 불리는 소프트웨어 개발 방법론에 대해서 살짝 맛을 보려고 합니다.

개발 방법론이라 하면 뭐 많이들 얘기하는 Lean startup, Scrum, Squad 등등 종류도 많고 이게 사실 무슨 소린지 잘 모르겠단 말이죠?

이게 무엇이며, 왜 DevOps 이야기에 애자일 관련 이야기 빠지지 않고 나오는지 관련해서 알아보도록 합시다.

소프트웨어 개발 방법론이란?

소프트웨어 개발을 함에 있어 절차, 툴, 기법 등을 제시해 주는 지식입니다.
실제 회사에서 제품을 만들 때, 예전부터 사용된 하나의 정형화된 작업 방식이라고 보시면 될 것 같습니다.

Waterfall

형이 여기서 왜 나와?

Agile을 설명하기 전, Agile의 개념을 보다 쉽게 이해하기 위해 Waterfall(폭포수 모델) 먼저 짧게 설명하고 지나가겠습니다!

이해를 돕기위해 폭포수 모델을 적용해 게임 개발 하는 상황을 예로 들어봅시다!

우리는 이제 게임 프로젝트를 시작하기로 합니다.
이름은 뭐... 대충 신들을 잡는 좀비가 주인공인 모바일 대작 게임 라스트 오브 워 M을 만들도록 합시다.

두 유 가이즈 낫 해브 어 폰?

그럼 이제부터 우리는 기획부터 시작해서 게임의 개발 QA 그리고 오픈까지 모든 걸 계획하고 준비하게 됩니다.

시작 전, 게임 컨셉과 기획, 요구사항에 맞게 문서화가 될 것이고, 그런 일련의 프로젝트 진행 과정들을 정리하면 아래와 같은 흐름으로 작업이 진행될 겁니다.

위 그림과 같이 프로젝트 진행이 위에서 아래로 내려오는 폭포수의 모습과 같아 Waterfall이라고 합니다.
그런데 제가 템플릿을 잘못 선택 해서 뒷산 계곡 같아 보이긴 합니다. ㅈㅅ;;ㅎㅎ..ㅋㅋ!

문제는 Waterfall에서의 단계들은 병행되거나 반대로 진행되지 않습니다.
그 말인즉 만약 테스트 중에 요구사항이 변경됐다면? 요구사항 분석부터 설계, 구현, 테스트까지 다시 전부 진행되어야 합니다.

머라구요? 사장님이 그 부분을 약간 바꾸라고 하셨다구여? 엄마 나 오늘 늦게 집에 들어가...

Agile

그렇다면 Agile이란 무엇일까요?

우선 Agile이란 '날렵한', '민첩한'이란 형용사입니다.

Agile이 빠르다고는 하는데, 뒤에서 채찍 들고 빨리해! 하면서 노예처럼 부린다는 의미는 아니구요...

이 경우 Waterfall처럼 큰 계획을 만들지 않습니다.
주어진 요구사항을 스프린트에 맞춰 작은 단위로 유연하게 개발하는 방식입니다.

위의 과정을 하나의 스프린트라고 하며, 서비스의 종류에 따라서 다르겠지만 그 주기가 빠르면 빠를수록 좋습니다.
왜냐하면 고객의 피드백을 빠르게 대응할 수 있기 때문입니다.

1. 고객의 피드백 or 서비스 요구사항 발생
2. Scrum이나 다른 개발 방법론 등을 통해 스프린트 목표 설정 (Scrum 포스트에서 다룰 예정)
3. 다음 릴리즈까지 스프린트 진행
4. 배포. (다시 1로)

Waterfall과의 차이가 느껴지시나요?

요리로 치면 Waterfall은 시작 전 미리 계량된 재료와 레시피로 요리를 완성시키는 것이기 때문에 레시피와 계량 등의 시간을 많이 소비하는 반면, Agile의 경우 정확한 레시피는 없지만, 중간중간 맛을 보면서 피드백을 통해 음식의 간을 맞출 수 있습니다.

물론 따지고보면 요리는 제품과 전혀 다르지만! 제가 말하려는데 무엇인지 전해졌기를 바랍니다! :)

여담이지만 우리 회사는 현재 1주 간격으로 서비스 배포를 진행 하고 있습니다! (이후 포스트에서 자세히 다룰 예정)

사용자의 피드백 빠르게 반영하자

애자일 소프트웨어 개발선언을 보시면 핵심 가치를 쉽게 이해하실 수 있습니다.

개인과의 상호작용
문서보다 작동하는 소프트웨어
고객과의 협력
변화에 대응하기

폭포수 모델에서는 요구사항 수렴단계에서 배포 이후의 상황을 예측하고 문서화를 해야 하는 반면, 애자일은 실제로 고객의 피드백을 빠르게 확인할 수 있고 좀 더 현실적이고 효율적인 서비스의 진화를 체감할 수 있습니다.

와우! 오늘 당장 Agile을 도입해볼까?

준비되지 않은 애자일 모델의 도입은 마치, 갑자기 운동하겠다고 헬스장 간 다음 자세도 잘 모르는 상태에서 스미스 머신이랑 각종 머신 깔짝대고 런닝머신타고 집으로 오는 것과 같습니다. 결국 헬스장 몇주 다니다가 안 가는...

심지어 재수 없으면 부상까지 입을 수 있습니다.

새해 운동하듯이 충동적으로 시작하면 안되고, 많은 준비가 필요합니다.

DevOps와 Agile

DevOps는 Agile과 연장선에 있습니다.

Agile의 목표가 Lean Manufacturing에 기반하여 빠른 소비자 피드백을 가질 수 있게 해준다면, DevOps는 분리되어있던 개발자와 운영자의 역할을 합쳐버리니 더욱 민첩한 개발 및 배포 사이클을 가질 수 있습니다.

고전적인 방법으로, 배포 시 운영팀에 연락해서 서버 올려주세요~ 하고 한참 기다린 후 수많은 절차를 걸쳐 준비됐다는 답변받은 후, 서비스 설치하고... 운영팀에 다시 연락하고... 이걸 2주마다 하려면...

감당하실 수 있겠습니까?

물론 감당할 수 있게 이를 도와주는 많은 도구나 서비스들이 존재합니다만, 그것들은 나중에 다뤄보도록 하겠습니다!

마치며

글을 몇 번을 다시 쓴 지 모르겠네요.

장단점 테이블로 써놓고 보니 뭔가 지루해도 지우고... 실제 경험을 써보니 뭔가 디스하는거 같고...
결국 "최대한 가볍고 읽기 쉽게 쓰자" 해서 다시 작성했습니다.

앞으로의 개발문화탐구 시리즈도 최대한 가볍고 이해하기 쉬운 정보전달을 목적으로 작성할 예정입니다.

잘못된 부분이나 이상한 부분이 있으면 댓글 부탁드리겠습니다.

긴 글 읽어주셔서 감사합니다!

나의 부족했던 2018년을 반성하며

손님1(Kendrick) — Wed, 2 Jan 2019 04:56:28 +0900

나의 부족했던 2018년을 반성하며

벌써 2018년이 지나갔습니다.
체감으로는 3개월 같은데 말 그대로 벌써 1년이네요.
많은 IT 블로거분들의 회고를 일일이 다 챙겨보고 많은 자극을 받았습니다.
다른분들의 회고에 써있는 성취들을 보다보니 나는 왜이렇게 이룬게 없는가!! 스스로 반성해야 될 듯 하여, 회고 겸 반성문?을 써봅니다

2016년 회고 - 2017년을 맞이하며
2017년 회고 - Merry Christmas!

2018년의 성과

이룬 것

LMIA 과정을 통해 취업비자를 무사히 취득할 수 있었습니다.
운 좋게도 DevOps 관련 업무를 맡아서 많은 걸 해볼 수 있었습니다.
Production 수준의 AWS 환경에 대해서 많이 배울 수 있었습니다.
전까지는 크게 관심 없었던 개발 프로세스(Agile, Scrum, Squad 등)에 대해 공부하며 이해와 시야가 많이 넓어졌습니다.
영어는 제가 느끼기에는 그대로인 것 같아서 동료한테 물어보니 처음보다 훨씬 좋아졌다고! 처음에는 진짜 처참했으니 뭐 ㅋㅋ.. 근데 영어가 따로 공부 안 하면 늘지도 않아서 꾸준히 정진.
잠시 한국에 방문해서 상견례도 잘 마쳤습니다.

잃은 것

시간을 효율적으로 사용하지 못한 것 같습니다.
2018년의 개발자로서 달성할 수 있는 만족도 최대치가 100이라면 저는 한 30 정도 달성한 듯합니다.
0개의 사이드 프로젝트. 작년에 뭘 했냐고 하면 딱히 보여줄 것이 없는...
뭐 조금 핑계를 대보자면, 연초에는 회사에 적응하느라 남는 시간에 나태해 졌던 거 같고..

컨디션 조절 실패도 한몫했습니다.
여름에 에어컨 없이 지내다 보니 최악일 때는 1주일간 매일 2시간 잤습니다.
그러다 보니 컨디션 난조에 빠지고, 매일 아침 화나있고... 끔찍.
여름내내 최악의 컨디션으로 인해 거의 한 분기 동안 멘붕 상태였던 것 같네요.
토론토 집값 넘나 비싸지만, 내년 여름 오기 전에 반드시 이사 갈 겁니다.

다시 생각해도 그 무더위에 에어컨 없이 살다니.. 안죽고 살아있는게 용함!

2018년의 블로그 활동

IT 블로그 < 여행 블로그

작년 총 17개의 글을 작성했습니다.
생각보다 터무니없이 적어서 당황스럽네요.

17개 이상은 썼다고 생각했는데, 아마 여행 블로그에도 글을 작성하다 보니 착각을 했나 봅니다.

여행 블로그에는 무려 36개의 포스트를 작성했네요.

처음에 여기 왔을 때는 신기한 게 참 많았는데요, 이제는 적응이 됐다고 해야 하나?
그런 이유로 여행 블로그에 처음에는 사사로운 것까지 다 기록을 했었습니다만, 이제 좀 큼직큼직한 이벤트를 작성하려고 합니다.

이게 별 내용 없는 주제에 의외로 들어가는 시간이 많은 데다가, 한 번에 몰아서 작성하다 보면 내용도 자꾸 중복되고 이래서 매우 고통입니다

워킹홀리데이를 마치며에서 멈춰있다. 1년간 꾸준히 쓴다는게 생각보다 쉽지 않더라.

앞으로의 블로그 활동

어느새 한 달에 10000명이 오는 블로그가 되었습니다. 눈물이 왈칵!
위와같은 이유로 IT 블로그에 업로드도 잘 안 했는데도 말이죠.
개발자스럽다님께서 제 포스트를 링크해주셔서 중간에 유입이 화끈하게 오른적도 있고 재밌는 경험이었습니다.

아무쪼록 내년에는 IT 블로그에 글 쓰는 것에 좀 더 집중하려고 합니다. 100개 포스트를 목표로!
타국에 와서 새로운 환경에서 일하다 보니 블로그용 소재가 많이 눈에 띄어 Backlog에 잔뜩 담아 놨습니다.
소재 걱정은 없으니 이제 꾸준히 작성해야겠습니다. 내년에는 100개를 목표로!

메일 혹은 댓글 환영!

이따금 관련 전공 졸업자분들 혹은 CTO분들이 메일을 보내주시곤 합니다.
용기 주셔서 혹은 호기심으로 보내주시는 메일이 블로그 운영하는데 큰 힘이 되었고, 서로 좋은 대화를 할 좋은 기회가 였습니다.

이런 관심과 댓글 정말 너무너무 환영합니다!

그래도 요즘 저는 흥미로운 혹은 재밌는 포스트를 볼 때마다 댓글을 달고 있습니다.
여러분도 다른 블로그에서 좋은 글 보시면 바로 페이지 넘기지 말고 댓글 다세욧!

2019년 로드맵

작년 한해를 지금 와서 돌아보면 매우 불만족스럽습니다.
더 잘할 수 있었으나, 개인의 나태함으로 못했다는 걸 제가 잘 아니까요.

리마인드 하는 마음으로 내년 로드맵을 순서대로 정리해 봤습니다.

IELTS 시험
영주권 취득
이사
결혼
IT 블로그 포스트 100개
회사 형님과 진행하는 서비스 진행
개인 사이드 프로젝트 매달 1개
3대 운동 300 하기

위에 있는 것들은 내년에 무조건 이뤄야 하구요.

그 외에도 유튜브를 해볼까 하는 생각도 하고 있습니다.
유튜브 스타가 되고 싶다! 이런 게 아니고 동영상을 녹화 중이면 딴짓을 좀 덜 하지 않을까 싶어서요. 비효율적이려나?
그리고 책을 내고 싶다는 생각도 항상 가지고 있습니다. 교수님들이 대충 찍어서 내는 듯한 그런 커리어에 +1 하려는 목적으로 내는 의미 없는 책 말고 임백준 님이나 김종민 님같이 그 사람밖에 낼 수 없는 그런 경험이 담긴 흥미로운 책 말이죠. 물론 당장은 부족하니 커리어를 좀 더 쌓은 후에 해야겠지요...

회사관련된 업무들이나 Personal Development는 당연히 해야 되는 것이고...

뭐 무엇하나 쉬운 게 없지만, 저는 제가 부지런한 사람이 아니라는걸 알기 때문에 이렇게라도 스트레스를 팍팍!

신년운세

올해도 네이버 신년운세를 봤습니다.
(네이버에서 신년운세 검색하면 무료로 해볼 수 있습니다)

제 내년 목표와 연관된 내용이 많아서 너무 신기하네요.

저는 운세를 독실하게 믿지는 않지만, 신기하게도 점집을 가던 타로를 하던 항상 좋게 나와서 덕담 듣듯이 즐겨 듣곤 합니다.

가볍게 흥미로 보시면 좋을 거 같아요 :)

매우 좋은 기운이 드는 한 해 입니다.

한 해를 마무리하는 9가지 질문들

9 Essential Questions Everyone Should Ask Themselves At The End of The Year

CEO 형님이 작년에도 보내주신 거 같은데 올해도 보내주셨네요.
연말에 모두가 스스로에게 해야 할 9가지 필수적인 질문들인데 여러분도 한번 보시면 좋을 것 같습니다 :)
사실 작년에도 봤을 때는 갓 취업했을 때라 정신이 없어서 쓱 훑어보고 말았는데, 올해 다시 보니 느끼는 게 많습니다.

요약

모두 2018년 고생 많으셨고, 시작된 2019년 목표 모두 이루시기를 바랍니다.

[개발문화탐구] 데브옵스 (DevOps) - Strangler Pattern: Migrate to Microservices

손님1(Kendrick) — Sun, 18 Nov 2018 14:30:07 +0900

개발문화탐구: 데브옵스 (DevOps) - Strangler Pattern: Migrate to Microservices

들어가기 전

이 포스트는 이전 포스트 마이크로 서비스 vs 모놀리식 서비스와 이어집니다.
매우 쉬운 내용이니 간단하게 훑고 오셔도 좋을 듯.

[개발문화탐구] 데브옵스 (DevOps) - 마이크로서비스 vs 모놀리식서비스

서비스 아키텍처의 진화

위 트렌드 그래프를 보면 아시겠지만, 마이크로 서비스에 관한 관심이 점차 많아지고 있습니다.

이전 포스트에서는 모놀리식 서비스도 경우에 따라서 더 좋을 수도 있다곤 했지만, 대부분에 서비스는 마이크로 서비스가 더 적합하다고 생각됩니다.

그럼 모놀리식 서비스는 어떻게 마이크로 서비스로 이전할 수 있을까요?
기존 서비스의 기능을 새로운 아키텍처로 처음부터 다시 짜야 할까요?

교살자 애플리케이션 패턴(Strangler Application Pattern)

유래

2004년 마틴 파울러옹이 호주 여행 중 본 덩굴을 보고 만든 용어입니다.
괴상한 넝쿨이 숙주 나무 위쪽 가지에 씨를 뿌리고, 나무를 타고 내려가며 성장.
결국, 숙주 나무를 죽이고 덩굴은 되려 환상적이고 아름다운 모양으로 자라는 걸 보고 말이죠.

점진적인 마이그레이션

위에서 말한 괴상한 넝쿨처럼, 기존 모놀리식 서비스의 기능별로 반복적으로 분리합니다.
이렇게 하면 새로운 아키텍처로 모든 기존 기능을 한 번에 다시 만들 필요가 없으며, 점진적으로 마이그레이션을 진행해 나갈 수 있습니다.

점진적인 마이그레이션을 통해 위험을 최소화하며, 유저는 이런 변화를 인식하지 못하고 동일한 서비스를 사용하게 됩니다.

여기서 중요한 점은 기존의 레거시 코드를 계속 유지해야 한다는 것입니다.
필요에 따라(오류 or 특정 상황) 이전 시스템을 호출할 수도 있어야 하기 때문에 마이그레이션을 하는 중에는 레거시 코드에 새로운 코드를 추가하지 않고, 새로운 코드를 새로운 서비스로 만들어야 합니다.

대상

헤아릴 수 없을 정도로 수많은 기업이 서비스 구조 개선 혹은 리팩토링을 위해 사용해온 패턴입니다.
교살자 패턴으로 이동된 최초의 서비스 사례는 무려 20년 전 IBM AS/400 중급 서버용 주문 관리시스템입니다.
시스코에서도 자사의 ERP 시스템을 클라우드로 옮길 때 교살자 패턴을 사용했습니다.
말이 필요 없을 정도로 많은 서비스가 리팩토링을 위해 이미 사용하던 패턴이지만 Strangler Application Pattern 용어는 자체는 마이크로 서비스를 위해서 정의된 듯 합니다.

보통 많은 서비스들이 이 패턴 이름은 몰랐어도 어느정도 이런 식으로 마이그레이션을 해왔을 것이라 생각합니다.
용어만 조금 낯설지 개념은 많은 분이 이미 알고 있으실 듯!

참고

StranglerApplication - martinfowler.com
Strangler Pattern: How to Keep Sane With Legacy Monolith Applications | OverOps Blog
스트랭글러 패턴 | Microsoft Docs
Refactoring a Monolith into Microservices - NGINX

마치며

교살자라는 용어를 사용해서 뭔가 좀 살벌하네요.. ㅋㅋ

[개발문화탐구] 데브옵스 (DevOps) - 마이크로서비스 vs 모놀리식서비스

손님1(Kendrick) — Sun, 18 Nov 2018 14:05:16 +0900

개발문화탐구: 데브옵스 (DevOps) - 마이크로서비스 vs 모놀리식서비스

들어가기 전

몇 년 전부터 마이크로 서비스에 대한 이야기를 흔히 접할 수 있었습니다.
마 그거? 서비스 다 따로 분리하는 거 아니야? 정도로 간단하게 알고 있습니다.

사실 그게 맞긴 하지만, 마이크로 서비스가 무엇인지 혹은 왜 사용하는지에 대해서 어느 정도 깊이있게 알지 못하면 이후 소개할 개념들이 매끄럽게 이해가 안 되는 부분이 발생할 수 있겠다는 염려가 들었습니다.

그런 이유로 한번 짚고 넘어가 봅시다!

그 전에 제목에도 언급된 모놀리식 서비스가 무엇인지 알아보도록 합시다.

모놀리식 서비스 (Monolithic)

귀에 딱지가 생길 정도로 많이 보이던 용어인 마이크로 서비스에 비해 모놀리식 서비스는 뭔가 생소합니다.

모놀리식 서비스 혹은 모놀리스 구조라고 합니다. (Monolithic)

이는 모든 비즈니스 로직이 한 애플리케이션 안에 포함되어 있는 구조를 말합니다.

이해를 돕기위해 간단한 위의 이미지를 봐봅시다!
위 이미지는 택시 앱의 비즈니스 로직입니다.
Billing, Notification, Payments, Management 기능들이 모두 들어가 있습니다!
모든 기능들이 한 애플리케이션에서 동작하는 구조이며 이를 모놀리식 서비스라고 합니다.

이해가 잘 안가신다구요? 하울의 움직이는 성을 떠올려보세요!

딱봐도 복잡해 보인다...

이로인해 얻을 수 있는 장단점을 한번 훑고 가 봅시다.

장점

처음에 구조 설계 및 개발이 간단하다. (통채로 각 기능들을 일체화된 구조에서 만들기 때문에)
내부 프로세스 간 지연시간이 짧음
배포 시, 한번 배포하면 끝

단점

낮은 모듈성
낮은 확장성
긴 빌드 시간

새로운 기능을 개발 시, 프로토타입을 만들기 좋습니다.
웹서비스를 예로 든다면, 배포가 한 번에 똵-! 끝! 대신 빌드 시간이 길겠지만 어쨋든 배포에 신경쓸 부분이 훨씬 줄어듭니다

개발과 배포가 단순하다니, 아아 매우 달콤하군요.

하지만 치명적인 문제가 있습니다!
모놀리식 서비스를 팀 단위로 개발한다면 아래와 같은 문제를 일으킵니다.

애플리케이션이 클수록 코드를 이해하기 어렵다. (그로 인한 숨 막히는 압박감은 덤)
IDE가 과부하로 인한 생산성 감소.
모듈화가 힘들다.
코드 단 한 줄을 변경에도 전체 애플리케이션 빌드가 필요, 지속적인 배포는 사요나라.
새로운 기술의 사용이 어려워짐.

그럼 이런 문제들을 어떻게 해결할 수 있을까요?

마이크로 서비스 (Micro)

일체형 서비스 구조로 인해 시스템 엔트로피가 자꾸만 늘어만 갔습니다.

결국 많은 서비스들이 이런 문제를 해결하기 위해 더 적합한 아키텍처를 찾아서 진화했습니다.

그것이 바로 이 마이크로 서비스!

마이크로 서비스로 인해서 얻을 수 있는 장단점은 아래와 같습니다.

장점

개발자 생산성 향상
각 단위가 간단하니 개발자들이 방대한 코드를 보고 개복치가 되는 경우 방지
테스트 용이성 증가
빠르고 지속적인 배포 가능
안전성 증가
책임이 명확하게 분리됨

단점

소스 저장소 및 서버 분리
각 마이크로 서비스 간 네트워크 문제 발생 가능
각 서비스에 대한 모니터링 필요

물론 단점이 없는 건 아니지만, 팀 단위 개발의 문제점이 많이 개선되었습니다.

Payments가 업데이트 된다면 그 부분만 checkout해서 변경 & 빌드하면 될 것이고, 각 기능이 완벽히 분리되어 있다보니 코드의 복잡도가 훨씬 줄어듭니다.
새로온 개발자에게 작업을 인계할 때도 부담이 훨씬 줄어들게 됩니다.

모놀리식은 구식이다?

결과적으로 지금까지는 마이크로 서비스에 대한 장점을 어필하고 있었습니다.
왜냐하면 오늘날에 많이 쓰이는 서비스 중심의 아키텍쳐이기 때문이죠.

와 그럼 마이크로서비스 개꿀이네 완전? 이라는 생각이 들었다면 이 포스트위 목적이 절반은 성공했다는 생각이 드네요!
하지만 이게 마냥 꿀이 흐르는 강은 아닙니다. Netflix의 마이크로서비스 아치텍쳐를 보면 입이 떡벌이지게 됩니다.

아.... 분명 뭐 하나만 고치라했는데 뭐였더라..

실제로 세그먼트라는 회사에서는 마이크로 서비스에서 모놀로틱 구조로 다시 돌아왔습니다.

Goodbye Microservices: From 100s of problem children to 1 superstar · Segment Blog
[번역] 잘가요 마이크로서비스: 100개의 문제점 투성이를 1개의 슈퍼스타로

결론은 서비스의 특성을 잘 이해하고 구조를 선택하자 입니다.
아 뭐지 이 고구마 먹은 느낌은...

하나의 정답 없이 서비스와 개발 문화에 따라 천차만별 변화하는 게 데브옵스의 묘미일까 싶기도 하구요!

참고

넷플릭스 마이크로 서비스 가이드 - 혼돈의 제왕
Introduction to Microservices | NGINX

마치며

그러면 모놀리식 서비스는 어떻게 마이크로 서비스로 만들 수 있을까요?
처음부터 새로 분리된 코드를 짜야 할까요?

이런 궁금증을 해소하기 위해 다음에는 교살자 애플리케이션 패턴에 관하여 이야기해 보겠습니다.

[ETC] Artillery - 서버 부하 테스트

손님1(Kendrick) — Wed, 14 Nov 2018 11:01:15 +0900

[ETC] Artillery - 서버 부하 테스트

유용한 Service, Tool, Library를 소개해 드립니다.

Artillery

Artillery는 자바스크립트로 된 모던 부하 테스팅 툴킷입니다.

처음부터 Artillery를 사용한 건아니고...

제가 만든 서비스에 대한 부하 테스트가 필요해서 뭐가 좋을까 찾아보다가 먼저 Vegita라는 툴을 발견합니다.

GitHub - tsenart/vegeta: HTTP load testing tool and library. It's over 9000!

이름이 베지터? 하고 들어가 봤더니 진짜 그 드래곤볼 베지터! 와 너무 맘에 든다 이거 쓰면 인싸되는 각? 하고 시도해보려는 찰나..!

간단한 테스트는 지원하는 Command로 할 수 있었지만 약간 플로우를 따라 부하 테스트해 보려 하니 기본적인 GoLang에 대한 지식이 필요했습니다.

그래도 이름이 맘에 들기도 하고 어렵지 않을 거 같아 그냥 쓰려고 했는데, Artillery를 발견하게 됩니다.

사용법

NPM을 이용해 Artillery를 설치해주신 후

# Global 설치가 싫으시면 npx를 이용하셔도 좋습니다.
npm install -g artillery

아래와 같이 부하 테스트해 줍니다.

# 10명의 유저가 각각 20번의 요청을 해당 도메인으로 합니다.
artillery quick --count 10 -n 20 https://artillery.io/

Test Script 작성

좀 더 자세한 디테일을 위해서 Test Script를 짤 수 있습니다.

테스트 결과에 대해 리포트도 해줍니다.

Test Script는 JSON과 YAML 형식 둘 다 지원합니다.

테스트 시나리오 작성
시나리오에 따른 테스트가 가능하므로 좀 더 디테일한 부하 테스트가 가능합니다.
ex) (동시에) 10000명의 SignUp API 요청 -> SignIn API 요청 -> User Data 반환
테스트 데이터 입력
예를 들어 특정 숫자를 받아서 저장하는 API 부하 테스트 한다고 하면, 랜덤한 값 입력도 가능합니다.
CSV 파일을 이용해서 특정 입력 데이터를 구체화할 수도 있습니다.

Test Report

테스트 Report를 원할 시 아래와 같은 옵션을 추가해줍시다

artillery run -o testResultFileName.json testTemplate.json

그럼 테스트 결과 파일이 생성됩니다. 하지만 아직 보기가 편하지 않습니다.

# html 파일로 변환
artillery report testResultFileName.json

위 명령어를 사용하시면 반환된 데이터를 기반으로 html 파일이 생성됩니다.

부하로 인한 서버 상태 확인은 물론 불가능합니다만... 그건 서버 내부에서 혹은 Datadog 등을 이용해서 체크 가능합니다.

테스트에 대한 결과를 차트를 이용해 시각화 해준다

Datadog 사용한다면 서버 상태를 보다 편하게 확인할 수 있다.

마치며

프로 버전도 존재하지만 간단한 서버 부하 테스트는 무료 버전으로 충분해 보입니다.

[ETC] myjson - 테스트용 온라인 JSON 저장소

손님1(Kendrick) — Sun, 11 Nov 2018 07:11:52 +0900

[ETC] myjson - 테스트용 온라인 JSON 저장소

유용한 Service, Tool, Library를 소개해 드립니다.

myjson

Myjson - A simple json storage and hosting service

Front-end 작업 시 데이터 요청이 필요할 경우, 테스트를 위해서 파일을 로드 하거나 하드코딩으로 데이터를 Return 하는 비동기 코드를 사용하곤 하는데요.

myjson을 이용하면 그럴 걱정이 없습니다.

그리고 CORS도 지원합니다.

사용법

사이트에서 JSON 형식의 데이터를 입력 후, Save 버튼을 눌러주면 끝.

예를 들어 아래 테스트 JSON 데이터를 입력하면...

{
    "user": {
        "name": "kendrick b. jung",
        "age": 70
    }
}

이렇게 값을 반환해 줍니다.

myjson을 이용할 경우, 코드를 변경해 줄 필요 없이 실제 사용할 URL로 변경해 주면 끝!

마치며

친절하게도 사용법 가이드도 제공해 주네요!

사실 너무 직관적이고 간단한 서비스라 뭐... 더 이상 자세한 설명은 생략하겠습니다.

[개발문화탐구] 데브옵스 (DevOps) - 소개

손님1(Kendrick) — Mon, 15 Oct 2018 06:40:59 +0900

개발문화탐구: 데브옵스 (DevOps) - 소개

데브옵스란?

DevOps는 개발(Development)과 운영(Operations)의 합성어입니다

왜 이 두 가지 개념이 합쳐 졌을까요?

서비스의 패치를 위해서 몇 달간의 작업 후 배포하던 고전적인 방식과 달리, 현재는 빈번한 서비스 배포가 주류를 이루고 있습니다.
대부분의 서비스가 설치 기반에서 웹 기반으로 바뀌었으며 마이크로 서비스와 애자일 개발 방법론에 대한 관심이 많아졌고 그로 인해 빈번한 서비스의 배포가 필요해 졌습니다. (이는 애자일 편에서 더 자세히 다룰 예정입니다)

하지만 개발팀은 서비스 개발에 매진하고, 운영팀은 보안과 안정적인 인프라 구축에 집중을 하므로 빈번한 배포 전략이 유연하게 동작할 수 없습니다.

이런 새로운 전략을 위해서 두 팀이 병합되어 개발, 테스트, 배포, 운영에 이르는 애플리케이션 수명주기를 개발하게 됩니다.

이를 데브옵스라고 하며, 이는 아래와 같은 이점이 있습니다.

DevOps의 이점

속도
배포까지의 빠른 작업속도를 효율적으로 제공하기 때문에 시장 변화에 빠르게 대처하고 비즈니스 성과를 창출 가능.
빠른 배포
새로운 릴리즈와 버그픽스를 빠르게 배포할 수 있으며, 그로 인해 고객의 요구를 빠르게 대응 가능.
안정성
지속적 통합, 지속적 전달, 모니터링, 로깅을 통해 안정적인 서비스 품질을 고객에게 제공 가능.
확장 가능
복잡하거나 변화하는 시스템을 효율적으로 관리 가능.
협업 강화
개발자와 운영팀이 긴밀하게 협력할 수 있기 때문에 책임을 공유하고 워크플로우를 결합할 수 있음.
이를 통해 비효율을 줄이고 시간 절약 가능.

클라우드 기반의 웹서비스를 제공하는 경우 빠른 고객 응대와 배포로 인해서 시장우위를 점할 수 있습니다.

Facebook, Netflix, Flickr같은 회사들은 하루에 10번이 넘는 배포주기를 가지고 있다고 합니다.

뭘해야 하나요?

그럼 저런 이점을 얻기 위해 DevOps는 무엇을 해야 할까요?
위 이미지의 DevOps Flow 구현을 위한 중요한 개념들을 정리해 보았습니다.

SCM (Source Code Management)

우선 팀 단위로 개발되는 소스를 지속적으로 관리해줘야 합니다.
아래와 같은 버전 관리 시스템을 이용해 소스코드 관리를 합니다.

이를 위해 Git, SVN 등을 사용합니다

CI/CD

보통 하나의 서비스를 여러 명이 팀 단위로 작업을 하게 됩니다. 이렇게 각각 개발한 코드 빌드부터 배포까지 걸리는 시간 단축을 위해서 CI/CD 구축이 필요합니다.

CI (Continuous Integration)

지속적인 통합.
CI는 Build와 Test를 실시하는 프로세스입니다.
서비스의 품질관리를 위해서 지속적인 빌드와 테스트 과정을 지원합니다.

Build
Unit Test
Code Coverage

일반적으로 CI를 위해 Jenkins, Travis CI 등을 사용합니다.
자동화 테스트의 경우 프로그래밍언어나 프레임워크에 따라 다양하게 사용됩니다.
e.g) Jest, Mocha, PHPUnit, NUnit, etc...

CD (Continuous Deploy (or Continuous Delivery))

지속적인 배포.
빌드단계 이후의 소프트웨어의 배포를 자동화합니다.
개발자가 원할 때 언제나 즉시 테스트 혹은 프로덕션에 지속적으로 배포할 수 있습니다.

Configuration Management

안정적인 지속적 배포를 위하여 서버 및 서비스의 설정을 관리 합니다.
서버 OS, 라이브러리 및 버전, 설치 순서, 컴파일, 등을 특정하여 더욱 안정적인 배포를 할 수 있게 해줍니다.
이를 위해 일반적으로 사용되는 도구는 아래와 같습니다.

Ansible, Chef, Puppet, etc...

모니터링 및 로깅

배포 이후 모니터링 및 로깅을 하여 제품이 최종사용자 경험에 어떤 영향을 미치는지 확인합니다.
데이터에 대한 실시간 분석을 수행하거나 알림을 생성 할 수 있으며, 사용자 데이터를 모니터링하여 서비스 발전에 방향을 잡고 계획할 수 있습니다.

서비스 상태를 확인 및 알람 - Datadog, PagerDuty, etc...
로깅 - Papertrail, Loggly, etc...
사용자 분석 - Google Analyics, Mixpanel, Segment, etc...

마치며

여기까지 기본적인 개념을 살펴보았습니다.
현재는 Docker Kubernetes, Terraform + Ansible, 혹은 Netflix의 Spinnaker를 사용하는 등 다양한 방식이 있습니다.

DevOps는 회사의 개발 문화와 밀접하게 연관이 되어 있습니다.
그렇기 때문에 정답이 없으며, 회사 개발 문화에 자연스럽게 녹아드는 DevOps가 최선이라고 생각합니다.
갑작스레 DevOps 전문가를 뽑아서 이렇게 해! 저렇게 해! 한다고 되는 부분이 아니며, 팀 내 개발자들의 관심을 통해 그 서비스의 맞춘 DevOps 환경을 만들어 가야 합니다.

회사에서 DevOps 작업하며 공부한 것들을 작성했으며, 더 많은 내용을 여기에 담으려 했으나!
그러면 매우 길고 지루해질 것 같아 제목에 소개를 붙였습니다.
DevOps 관련하여 자동화 배포, 마이크로서비스, 서버패턴, 배포전략 등의 내용을 추가적으로 쓸 예정입니다.
포스트 하나로 때우기에는 생각보다 너무 방대하네요...

상황에 따라서는 AWS에서 관련 서비스를 많이 제공하기 때문에 위에 열거한 툴을 사용하지 않아도 됩니다.

GitLab 자체에서도 CI/CD 도구를 제공하고 있습니다. 회사 동료가 쓰는걸 봤는데 인상적이더군요.

참고

Roadmap to becoming a web developer in 2018
How Netflix Thinks of DevOps
데브옵스란 무엇입니까? – Amazon Web Services(AWS)
[개발상식] 23. DevOps란 무엇이며, CI는 무엇인가?

[ETC] MacOS Mojave - invalid active developer path Issue

손님1(Kendrick) — Mon, 15 Oct 2018 04:04:31 +0900

MacOS Mojave - invalid active developer path Issue

MacOS 모하비 버전이 나왔습니다!

제가 느끼는 주요 변경 점이라면 다크모드와 새로운 Finder 뷰 모드? 정도가 있겠네요.

요런느낌

한 시간에 걸친 업데이트 후, 문제가 생길 것이라는 불안감은 빗나가지 않습니다...!
git command를 사용하려 하니 귀신같이 아래와 같은 에러를 뿜뿜!

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

하아...

찾아보니 기존 MacOS 시에라 혹은 하이 시에라 버전으로 업데이트 시에도 있던 이슈라고 하네요.

나중에 또 업글하면 또 발생하겠지? 싶어 이렇게 포스트를 작성 중입니다.

해결방법

OS 업데이트 후 사용권 계약 관련해서 발생하는 문제이므로, 문제 해결을 위해서 xcode developer tool을 설치해 주면 됩니다.

터미널로 가신 후 아래 명령어를 입력해 주세요

xcode-select --install

이후 git 명령어가 잘 동작 합니다. 굿!
또 다른 문제가 생기지 않길 바랄 뿐입니다.

잘 된다!

참고

sierra - macOS Mojave: invalid active developer path - Ask Different

[ETC] 동적 서버 접속을 위한 SSH Config

손님1(Kendrick) — Sun, 16 Sep 2018 09:17:16 +0900

동적인 EC2 Instance 접속을 위한 SSH Config

작년까지 Snowflakes Server 패턴을 사용하다가 올해 초 Phoenix Server 패턴으로 변경하게 되었습니다.
작업 후 새로 배포되는 서버들이 매우 안정적으로 생성되는 걸 확인하고 야호를 외쳤으나... 새로 생성된 서버에 SSH 접속때 마다 매번 IP가 다르니 불편함이 이만저만이 아니었습니다.

그 와중에 Bastion 서버도 통해서 접속해야 했기에 매번 만들어둔 긴 SSH Command 수정하기도 매우 번거로운 것..!

그렇다고 SSH Config를 만들어놔도 새 서버를 만들 때마다 SSH 접속 정보를 변경해 줄 수도 없는 노릇이고 말이죠..!

비슷한 문제를 가지고 계신 분들이 분명 있을거라고 생각해 글을 쓰게 되었습니다.

아래와 같거나 비슷한 환경이신 분들을 위한 SSH 접속 팁입니다.

Phoenix Server Pattern을 사용한다. (서버 배포마다 IP가 변경된다)
보안을 위해서 SSH 접속 시 Bastion 서버를 사용한다.
여러 AWS Region을 사용한다.

사용 방법

아래와 같은 ssh-config 파일을 ~/.ssh 폴더가 아닌 별도의 폴더에 생성해 줍니다.
[Bastion 서버 host name]와 [ssh-config 파일 절대 경로] 값을 자신의 환경에 맞게 대체해 주세요.

Host bastion-canada
    User ubuntu
    Hostname [Bastion 서버 host name]
    IdentityFile ~/.ssh/bastion-canada.key

Host *.ca-central-1.compute.amazonaws.com
    User ubuntu
    ProxyCommand ssh -F [ssh-config 파일 절대 경로] bastion-canada -W %h:%p
    StrictHostKeyChecking no

Host bastion-us
    User ec2-user
    Hostname [Bastion 서버 host name]
    IdentityFile ~/.ssh/bastion-us.key

Host *.compute-1.amazonaws.com
    User ubuntu
    ProxyCommand ssh -F [ssh-config 파일 절대 경로] bastion-us -W %h:%p
    StrictHostKeyChecking no

아래 Command로 접속 할 수 있습니다.

ssh -F ssh-config -i [pem file name] [ec2hostname].ca-central-1.compute.amazonaws.com

추가 1)
ssh-config 파일이 있는 폴더로 이동 후, ec2 host name만 변경해 주시면 됩니다.
pem file name의 경우 접속할 서비스 종류가 여러 개인 제 입장에서는 필요하지만, 여러 서버의 접속할 필요가 없다면 ssh-config에 pem정보 추가해 주고 사용하시면 더 짧은 Command로 간단하게 ssh 사용하실 수 있습니다.

추가 2)
제 경우 bastion을 사용하지 않는 서버도 고려해서 ssh-config를 별도의 폴더로 옮겨놓았지만, 만약 회사용으로 완전 개발환경을 분리해서 사용하신다면 그럴 필요가 없을 거라고 생각이 듭니다.
그럴 때는 ssh-config 파일을 ~/.ssh/config로 생성해주시면 됩니다.

결국 추가 1, 2를 적용하면 아래와 같은 Command로 Bastion을 통한 ssh 접속이 가능하겠네요.

ssh [ec2hostname]

추가 팁

여러 서버에 접속한 이후, 예를 들면 10개의 서버에 접속 후 로그를 확인한다면 10개 서버 각각 따로 커맨드를 입력해줘야 하지만 더 간단한 방법이 있습니다.
바로 Iterm2를 사용하는 것..!

저도 최근에 안 사실이지만 Iterm2 자체에서 Broad casting input이라는 기능을 제공하고 있습니다.

먼저 원하는 만큼 Split tab을 생성해 줍니다. 단축키는 CMD+D or CMD+SHIFT+D

이후 CMD + OPTION + I를 눌러주시면 열려있는 전체 패널에 대한 Broad Casting Input 기능이 동작합니다.

마치며

제목이 말이죠 이게 참... 동적 관리 서버? 동적 생성 인스턴스? 흠 저걸 뭐라고 명명해야 잘 했다고 소문이 날까요... 애매하네요

동적생성되는 인스턴스에 대한 SSH 접속 방법으로 이보다 더 좋은 방법이 떠오르지 않아 근 6개월 동안 이 방법을 고수해오고 있습니다.
더 좋은 방법이 있다면 알려주시면 감사하겠습니다!

참고

An SSH tip for modern AWS patrons - David Winterbottom

[개발문화탐구] 코드리뷰 (Code Review)

손님1(Kendrick) — Sun, 16 Sep 2018 07:48:43 +0900

개발문화탐구: 코드리뷰

코드리뷰

개발문화 중 하나인 코드리뷰에 관해서 이야기를 해보려 합니다.

코드리뷰라 함은 간단히 말해, 내가 작성한 코드를 제3자가 검사하는 것입니다.
타인에 의해 예상치 못한 오류를 찾아내거나 코드를 더 좋게 개선할 수 있습니다.
자신의 발전과 팀의 발전 그리고 제품의 안정성을 위하여 꼭 도입되어야 하는 문화입니다.

허나 이런 중요성에도 불구하고 코드리뷰를 왜 하는지 가슴으로 느끼기는 참 힘듭니다.

이 포스트를 본다고 해서 직접 경험 해보지않는 이상 코드리뷰의 중요성을 100% 이해하기는 어렵겠습니다만 느낌이라도 살짝..

코드리뷰를 대하는 자세

직장 내의 서로 다른 개발자가 right way를 향해 발전하는 가장 좋은 문화가 바로 코드리뷰라고 생각합니다.

하지만 기본적으로 서로를 인정하고 리스펙하는 분위기가 형성되어 있어야지, 그렇지 않을 경우 단지 서비스 오류를 방지하기 위해(혹은 코드 Merge를 위해) 행하는 매우 귀찮은 검사단계 정도로 치부될 수 있습니다.

최악의 경우 이런걸 왜 하냐고 직장 동료들끼리 상사 뒷담화 할지도…? (아주 오래된 경험상...)

" filename="hello-i-m-nik-743251-unsplash.jpg" filemime="image/jpeg" original="yes"/><내가 수정한 코드가 실서버에 배포되기에 충분할까?>

코드리뷰의 첫인상

코드리뷰를 처음 도입 혹은 처음 경험했을 때, 이게 생각만큼 마냥 유쾌하지만은 않습니다.
마치 숙제를 검사받는 기분이 들기도 하고, 익숙하지 않으면 살짝 부담스럽기도 합니다.
저도 처음에는 내 코드를 타인이 본다는 게 참 쑥스러웠으나 적응되고 나니 지적받고 싶어지기도…?

아무튼 리뷰어가 좀 더 쉽게 코드리뷰 할 수 있게 Commit 메시지를 더욱 디테일하게 작성하는 근본적인 이유가 생기며, 코드 자체도 경각심이 생겨서 좀 더 신경 써서 작성하게 됩니다.

고전적인 방식의 코드리뷰

이전 회사에서의 코드리뷰 방식은 고전적인 방식의 코드리뷰였습니다.

서비스의 릴리즈가 한 달 혹은 그 이상의 시간이 걸리기 때문에 그간의 변경 사항에 대한 프로세스 리뷰 및 특별히 적용한 알고리즘에 대해서 얘기를 했습니다.
변경사항이 많아서 각자 미리 해당 코드를 보고 와서 회의실에서 이야기하곤 했습니다. (물론 진짜 읽고 온지는 아직도 의문)

하지만

실제 업무를 하지 않던 윗단에서는 한 귀로 흘려들었으며, 개발자 간에도 서로 각자 담당 서비스가 있었기 때문에, 지금까지 손댄 적도 없고 앞으로도 손댈 일 없는 코드에 관심이 있을 리가 없었습니다.
결국 한 두번 해본 후, 코드리뷰는 소리소문없이 사라졌습니다.

이와 같은 방식의 코드리뷰를 Walkthrough 방식이라고 한다고 합니다.

하지만 제가 이번 포스트에서 말하고 싶었던 코드리뷰는 Github의 Pull Request를 이용한 방식입니다.

Github PR Code Review

예전과 다르게 지금은 대부분의 회사가 Agile 방식이나 좀 더 작은 단위의 개발 및 릴리즈를 선호하고 있습니다. (아마도...)

그런 흐름에 맞춰 대부분 A successful Git branching model에 기반한 git flow나 github flow와 같은 흐름으로 개발을 하고 있습니다.

이전에는 큰 목표를 설정하고 오랜 시간에 걸쳐 작업하기 때문에 매우 많은 코드의 변화가 생김으로써 코드리뷰가 너무 힘들었던 반면, 요즘은 위 flow와 같이 동시에 작은 단위 및 기능별로 개발을 하게 됩니다.

추가/변경되는 코드의 수가 이전보다 훨씬 적기 때문에 코드리뷰를 기능별로 더욱 명확하게 할 수 있습니다.

자세한 방식은 github flow 내용을 참고하시면 좋을 것 같습니다.

왜 코드리뷰를 하는 건가요?

간단하게 정리하면 아래와 같습니다.

코드의 정확성 및 품질향상
당면한 문제에 대해 다양한 관점에서 개선 및 해결책 제시
새로운 아이디어에 대한 의견공유
사내 Code Convention 정착
코드 작성자가 놓친 오류 방지. 더해서 깜박하고 안 지운 console.log도 :)

위와 같은 명백한 장점이 있으며, 이외에도 타인의 코드를 검토하면서 실력 상승이 된다거나 반복된 검토로 인해 코드 리딩 및 이해 속도가 향상되기도 합니다.

도입 시 주의사항

만약 코드리뷰를 도입한다면, 먼저 코드리뷰에 방해되는 고전적인 개발 문화들이 있는지 보고 좀 더 심사숙고 후 적용을 하셨으면 좋겠습니다.
물론 코드리뷰를 위해서 그렇게까지 해야 하나 싶을 수도 있지만 제 경험에 비춰볼 때 어설프게 적용하면 안 하느니만 못 한 느낌!

최악의 예를 들자면… 각 개발자가 서로 다른 서비스를 담당하고 있어 서로의 코드를 볼 일이 없는 와중에 갑자기 코드리뷰를 도입한다면, 원하는 결과를 끌어 낼 수 있을까요?
물론 간단한 조언이나 성능 개선을 위한 의견을 낼 수는 있겠지만, 코드리뷰 할 때 딴생각하고 넋 놓지만 않아도 다행일 것 같네요.

그리고 효과를 보기 위해서는 두 달 정도는 꾸준히 진행해야 그 효과를 체감할 수 있으며, 이를 위해서 팀 리더의 역할이 매우 중요하다고 생각합니다.

마치며

적은 스코프로 코드리뷰 요청을 해야하지만, 이 부분이 아직 저도 익숙하지 않아 어떨 때는 1000라인이 넘는 PR을 만들 때도 있는데 글을 작성하면서 이 부분은 고쳐야겠다고 반성 중입니다 ㅎㅎ!
몇 주 전 캠핑장 갔을 때 wifi도 안되는 곳이라 블로그 글이나 쓸까 하고 간단하게 작성한 글이었는데, 몇일 텀으로 읽을 때 마다 뭐가 부족한가 싶어서 계속 수정하다 보니 시간이 너무 오래 걸렸네요.
정말 오랜만에 올리는 포스트인 듯! 다시 기운 바짝 내서 올려야겠습니다.
뭐 쓸지 주제만 정해놓고 Backlog에 올려놓은 게 너무 많아서 약간 압박이…
이글을 작성하는 중에 타이밍 좋게 현 회사 CTO 형님이 팀원들 공유 목적으로 관련 문서를 만들었는데 많은 도움이 됐습니다.

참고

Giving better code reviews – Joel Kemp – Medium

How to code review in a Pull Request - Codacy Blog

코드 리뷰 가이드 - Edward Kim

Kendrick's Blog

새로운 블로그로 이전 완료

2022년 회고

2022년 회고

일상

일

블로그 이전

앞으로의 계획

2023 신년 운세

마치며

바닐라 코딩 인터뷰 내용 정리

들어가기 전

1. 멘토를 찾으세요

1) 사실이 아닌 의도를 공개하고 접근하자

2) 개발자 멘토의 실력은 내가 판단할 수 있을까?

3) 좋은 멘토는 없다, 좋은 제자가 있을 뿐이다.

2. 영어 공부는 어떻게 하나요?

3. 한국 경력은 타이틀이 아닌 경험을 어필하세요

4. 자기 객관화를 잘하세요

5. 당신의 일을 위임하세요

1) 중요하고 새로운 일은 여유가 있는 사람에게 주어진다.

2) 언제든 퇴사당할 수 있다고 생각하자.

마치며

결혼 모바일 초대장 후기

결혼 모바일 초대장 후기

왜 만드는데 시간을 쓰시죠?

소개

구조

스펙

아쉬운 점

마치며

자바스크립트 Spreadsheet 라이브러리 추천

자바스크립트 Spreadsheet 라이브러리 추천

Jspreadsheet

handsontable

명암 대비를 고려한 디자인 - WCGA 2.1 Contrast

명암대비를 고려한 디자인 - WCGA Contrast

WCGA란?

Contrast 명도 대비

Contrast ratio(명도 대비율) 계산법

적합성 수준 with Contrast Ratio

AAA

AAA Large

AA

AA Large

Fail

마치며

References

독서 모임을 유지하기 위한 방법

독서 모임

독서 모임을 하는 이유

독서 모임을 유지하기 위한 방법

초집중 보장하기

독서 리뷰는 필요 없다

모임을 위한 환경설정

배경음악 깔기

마치며

홈페이지 디자인을 위한 줄 바꿈 위치 제안 - &shy;

홈페이지 디자인을 위한 줄 바꿈 위치 제안 &shy;

&shy;

CSS hyphens

Ref

마케팅 - 콜드 메일(Cold mail)이란?

콜드 메일(Cold mail)이란?

Paywall을 위한 CSS linear-gradient

paywall을 위한 CSS Gradient

Paywall이란

Gradient로 흐려지는 효과 적용하기

마치며

참고

2020년 회고

2020년 회고

COVID19

원격근무

새로운 작업환경

업무

독서 모임

신년운세

마치며

Mac OS Big Sur 메뉴바 밝기 이슈

홈페이지 디자인을 위한 줄 바꿈 위치 제안 -

홈페이지 디자인을 위한 줄 바꿈 위치 제안 ``