변곡점

2022년의 마지막 날이다. 잠이 안와서 새벽 4시에 일어났다.

과거의 2022년을 맞이하며 쓴 글을 보고 충격받았다.

아무 것도 다르지 않은 내용을 오늘까지 말하고 있었기 때문이다.


그렇구나.

나는 올해 아무런 변곡점을 만들지 못했구나.

팀에서 제일 많이 말하는 단어를, 정작 나 스스로는 만들지 못했구나.

…라는 자책이 컸다.

왜 그랬을까, 나는.

자책

올해의 나를 짓누른 단어는 자책감이었다.

무엇 하나 나 때문이 아닌 것이 없더라. 대통령도 아닌데 우습지. 내가 뭐라고.

일이 느려지는 것도, 동료들간에 갈등이 생기는 것도, 누군가에게 험한 말을 듣는 것도. 결국 다 나의 부족함 때문이었다. 힘들더라.

‘아… 나의 인격은 여기까지였나’라는 생각이 어찌나 자주 들었는지 모른다.

물론 더 성장하기 위한 현실인식의 최소치를 경험한 것도 같다.

내가 뭘 못하고 있는지 알고 싶었는데, 꽤 잘 안 것 같다.

그것이 소득이라면 소득이다.

성취감

가장 부족했던 것이 성취감이다. 사실 2022년의 나는 아무런 성취감을 느끼지 못하며 살았다.

부모님에게 부끄럽기도 했다. 이러려고 나를 응원하신게 아닐텐데 하며.

흥미로운게, 나를 관찰하는 사람들은 내가 무척 성취감을 느끼며 살거라고 생각하고 있었다. 외연은 분명 확장된게 있다. 그런데 그것은 결국 한 회사 안에 국한된 이야기이지 나 자신이라고 말하기엔 무리가 있었다.

회사가 아닌 나 자신은 무엇일까. 직업인에서 직장인이 되었고, 그 직장이어야만 나의 의미가 강해진 것 같은 종속감을 견디기 무척 힘들다.

코딩에서도 부쩍 멀어졌다. 뜨문뜨문 해보고, 감각을 잊지않으려고 발버둥쳐보기도 한다.

성장

나는 ‘왜 꼭 성장을 지향해야 하나’라는 생각을 올해 한 것 같다. 지금도 마찬가지다.

그만 성장성장 하고 싶더라.

어쩌면 번아웃을 매일 겪으며 살았던 것 같다. 2023년은 다를까.

변곡점

변곡점을 만들려면 환경을 바꾸는게 가장 쉽다던데. 그것을 무엇일까.

이 글을 쓸 때는 고민했는데, 새 해부터는 서현으로 출근한다. 환경이 (강제로?) 바뀐 셈이다. 서현오피스는 사람이 적고 아주 조용하며, 인테리어는 1784의 회색과 삭막함과는 달리 나무와 흰색의 인간적이고 자연스러운 느낌이 테마라서 심적으로도 더 좋은 기분이다.

2023-01-02 출근한 서현 사무실에서.

2023년의 나는, 변곡점을 만들 수 있을까.

그런데, 어디로 변하는 변곡점일까. 그것조차 지금은 별로 생각이 나지 않는다.

문법

나 자신이 자주 말하는 단어가 점점 보였다. 그러니까, 나의 철학이 만들어지고 있다.

프로덕트, 유저, 팀.

평소에 위의 세 단어만 말하곤 하고, 위의 세 단어만 생각하곤 한다.

또한, 팀에 말하는 문법이 몇 가지 고정적인게 생겼다. 그러니까, 나만의 팀 매니징 철학이 만들어지고 있다.

집중, 변곡점, 컬러.

위의 세 단어를 가장 많이 말한 것 같다.

한 명 한 명이 자신의 컬러를 가지고 집중하길 바라고, 팀에 있으면서 자신의 변곡점을 만들길 바란다는 말을 거의 모두에게 공통적으로 말하곤 한다. 컬러는 곧 표현을 의미한다. 모두가 자신의 컬러를 가지고 그것을 자신만의 전문성과 방법으로 표현하기를 바란다.

희망

뭐라도 좀 희망적인 얘기로 이 글을 마무리 하고 싶다.

그래도 몸이 아프진 않았다. 코로나는 겪었지만 별로 아프지 않고 넘어갔다.

일본을 자주 가며, 그래도 2개월 전, 4개월 전, 6개월 전보다는 좋아지고 있다.

처음으로 자체적으로 팀을 셋업했다. 50명 단위 팀의 변곡점을 그럭저럭 잘 넘기고 있다.

일본어 책 한 권은 다 봤다. 새롭게 NHK 책을 보는데 재미를 붙이고 있다.

독서를 많이 하지는 못했다. 새해부터는 서현으로 출근하는데, 지하철에서 책을 자주 보겠노라 다짐한다.

무례함을 줄이고, 웃음을 늘려야지.

올해 가장 기억에 남는 말이라면, 미래의 나는, 매일의 내가 대답할 것이라는 말이다. (YouTube 4:05)

희미한 빛

희미한 빛을 쫒아가라는 상사의 조언이 있었다.

그래도, 분명한 목표는 하나 있다. 턴어라운드. 정확히 20년 전에 ‘우리는 기적이라 말하지 않는다 (교보문고)‘라는 책을 보고 꿈꾸던거다.

몰입의 상실

오늘은 여느 때처럼 0시 즈음에 잤다가 갑자기 새벽 2:30에 깼더랬다.

