HJH 기술블로그

프로그래밍을 오래 하다 보니 통찰력이란 게 생기게 된다. 지식과는 별개로 지혜를 얻게 되는 것인데, 사실 알고 나면 별거 없지만 모를 때는 정말 안갯속을 걷는 기분이다.

1. "무조건"이 없어지게 된다.

모든 것은 양면이 있다는 사실을 알게 된다. 새로운 프로그래밍 언어가 나오면 무조건 그것이 좋다며 신봉하는 사람이 생겨난다. 프로그래밍 "언어"인데 왜 새로운 그것을 더 신봉할까? "언어"라는 것에 빗대어 설명해 보면 그렇다. 한국 사회에서 잘 적응하지 못해서 해외로 나가는 케이스를 많이 보았다. 물론, 한국이 문제 기는 하지만 대부분의 경우 적응이라는 것은 경쟁에서 뒤처진다는 것이고 그것이 수학이던 국어던 중요치는 않다. 뒤쳐진 경쟁에서도 행복을 느낄 수 있는 자존감이 강한 사람이라면 모르겠지만 대부분 사람은 그렇게 강하지 않다. 즉, 그 언어를 잘 못해서 새로운 언어를 배우게 된다는 것. 만약, 반대의 경우가 있다면 잘하는데도 잘하는 것을 버리는 경우가 있다면 새로운 것이 정말 좋은 것이다. 버리는 것의 "크기"에 따라 얻는 것의 크기는 다르다. 오랜 세월 동안 내가 본 사람 중에 프로그래밍을 가장 잘했던 두 사람은 전자공학도였다. 수학과 출신이 프로그래밍 잘하는 것과 비슷한 이치인 것 같다. 위에서 말한 것처럼 양면의 경우, 본인의 길이 막막해서 다른 것을 하는 경우도 있지만 본과의 공부를 정말 잘하는데 모든 것을 버리고 다른 것을 하는 경우가 있다. 박사 수료가 아닌 박사 학위를 받고 음악을 하는 루시드 폴이 음악을 하는 이유도 같은 이유라고 생각된다.

 프로그래밍을 대안으로 하느냐 정말 좋아서 하느냐에 따라 특별히 다른 것은 없다. 즐기지 못하는 자와 즐기는 자로 말하기도 하지만 사실, 즐긴다고 해도 힘들 때는 힘들다. 그래서 개발자끼리 싸울 필요는 없다. 역사서 보지 않고 혹은 잘못된 역사서를 보고 역사를 말하거나, 아예 역사를 모르고 독도를 일본땅이라고 하는 것처럼 우둔한 것이 없듯이 프로그래밍 세계에서도 목에 핏대 세우며 말하는 많은 사람들 중에 제대로 된 경우는 전무했다. 거의가 아니라. 그냥 뭘 하던 좋아하는 것 하면 된다. 사람인에 올라온 코볼 개발자 연봉이 스타트업에서 최신 기술만 이야기하는 연봉의 2배인 경우를 보고 일전에 글을 올렸더니 많은 마케팅 문구가 변하는 것도 보았다.

 얼리어답터만 고집하다가 여러 사정으로 이제 라스트 무버가 되고 있는데 양쪽 다 장/단점이 있다. IT 세계에서 무조건이라고 확신했다가 망한 경우가 많았는데, 그런 경우 자체도 무조건이 없다고 하고 싶다. 왜냐면 스티브 잡스나 빌 게이츠가 뛰어난 엔지니어는 아니기 때문이다. 메모리는 640KB로 충분하다는 등, 그들이 말한 게 틀린 부분도 있어서 확신하지 말라는 것 자체도 무조건에 속한다. 변한 지 않는 것은 변한다는 사실 뿐이라는 문장이 이미 존재한다. 이 말을 자기 말을 뒤엎는데 쓰는 파렴치한도 직접 만나보기는 했는데, 상황과 때에 맞게 적용하려면 충분한 내공이 있어야 한다고 생각한다. 프로그램이 할 때도 모듈, 컴포넌트, 프레임웍, 서비스, 요즘엔 휴대폰을 AI에 이용하려고 하니 심지어 시스템까지 그 목적이 변한다.

 OLPP 역시 모든 것은 변하지만 관계(LINK) 속에서 변한다는 사실을 말하고 싶은 것이다. 새로운 프로그래밍 언어가 나오면 좋은 쪽으로 갈 수도 있고 아닐 수도 있다. 

2. 내가 iOS/SWIFT를 타깃으로 정한 이유는 사실 생각보다 간단하다. 구글의 GO 언어나 안드로이드에서 밀고 있는 코틀린 그리고 애플의 SWIFT 3개 중 하나를 해야 한다는 생각이 들었다. 애플의 언어를 주 언어로 선택한 이유는 우선, 그 본체가 Objective-C가 LLVM 기반이고, 그 뿌리는 gcc 이기 때문이다. 컴파일러를 잘 만드는 국가는 덴마크와 미국이고. 애플은 이것을 확실히 알고 있다는 생각이 들었다. 그리고 확실히 평생 이것만 해도 되겠다고 생각한 결정적인 이유는 애플의 시가 총액이 1위를 했기 때문이다. 상업적으로 성공한 프로그래밍 언어가 최고는 아니겠지만 예전 선배의 가르침에 더욱 확실해졌다. 리눅스 잘하시는 분이 모든 것을 버리고 마이크로소프트 진영으로 가셔서 MVP 되시고 잘 나가실 때 강연을 하셨는데, 이미 10년도 더 넘은 이야기다. 왜 리눅스를 버렸냐는 질문에 본인도 리눅스가 너무 좋은데 "청춘이 멍들잖아요"라는 말을 했었다. 이제 정말 뼈저리게 이해한다. 이제 FSF 멤버도 떠났는데 보스턴에서 자꾸 소식지는 보내준다. 진정한 자유와 소프트웨어 개발의 기쁨은 FSF에 있다는 것을 안다. 다만 지금은 닿지 못하는 이상향으로 보인다. 정말 깨끗한 사람이 걸을 수 있는 길이다 FSF는. 사실, 개발자는 C만 잘해도 먹고살 수 있다. 도전적인 부분도 많아서 챌린지 한 프로젝트도 많다. 소위, 안될만한 것을 잡아서 되게 만드는 프로젝트가 많아서 보람도 남다르겠다. 이제 그런 모듈이나 아키텍처나 시스템, 그리고 의뢰자의 요구사항도 의뢰자의 수준에 맞춰서 보이면 삽질은 되도록이면 안 하고 싶다. 여기서 매우 큰 차이는 포주가 되느냐 아니냐 차이인 것 같다. 스트라디바리는 사랑해야 하지만 과르네리는 강간해야 한다는 말을 듣고 너무 저질이라고 생각했는데, 소리 비교 영상을 보면서 뭔가 사라지지 않는 여운이 있는 것을 보면, 참... 더 이상 말을 말자. 나 역시 너무 저급스런 표현이면 에이전시를 운영하게 되느냐 현역으로 계속 뛰느냐 차이인 것 같다. 또, 다 안다고 생각해도 현역으로 뛰는 게 맞다고 본다. 짧은 생을 살면서 지식의 정수에 다가가지는 못한다. 나 역시 아래쪽으로 계속 내려다가 보니 C, 펌웨어, 어셈블리, 피스파이스, 베릴로그, RTL로 내려가다 결국 전기 학원까지 다녀봤는데 전문가란 하고 싶은 것을 포기하고 자신의 전문 분야를 닦는 것을 말한다. 고 내 책에 썼다. 또, 쓰는 책마다 쓴다. 왜냐면 내 딸이 다리 다쳐서 외과 수술을 받아야 하는데 산부인과나 내과에 부탁하지는 않을 것이기 때문이다. 물론, 수술을 못할 거라 생각지는 않는다. 변호사가 만능 자격증이긴 해도 세무는 세무사에게 노무는 노무사에게 맡기는 것과 비슷한 이치는 아니다.(이제 아니라고 생각한다.) 왜냐면 같이 부서에서 일하던 사법고시 출신 변호사 형의 업무 능력이 사실, 너무도 뛰어났기 때문이다. 물론, 나이가 들면 ^^;;; 그때의 체력과 열정은 똑같지는 않을 것이다. 양면적으로 생각하다 보니 자꾸 산만해진다.

