IT 회사에서 즐겁게 지내기!

지난 6월 17일 코로나 예방 접종을 하였습니다.
얀센 잔여 백신이었고 경험한 증상(부작용?)을 공유합니다.

잔여백신 예약은 와이프가 지도를 새로고침하며 재빠른 손으로 예약을 해주었습니다.

요약하자면 48시간동안 두통, 오한, 발열을 겪었고 주사 부위 근육통을 겪고 있습니다.

6월 17일 (주사 맞은 당일)
12시 35분경 주사를 맞았습니다.
주사 맞은 자리는 꽤나 뻐근하고 4일 정도 통증이 지속되고 있습니다.
21시 30분경(9시간) 두통이 시작됩니다.
22시 15분경(10시간) 오한이 왔습니다.
증상이 더 심해지기 전에 얼른 타이레놀을 한 알 먹고 잤지요.

6월 18일 (다음 날)
2시 45분(14시간) 두통으로 잠이 깼습니다.
타이레놀을 한 알 더 먹고 잤네요.
다음날 오전 7시(19시간) 두통에 더해 열이 나기 시작합니다. 38도 정도 였습니다. 타이레놀을 한 알 먹으면 참을만 했습니다.
11시20분(23시간) 이제 두통과 열에 오한까지 추가됩니다. 타이레놀 약효(4~5시간)가 떨어지면 증상이 바로 올라옵니다. 이번에는 약을 두 알 먹어봤습니다. 몸 상태가 매우 호전됩니다.
17시30분(29시간) 열은 거의 사라지고 두통만 있습니다. 타이레놀 한 알을 먹고도 버틸만 합니다.
22시15분(33시간) 두통이 좀 있고 오한이 살짝 있습니다. 길게 자고 싶어서 타이레놀 두 알을 먹고 잤습니다.

6월 19일 (3일차)
8시 30분(43시간) 두통이 있습니다. 타이레놀 한 알을 먹고 완벽한 일상으로 돌아왔네요.
13시(48시간) 미약한 두통 이외 증상 없고 몸 상태가 정상이 됩니다. 이제는 약도 필요 없어졌습니다.

아래는 예방접종 안내문(보건소) 발췌입니다.
구분: 얀센 사
백신종류: 전달체 백신(바이러스 벡터)
접종횟수: 1회

3일간 특별한 관심을 가지고 관찰
코로나 19 백신은 생백신이 아니므로 코로나 감염되지 않음
가능한 국소 반응: 접종부위 통증, 부기, 발적
가능한 전신반응: 발열, 피로감, 두통, 근육통, 메스꺼움/구토 등

접종 직후 15분간 알러지 반응(아나필락시스)이 나타나는지 관찰 필요

아래는 병원 안내문입니다.
백신 접종 후 20분간 병원에서 대기 후 귀가하셔야 합니다.
접종 후 몸살증세나 근육통 두통 시 타이레놀 복용하셔도 됩니다.
심한 두통 마비증세 닜으면 119 연락하여 응급실로 가셔야 합니다.
가족과 함께 계실 것을 부탁드립니다.
그 외에도 사지절임 증세는 2~4주간 지속 될 수 있습니다.
서서히 좋아지기는 합니다.
부작용은 보건소(관할) 질병관리본부(1339)에 문의하세요!
치료를 요하는 심한 증세시 저희 병원에도 알려주세요!
백신 접종 후 대부분은 경미한 반응이지만 개인에 따라 차이가 있을 수 있습니다.

얀센 백신을 맞은 주변 사람들 대부분이 비슷한 증세로 고생을 했다고 들었습니다.
아는 분 중 한 분은 두통, 발열이 없었는데 사지 절임 증상이 일주일 후에 나타났다고 하네요.
저도 지켜봐야할 것 같습니다.

코로나 19 감염보다는 훨씬 나은 감당할 부작용이라는 개인적인 의견이구요. 예방 접종 후 대부분의 사람들에게 부작용이 있으니 몸 상태가 좋을 때 맞는 걸 추천드립니다.

얀센의 부작용에 대한 기사가 많은데요. 외신에서는 부작용의 위험성 또한 코로나 19 예방 효과가 크기에 감수할 만하다라는 의견이 지배적으로 보입니다.

백신 접종을 계획하시는 분들께 도움 및 참고가 되었으면 좋겠습니다.