왜 이렇게 정신이 말끔할까 고민도 잠시, 창 밖에 지나가는 차도 구경하고 아무 생각 없이 식탁에 앉아서 멍하니 있었다.

그렇게 한동안 앉았다서다 깨달았다.

‘아… 내가 무언가 몰입할게 없구나’

입사 즈음이든, 그 전에 무언가를 만들 때든, 나는 종이조각이나 화이트보드에 늘 무언가를 설계했다. 많은 다이어그램을 그렸고, 글자를 썼고, 화살표를 그리며 작든크든 무언가를 열심히 그려냈다.

그게 없어졌다.


아침에 말했다.

“내가 새벽에 갑자기 일어났는데 말야… 머리가 너무 맑은거야.”

“뭐라도 하지 그랬어”

“…그게 없더라. 몰입할게.”

“그건 큰 일이네…”

“자긴 지금 스타트업 일로 머리가 가득 차 있잖아”

“그렇지”

“근데 난 그런게 전혀 없는걸 깨달은거 있지. 일은 많아… 근데 회의 끝나면 아무 생각이 안나. 심지어 그 회의가 무엇을 위한 것이든 그 후로는 더 이상 몰입하고 싶어하지도 않고 있어”


적어도, 이번 설 연휴에 뻔뻔하게 쉬는 동안 내가 뭘 잃었는지는 알았다.

내가 몰입할 것은 무엇인가.

2021 회고

사실 비공개로 개인적인 회고를 하나 썼는데, 내용이 너무 다크해서 차마 공개하진 못하겠더라.

마냥 2021년이 나에게 다크했냐고 묻는다면, 사회적인 시선으로는 그렇지 않다. 아주 많은 성취를 한 해라고 보일 수는 있겠다.

사회적인 성장

팀은 10여명에서 50여명이 되었고, 곧 조직개편으로 (원하지 않아도) 100여명이 될 예정이다. 그 사이에 스케일 업/아웃이 동시에 된 셈인데 나름 안정적으로 했다는 생각이 든다. 동료들에게 무한히 고마운 한 해였다.

직접적으로 대화하는 상사는 7명에서 13명이 되었고, 그만큼 새롭게 알게 된 분들의 개성을 또 배워가고 있다. 내가 여러 상사와 대화하는건 이 회사가 매트릭스 구조라는 특성과 내가 가진 중간관리자라는 포지션 때문인데, 나 같은 경우가 얼마나 많은지는 잘 모르겠다. 중간관리자는 대체로 많은 상사와 커뮤니케이션을 하는건 맞겠다.

임원 초년차를 지냈다. 한가지 달라진게 있다면 위의 상사들과 대화를 많이 해서인지 횡적인 지식과 판단이 폭발적으로 늘었다는거다. 여러 법인과 조직의 모든 이해관계 사이에서 퍼즐을 맞추고 체스를 두는 일들이다. 어릴적부터 체스든 장기든 바둑이든 지뢰찾기든 영 소질이 없었는데 어쩌지 싶다.

큰 회사에서 보다 깊은 의사결정 자리에 초대받은건, 내가 이 회사 안다니면 만나주지도 않을 훌륭한 분들 사이에 껴있다는 것만으로도 가치있는 경험이다.

끝으로, 계열사 중 하나인 조단위 상장사의 C레벨 셋 중 하나로 임명되었다. 나에겐 중요한 마일스톤이라는 생각을 한다.

아참, ‘개발자에서 아키텍트로 [클릭:교보문고]‘ 번역서 출간과 중쇄 경험은 꽤 기분 좋았다.

성장의 정의를 잃다

아쉽게도 2021년동안 나는 뭐가 성장했는지 모르겠더라. 내적으로.

솔직히 말해서 너무 너무 스트레스를 심하게 받은 한 해였다. 정신적으로 건강하지 못했다. 스트레스를 너무 받다못해 왜 받는지조차 모를 정도에 빠졌더랬다 – ‘나 왜 스트레스 받는거였지…?’

어쩌면 나 스스로가 무엇으로 성장을/재미를/행복을/성취를/만족을 느껴야 하는지 잃어버려서이다.

과거엔 나름 소소하게 말할 수 있었다. 디버깅에 기어코 성공했을 때, 만든걸 자랑했을 때, 릴리즈해서 반응이 좋을 때, 장난감 같은 십만원 정도의 가젯을 사서 놀 때, 페북에 뻘글 쓸 때, 가끔 컨퍼런스 갔을 때, 피아노 곡 하나를 잘 외워서 칠 때, 어학 실력이 늘었을 때, 맘에 드는 책을 휘리릭 읽었을 때, 주말마다 서점에 갔을 때, 카페에 가서 두 시간 멍때리다 왔을 때, 동료들과 시덥잖은 농담을 하며 막걸리를 먹었을 때 등등…

윗 문단에서 말한 근 10년 정도 행복을 느꼈던 모든 것을 2021년에는 전혀 못했다. 코로나 때문에 카페에 오래 편하게 있지도 못했고, 동료들도 자주 못보니 시덥잖은 대화도 못했고, 코딩할 시간도 못냈고, SNS에 글 쓰는 것도 댓글 때문에 피곤한 경우가 많아서 거의 안썼다.

그래서 나 자신을 잃었던거 같다. …어떻게 찾지?

2022 키워드 – 시간의 낭비

일단, 나 자신을 압박하는 것들을 적극적으로 줄이는 한 해가 되면 좋겠다.