3. 시중의 프로그래밍 책은 뭔가를 새롭게 만든 게 아니라 제약 사항에 대해서 설명하는 것이다.

생각해 보자. 전기 안 들어가면 컴퓨터 안 켜진다. 컴퓨터 안 켜지면 프로그래밍 못한다. 내가 만든 프로그램도 온갖 프로그래밍 기법을 쓰지만 결국 Windows, MAC, Android, iOS 등이 제공하는 수준에서 벗어나지 못한다. 프레임웍을 만든다고 해도 칩이 제공하는 기능을 벗어나지 못한다. 하드웨어가 BLE를 제공하지 않는데 BLE 프로그래밍을 할 수는 없는 것이다. 물론, 칩 설계도 요샌 프로그래밍해서 디자인 하우스에 보내기는 한다. 프로그래밍을 포괄적으로 보면 사실 하드웨어도 포함한다고 봐야 하겠다. 시중에 나온 책은 추상화된 APi와 그런 API를 효율적이고 멋있게 쓰는 방법에 대한 기술이다. 해당 API는 하드웨어 제약 사항에 제약을 받을 수밖에 없고 설계 역시 그렇다. 시중의 프로그래밍 책은 모두 그런 제약 사항에 대한 설명이다. 보다 자유를 느끼고 싶으면 전기 이론을 공부하면 되는데 사실 반도체 하나만 해도 한 사람이 평생 가도 모두 공부할 수 없는 분야기 때문에(원자력과 같은) 커뮤니케이션의 능력이 중요하게 된다. 그리고 리더의 자질에 대한 중요성도 더욱 커지게 된다.

리더라는 것은 처음부터 없었던 것이다. 필요하게 되어 생겨나게 된 것이다.

내 딸이 있어 내가 아버지가 된 것처럼 아버지도 필요에 의해 생겼다.

내가 아버지라고 어디 가서 좀 거들먹거리고 싶고, 우리 아버지가 그랬던 것처럼 가족들에게 폭력을 쓰고 싶어도

가족이 없는 순간 난 아버지 자체가 아니기 때문에

결국 OLPP 란게 중요한 것이다.

나약한 현실 도피의 사상에서 출발한 것은 아니다. 이미 중학생 때부터 오래도록 다져온 생각이다.

운영계획 4

주간 방문 1324 -> 1221

운영계획 1, 2 편의 경우 포럼에 올리고 이 블로그에 저장하는 방식이었다. 그래서 아래 3편을 올리고 4편을 여기 올린다. 4편은 마지막으로 포럼에 올리고 5편부터는 포럼에는 올리지 않는다. 포럼에는 운영계획이 마지막 글이라 생각과 아이디어를 꽤 길게 적을 생각.

- 구글 애드센스 승인 완료 : 내가 블로그를 모두 정리하면서 일원화 하느라 기존의 블로그 애드센스를 지우며, 새로 신청했던 사이트를 삭제하고 다시 올린 줄 몰랐다. 정작 승인 기간이 2주 넘은 줄 알았는데 실제 시간을 보니 승인까지 대략 10일 정도 걸린 것 같다. 기존에 승인 받은 애드센스를 지우면서 티스토리로 오기로 결정하고 좋은 소식이다. 사실, 사용자 유입과 광고는 관계없으나 이탈율을 줄이려면 광고를 바로 달면 안된다는 생각이 있고, 아직 개뿔 인기도 없는 블로그이기에 딱히 수익이 발생할 것 같지도 않아 광고 관련한 계획은 생각하지 말기로 하자. 아직은, 그럴 시간에 코드 한 줄 더 짜는게 더 이득이니까. 

- 재미있게 통합하자 : 이제 블로그를 정말 즐기면서 해야 할 시기가 왔다. 포스팅 하나하나에 수준급 통찰과 내용을 담아 포스팅을 하는 것보다 유툽하는게 금전적으로는 더 이득이다. 분산되어 있던 SNS와 블로그를 하나로 통합하면서 내 추억도 돌아보고 관리도 더 쉽게 할 수 있으니 좋다. 그리고 정말 부끄럽지만 티스토리에 동영상이 올라간다는 것을 오늘 알게 되었다. 사실, 상상도 못했다. 서버 기술이야 파일 첨부 기능을 보고 어느 정도 있다고 생각했지만 500메가 까지 동영상을 올릴 수 있는 것을 보고 조금 놀랐다. 내 컨텐츠가 수준이 있는 것은 아니지만 매우 솔직한 내용을 담고 있으니 분명 도움이 될거라 생각한다. 나 역시 매일 일기를 쓰는 기분이라 재미있게 해 나가다가 수익이 될까 싶으면 달아는 놨으니 광고에 대해서 어떻게 더 수익을 올릴지 고민을 해보자는 생각이다.

- 애널리틱스를 보니 사용자 유입이 줄었다. 그리고 유입 경로에 direct가 여전히 80% 이상을 차지하고 있었다. 이제 포스팅도 꽤 늘었는데 여전히 검색이 안되나 하고

https://code.google.com/archive/p/sitemap-generators/wikis/SitemapGenerators.wiki