프론트엔드 개발을 하다보면 종종 CORS(Cross Origin Resource Sharing) 오류 메시지를 마주치게 됩니다.

이 오류는 간단히 말해서 접속한 사이트가 내부적으로 다른 도메인(Domain) 혹은 포트(Port)의 자원(Resource)을 요청했을 때 브라우저가 보안 상의 이유로 해당 요청을 허용하지 않기 때문에 발생하는 오류입니다.

보통 운영 환경에서는 API서버와 프론트 서버를 같은 도메인 상에 묶어 놓는 경우가 많습니다. 다만 개발 시에는 서로 다른 도메인 혹은 포트 상에서 진행되는 경우가 대부분이죠. 프론트엔드 서버와 API 서버를 로컬의 서로 다른 포트에 두거나 개발은 로컬에서 API서버는 별도의 서버에 기동되는 등의 경우입니다. 결국 개발 시에는 CORS 오류를 마주할 가능성이 높다는 이야기죠.

이에 대한 근본적인 해결책은 물론 API 서버 측에서 CORS를 허용하는 쿠키를 넣거나, 프록시 세팅을 통해 두 서버를 같은 도메인으로 묶거나 하는 등의 방법이 있습니다. 하지만 단지 개발을 위해 그런 처리를 하기에는 귀찮죠. 간단하게 테스트 용으로만 사용할 수 있는 방법이 있어 공유합니다.

그 방법은 바로 로컬의 브라우저의 보안을 꺼버리는 것 입니다. 이미 말씀드렸듯이 테스트 용도입니다. 안전하지 않기 때문이죠. 신뢰할 수 있는 자신이 개발하는 코드의 테스트 용도로는 딱입니다.

윈도우에서 예로들면 아래와 같은 명령을 통해 Chrome 브라우저의 보안을 끄고 CORS 오류 없이 작업이 가능해집니다.

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="C:\Temp"

그러면 아래와 같은 Chrome창을 확인할 수 있습니다.

'지원되지 않는 명령줄 플래그(--disable-web-security)를 사용 중이므로 안전성과 보안에 문제가 발생합니다'라고 하는 안내문구가 보이시죠? 바로 저 안내문구가 CORS 오류를 체크하지 않는 다는 것을 의미합니다. 물론 이 뿐만 아니라 사용자를 보호하기 위한 다른 보안 기능들도 꺼져있다고 보시면 됩니다. 개발 시에 사용하는 임시방편이라는 의미죠. 하지만 다른 CORS 툴을 깔거나 고생하는 것보다는 훨씬 편리한 방법입니다.

많은 디바이스의 다양한 해상도에 대응하기란 참 어렵습니다. 그 중 대표적인 것 하나가 반응형 웹사이트입니다. 브라우저의 너비(Viewport)에 따라 다른 스타일을 보여주는 방식이지요.

하지만 이 또한 한계가 있습니다. 전환점(Breakpoint)에 따라 디자인을 다르게 하려면 그 또한 시간과 비용이 듭니다. 결국 어느 정도 선에서 타협이 이루어집니다. 제가 속한 프로젝트는 진행 속도를 위해 모바일/데스크탑용 2종류 디자인을 가지고 그 중간 영역에서는 비율에 따른 너비(vw)로 대응하였습니다.

아래와 같이 나누었지요.
1. ~360px (모바일 디자인)
2. 361px ~ 768px (모바일 디자인 비율 확대)
3. 768px ~ 1440px (데스크탑 디자인 비율 축소)
4. 1440px~ (데스크탑 디자인)

그런데 Galaxy Fold라는 디바이스로 위기를 맞이합니다. 안타깝게도 이 디바이스는 접힌 화면의 너비(Viewport)는 320px, 펼친 화면의 너비는(Viewport) 535~683px 입니다. 디바이스의 글자크기 설정(작게, 중간, 크게)에 따라 브라우저의 너비(Viewport)가 535, 586, 683px로 달라집니다.

접힌 화면(320px)에서는 가로 스크롤이 생기고, 펼친 화면의 애매한 크기(535~683px)는 확대된 모바일 컨텐츠가 잘리는 안타까운 상황이었습니다. 딱히 묘안은 없었고 결국 Breakpoint를 추가할 수 밖에 없었습니다. 초기에 작업했던 것들은 전부 재작업해야했죠.