그래서, ‘일일커밋’이라는 오픈채팅방에 가입했다가 제대로 활동도 못하고 커밋 종용하는 메시지만 쌓여있었는데 새해가 되면서 탈퇴했다. 일본어도 한 해 내내 월수금 했는데, 한 달 쉬겠다고 하고는 중지했다. 그렇게 나 자신이 ‘해야지 해야지’ 했던 것들부터 그냥 아이얘 적극적으로 안하고 말자는 생각을 할까 싶다.

나 외의 사람들과의 약속을 지키는 것도 여력이 없는데 나 자신과의 약속까지 지키려니 그것이 나에게 부담이 컸다고 생각해서, 나 자신의 Gap Year 비슷한걸 좀 보내보면 어떨까 싶더라. 이건 내가 올해 받은 코칭프로그램에서 hogan 이라는 성격테스트(?) 같은걸 받았는데, 여러 수치 중 “완벽주의 100%”가 나와서 이것이 나 자신을 너무 힘들게 한다는 생각을 스스로 해서이다.

연말에 혼자 인천 네스트호텔에 노트북도 안가지고 책만 여러권 들고 가서 죙일 읽고 쉬다 온 적이 있다. 평범한 수요일에. 그 기억이 참 좋더라. 그래서 앞으로는 한두달에 한 번 정도는 호텔에 쉬다 올까 싶다.

그렇게, 자주 멍때리고 쉬고 아무 것도 안하는 시간을 뻔뻔하게 가지고 싶다.

LG WING 사용기

갤노트10을 잘 쓰다가 LG WING으로 바꾼지 2주 정도 되었다.

어떤 핸드폰을 썼는지 기록해놓으면 나중에 추억거리도 되더라. 이 글은 제품 개선 방향에 대한 내용도 있으니 개발팀이 보면 좋겠다는 생각도 든다.

LG Wing open main interface
출처: https://www.androidauthority.com/lg-wing-price-release-date-verizon-1162981/

여담으로, 현재 시점에 가장 밸런스 좋은 안드로이드 휴대폰은 (S20, 노트20가 출시했음에도) 노트10이라고 생각한다. 좋은 무게, 좋은 크기, 빠른 카메라, 좋은 성능, 256GB 용량, 노트 고유의 펜 경험 등.

평범한 유저치고는 LG폰 많이 쓴 편이다. G, G2, V30을 모두 2년씩 썼다. 그 사이사이에 아이폰 4, 6S, X를 썼다. V30은 매우 만족했지만, 딱 하나 때문에 바꾸었는데 그게 카메라였다. 지옥같이 느린 카메라 속도였다. 셔터를 누르면 3초 즈음 후에 찍힐 때가 있는데 가끔 이 버그가 걸리면 너무 화가 나곤 했다. 그런데 끝까지 안고치는거 같더라. 사실 그 외에는 완벽했던 폰이라고 생각한다. 하지만 휴대폰이라는건 단 하나의 몹시 마음에 안드는 것 때문에 돌아서게 한다.


나는 Android 개발자로서 stackoverflow 은메달을 가지고 있으니 평균 이상의 기술적인 이해도는 갖추고 있다고 본다.

나의 stackoverflow badge: https://stackoverflow.com/users/361100/youngjae?tab=badges

제품에 대해 사람들은 긍정/부정이라기보다는 의구심을 더 많이 가지고 있다. 새로운 폼팩터는 어떤 새로운 사용성을 줄까.

나 역시 새로운 폼팩터가 주는 경험을 하고 싶었다.


가장 기대했던 사용성은, 유튜브를 가로로 보면서 채팅이나 업무용 앱을 보는거다.

그리고 기대했던 시나리오대로 쓰고 있다. 짐벌기능의 동영상 촬영도 꽤 쓸만하다. 가로로 촬영할 때 편하게 잡을 수 있어서 좋다. 짐벌모드일 때 소프트웨어 크롭방식이라 화질이 자글자글한게 거슬리지만, 첫 버전으로는 용납할 수 있는 수준이라고 생각한다.

노트 10보다 확연히 느껴지는 의외의 장점은

  1. 화면에 카메라 펀치홀 없이 온전한 사각형으로 보이는게 이렇게 시각적 청량감을 주는지 몰랐다. 화면이 정말 좋다.
  2. 둘 다 스크린 지문인식인데 인식률이 노트10보다 무척 좋다. 노트10은 제품하자에 가까운 인식률을 가지고 있다.

뜬금없이 유용하게 쓰는 모습은 아래와 같다.

위: 어학반복학습기, 아래: 네이버사전

나는 매일 일본어 공부를 하는데 어학공부하기에 꽤 좋다. 기존에는 어학 mp3 실행하다가 사전 찾을 때 꽤 귀찮았다.


하지만 궁극적으로는 폰을 점점 멀리하게 되었다. 디지털 디톡스를 강제로 하도록 만드는 폰이다….

그 이유는.

너무너무 무겁다

260g이라는데, 주머니에 넣기엔 무겁고 들고 다니자니 어깨에 통증이 생겼다. 노트10은 168g이고, 무거워서 안되겠다고 생각하던 노트9은 201g이다. 나에겐 180g 정도가 폰을 들고 다니는 한계일듯 싶다.

침대에서 폰을 보는 재미도 없어졌다. 무거워서 얼굴 위로는 못들고, 옆으로도 어깨와 손목이 아파오기 때문에 이제는 그냥 일찍 끄고 잔다.