맥용 사이트 맵을 받아서 실행해보니... 한글로 된 URL인 경우 UTF로 변환되었는데도 불구하고 invalid url 로 분류되고 있었다. 구글 애널리틱스에서 어떤 포스팅이 인기 있는지 보기 편해져서 좋다고 생각했는데 크롤러에서는 invalid url 로 분류되어 특정 검색 엔진에 나타날 수 없을 수도 있겠구나 하는 생각이 들었다. 뭐, 일단은 애널리틱스에서는 한글이 잘 나오니 구글에서 잘 검색될거라 생각하고 블로그 주제가 구글러들이 찾는 내용이므로 이 부분은 나중에 생각하기로 했다. 애널리틱스에서 편하게 인기글을 보느냐, 포스팅 URL 을 번호로 바꾸어서 utf 제대로 지원 안되는 검색 엔진에서도 뜰 수 있게 하느냐... 그리고 그런 검색 엔진이 뭐가 있을까 하는 생각들.(어차피 한국인 대상이니 굳이 번호로 바꿀 필요는 없을 것 같다. 또 두가지 방식을 다 지원하는 티스토리의 기능이 꽤 마음에 들었다.)

- 사용자 유입은 줄었으나 이탈률이 10% 또 감소했고 세션 타임이 많이 늘었다. 골수팬이 생기는 것이라고 착각하고 싶었으나 화면 상단에 카테고리를 배치해서 아마 여행기의 경우 여러 사진을 봤을거라 생각한다. 인기 페이지를 보니 역시나 코드 보다는 여행기를 더 많이 보았기 때문 ㅠㅠ 

- 사이트 맵 생성을 제출을 구글 서치 콘솔에 접속하고 티스토리 주소를 등록하려고 하니 구글 애널리틱스에서 자동 승인된 사이트라는 팝업과 함께 바로 등록이 되었다. 가만 생각해보면 애널리틱스를 돌리는데 구글에서 크롤링을 위해 다른 작업을 할 필요가 있을까 라는 생각이 든 것이다.

- organic 검색을 보니 다음이 1등, 구글2등, hajunho.com 에서 넘어온 것과 zum 검색은 동일하게 3등이었다. 그래봤자 9건 7건 2건, 2건인데 ... 뭔가 판단할 최소 샘플링 개수는 안되지만 이 적은 방문객에서도 뭔가 정보를 얻고 운영 계획을 세우려면 나의 경험이 많이 들어갈 수 밖에 없다. 우선, 티토리는 카카오(다음)꺼기 때문에 티스토리는 네이버에서 들어올리는 만무하다. 내 주변 사람중에 개발자를 제외한 사람들은 모두 네이버에서 검색을 하는데 카카오에 검색 기능이 들어가도 네이버 앱을 켜서 검색하더라. 직접 유입보다 organic 유입을 키우고 싶은 마음이 있는데 그럴려면 결국 다음과 구글을 함께 물고 가야 할 것 같다. 구글은 개발자가 많이 쓰니 코드를 많이 올리면 될 것 같고. 다음의 경우 우선, 사람들이 다음 검색엔진으로 뭘하는지 알아봐야 겠다. 그리고 다음 검색 SDK가 있는지 보고 해당 SDK를 이용해서 뭔가 할 수 있는지도 찾아봐야 겠다는 생각이 들었다.

- 나름 포럼에 꾸준히 글을 남겼고 조회수도 꽤 있는 것 같았는데 1300, 1200 찍고 직접 유입이 80%라고 보면 1000명은 포럼타고 오는 경우라는 것이다. 나중에 광고 활성화가 되어서 1000명이 들어오고 모두 광고를 클릭했을 때 5천원 예상된다. 한 달 2만원 가능하다는 말이다. 내가 학생 때라면 목을 매겠는데 그런 것을 신경쓰는 것 자체가 뭔가 깨림직하다. 이제 포럼을 이용해서 블로그 광고는 했으니 포럼에 광고 목적으로 글을 쓰지는 말자라는 생각이 들었다. 새로운 블로그를 보고 비슷한 성향을 블로거를 찾고 댓글 다는데 의의를 가지자는 생각이다.

- 내가 포스팅한 글을 보면 10년 블로그 해서 번 수익보다 한달 유투브 해서 번 수익이 더 많았다. 유투브던 비트코인이던 사람들이 관심도 없을 때 항상 먼저 시작했고 미래를 봤던 자신감으로 지금은 티스토리를 어떻게 그렇게 만들까... 카카오를 어떻게 그렇게 만들까 하는 생각이 앞선다. 구글은 글로벌 기업이니 꼭 배척할 필요는 없지만 구글 코리아는 한국기업이라 생각하고 함께 해 나간다고 생각하면 네이버의 오랜 아성도 무너뜨릴 수 없을까 하는 생각이 든다. 네이버가 싫은 소소한 이유가 있긴 한데(킬베 때와 IS반대 블로그 운영할 때 경찰서에 내 전번 팔아버린 사건과 블로그의 오래된 동영상 플레이가 지워져서 플레이가 안되던 사건 등) 굳이 싸울 필요는 없지만 정확한 목표는 있어야 해서 네이버의 검색 기능을 이용하는 빈도를 낮출 방법을 생각하고 있다.

- 그런데 아무리 생각해도 이길 수 밖에 없는 구조다. 네이버의 지식in 처럼 수익을 나눠주는 구조가 티스토리와 구글 애드센스에 있기 때문이다. 네이버가 뜬 것은 지식 in 때문이고 그 때 당시 사람들은 자신의 지식을 나누어줘서 사람들을 이끌겠다는 제2의 새마을 운동 분위기였고, 거기에 지식을 나누어 주는 사람에게 돈까지 챙겨줬으니 잘 될 수 밖에 없었다. 그 킬러 컨텐츠를 구글의 검색 봇이 모두 크롤링 했고 위기를 느낀 네이버는 그걸 막도록 했다. robots.txt 도 그 당시 유행했다. 

- 내가 마소와 레드헷은 나중에 손 잡을 것이라고 15년 전 즈음에 예상했는데 레드햇은 리눅스 커널로 마이크로 소프트보다 더 비싼 값에 돈을 버는 수익형 기업이었기 때문이다. 무슨 오픈소스 진영과 상용 진영의 만남이라고 사람들은 포장하지만 걍 M$ 와 돈에 혈안이 된 RED EYES의 만남으로 밖에 안보였다. 그 당시 다음은 카페라는 것을 운영하면서 사람들의 모임에 기여했으나 이렇다할 수익 모델이 하나도 없었는데 네이버는 정말 광고, 쇼핑, 뉴스까지 포섭하며 광고판이 되어 갔고 그런 것을 싫어한 사람들이 구글로 가자 자신의 정보를 닫아버렸다. 오라클, MS, 어도비, 네이버는 사실상 다 같은 철학을 가지고 있다고 보면 되겠다. 자유경제체제에서 나쁜 것은 아니다. 내가 이길 수 밖에 없다고 생각하는 이유는 지신in 의 구조에 있었다. 구글 adsense는 정말 성공한 서비스라고 여겨지는데 컨텐츠 제작자에게 돈이 가도록 하고 있다. 그게 너무 푼돈이라 스타를 만들자고 생각해서 최근에는 일정한 시청 수준 이하의 사람들의 수익을 끊어버리고 스타성 인간들에게 돈을 많이 줌으로서 아프리카 TV에서 유투버로 넘어오게 만들었다. 그런 스타들이 나오니 다른 사람들도 많이 유툽을 하게 되었다. 우선, 여기서 볼 것은 일단 구글은 창작자에게, 그것이 비록 작은 창작자라도 기본 이상이면 돈을 지불하는 시스템을 만들었다. 스타 유투버가 나오면 그 유투버는 돈을 써서 더 나은 컨텐츠를 만들고 더 나은 편집을 한다. 그래서 이제는 방송국 방송만큼 수준이 올라왔다. 물론, 방송국 방송에 비할바는 아니지만 엔터테인먼트 부분은 사실상 따라 잡았다고 보면 되겠다.