대상 디바이스에 대한 조사가 선행되고 전환점(Breakpoint)에 대한 고민을 했다면 오히려 시간을 아꼈을 수 있겠다는 아쉬움이 남네요. 적어도 폴드는 작년에 나왔으니까요. 앞으로도 다양한 디바이스들이 계속 출시될텐데 반응형 디자인에 대한 고민은 계속 되어야할 것 같습니다. 하나의 소스로 모두 대응하려는 방식(One source multi-use)은 어쩌면 독이 될 수도 있다는 생각도 하게 됩니다.

이 글은 아토믹 디자인(Atomic Design)이 무엇인가에 대한 글은 아닙니다. 아토믹 디자인 컨셉을 활용해 본 후기입니다.

아토믹 디자인은 아래 블로그에서 자세히 확인하실 수 있습니다.

아토믹 디자인이라는 용어를 접한 건 작년 2019년 입니다. 아토믹 디자인은 쉽게 말해서 화면을 구성할 수 있는 아주 작은 단위의 요소부터 디자인 시스템을 만들어가는 방법론이라고 볼 수 있습니다.

놀랍게도 2013년도부터 이 용어가 쓰여졌는데요. 2016년에는 책도 쓰였으니 꽤나 오래된 개념이라고 볼 수 있겠네요. 제가 이 용어를 접하게 된 계기는 재미있게도 디자인이 아닌 개발 효율화 측면이었습니다. 비슷한 모양의 비슷한 기능을 하는 스타일코드와 스크립트들이 중복하여 존재하는 프로젝트가 있었습니다. 이를 개선할 방법은 중복 코드의 제거를 통한 효율화인데 프로젝트의 오너는 비개발자여서 이를 더 멋지게 설명할 그럴듯한 단어가 필요하여 아토믹 디자인을 발견하게 되었습니다. 최신 웹 개발 프레임워크(Angular, React, Vue 등)들이 컴포넌트 단위의 개발을 지원하기에 아토믹 디자인과 디자인시스템의 도입은 개발 측면에서도 상당한 이득을 가져다 줄 수 있었습니다.

여기까지가 머리 속에서 그린 청사진이지요. 안타깝게도 현실은 만만치가 않습니다. 머리 속에서 그렸던대로 흘러가지 않았습니다. 제가 마주한 어려움들 몇 가지를 공유하며 아토믹 디자인을 적용하기 위한 전제에 대해 적어봅니다.

1. 아토믹 디자인은 모든 팀원이 이해하고 시작해야 합니다.
어떤 방법론이든 참여자들의 이해를 기반하여 성과가 나온다는 것은 명확합니다. 아토믹 디자인은 특히나 기획/디자인/개발 역할자 모두가 아토믹 디자인이 어떤 식으로 흘러가는지 이해할 필요가 있습니다. 일반적인 작업 방식과 순서부터가 다릅니다. 전체적인 그림을 그리고 부분적으로 채워가는 Top-Down 방식이 아닌 가장 작은 요소부터 만들어가는 Bottom-Up 방식으로 만들어집니다. 요즘은 애자일이라 부르고 짧은 일정에 디자인과 개발이 병렬적으로 수행되는 경우가 많은데 이런 상황에서는 기획/디자인이 Top-Down 방식으로 가는 이상 개발에서 아토믹 디자인을 적용하기 상당히 어렵습니다. 논의를 통해 공통요소를 도출하고 적어도 스타일 가이드는 만들어가야 그나마 흉내는 낼 수 있죠. 다만 상당히 고생할 수 밖에 없습니다.

2. 이미 정의된 아토믹 요소를 공유할 체계가 필요합니다.
프로젝트는 여러 사람이 함께합니다. 아토믹한 요소들에 대해 모두가 숙지하고 있다면 좋겠지만 큰 프로젝트의 경우 스타일 가이드를 완성해가는 사람들과 실제 화면을 디자인해가는 사람들이 다릅니다. 따라서 디자인의 근간이 되는 요소들이 실시간으로 공유될 체계가 잡혀있어야합니다. Zeplin이든 Sketch Library든 또는 코드가 포함된 Style Guide든 (PatternLab, Storybook, Fractal 등) 눈으로 쉽게 확인할 수 있는 방법과 무엇이 언제 왜 업데이트가 되는 지에 대한 내용이 문서이든 협업 도구든(Slack, Jira, Confluence, Wiki 등) 잘 기록되고 관리되어야합니다. 아무 체계 없이 가다가는 혼란스러울 뿐입니다.