다음 세대가 나온다면 30g 정도는 줄이는걸 1순위 목표로 해야 한다고 본다. 물론 어렵다는거 안다. 하지만 이처럼 변신하는 폼팩터에서 정답같은 수준의 무게감은 220~230g 정도여야 할거다.


무게는 하드웨어 요소니까 어쩔 도리 없고, 소프트웨어에 집중해보자.

V30 때 끔찍하게 느렸던 카메라였기에 걱정했다. WING은 노트10보다는 느리지만 그래도 괜찮게 동작한다.

소프트웨어의 단점은 세 가지다

모두 세컨드스크린에 대한 내용이고, LG가 관심만 있다면 쉽게 개선할 수 있다.

  1. YouTube 재생 중에 세컨드스크린의 미디어 콘트롤러가 안뜰 경우가 심심찮게 있다. 원래는 미디어 전용 콘트롤러가 떠야 하는데, 이 버그 때문에 안뜨면 내가 화면을 돌릴 이유가 없다.
  2. 세컨드스크린의 미디어플레이어에 Progress Bar가 없다. 영상 볼 때 제일 중요한 정보 중 하나가 시간인데, 그게 왜 안뜨는가 싶다. 이상적으로는 좌상단에 시계를 노출하고, progressbar도 어딘가에 나와줘야 한다. 자꾸 본화면을 터치하여 재생시간을 확인한다. 이거 구현도 어렵지 않다.
  3. 세컨드스크린의 미디어플레이어에서 설정을 누르면 ‘스위블 모드에서 화면 확장’이라는 설정메뉴가 뜬다. 여기서 백버튼을 누르면 우습게도 오른쪽>왼쪽 슬라이드하는 화면전환 효과가 적용되는데 이게 무척 혼란스럽다. 백을 눌렀는데 오른쪽에서 새로운 페이지가 들어오는 느낌이라니. 내가 무슨 화면에 있는건지 한참 헤매었다.

이 단점 때문에 화면을 돌릴 가치가 떨어지고 있다. 동영상을 볼 때 화면을 돌릴 가치가 떨어지면, 이 무거운 폰을 써야 할 이유 역시 줄어든다.

소프트웨어에 장점도 있다

아이폰X를 같이 쓰고 있는데, 아이폰과 완벽히 동일한 제스처 시스템을 가지고 있다. 아래에서 스와이프하여 홈으로 가거나 다른 앱으로 전환하는거 말이다.

심지어 백버튼을 좌측/우측 양면에서 스와이프를 제공해서 아이폰보다 사용성이 낫다. 밑에서 쓸어올릴 때의 멀티태스킹은 아이폰만큼 부드럽진 않지만 꽤 잘 된다. 백버튼 제스처 인식은 아주 잘되어서 만족스럽다. 노트 10에 없는 장점이다.

또한 LG 홈은 꽤 좋다. 원래 Microsoft Launcher를 사용했는데, 굳이 그럴 필요 없을 정도로 괜찮다.

노트10에서 그리워하는 기능은 빅스비 버튼이다. 빅스비버튼을 꾹- 누르면 워키토키처럼 음성입력 키보드가 뜨는데, 이게 그렇게나 유용했다. 전원버튼을 롱클릭할 때의 옵션이 있다면 좋겠다.

참고로, 빅스비 버튼을 끔찍히 싫어하는 사람들도 많은데, 그건 전원버튼과 함께 있을 때의 혼란이었다고 본다. 예를 들어, 노트9은 전원버튼이 별도로 있어서 많은 유저들에게 불평을 들었지만, 과감하게 전원 버튼과 통합한게 노트10의 멋진 한 수다.

다음 버전을 개발할 가치가 있을까

새로운 폼팩터로서 가치가 있는가? 있다고 생각한다.

“영상 볼 때 훨씬 즐거운 폰”, “동영상 찍을 때 특히 즐거운 폰”이라는 포지셔닝으로는 독보적인 위치를 차지할 수 있으리라 생각한다.

  • 무게를 줄이고 (가장 중요)
  • 화면의 종축을 조금 줄이고 (지금은 영상볼 때 레터박스가 너무 크다)
  • 짐벌모드의 자글자글한 영상 품질을 좀 더 개선하고
  • 스테레오 스피커를 장착하면

이 폰만의 장점을 더 강하게 어필할 수 있으리라 생각한다. 그리고, 지금 시대는 이 강점에 매력을 느낄 소비자가 잘 마련되어 있다.

사업을 한다는 것

사업을 한다는 것

사업을 한다는 것

레이 크록 저/야나이 다다시, 손정의 해설/이영래

소프트뱅크회장 손정의와 유니클로 회장 야나이 다다시가 인생바이블로 선언한 책손정의 VS 야나이 다다시 대담 수록소프트뱅크 손정의와 야나이 다다시 유니클로 회장이 ‘인생 바이블’로 꼽는 책이 있다. 일본 산업계의 두 거물은 입을 모아 그 책의 주인공을 동경하는 마음으로 각자의 사업을 일으킬 꿈을 꾸었다고 말…

페이스북에 이 책을 추천한다는 글을 몇 번 보고 그대로 구매했다.

1과를 읽기 전까지는 맥도날드 창업자의 자서전이라는 것조차 몰랐다. 책 표지 어디에도 맥도날드 글자가 없다. 나는 유명인들이 사업가의 마음가짐에 대해서 모아놓은 책인 줄 알았다.