- 다음 검색에 의료쪽이 들어가고 사람들은 의료라면 다음에서만 검색하도록 하면? 아니면 그런 앱을 하나 만들면? 그리고 병원이 광고 할 수 있도록 한다면? 네이버에 있던 친구 몇몇이 해외행을 택하면서 퇴사를 했고 줏어들은 이야기가 있다. 네이버는 이미 망했고 수익은 라인에서만 난다고. 물론, 정량적이진 않겠지만 한 기업의 트랜드, 추세, 추이를 반영한다고 생각한다. 그리고 병원 지인을 통해 작은 병원~중견 병원까지 이야기를 들었는데 네이버에 지출하는 광고비가 작게는 250~5000만원까지 낸다고 한다. 여기서 난 이런 생각이 들었다. 최근 진주종 때문에 분당 차병원에서 수술하고 재발하여 또 수술했는데 상태가 좋지 않아 서울대 어린이 병원으로 옮긴 지인이 있었다. 그 지인에게 서울대 어린이 병원을 소개시켜 주기까지 논문부터 인터넷 포스팅까지 싹 뒤지게 되었는데 사실 분당 차병원 이야기 밖에는 없었다. 또 삼성전자의 지인은 서울대 삼성 병원에서 부모님께 효도 건진 시켜 드린다고 무쟈게 비싼 건진을 선물해 드렸는데 암을 발견 못해서 이 후 갔던 다른 병원에서도 위 내시경 최근 했다고 거부하는 바람에(왜냐면 최고의 병원에서 건진받았으니 그럴만두...) 결국 암으로 돌아가신 사건이 있었다. 친구는 소송을 준비한다고 이래저래 발로 뛰었지만 의료사고가 사실 적은 수가 아니라 쉽지 않았다. 아무도 안 도와주니. 난 의사는 아니지만 의사랑 오래도록 친분이 있어 아는데 사실 도와줄 시간도 없거니와 의료사고는 무지하게 많다. 그래서 나는 이런 사실을  알아도 의사들 고맙다며 블로그 포스팅을 많이 했었다. 음... 이런 정황을 보니 그냥 의료 전문 포털 사이트를 하나 만드는게 좋다는 생각까지 든다. 너무 삼천포로 빠질 수 있으니, 의사들의 노하우를 공개하는게 문제가 아니라 수많은 사람들의 노하우를 검색할 수 있을 정도면 좋을 것 같은데... 혹은 투병 활동 하는 사람이 블로그를 하면 그것을 모으는 것도 좋다는 생각이 들었다.

- 일단, 시작해야 하는 거고 두고 봐야 하는 거니 좀 더 고민을 해보자.

운영계획 3

하루 최대 방문자 수 : 359 -> 355로 정정
주간 방문자 수 변화 : 674 -> 1007 -> 1324(저번 주 종료)

티스토리 통계가 변화되는 것을 보면 본인 방문이다. 기타 통계가 특정 알고리즘에 따라 정정되는 것 같습니다. 

구글 애널리틱스 홈에서 결과는 아래 게제하겠습니다. 아직도 블로그 유입에 direct가 80% 이상인 것을 보면,

갈 길이 멀어뵙니다. 티스토리 하시는 분들이 놀러와 주시니 이탈률은 매우 낮은 편입니다. 보통 블로그는 한 페이지 보고

나가버리니 80% 이상으로 알고 있거든요. 재미있는 글은 시리즈로 쓰면 이탈률은 낮아지겠지만 그게 무슨 의미가 있을까요? ㅋㅋ

아무튼, 꾸준히 글도 올리고 블로그 이전도 해야 겠습니다.  구글 애드센스에 사이트 등록 신청을 했습니다. 마지막 240 달러를 인출하고나서 40달러가 남아서 1년뒤 하려다 애널리틱스 달면서 같이 했는데요. 아래2와 같이 하루 기다리라고 한지 이틀이 되어도 안되는 것을 보면 뭔가 이유가 있나봅니다. 그리고 세부정보 표시에서 나오는 남은 날짜가 정확하지는 않다는 것을 알게 되었네요.

• 아 래 -

203

434.2%

지난 7일 동안 대비

세션수

292

548.9%

지난 7일 동안 대비

이탈률

49.66%

17.2%

지난 7일 동안 대비

세션 시간

3분 55초

72.8%

지난 7일 동안 대비

• 아래 2 -

사이트의 광고 게재 가능 여부 검토 중

검토 절차는 일반적으로 1일 이내에 완료되지만 경우에 따라 시간이 더 소요될 수 있습니다. 사이트를 확인한 후 결과를 알려드리겠습니다.

기다리시는 동안 광고를 게재할 모든 페이지에 코드를 추가하세요. 확인이 완료되면 사이트에 광고를 게재할 수 있습니다.

내 광고로 이동하여 게재할 광고 형식을 선택해야 합니다.

광고를 언제 게재할 수 있는지 자세히 알아보세요

광고 설정

띄엄띄엄 있는 코드에 말씀드릴게 있고 많은 분들의 오해는 피하고 싶어서 OLPP에 미리 밝혀둡니다.

사실, 이 블로그는 코드 관련해서는 친절한 블로그가 아닙니다. 그렇게 되려고 생각도 하지 않고 있습니다. 이미 github이 있는데 그렇게 될 필요도 없을 것입니다. 제가 초급편 책을 쓴 이 후로 완벽하게 친절한 설명은 따로 잘 할 수 있는 사람이 있다고 믿고 있습니다. 기초를 상세하게 잘 설명하는 것은 그만큼 힘든일이고 인터넷 상에 잘하는 분이 많이 있습니다.  그럼에도 불구하고 불친절한 IT 블로그를 운영하는 이유는 분명 도움이 될거라 생각되기 때문입니다. 그리고 제 경력 때문입니다. 주변에서 경력 관리를 잘했다고 말하는데 사실, 코드가 좋아서 그렇게 따라갔었던 것 뿐이지. 따로 경력 관리를 하지는 않았습니다. 제가 작은데서 시작해서 큰 곳으로 이동한 것도 아니고, 대기업에서 시작을 했다고 알려져 있지만 사실 대학생 때부터 IT 호스팅 사업을 해서 사장이라는 직함이 있었습니다. 특허는 회사에서 시켜서 내게 된 것이지 제가 회사 나오려고 특허를 낸 것도 아닙니다. 그리고 지분률도 대표 발명자가 마음대로 정할 수 있었지만 지금은 애플에 있는 앨리스와 팀 관리하시는 분께 많이 할당했습니다. 회사 나오고도 케어를 했음에도 불구하고.