3. 적당한 경계를 잘판단해야 합니다.
가장 어려운 단어인 '적당한'이 등장 합니다. 어디까지가 표준이고 공통이며 어디부터가 변용인지 명확한 경계가 없습니다. 팀원들이 잘 정해나가야하죠. 표준이 너무 강하면 디자인의 자유도가 떨어지고, 변용이 너무 강하면 표준이 의미가 없어집니다. 브랜딩인지 마케팅인지 성능인지 사용성인지 방향성을 잘잡고 가야합니다.

주저리 주저리 적어봤지만 너무 추상적이 되어버렸네요. 컴포넌트 단위의 개발, 스타일 가이드, 디자인 시스템이 효율적인 방법론을 제공하는 것은 분명합니다만, 쓸 줄 모르는 도구는 때론 안쓰는 것만 못할 때가 있다라는 더 추상적인 말로 마무리 짓겠습니다.

이제 200일 된 아이를 키우면서 개인적으로 정말 잘 썼구나 싶은 아이템 3가지를 소개해보려고 합니다.

1. 바구니 카시트(맥시코시 카브리오픽스)
2. 자동 분유 제조기(베이비 브레짜)
3. 기저귀 갈이대(리엔더)

1. 바구니 카시트
아이를 안고 차에 타는 건 사고 시 아이가 어른의 에어백 역할을 하도록 하는 매우 위험한 행동이라고 하더라구요. 카시트는 꼭 써야겠다 싶었고, 고민 끝에 사용기간이 짧더라도 바구니 카시트를 써보자라는 결론에 이르렀습니다. 많이 못쓰더라도 차에서 아이 들어올릴 필요 없이 카시트 째로 이동할 수 있다는 장점은 더 없이 좋았습니다.

특히 미리 예약해둔 조리원이 자리가 없어 임시로 다른 곳에 가게 되어 병원에서 나올 때부터 카시트를 써야했는데 거의 눕다시피 태울 수 있는 바구니 카시트는 정말 유용했습니다. 그리고 6개월 전까지 잦은 예방접종 및 스튜디오 촬영을 위한 이동에도 잘 썼습니다. 바구니 카시트는 유모차와 호환 되는 점이 또 유용했습니다. 바로 차에서 유모차로 꽂아 손으로 들고 다니는 것을 최소화할 수 있습니다.

2. 자동 분유 제조기
사실 이건 필수품은 아닙니다. 손으로 타면 되는데 굳이 필요한가라는 의문이 들 수 있습니다. 그런데 언제 배가 고플지 미리 준비해놓지 않아도 되는 점은 초보 아빠에게는 매우 유용했습니다. 우는 아이 내버려두고 물온도 맞추고 분유타는 마음이 편치 않습니다. 배고픈 아이에게 조금이라도 빨리 분유를 타줄 수 있는 건 꽤 가치가 있다고 봅니다.

특히 자동 분유 제조기가 가치를 발하는 것은 할머니, 할아버지에게 아이를 맡길 때 입니다. 젖병 눈금을 보기 위해 안경 쓸 필요 없고, 분유 타기를 다시 익히실 필요가 없어 육아 참여가 수월해집니다. 또한 밤에 배고파서 깬 아이에게 대응하기도 좋구요.

3. 기저귀 갈이대
기저귀 갈이대는 사실 제품보다는 구성이 좋았습니다. 아이를 바닥에 눕혔다가 기저귀를 갈고 들어올리는 것은 손목과 허리에 꽤나 무리가 가는 행동입니다. 기저귀 갈이대를 사면서 서서 아이 기저귀를 갈 수 있도록 가구 위에 올려둠으로써 손목과 허리를 보호할 수 있었습니다. 특히 출산으로 몸이 완전히 회복되지 않은 상태에서 아이를 돌봐야하는 아내에게 점점 무거워지는 아이를 바닥에 들었다놨다 하지 않을 수 있도록 해준 것은 큰 장점이었습니다.

육아하는 데에 도움이 된 아이템은 참 많았지만 3가지를 고르라면 이렇게 생각이 나네요. 모빌이나 바운서 등도 도움이 되긴 했습니다만 아이마다 많이 다를 듯 하구요. 아이를 기다리며 아이템을 찾는 예비 엄마, 아빠에게 추천을 하자면 위 세 가지를 추천할 것 같습니다.