책 읽으면서 드는 생각은 조 지라드의 자서전 ‘판매에 불가능은 없다‘를 읽을 때와 비슷한 감성이 느껴진다는 점이었다. 뭐랄까, 직관과 임기응변과 수십년 전 아메리칸드림에 편승한 고집센 사람의 성공스토리랄까.

지독하게 독단적인 사람의 성공스토리. 하지만 성공하면 이런 책을 써도 될거다.
자신이 구단주인 야구장에서 마이크를 잡고 고래고래 소리지르고 그에 대해 떳떳하다고 책에 쓸 정도로 아무도 토 달지 못하는 성격의 소유자가 될 수도 있지만 말이다.

이 책에서 도움 받은건 인재 채용에 대한 내용들이다.
책에서는 우연히 만난 사람들과 그 사람들과 일하는 에피소드의 연속이지만, 각자의 특징에 대해 꽤 자세히 묘사하고 있다. 좋은 사람을 끌어당기는 한편, 맞지 않는 사람을 내보내거나 싸운 내용도 많이 있다.

이 책의 1과를 읽고 ‘뭐야, 자서전이었네’라며 내 기대와 엇나갔음에도 다시 읽게 한 동기이기도 하다. 내가 채용에 대해서 근심할 때 우연히 책상 위에 있던 이 책에서 펼친 페이지가 나름의 의미를 줬기 때문이다.

나는 그가 우리와 맞는 사람이 아니라는 것을 직감적으로 알았다. (…) 문제의 인물은 계속해서 살아남았다. 몇 번이나 해고될 위험에 처했지만 자리를 옮기거나 새로운 상사를 만나는 식으로 위기를 넘겼다. 예의 바른 사람이다보니 새로운 상사는 매번 그를 바꿔놓을 수 있다고 생각했고 그렇게 하기 위해 공을 들였다. 수년이 흐른 뒤 그는 결국 해고되었다. (…) 중요한 것은 그에게 들인 우리의 시간과 노력이 낭비되었다는 점이며, 더 중요한 것은 그가 결국 막다른 길로 판명난 일에 인생의 소중한 몇 년을 보냈다는 사실이다. 차라리 일찍 해고를 당해서 적성에 더 맞는 다른 일을 찾았더라면 경력에 훨씬 도움이 되었을 것이다. 양쪽 모두에게 불행한 결과였다. 이 일을 통해 알 수 있는 한 가지는, 아무리 기민한 판단을 내릴지라도 다른 사람들에게는 그것이 독단으로 비칠 수 있다는 것이다.

page 182-183

실제 맥도날드 본사의 직원 수가 얼마나 빠르게 증가했는지는 모른다. 다만 꽤 적은 수의 직원들이 아주 오랫동안 일해온 것으로 읽힌다. (프랜차이즈 업은 본사 직원이 규모에 비해 적다고도 써있다)

언제나 경영을 할 때 고민하는게 하나 있다 – ‘나 자신의 직감을 얼마나 믿어야 하는가?’

어릴 때 직감만으로 성공한 사례들만 접하다가 시간이 흐를 수록 실패한 경우를 너무 많이 봐왔기 때문에 직감을 믿는 것에 겁이 나는 것도 사실이다. 그래서 이성적으로 보이기 위해 데이터를 (사실은 자기 직관에 맞게 요리해서) 논거랍시고 활용하는 것이 요즈음 대부분의 직장인들이다.

이 책은 한편으로 이런 고민에 대해 ‘괜찮아. 직감 믿어도 괜찮아’라고 풍선을 불어주는 것만 같다. 다가오는 새 해에는 보다 직감에 많이 귀기울여볼까 한다.

Xamarin 과연 쓸만한가

Xamarin은 한마디로 애증의 기술입니다.

WebView를 이용하는 하이브리드앱 기술이든 중간자를 이용한 Xamarin 같은 멀티플랫폼앱 기술이든 5년 내내 개발자들과 CTO들을 갈등하게 만듭니다.

▲ Xamarin과 Blockchain 연동이라지만 그냥 Azure Blockchain WebAPI 용례입니다. 속았잖아!

Xamarin의 장점은 하이브리드앱 보다 네이티브API 연동이 더 직관적이고, 단점은 안드로이드/iOS 둘 모두 중급의 실력을 필요로 한다는 것입니다. ‘네이티브로 컴파일된다’는 기치를 걸고 있는 ReactNative, NativeScript는 Xamarin보다 복잡도가 더 높다는 생각이 듭니다. 저는 그래요.

왜냐하면 네이티브 프로그래밍에 가까운건 C# 코드와 1:1 변환 수준인 Xamarin과 HTML+JS+CSS를 동원하는 다른 것들과는 중간자의 복잡도에 있어서 시작부터 게임이 안되거든요. 아키텍처 관점에서의 논리랄까요.

JS기반 하이브리드앱 프레임워크(대표적으로 Cordova, Phonegap)들은 네이티브 연동을 위해서는 npm 모듈이 나올 때까지 멍때려야 하는 경우도 있지만 양쪽 플랫폼 모두 중급의 실력까지는 필요 없다는 점이 장점입니다. 뭐 실력이 좋으면 직접 모듈을 작성하면 되겠지만 하이브리드가 아닌 경우에는 ‘그냥’ 되는걸 굳이 왜그래야하나 싶은 생각이 들기 마련이죠. 특히 비슷한 기능의 npm이 여러개인데 뭐가 좋은지 어디까지 믿어야 하는지 고민할 때마다 ‘내가 지금 왜 하이브리드앱을 선택했다는 이유로 이런 것에 시간을 써야하나’싶죠.