회사를 나오고 나니 삼성은 오래 못 다니는 곳이니 뭐라고 하시는데 사실, 저는 마음만 먹으면 임원이 될 수 있다고 생각했었고 지금도 그렇다고 생각합니다. 저는 정치에 별로 관심이 없는데 한번 정치를 하면 무지하게 잘하기도 하지요. 그것은 이 블로그 보시면서 잘 아시게 될 것이고. 한번 본 사람 계속 보고 싶어서 나온 회사 계속 다시 들어갔고 회사원임에도 불구하고 회사를 위해서 월급의 반 이상을 서버 구입에 쓰고 디자인 하는데 쓰고 그랬습니다. 물론, 일년이 지난 뒤 회사 사정이 괜찮아졌을 때 정산해서 받았습니다.

저는 어설픈 관계를 싫어합니다. 스타트업 경험 때문에 인간 자체가 싫어져서 사람을 많이 줄였습니다. 인간 자체를 싫어할 경험을 그 전에도 숱하게 했지만 그래도 인생은 그것이 아니라고 하는 기준을 세우고 살았습니다. 그런데 지금은 병렬 처리를 좋아하는 저도. 다른 길 가는 길에 저를 만나러 오는 사람이 있다면 굳이 만나지 않습니다. 왜냐면 어차피 무료로 IT 컨설팅을 받으러 오는 이유, 공짜로 본인의 아이디어를 구현해 달라고 하는 부탁이 대부분이기 때문입니다. 

저 자신의 본질도 다른 사람이 어떻게 하느냐에 따라 변한지 오래 되었습니다. 제 자신의 가치나 본질보다 다른 사람과의 관계에서 정해지는 모습이 딱 그 모습입니다. 그러나 저는 스스로 생각하는 사람이기에 제가 어느 정도의 인식을 받느냐는 제가 정하기에 따라 다르다는 것을 알고 있습니다.

제가 처음 책 출판을 권유 받은 몇몇 출판사에게 이야기 했던 것은 돈이 안된다는 것을 알고 있다는 말이었습니다. 이 말은 오해의 소지가 있으나, 우선 저는 책을 무척 좋아하는 사람입니다. 다만, IT 쪽은 저자보다 출판사 관계자 쪽을 더 좋아합니다. 그래서 솔직하게 이야기를 합니다. 본디 솔직한게 정답이라는 철학이 있기도 하지만 말입니다. 

아이들이 많이 모였을 때는 피자가 좋은 것 같다.

어른들이 많이 모였을 때는 회+소주가 좋은 것 같다.

모나코 정말 작은 나라인데... 세계 스포츠 카는 다 볼 수 있는 곳이다. 물론, 길거리에서 사진은 매장 사진을 주로 올린다. 길거리 슈퍼카는 쪽팔려서 찍지 않았음. 차주한테 어글리 코리안으로 보일까봨ㅋㅋㅋ.

미국 여행기를 좀 덜 올렸는데 미국 보다는 유럽이 더 낫다고 하는 사라들의 이유는 딱 2가지 인 것 같다. 모나코는 워낙 좁아서 유럽으로 일반화해서 말하면.

1. 음식이 정말 맛있음. 식당 마다 천지차이인데 어느 동네를 가던 미슐렝 스타가 붙은 가게는 항상 있는 듯. 물론, 예약 대기는 최소 1달임.

2. 어릴 적 생각하던 이상형이 유럽에 다 있음. 미국에서는 3년간 딱 1명 봤는데 유럽은 2~3일에 1명 정도 보게 됨.

그 외에는 좋게 생각하면 좋은 거고 나쁘게 생각하면 나쁜거.

가령 작은 차들이 매우 많은데... 여기서는 주차장 난이 심해서 정말 김한장 차이로 주차를 해야 하기 때문에 어쩔 수 없는 일. 제일 밑에 사진 처럼 작은게 대세다. 그런데 좋게 생각하면 한국에서 쓸대없이 큰 차 타면서 가오 잡는 애들은 안봐서 좋다. 그나마 큰차라고 하면 페라리나 맥라렌 정도? 모타코 둘러 보면 정말 좁은데 요트랑 슈퍼카 밖에 안보임.

우리나라 유투버들이 차 자랑 하는거 보면, 선진국 따라 가려면 이제 개인 전용기나 요트 자랑할 때 되지 않았나... 하는 생각이 든다.

그리고 딱히 몰카는 아니고 사람들 얼굴이 나와서 굳이 블러처리 좀 했다. 모델급 남자 사진도 많고, 여신 사진도 많지만 혼자 보고 말란다. 결혼도 했으니 주책떨지 말아야지. 믓튼, 유럽 모나코는 다시 한번 가볼만한 곳이다.

두바이 3박 4일 동안 기억나는 것은 미친듯이 마셨던 와인 밖에 없다. 그리고 어쩌다보니 두바이에서 장관급 인사도 뵙고 우리나라 보건 복지부 사람들과 회식도 가지고... 나름 좋은 경험이었다.

여기는 한번은 더 오지 싶다. 일전에 포스팅 했던 나라 중 푸켓, 코타키나발루, 세부는 다시 안 갈 것 같다. 아.. 세부는 아직 포스팅 안했나?

믓튼, 세부는 애플 망고 주스 밖에 기억이 안난다. 너무너무 맛있었고, 다음 달 하와이를 다시 가기는 하는데 거기도 과일 주스 하나는 정말 괜찮긴 하지만 세부 만큼은 아니었다.

리조트도 정말 좋았지만 리조트 들어가는 차를 검문 할 때마다 기관총 든 사람들과 아래쪽 폭탄 점검하는 것 때문... 또 범퍼카 같은거 타고 도시 투어 운전하면서 했는데 너무 낙후 되어 이건 하와이도 그렇지만, 다시 안 갈 것 같고. 푸켓은 물이 맑지 않아서 다시 안 갈 것 같다(세부에 비해서) 사이판은 물이 정말 맑았지만(이것도 아직 포스팅 안한 듯) 너무 좁아서 아마 그 옆에 섬에 갈 것 같다. 와이프가 섬 이름 말했었는데 까먹었음. 중간에 가려고 했었던 그리스나 기타 등등 나라가 폭동이니 화산이 폭발했니 등으로 다 취소되어서 조금 거시기 했음. 유럽 쪽 포스팅도 남겨야 하는데 빨리 올려야 겠다는 생각이 든다. 블로그 이전 1년으로 잡긴 했는데 생각보다 쉽진 않다.