육아는 템빨이라죠? 큰 도움이 되긴 합니다. 하지만 더 중요한 것은 엄마와 아빠가 건강하고 행복한 마음으로 아이를 함께 돌보는 것 아닐까요?

몇달 전 미국 법인 친구들이 한국에 와서 치맥을 하러 갔을 때의 일입니다.

사무실이 강남역 근처라 많고 많은 음식점 중 가까운 치킨집으로 갔는데 메뉴판에 영어가 없더군요. 굳이 외국인을 받지 않아도 손님이 많아서 그런지 심지어 그림도 없는 메뉴판. 그리하여 메뉴를 설명해야할 필요가 생겼습니다.

그런데 미국 법인 친구들이 갑작스레 으쓱하며 요즘 이런거는 실시간으로 번역을 해준다며 설명 필요 없다는 겁니다. 한 친구는 Bixby 비전 다른 친구는 구글 번역을 켜더니 메뉴판을 카메라로 보더군요.

다른 거는 뭐 그럭저럭 알아들을만 한지 보다가 '닭똥집'을 본 순간 재미난 표정을 보이는 겁니다. 이건 대체 뭐냐면서요. Bixby는 'Chicken shit', 구글 번역기는 'Chicken dung'이라고 번역이 된 문구를 보여주며 이런걸 먹냐는 난처한 눈빛.

설명이 필요할 것 같아서 생각을 하는데 아무래도 단어가 안떠오르는 겁니다. 결국 'Chicken intestine' 이라고 했는데 아무래도 찝찝했네요.

정확한 단어를 찾아보니 'Chicken gizzard'(닭 모래주머니) 였습니다. 좀 더 호기심이 발동해서 모래주머니가 왜 필요하며 이름은 왜그런가 궁금해졌습니다.

새들은 모래주머니라는 소화기관을 가지고 있는데요. 그 이유는 새들은 이가 없기 때문에 먹이를 바로 삼키고 그것을 잘게 부수기 위함입니다. 이로 씹어 삼키는 대신 모래주머니가 그 역할을 하는 것이지요. 그런데 왜 이름이 모래주머니일까요? 그것은 먹이를 삼킬 때 모래나 돌맹이를 함께 삼켜 그것을 이용해서 소화를 돕기 때문입니다.

음식점에서는 모래주머니를 왜 하필 똥집이라고 썼을까요? 이는 모래주머니가 닭의 '위'의 일부이고, 똥집은 '위'의 속어이기 때문에 '닭의 위'라는 재료를 음식 이름으로 쓴 것 뿐이랍니다.

담담하게 써내려갔지만 재미난 에피소드였던 것 같습니다. 저는 조만간 외국어를 배울 필요가 없는 세상이 되지 않을까 기대하고 있는 사람이지만 이런 것들은 과연 기술이 어떻게 극복할지 참 궁금해지는 날이었습니다. ^^

지난 6월 소개드렸던 '베이비페이스'의 후기입니다.

가장 궁금한 점은 미리 본 아이의 얼굴과 태어난 아이의 얼굴이 얼마나 비슷할까겠죠? 일단 어느정도 비슷하다는 걸 말로 표현하기 쉽지 않으므로 사진부터 보여드립니다.

 babyface 서비스와 실제 아기 비교사진

아이의 동의 없이 얼굴을 인터넷에 공개하는 것이 마음에 걸리긴 합니다. 그렇지만 눈을 감은 사진이고 아이 얼굴은 수시로 변하니 이 정도는 괜찮은 걸로 생각하려구요. (나중에 마음이 변하면 지울 수도 있습니다...)

아무튼 태어나자마자 비슷하다는 생각은 들지 않습니다. 왜냐하면 미리보기 사진의 볼 살은 태어난지 꽤 지난 살이 오른 모습이니까요. 태어난지 60일 즈음되니 주변 지인들이 꽤나 비슷하다는 이야기를 합니다. 참 신기하죠?

아이가 태어나기 전부터 우리 아이에 대해 구체적으로 상상하고 더 깊은 애정을 가질 수 있는 기회였습니다. 태교에도 도움이 되었습니다. 뱃 속의 아이에게 책을 읽어주거나 태동을 할 때 왠지 아이 얼굴이 그려지거든요.

입체초음파를 찍을 생각이라면 베이비페이스 서비스도 한 번 고려해보면 어떨까 싶네요.

베이비페이스 서비스는 아래 링크에서 만나보실 수 있습니다.

babyface.io