저는 클라이언트 개발에 있어서 언제나 네이티브 주의자인데, 요즘은 ‘평범한 소셜 앱서비스’ 정도는 하이브리드로 최대한 버티려는 마음도 있습니다. 특히 다른 분들에게는 하이브리드를 추천합니다. 왜냐하면 저희 팀처럼 보폭을 착착 잘맞추는 팀은 많지 않기 때문입니다.

그래도 여전히 Xamarin을 눈여겨보는 이유는 양쪽 플랫폼의 발전에 꽤 빠른 속도로 따라가고 있는 점을 높이 사기 때문입니다. 예를 들어 지문인식 API 등 OS에 강하게 결합하는 API의 지원은 여느 하이브리드앱보다 빠르게 대응해왔습니다.

Xamarin의 인기가 적은 이유는 두가지라고 생각합니다.
멀티플랫폼 모두에 대한 중급 이상의 실력이 필요: Microsoft는 외계인들이 많겠지만, 평범한 회사는 둘 중 하나만 잘하거나 둘 다 못하는 개발자들이 대부분이죠.
훌륭한 설계가 필요: Microsoft는 IT 역사에서 가장 아키텍처링을 잘 하는 회사입니다. 하지만 대부분의 IT회사는 하루하루 먹고살기 바빠서 아키텍처에 쓸 시간이 부족하고 언제나 레거시에 허덕이고 있습니다.


그런데 요즘 하이브리드, 멀티플랫폼 모두 의미없게 만드는 경향이 작년부터 강하게 밀려옵니다.

다름 아닌, kotlin/swift 언어인데요. 공교롭게도 두 언어의 느낌이 비슷~합니다. 그러다보니 많은 개발자들에게 언어간 적응력이 뛰어납니다. 이제는 Android/iOS 양측의 이해도만 적당히 갖추면 두 언어를 오가며 개발하는 것도 큰 불편이 없어질거라 생각합니다.

여러분이 앱개발자라면, 2019년에는 완전히 kotlin/swift로 전향하는 것을 목표로 하길 권합니다. Xamarin은 XAML Standard가 성숙한 다음에 고려하는 것이 맞겠습니다.

Keras + CNTK Backend

얼마 전에 Keras로 RNN을 구현할 일이 있었습니다.
문제는 아래와 같이 LSTM을 적용하는 부분이었는데요.

model = Sequential()
model.add(LSTM(128, input_shape=(SEQUENCE_LENGTH, len(incoming_list))))
# fully connected layer with softmax activation for classification
model.add(Dense(len(incoming_list)))
model.add(Activation('softmax'))

위 코드에서 while_loop() got an unexpected keyword argument 'maximum_iterations' 에러가 발생하는데, tensorflow backend 코드를 봐도 딱히 문제를 모르겠더군요.

▲ 봐도 모르겠더라. Tensorflow도 구글스럽게 버전별 호환성은 나쁜 듯.

tensorflow backend에서 input_sharp=(...)input_dim, input_length로 나뉘는 것을 **kwargs로 퉁쳐서 입력받는 것이므로, input_dim, input_length으로 나누어 입력했더니 이번엔 IndexOutOfRange 에러가 발생했습니다. 수치적으로만 보면 에러가 날 이유는 없었는데 말이죠.

이와 같은 에러는 구글링 이곳저곳에서 찾을 수 있었는데, 표면적인 원인은 그저 TF/Keras 버전이 안맞는 문제였습니다. 저는 Keras repo의 여러. 이슈.에서 말하는 버전들로 바꿔봐도 문제가 해결되지 않았지만, 해결되었다해도 일부러 Tensorflow/Keras 둘 모두 구버전으로 쓰고 싶지도 않았습니다. 신버전 적용을 두려워하면 영원히 업데이트를 못할 수도 있거든요. (참고로 글쓴 시점 기준 최신은 keras 2.2.4, tensorflow 1.13.1 입니다)

결국 TF backend는 몇 시간동안 버전 이것저것을 맞춰보다 포기하고 CNTK backend를 시도해봤습니다. CNTK backend 적용 방법은 https://docs.microsoft.com/en-us/cognitive-toolkit/Using-CNTK-with-Keras 링크대로 keras.json을 수정하고 환경변수만 하나만 적용하면 잘 됩니다.

결과는 성공적이더군요! 별 일없이 잘 돕니다. 이래야지.

Keras RNN을 적용하다가 저와 같은 에러가 난다면 CNTK backend를 시도해보세요 🙂

▲ 지금 우리가 iteration 한두번 더 해보는게 중요하지 backend가 뭔 상관이겠어요

Azure Service Fabric Mesh는 아직 애매하다

개발자라면 누구나 마음 속에 두고 있는 신기술이 있을겁니다.

“언젠가는 꼭 써보고 싶다”

위와 같은 소망을 담고 말이죠.
저에게는 Service Fabric이 그렇습니다.

Service Fabric은 K8S+Akka+PaaS의 특징이 결합한 형태라고 생각하면 됩니다. K8S, Akka를 그대로 쓸 수 있다는 뜻은 아니고 Container Orchestration, Routing/Scaling/Healing, Infrastructure Virtualization, Actor Model 등을 도입할 수 있다는 겁니다. 좀 더 간단한 표현으로는 “MSA(Micro Service Architecture) 종합선물셋트”입니다. 아래는 Service Fabric이 막 고개를 들기 시작할 때 제가 발표했던 자료입니다.