git log 로 commit 을 확인한다.

최근 2개만 diff 포함 볼 때는

git log -p -2 로 보고 화면 이동은 vim 과 같이 ^f, ^b 포 페이지 이동, ^e, ^y 로 한줄 씩 이동해서 본다.

git log 로 commit 번호를 확인 후에는

헤드만 이동

git reset --soft [commit#]

스태이지에 올려진 파일도 이동(index 이동)

git reset --mixed HEAD~

현재 작업 디렉토리 파일도 이동

git reset --hard HEAD~

[commit#] 을 HEAD~ 로 바꾸면 현재 head 

보통 git reset --hard HEAD~ 를 많이 쓴다.

깃에서 헤드가 마스터보다 앞서 있을 때 헤드로 싱크하기

git branch -f master HEAD

git checkout master

왠만하면 브랜치는 master에서만 하지 말고 develop에서 하고 주기적으로 master로 머지하자. 주기적 머징이 없다면, 헤드를 잘못 이동시켜 깃이 꼬일 수 있다.

결국, 디벨롭 따서 거기서만 개발하는 것은 차라리 master에서만 개발하는 것보다 더 못함.

git remote add original/develop git@github.com:hajunho/xxxx.git

ㅏ키

키나

석양이 아름답다 했는데 우리가 갔을 때는 날씨가 좋진 않았다.

푸켓과 함께 여기는 2번 갈 것 같지는 않다.

우선, 결론만 알고 싶으신 독자를 위해 라돈 측정기에 올려둔 [판매자에게 질문] 과 [제품리뷰]를 올린다.

그리고 지극히 개인적인 내용이니 구입할 때 참고만 했으면 한다. 그리고 그 개인을 과대 광고를 성폭행범 만큼 싫어하는 사람임을 밝힌다.

이 제품 때문에 반품한 물건에 몇 개인데, 1시간 만에 측정 가능하다고 해놓고 설명서 보니 2시간. 그리고 반품 한 이불 업체에 라돈 때문에 대표랑 싸우고 있는데 그 업체에서 같은 제품 구매하니 업체에는 일주일 측정해야 제대로 된거라고 말했다면서요? 지금 장난합니까? 일주일 측정치가 정확하다는 것은 설명서에 나와서 알겠는데 그게 2000 넘게 나오다가 나중에는 확 떨어지는 거면 무슨 광고는 이따위로 하는거죠? 환불 방법 가르쳐 주세요.

나는 여기서 구매를 했다.

http://www.11st.co.kr/product/SellerProductDetail.tmall?method=getSellerProductDetail&prdNo=2162952797&xfrom=&xzone=

온 갖 사탕발림이 있는데. 화면을 캡쳐해서 올려둔다.

라돈도 이동이 가능한 것인가? 매트리스에 라돈 수치가 100을 넘지도 않았는데 라돈이 문제라고 생각한 이불을 반품하고 측정했을데 2000이 넘어갔다.

내가 1000넘으면 아... 라돈도 이동이 되는구나 하겠는데. 2000 넘으니까 이젠 모르겠다. 숏텀과 롱텀이 설명서대로 뭘 뜻하는지 모르겠다. 대학 나오고 명문 대학원 두군데 전액 장합금으로 합격했으나 못갔고, 서울 연고대생 및 대학원생 가르치는 나도 이해를 못하겠는데 내가 정말 ㅂㅅ 일까?

일단, 환불 시도를 해 보려고 한다. 어쩌면 여기가 정말 희대의 사기꾼 기업이 아닐까하는 생각도 든다. 한시간 안에 뭘 측정한다는 거지? 이젠 측정하는 제품마다 warning 이 맥스를 찍는데,...

안방 벨라 이불 측정 : 1300 이상 warning 단계 거의 맥스(사진 공개 했음)

안방 벨라 이불 세탁 후 측정 : 마찬가지

따쑤미 텐트 와서 측정 ; 1400 이상 

이상해서 그냥 안방 대기에 놔두고 이틀간 측정  40 이하

따수미 텐트 교환 신청하고 안방 메트리트 측정(이전에 30 이하 나왔던 제품) -> 2300 이상

내가 라돈에 대한 지식이 모자란 것은 알겠는데, 다른 소비자를 위해 한마디 하면, 광고랑은 다른 제품인 것 같다. 

ㄱ ㅆ 거지 같은 제품이라고 하고 싶지만 블로그이기 때문에 그렇게 쓰진 않겠다.

클렙튼 라돈 측정기 반품 이후에 벨라 이불 재 주문 해야 겠다. 반품이나 제대로 될런지 모르겠다.

import UIKit

class MainSplitter : UISplitViewController {

    override func viewDidLoad() {

        super.viewDidLoad()

        preferredDisplayMode = .allVisible

        maximumPrimaryColumnWidth = 200 //얘는 마스터 뷰 width related

    }

}

코드로 UI를 그리다 보면 중첩이 많다. 그렸다 지웠다 하는 경우는 레이어를 쓰게 되고 그 외 뷰는 대부분 UIView로 그리게 된다. 또, 하나의 파일에 넣는게 길어져 파일을 나누고, 결국은 클래스를 나누게 된다.

import UIKit

import SnapKit

class InsidePanel1 : UIView {

    var ret = UIView()

    var item1 = UILabel()

    var img1 = UILabel()

    var item2 = UILabel()

    var item3 = UILabel()

    func entry() {

        item1.text = "Item1"

        ret.addSubview(item1)

        ret.addSubview(img1)

        ret.addSubview(item2)

        ret.addSubview(item3)

        self.addSubview(ret)

    }

}

또 그룹을 나누게 된다.

    lazy var topGroup : UIView = {

        let uptownGirls : UIView = UIView()

        return uptownGirls

    }()

    lazy var leftGroup : UIView = {

        let leftHander : UIView = UIView()

        return leftHander

    }()

    lazy var rightGroup : UIView = {

        let uRright : UIView = UIView()

        return uRright

    }()

UIView라서 스크롤뷰도 안에 넣을 수도 있고 기타 그래픽 stuff도 모두 넣을 수 있다.

   lazy var imgBloodSugar : UIView = {

        let view : UIView = FilledRect(frame: CGRect(x: 0, y: 0, width: 10, height: 18), level: 1, color :  colorLiteral(red: 0.9529411793, green: 0.6862745285, blue: 0.1333333403, alpha: 1))

        return view

    }()

가능

    lazy var labelUpperValue : UILabel = {

        let label: UILabel = UILabel()

        label.font = UIFont.init(name: "NanumSquareOTFL", size: 16)

        label.text = "......--%(---회)"

        label.textAlignment = .center

        label.textColor =  colorLiteral(red: 0.9764705896, green: 0.850980401, blue: 0.5490196347, alpha: 1)

        return label

    }()

가능

코드로 모두 그렸기에 redraw 나 refresh 도 가능하다.

func jhRedraw() {

        print("xDistance", xDistance)

        dataLayer.removeFromSuperlayer()

.

.

.

    open func refresh() {

        if let view = zoomView {

            display(view: view)

        }

    }

redraw 만을 위한 큐를 만들어서 for문을 돌며 한꺼번에 redrawing 도 가능 하다.

protocol observer_p {

    func jhRedraw()

}

선언하고

    private static var listeners = [observer_p]()

    static func attachObserver(observer : observer_p) {

        listeners.append(observer)

    }

전역에서 호출하게 만들고

    public static func notiDataDowloadFinish() {

        for x in listeners {

            x.jhRedraw()

        }

    }

모두 호출해 주면 된다.

필요한 상황에 필요한 drawing만 가능하니까 무조건 반응형(reactive)으로 만드는 것보다. 효율적이다.

소스 고치기도 쉽다. 

    override func jhRedraw() {

        drawAxes()

옵저버 프로토콜을 구현한 애들만 리스너에서 제외하던지 해당 함수를 지워버리면 된다. 

너무 쉬운 것만 추구하면 기본을 잊어버리고 유연성을 잃어버리게 된다. Swift design pattern 책이 많다.

모듈 디자인은 디자인 패턴 책 하나면 충분하다.

내가 이전 블로그에서 여기에 해당 책을 올려놨는지 기억이 안난다. 최근 술을 자주 마셔서 black out 이 온다. 중복 사진을 올리더라도 독자의 너그러운 이해를 구한다.

아이와 휴양 가는 곳? 

잘 띄웠다. 바닥에 까는건 에어 콤프레샤를 이용했다. 에어 컴프레서 가 좀 더 맞는 느낌이지만 샤 로 검색해야 하고, 저걸로 충분했다. 바퀴가 없어서 좋았다. 헬륨은 혼자 넣어도 되는데 컴프레샤는 무조건 2인 1조로 해야 한다. 공기압이 채워지기전에 계속 불어야 하기 때문.

요런거 한 20번 뜨네 ㅡㅡ;

다시 10개씩 올려야지.

이 글은 정말 내가 주변 사람들에게 일일이 설명하기 귀찮아서 적어두는 썰이다.

모든 것을 제대로 예상한 설계 이 후 추가되는 요구사항 때문에 폴링을 써야 한다면 결국 타이머를 돌려야 한다. 타이머를 돌린다는 것은 스케쥴러는 만든다는 뜻. 즉, 스케쥴러와 큐가 필요한 시기가 온다.

작년 4월에는 facebook의 리액트로 프로젝트를 한다는 이야기를 들었는데 하드웨어 제어가 들어간다고 하길래 분명 망할거라고 했다. facebook 이 만드는 wrapping API 덩어리 프레임웍이 제대로 될리가 없다. 왜냐면 페이스북 폰이 망했었기에.

내 예상대로 수천만원의 비용을 쓰고 해당 프로젝트는 결국 망했다. 

작년 9월에 특정 프로젝트를 담당하면서 RxJAVA 고수가 RESTFUL API 와 BLE를 쓰기 때문에 Reactive 방식으로 하면 안되냐길래 리액트 기본은 스케쥴러와 큐인데 꼭 동시성을 그렇게 맞추지 않는다고 해도 콜백 지옥을 벗어날 수 있다고 했다. 그리고 별 어렵지 않게 프로젝트를 진행하였다. 그리고 최근 다른 프로젝트를 진행하는 스타트업 회사의 지인에게 리액트 쓰다가 소켓 통신이 들어가고 나서는 디버깅이 어려워졌다는 말을 들었다.

프레임웍에서 올라온 API wrapping 하는 것은 편리함만 있으면 된다. Alamofire나 Snapkit이 그렇다. 작년 리액트와 리액티브를 공부하면서 RxSwift 소스도 보게 되었는데 역시나 wrapping. 그런데 MVC 패턴이 아닌 나름이 패턴을 제창하는데 나는 그게 도저히 새로운 개념이라고 보기가 참 힘들었다. 그럴거면 iOS 프레임웍단을 새로 만들지... 하는 생각. 쿠팡과 같이 하드웨어 제어가 전혀 없는 프로젝트라면 모르겠는데. 하드웨어 제어, 혹은 3D 그래픽 기술이 들어가는 프로젝트에 적용하지 못하는 것을 마치 일반화가 가능한 패턴이라고 말하는 것 자체가...

그런 소스를 보다가 전수열씨의 프로젝트도 보게되고 그 중에는 국내 swift 개발자로 많은 스타를 받은 프로젝트도 있었는데. 그 중 하나가 then 이었다. 나 역시 snapkit 을 자주 쓰기 때문에 lazy var를 많이 쓰는 편인데 then을 쓰면 snippet이 먹지 않는다. snippet을 적용하려면 closure 파라미터에 s : UIButton 처럼 다시 또 써줘야 snippet이 먹는다. 한 단어만 더 들어가도 해당 프로젝트는 쓸 이유가 없어진다. 더군다나 다른 포스팅에서 밝혔듯이 내부적으로 한번 더 생성해서 return 하는 녀석은 attribute를 펑션 설정으로 뺄 수 있기 때문에 더 편리하다. 나는 여러 프로젝트를 하며 IB를 거의 안쓰기 때문에 모두 코드로 UI를 짜는데도 snippet이 안 먹히면 불편함을 느낀다. 그리고 Swift 특성상 클로저 파라미터에 상속을 먹일 수는 없는 제약이 있기 때문에 autocompletion을 할 수 도 없다. 내 동료들도 내 블로그를 보기 때문에 왜 내가 해당 프로젝트들을 안 쓰는지 일일이 변명하기 귀찮아서 이렇게 써 둔다. 그냥 위치만 가르쳐 주면 되니까.

그리고 새로운 언어나 개념이 나오면 다 거기 달라붙는 이유를 이번에 확실히 알 것 같았다. 최근 특정 회사를 옹호하는 개발자들 말처럼 뭘 더 해보라고는 안하겠다. OS 만들어 보고 firmware도 해보고 다양한 OS 환경에서 앱과 프레임웍도 만들어 보라고는 안하겠다. 그런 경험을 할 수 있거나 했던 사람중에 개발자로 계속 남아 있기도 힘드니까.

애플이 특정 개념을 만들었기에 무조건 신봉할 필요도 없고. 최대한 규칙을 지키며 프로그래밍 하다 대세가 되면 애플에서 밀어줄 수도 있겠으나. wrapping을 하면 할 수록 성능은 떨어지고. 수억이 사용하는 검증된 프레임웍을 수천명의 개발자가 쓴다고 해서 바꿔줄 수도 없다. 적어도 수십만은 되어야 바꿀 수 있다. 일반화는 그 정도로 어렵다. 리액티브 개념을 시스템, 아키텍쳐 수준으로 올리지 말았으면 좋겠다. 모듈 정도는 괜찮다.

시스템 설계는 패턴이 존재할 수 없다. 뭔가 예측하기 위한 최소 샘플링 개수도 얻을 수 없다. 삼성, LG, 애플, 중국폰의 SW 시스템에서 공통점을 뽑아내고 패턴화 해서 그것을 새로운 제품에 적용할 수 있을까? 불가능하다. 그럴 필요도 없다. 그 안에 속에 있는 수많은 기술이 업그레이드 되니가.

꿍하고 공개 안하는 개발자보다 뭔가를 공개해서 도움을 주고 논란거리를 만들어 주는 개발자가 더 좋다. 그러나 개발 방법은 천차만별이고, 우리가 계속해서 공부해야 할 것은 새로운 테크닉이 아니라 기초다. 공부할게 너무 많은데? 만약 따라가다보면 그게 틀렸다면 어쩔 것인가?

그만 써야 겠다.

결혼식 가서 마신 맥주가 기억나 맥주를 좀 마셨다. 술은 정말 좋은 친구인 것 같다.

이미 싱글톤 GS(Global Setting)에 대해서는 다른 포스팅에서 여러번 밝혔다.

바이너리 세마포어, 혹은 뮤텍스 이름은 거창하지만 단순 플레그일 뿐이다. 펌웨어 쪽에서도 마찬가지.

물론, 펌웨어 쪽에서 경험없는 엔지니어의 플래그 하나를 잘못 읽거나 세팅하면 시스템이 죽어 버리지만

앱에서는 그럴일 없다. 문제는 다른 swift 파일에 쓰여진 bool 값이 얼마나 오래동안 유지될 수 있느냐.

그래서 gs가 있고 gs는 프로젝트 전반에 걸치는 부분을 모아 둠으로서 메모리에서 내려가지 않게 만드는 것이 관건이다.

행여나 내려가면 앱을 다시 시작시키거나 리소스를 복원하는 작업을 해야 한다. 나중에 모바일 하드웨어가 데스크탑 수준이 되면

걱정거리는 줄겠지만 그런 류의 생각은 항상 해야하고 항공 SW 처럼 커널 수준의 앱에서 모든 것을 제어하기에는 이미 컨트롤

되지 않는 멀티태스킹 작업이 통합을 방해하고 사람 목숨과 관련된 것을 만들기 어렵게 한다.

항상 고민해야지.

 var bSemaphore : Bool = true

 let queue = DispatchQueue(label: "com.hajunho." + UUID().uuidString)

GS.s.queue.sync {} 혹은 async... 

개인적으로는 main queue가 아닌 global queue는 쓸 일이 많지 않다. 블루투쓰나 RESTFUL API 의 동시성 역시 @escape 클로저 로 동시성을 맞추는 것이 가능하기 때문이다. 또 이미 iOS 에서 추상화된 API가 모두 concurrency를 만족한다. 앱 자체도 멀티태스킹이 되니 Node.js 가 증명한 것처럼 Queue 하나면 족하다. 

//제주도에 관심이 많으신 듯.

interfacebuilder의 constraints는 무시하고 했는데 이제 같이 고려해야 겠다. 캘린더, 메세지 뷰 등 오픈소스 땡겨서 넣고 나니 충돌 에러가 많네.

Incident Identifier: 8119A8B0-F57D-43DD-9EC4-986726331B59

CrashReporter Key:   2d69027677e0f1a6099d22d81b232d222a98ff18

Hardware Model:      iPhone9,4

Process:             KakaoMobility [11719]

Path:                /private/var/containers/Bundle/Application/BCCD7B8E-F697-4E77-B159-7C3B33AA8394/KakaoMobility.app/KakaoMobility

Identifier:          com.kakao.taxi

Version:             2 (3.0.5)

Code Type:           ARM-64 (Native)

Role:                Foreground

Parent Process:      launchd [1]

Coalition:           com.kakao.taxi [1557]

Date/Time:           2018-01-24 23:32:02.6545 +0900

Launch Time:         2018-01-24 23:04:01.5065 +0900

OS Version:          iPhone OS 11.2.2 (15C202)

Baseband Version:    2.02.04

Report Version:      104

Incident Identifier: D9626DA3-2CDA-4949-8C6B-484CCE927D18

CrashReporter Key:   2d69027677e0f1a6099d22d81b232d222a98ff18

Hardware Model:      iPhone9,4

Process:             OneBank [2758]

Path:                /private/var/containers/Bundle/Application/B12B5B55-147A-46F4-86F2-4491D973CA6A/OneBank.app/OneBank

Identifier:          com.ibk.onebankI

Version:             1.3 (1.3.5)

Code Type:           ARM-64 (Native)

Role:                Foreground

Parent Process:      launchd [1]

Coalition:           com.ibk.onebankI [504]

Date/Time:           2018-03-03 10:56:33.0959 +0900

Launch Time:         2018-03-03 10:50:38.6117 +0900

OS Version:          iPhone OS 11.2.6 (15D100)

Baseband Version:    2.02.04

Report Version:      104

Exception Type:  EXC_CRASH (SIGKILL)

Exception Codes: 0x0000000000000000, 0x0000000000000000

Exception Note:  EXC_CORPSE_NOTIFY

Termination Reason: Namespace ASSERTIOND, Code 0x8badf00d

Triggered by Thread:  0

Incident Identifier: 8B9FF608-CAF0-4459-B50A-4F619B79B70B

CrashReporter Key:   2d69027677e0f1a6099d22d81b232d222a98ff18

Hardware Model:      iPhone9,4

Process:             hearthstone [19245]

Path:                /private/var/containers/Bundle/Application/1323A4C4-552F-463B-B9D8-BEA446DB1254/hearthstone.app/hearthstone

Identifier:          com.blizzard.wtcg.hearthstone

Version:             11.0.23966 (11.0.23966)

Code Type:           ARM-64 (Native)

Role:                Foreground

Parent Process:      launchd [1]

Coalition:           com.blizzard.wtcg.hearthstone [1065]

Date/Time:           2018-04-24 13:48:55.2006 +0900

Launch Time:         2018-04-24 13:01:10.1772 +0900

OS Version:          iPhone OS 11.3 (15E216)

Baseband Version:    2.03.12

Report Version:      104

Exception Type:  EXC_BREAKPOINT (SIGTRAP)

Exception Codes: 0x0000000000000001, 0x0000000100247ba4

Termination Signal: Trace/BPT trap: 5

Termination Reason: Namespace SIGNAL, Code 0x5

Terminating Process: exc handler [0]

Triggered by Thread:  0

결론만 말하면 괌맥주는 내 스타일 아니었음 ㅠ 맥주는 역시 호가든이었다. 아니면 카스 미니. 물론, 하루 일 끝나고 나서 마시는.

얘가 그나마 낫다.