Service Fabric을 실서비스까지 적용해보지는 못했지만, 시험적으로 사용해봤을 때 많은 매력을 느꼈습니다. 매력 중 하나는 Reliable Collections였습니다. 웹기술의 대부분은 stateless만 고려합니다. 즉, 같은 클라이언트가 요청해도 과거의 접속과 상태를 유지하는 것이 아니라 새로운 요청을 가정한 후, 클라이언트가 부수적으로 주는 쿠키 등 정보 조각을 이용하여 과거와 같도록 만든 것이지 원론적으로는 과거의 요청과 새로운 요청은 무관합니다.

과거의 요청과 새로운 요청을 잇기 위해 여러 단계와 과정이 있는데, 최종적으로는 DB까지 요청해서 확인을 하곤 하죠. 즉, 어플리케이션 로직과 무관하게 DB가 사라지면 어플리케이션이 바보가 되는 형태가 흔한 웹서비스의 3-tier architecture 입니다. (과거 값 + 1) 로직에 대해 ‘과거 값’을 DB에 의존해야 하는거죠. 어느새 우리가 너무 자연스럽게 3-tier 구성을 사용하다보니 ‘DB가 없으면 어플리케이션이 바보되는건 당연한거 아냐?’라고 생각하고 있었습니다. 하지만, 어플리케이션이 충분히 견고할 때는 DB가 필요없을 수도 있다고 생각한 것이 Service Fabric의 철학입니다.

Reliable Collections는 어플리케이션의 replica에서 정보를 계속 유지해서 이 문제를 해결합니다. 그 정보는 메모리일 수도 디스크일 수도 있고요. 그래서 데이터가 어플리케이션 로직 안에 하나의 자료구조 변수처럼 존재합니다. 흔한 ORM들이 ‘DB를 마치 하나의 자료구조 변수인 것처럼’ 인식시키는 개발 경험을 주지만, DB가 사라져도 자료구조 변수와 그 값이 온전히 남아있지는 않습니다.


다시 본론으로 와서, Service Fabric Mesh는 Service Fabric을 보다 가상화해서 Serverless(?: 개인적으로 이 표현을 좋아하지 않습니다) 경험을 줍니다…라고 생각했지만, 의외로 제가 위에서 강조한 Service Fabric의 강점과 큰 상관이 없어보입니다. Mesh 관련 피드백에도 “Reliable Collections 지원이 안되면 의미없음“이라고 유저피드백이 있네요.

▲ 인프라 설정을 json/yaml로 다루는 경험은 대안이 많은데…

대신 Mesh의 의도는 MSA 다수의 어플리케이션을 WebApp 배포처럼 쉽게 올릴 수 있도록 하는 것으로 보입니다. 다만, 위 영상의 인프라 구성 파일(json)을 보면 이것만의 강점이 뾰족하지는 않아보입니다.

즉, Mesh는 아직까진 Service Fabric의 인프라(auto healing/routing 등) 취급 경험만 의미하는 것으로 보입니다. 그래도 Reliable Collections 지원이 언젠가는 이뤄질테니 그 때까지는 기다려봐야 겠습니다.

Five Things 시리즈 소개

IT 개발 기술에 대한 트렌드를 빠르게 짚어주고 영어회화 공부도 되는 YouTube 영상을 소개합니다.

▲ Five Things 시리즈

Five Things의 내용은 ‘최신 하이브리드앱 프레임워크 5개’ ‘최신 IoT 키워드 5개’ 등 Five Things 이름에 맞게 뭐든 5개로 정리해서 나눕니다. 농담따먹기가 20% 넘으니까 영어회화를 익힐 겸 봐도 좋습니다. 이 영상에 나오는 정도는 해야 기술을 주제로 영어로 편하게 대화나누는 수준일테니까요.

MSDN YouTube 공식채널 중 하나지만, 참석자들이 Google, Facebook, Netflix 등 가리지 않고 나오는 점이 좋습니다. 진행자는 Burke Holland (클릭:트위터계정) 외에 AngularJS로 유명한 John Papa 등 Javascript 분야로 활발한 활동을 하던 분들이 돌아가면서 합니다.

그래서인지 Javascript스럽게(?) 정체성 따위 없이 다양한 분야의 지식을 떠들석하고 빠르게 소개합니다. 다루는 내용도 JS 비중이 높은 편입니다.

제 경우 관심있는 기술분야에 대해 Five Things 시리즈에 있는지 찾아보고 연관 검색어에 대한 힌트를 얻곤 합니다. 이 시리즈에 나오는 내용은 ‘어디가서 기술영업만 하는게 아니라 매일매일 코딩하는 사람들’을 대상으로 하기 때문에 거창한 홍보문구 따위가 아닌 실제로 사용하는 프레임워크나 기술 이름을 말하거든요.

YouTube 재생목록을 보면 이 글을 올린 현재까지 42개의 영상이 올라와 있네요. 여러분도 한 번 쭉 훑어보고 관심있는 주제를 재생해보세요.
– 재생목록: https://www.youtube.com/playlist?list=PLlrxD0HtieHgugDxYBujMFnvSveH4fgWN

Azure WebApp in 2018

Azure에 아무리 많은 서비스가 있지만, 그 중에서 가장 빈번히 사용되는 것 중 하나는 WebApp일겁니다. 물론 IaaS 기반의 회사들은 VM에 WAS 설치해서 쓰고 있겠지만, 평범한 웹서비스 회사는 WebApp만으로도 대부분 큰 불편없이 상용 서비스를 하고 있습니다.

Azure WebApp

WebApp은 Azure가 AWS보다 후발주자로서 AWS를 단숨에 뛰어넘을 히든카드 중 하나였습니다. 그 단숨에 뛰어넘는 전략으로 PaaS 최우선 정책을 가졌는데, WebApp은 PaaS의 핵심 제품이었기 때문입니다.

그리고 실제로 그 전략은 잘 먹혔다고 봅니다. Azure WebApp을 경험해본 사람들이 다른 유사서비스들을 써보고는 ‘이건 PaaS가 아닌데’ ‘PaaS라며 왜 이래’ ‘PaaS답게 만들었지만 PaaS라서 불안한건 싫은데’ 등등의 불평을 했거든요.

WebApp의 시작은 간단했습니다. ‘클릭하면 나오는 WAS(Web Application Server)’ 그 이상도 이하도 아니었습니다. 그러다가 웹 서비스를 둘러싼 다양한 요구사항을 받아들여서 이제는 메뉴가 정말 많아졌습니다.

Git연동으로 자동배포하는건 기본이고, Let’s Encrypt 연동도 내부 확장기능으로 지원하고 있지요. 평범한 웹서비스를 만든다면 DB/Storage 외에는 별다른게 필요 없을 정도입니다.

▲ 아직 WebApp을 써본 적 없다면 이 영상으로 감을 잡아보세요

이 글에서는 2018년 동안 WebApp의 변화로 어떤 것이 있는지 살펴보겠습니다.

My SQL in-app data import

WebApp 자체적으로 작은 MySQL DB를 운영할 수 있습니다. 이를 위한 DB import/export 기능입니다. in-app DB 사용시 주의할 점은 어디까지나 in-app에 충실하므로, 웹서비스를 중지시키면 DB도 중지된다는 사실입니다.

https://blogs.msdn.microsoft.com/appserviceteam/2017/03/06/announcing-general-availability-for-mysql-in-app/

HTTP/2 support

HTTP/2는 최신 OS와 브라우저들이 안정적으로 지원하기 시작했으며, IoT에서도 점점 수요가 일어나고 있습니다. HTTP/2의 장점은 여러가지지만, 그 중에서도 연결 유지와 TCP/IP 커넥션 하나로도 여러 요청에 대응할 수 있다는 점을 꼽습니다. WebApp도 이에 맞춰서 작년 초부터 HTTP/2를 지원하기 시작했습니다.

https://blogs.msdn.microsoft.com/appserviceteam/2018/04/13/announcing-http2-support-in-azure-app-service/

Linux, Docker, K8S support

작년에 WebApp의 가장 큰 변화를 꼽으라면 바로 이것이죠. 제 기준으로는 기존 WebApp은 Python에 대해 WebApp Extension으로 지원해서 셋팅부터 구동까지 좀 불편했는데, Python으로 만든 Docker를 WebApp에 그대로 불러와서 올리게 되었기 때문에 정말 좋아졌습니다.

Kubernetes Pod Definitions, Docker Compose yaml 파일을 WebApp에 적용할 수 있다고 하네요. 저는 안써봤는데, Docker는 어떻게 되는건지 감이 잡히는데 K8S을 불러왔을 때는 어떤 형태로 동작하는지 공부를 해야할 것 같습니다.
https://docs.microsoft.com/ko-kr/azure/app-service/containers/app-service-linux-intro
https://blogs.msdn.microsoft.com/appserviceteam/2018/05/07/multi-container/

Undelete, Bring your own Storage

Undelete는 예상하시는대로, 실수로 WebApp을 지웠을 때 복구시키는 기능입니다. 30일 내로 삭제한 WebApp에 대해 url, 콘텐츠, 설정 등 (거의) 모든 것을 복구할 수 있다고 하네요.

https://azure.microsoft.com/ko-kr/updates/announcing-webapps-undelete-preview/?ref=msdn

Bring your own Storage는 Azure Storage를 직접 WebApp에 마운트할 수 있는 기능입니다. 현재 Linux/Container WebApp만 지원되고 Windows는 아직 안된다네요. 이 기능은 꽤 호응이 좋을거 같네요. 전통적인 웹서비스들은 파일업로드에 대해 파일 기록을 하는 경우도 많으니까요.

https://blogs.msdn.microsoft.com/appserviceteam/2018/09/24/announcing-bring-your-own-storage-to-app-service/

저는 클라우드로 기존 서비스에서 옮기는 분들에게 클라우드에 맞춰 소프트웨어를 강하게 개선하는게 맞다고 말합니다. 대표적인 예가
Bring your own Storage 기능처럼, 전통적인 서비스들은 서버 하드디스크에 바로 기록하는 형태가 많은데 이런 경우 모두 Azure Storage로 재설계해야 하는게 낫다고 말해왔습니다.

하지만, 그건 너무 제가 편하게 생각하기 때문이고 Azure는 오래된 엔터프라이즈 환경(≒레거시)에 대응하는 기능 또한 충실히 잘 구축해야 더 많은 유저를 수용하는 거겠죠?

Azure WebApp은 제가 참 좋아하는 서비스입니다. 참고로 아래는 2017년의 제 발표자료입니다.

이상입니다.