ha-ah

OKKYCON 2017 참석 후기

http://jojoldu.tistory.com/249

2017년 말 (후기 전문가의) 한 행사 후기를 올 4월에 읽었는데 좋은 내용이 많아 아카이브 하기로.

4월에 갑자기 스크럼이 본격 도입되고(지금은 음…) 꽤나 혼란이 있었는데, 여기서 좋은 힌트를 얻었었다. 당시 이 링크를 공유하면서 이야기 했던 것이,

가장 아차싶었던 것은 이번 스프린트가 끝났을 때 어떤 결과가 되길 바랐는가 생각이 없었구나 생각했어요…생략…제 티켓은 완료가 되었으나 사실 일이 완료되진 않았고 이번엔 계획하지 않았던 부분을 더 많이 고민했던 스프린트였…생략

우리가 했던 애자일과 툴(JIRA)과 현실은 아구가 잘 맞지 않았고, 이런 저런 시도와 실패를 했고, 급하게 맥이 끊기게 됐지만, 좋은 경험이 됐으니 다음엔 더 제대로 해보고 싶으니, 이 정도면 애자일인가.

김훈민 님의 이런 포스팅을 보면서는 또 다른 공감을 했다. 프로세스가 과연 도움이 되긴 하는가라는 질문인데, 똑똑한 사람들이 모였다면 간단한 프로세스를 만들고 선의를 보이고 협업을 하는 것이 최고겠지. 우리도 아직 소규모라 그런지 잘 해내는 것 같다(xx같은 놈이 팀에 없다고 생각하면 내가 xx이란 말이 있었지).

[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유

https://www.slideshare.net/ssuser380e9c/ndc18-95524337
https://www.slideshare.net/ssuser380e9c/ndc18-2-95522893

주제도 참 재밌거니와 발표 자료에 하나 하나 스크립트를 달아놓아 현장감 있고 아쉽게 행사에 참여 못한 사람도 충분히 즐길 수 있는 매우 좋은 자료. 발표를 최대한 효과적으로 하기 위해 그 시간만을 위한 자료를 만드는 사람도 많은데, 매번 행사장을 찾아갈 수 없는 입장에선 조금 아쉽긴 하다. 나의 경우는 좀 귀찮아서 발표자료에 내용이 충분히 안 넣는 편…

😎한국어로만 선별된 타입스크립트 리소스 리스트 🇰🇷

https://github.com/typescript-kr/awesome-typescript-korean

저 아래 언젠가 쓸모 있을 것 같은 링크 모음에 들어가야할 것 같은 저장소지만, 이런 시도 매우 좋다.

ES6 시대가 열린 이후로 전혀 실무 경험이 없는데, 날 잡고 읽어봐야겠다.

수많은 데이터 사이언티스트들이 직장을 떠나는 이유는 무엇인가?

https://github.com/youngwoos/etc/blob/master/Here%E2%80%99s%20why%20so%20many%20data%20scientists%20are%20leaving%20their%20jobs.md

유망하고 인기있는 분야라서 자금과 뛰어난 인재가 모이고 그런데 자금을 쥔 자들은 그 분야를 잘 모르는데 어린 친구들은 거기서 장미빛 미래를 보니까 학원들이 강좌를 열고 더 어린 친구들이 또 다른 학원에서 쪼이는 세상에서 항상 발생하는 일. 10년 전 모든 개발자가 그랬고, 5년 전 앱/빅데이터 전문가가 그랬고, 최근은 머신러닝과 블록체인인가. 잘하는 놈이 잘한다.

그 분야 자체도 힘들겠지만 명예나 돈 같은 다른 욕망을 쫓아 갔다면 어디든 버티기 힘들텐데. 나는 진로를 결정(이 결정도 내가 한 건 아니고)할 때부터 아무 욕망이 없었으니 이 실력으로 여지껏 버텼나 싶군. 간간이 만나게 되는 소위 돈 버는 사람들을 보면 볼수록 역시 난 못 벌겠다 싶다.

딥러닝 간단하게 시작하기

https://www.facebook.com/dgtgrade/posts/1854447711280753
https://medium.com/daangn/이미지-탐지기-쉽게-구현하기-abd967638c8e

이정도로 쉽게 시작할 수 있다니. 시작을 시작하기가 더 어려운 세상이다.

TDD는 죽었는가?

http://jinson.tistory.com/m/271

이규원님의 포스팅에서 알아낸 번역 페이지. 아니 저 대단한 사람(DHH)이 어쩜 저렇게 TDD에 대해 오해를 했을까 싶을 정도로 놀라운 경험이었다. 정말 토론이라기 보다는 예수님과 부처님이 중생을 달래는 분위기였네. (그렇다고 DHH가 나보다 TDD를 못했겠느냐 그건 아니다)

DHH의 TDD is dead. Long live testing.은 나도 TDD를 전혀 모르던 시절에 한번 누군가에게 공유했던 기억이 난다. 나는 전혀 모르면서 TDD를 둘러싼 난리법석과 어려움만 얘기 듣고 ‘그래 이건 현실적이지 않아’라고 생각했던 것 같다. 어디서 많이 보던 풍경인데, 그렇지?

10배 뛰어난 개발자 되기 - 좋은 동료가 되기 위한 10가지 방법

http://muchtrans.com/10xdeveloper.html

페이지 구성이 참 마음에 드네. 어차피 번역도 괜찮으니 왼쪽 원문은 안 읽을 것 같기도 하지만…

어쨌든 참 좋은 관점이라고 생각한다. 예전에는 정말 사람이 부족할 때, 실력이 있으면 성격 좀 거칠고 진상 좀 부려도 어느정도 용인할 수 있다는 생각을 했다. 나는 그런 사람과 비교적 잘 지내는 편이었기 때문에 그런 생각도 했겠지? 그런데 팀원들에게도 새로운 사람이 오면 같이 적응하고 변하길 바랐던 건 잘못 판단했다.

스포카 크리에이터 행동 강령 소개

https://spoqa.github.io/2018/06/28/code-of-conduct.html

스포카의 행동강령(이라고 하니까 뭔가 운동권 같은 느낌도 있는데…)입니다. 역시 스포카다. 이 역시 위에서 소개한대로 좋은 동료가 되기 위한 방법.

좋은 대화를 하기 위한 10가지 비법

https://www.ted.com/talks/celeste_headlee_10_ways_to_have_a_better_conversation?language=ko

xx하기 위한 10가지 비법…이란 제목은 영 마음에 안드는데, 역시 제목을 이렇게 지어야 하나보다. 이 글 제목도 이번달 나를 사로 잡은 10가지 뉴스로 바꿔야 하나.

페북에도 한번 공유했는데, 꼭 명심하길 바라며 기록에 남기기로 한다.

안 그래도 요즘 얘기하다가 머릿속을 엄청 굴리면서 시선을 다른데로 돌리는 버릇이 재발했는데, 꼭 나중에 생각난다. 누구든 나랑 말하다가 내가 집중하지 않으면 뺨을 찰싹 치..일 것처럼 손을 들어주면 좋겠다.

계속 노력 중.

SI / 대기업에서 스타트업으로 이직하기

https://okky.kr/article/470785

약 파는 이야기 같으면서도 참 공감되면서도 기억해놔야할 것 같다가도 좀 오해도 있으신 것 같고 그러함.

머리가 하는 노동, 손이 하는 노동…’월급 차이는 당연한가’

http://www.hankookilbo.com/v/f7ff09cc4af3477e9218a5c83286815f

별로 생각도 안 해본 주제인데, 나도 은근 편견이 있었구나 싶다. 곧 후기를 쓸 직업의 지리학이란 책에서는 혁신 일자리 주위에 만들어지는 많은 일자리(서빙, 미용실, 의료)는 몇 십년 전이나 지금이나 (시간 관점에서의) 생산성이 거의 변함없다고 지적했다. 결국 수익이나 생산성을 극적으로 높여주는 직군에 더 돈이 모이게되는 시장의 이치. 그리고 누가해도 비슷하고 누구든 쉽게 시작할 수 있다고 여겨지는 직업에는 편견이 쌓이는 것 같고.

가만, 그러고보니 영화 서칭 포 슈가맨의 그 슈가맨은 엄청 돈을 잘 벌고 있었던 게 아닐런지.

PS. 공유 당시에는 ...'월급 차이'는 당연한가라는 문구가 붙어있었나보다. 문구는 나쁘지 않은데 월급 차이에 왜 따옴표를 붙였을까?

신규 Web 서비스시 고려해 볼 사항

http://kwonnam.pe.kr/wiki/web/신규서비스

오랫동안 정리해오신 것 같다. 신규 서비스 시작할 때 기억해놓고 다시 읽어봐야지.

게임 디자이너에게 도움이 되는 확률과 통계 이야기

https://drive.google.com/file/d/1Z71So_Xc-4QBtriYe9G1XlrNM9FoNk3z/view

수포자에게도 도움이 됩니다.

확률를 따져야할 때 기억하고 다시 읽어보기!

언젠가 쓸모 있을 것 같은 링크 모음

자바스크립트로 블록체인 구현 강좌 - 나만의 비트코인 발행하기

[번역] 깊이 있는 리액트 개발 환경 구축하기

File Api와 이미지 용량 줄이기

자바스크립트는 어떻게 작동하는가: 웹어셈블리와의 비교 + 언제 웹어셈블리를 사용하는 게 좋은가

ES modules: 만화로 보는 심층 탐구

블록체인 공부 자료 정리

파이썬 개발환경 구성하기의 끝판왕 - Docker Compose

리눅스 서버 60초안에 상황파악하기

일본 여행 정보

BASH Shell Script

간만에 모던PHP 모임에서 발표한 자료.

https://github.com/ModernPUG/meetup/tree/master/2018_06

발표 코드와 큰 흐름은 Kevin Smith의 Modern PHP Without a Framework이라는 글에서 가져왔고, 여기에 이런 저런 설명을 붙여서 발표했다.

발표 자료 만드는 도중에 엄청난 고민에 빠졌는데, 문제는 DI(Dependency Injection, 의존성 주입)였다.

DI container를 설명하면서 (내가 만들지 않은) 아래 코드를 예로 들게 되었는데,

class AwesomeClass
{
    private $dbConnection;

    public function __construct(\PDO $dbConnection)
    {
        $this->dbConnection = $dbConnection;
    }

    public function doSomethingAwesome()
    {        
        // Make magic happen with $this->dbConnection
    }
}

이 코드는 DI인가, 아닌가?

이 코드는 의존성이 주입되지 않았다. 의존하는 객체를 생성자를 받은 것 뿐이다. 이미 이 ‘대단한’ 클래스는 PDO에 강하게 의존하고 있다.

그럼 DI란? 간단히 설명하면, 의존 관계(토비님은 이 표현이 적당하다고 생각하시는 듯)를 런타임에 맺어주는 것.

그래서 의존성 주입의 적당한 예로 아래처럼 다른 코드로 바꿀까 고민을 많이 했었다.

class PizzaDelivery
{
    private $pizza;

    public function __construct(PizzaInterface $pizza)
    {
        $this->pizza = $pizza;
    }

    public function deliver()
    {        
        // vroong!
    }
}

런타임에 HawaiianPizza 인스턴스가 들어온다고 가정을 해보자.

‘의존성을 제거한다’라는 말을 들으면, 예전에는 ‘어차피 이런 코드도 PizzaInterface에 의존을 하고 있구만. 의존성을 제거할 순 없지’이라만 생각을 했는데, 여기저기 찾아보니 의존성 주입에서의 ‘의존성(Dependency)’은 특정 상황을 나타내는 고유명사로 생각하는 게 속이 편하겠다는 생각이 들었다.(이건 논란의 여지를 피해 또 논란 거리를 만드는 건가?)

PizzaDelivery는 HawaiianPizza와의 의존성이 없다. HawaiianPizza와 의존 관계가 만들어지는 건 런타임이다. 그래서 이 코드는 의존성이 주입되는 예시가 된다.

발표에서 PHP-DI라는 DI container라고 스스로 이야기하는 툴을 DI로도 쓰고, Service Locator로도 쓰기도 하는 것에 어째 이물감이 생겼다. 남들을 더 혼란스럼게 하나 싶기도 하고.

생성자에 뭔가를 넘기는 것을 의존성 주입이라고 퉁치는 경우가 많기 때문에, 이것도 REST처럼 정확히 따지고 들자면 꼰대가 되는 것 같지만, 한번쯤 DI의 의미를 깊이 생각해볼 필요가 있을 것 같다.

여기까지가 DI에 대해 공부했던 내용이고, 그 출처는 아래 링크에서 많은 도움을 받았다.

(공부는진행중…)

도움받은 글

http://jwchung.github.io/DI는-IoC를-사용하지-않아도-된다

• Martin Folwer의 Inversion of Control Containers and the Dependency Injection pattern(박성철님의 번역본 참고), Mark Seemann의 주장(haruair님의 번역본 참고)등을 예로 든 DI에 관한 글이 있었는데, 이 글과 댓글을 읽고 많은 생각을 하게 됐다.

https://justhackem.wordpress.com/2016/05/13/dependency-inversion-terms/

• 그 댓글에서 논쟁을 벌였던 이규원님의 글 ‘의존성 역전 원리(Dependency Inversion Principle) 관련 용어’

http://toby.epril.com/?p=808

• 토비님의 DI에서 dependency를 어떻게 번역할 것인가에 대한 글

1달러 프로토타입

빠르고 획기적으로 서비스 변화를 줄 수 있는 포스트잇 한 묶음의 비밀!

엄청 길고 쓸데없는 부제에 실망할 겨를 없이 아주 얇고 유익하고 간결하고 비싼 책이다. 그림 그리는 것과 이야기 만드는 것, 생각을 정리하는 것 모두에 관심을 갖고 있던 터라 아주 즐겁게 읽었다. 머리를 식힐 때 옥상에서 매일 꾸준히 그림을 그려볼까 다짐했던 과거는 주마등처럼 지나가며, 마치 ‘아참! 나는 매일 밤 자기 전 플랭크를 하기로 했었지’와 같은 뻔하고 당연한 클리셰가 되었다. 그래도 다시 도전해볼까!

디자인 오브 디자인

《맨먼스 미신》의 저자, 브룩스 교수의 설계 에세이

맨먼스 미신을 읽진 않았으나 명성을 익히 들어봤고, 거장의 신작이라니 뭔가 땡기기도 하고, 누군가 추천하며 재밌게 읽기도 하고, 마침 설계에 대한 고민이 되던 시기에 고른 책.

정말로 이름대로 디자인 오브 디자인. 즉, 설계를 어떻게 설계할 지에 대한 이야기이다.

지금은 잘 기억이 안나지만 설계에 대한 답답함에 고른 책이었는데, 컴퓨터 과학이나 컴퓨터 아키텍쳐에 발톱만큼의 관심도 없는 나에게는 조금 지루하긴 했다. 오히려 건축을 다루는 부분은 꽤 흥미롭기도 했고, 에세이답게 그 과정을 너무 길다 싶을 정도로 열심히 설명을 한다. 그래서 후반부 건축 설계쪽은 프로그래밍 설계에 대한 은유를 발견하는 것이 쉽지 않았다.

브룩스 아저씨는 어떤 분야든 설계 프로세스의 핵심이 되는 부분에 공통점이 있다고 이야기 한다.

애자일(이 용어를 썼는지는 확실치 않지만 결국 애자일 만세), 제한된 자원, 제약 조건, 설계 모범 사례 등에 대해 그럴듯하게 이야기를 풀어나가고, 이 할아버지 엄청 똑똑하다는 감탄이나 하고 앉아있을 무렵 사례 연구의 홍수에 허우적거리다 책을 덮었다. 마지막엔 솔직히 슥슥 넘어갔다고 고백한다.

이 무거운 책을 들고 읽다 팔에 배긴 알보다 내 머릿속 지식과 교양이 먼저 빠져나갔다는 사실이 슬플 뿐.

소프트웨어 객체의 생애 주기

올 해 전주영화제와 함께 한 테드 창의 중편 소설.

사실 영화 컨텍트의 원작 소설(당신 인생의 이야기)을 읽어야지 했다가 잘못 고른 책인데, 꽤 좋았다.

나는 작가 소개부터 차례로 읽는 편이라 매우 분명한 편견을 갖고 읽기 시작했는데, 읽자마자 딱 공대생 혹은 프로그래머가 쓴 책이라는 생각이 들 수 밖에 없었다.

그러나 인간과 타 객체와의 (여러 종류의) 관계를 다양하고 섬세하고 다루고 있다. 육아에 관한 이야기이기도 하고, ‘의식이란 무엇인가’같은 논쟁을 해도 좋을 내용도 담겨있다.

그래서 중편이라는 애매한 길이인데 너무 다각도로 짚은 것 아닌가 생각도 든다. 마치 비틀즈처럼 앞서 이런 작품을 만든 사람이 별로 없는 상황에서 똑똑하게 마음껏 질러놓은 작품 같다는 생각도 들었다. 아이디어는 좋았지만 글쎄. 내가 비틀즈에 열광하지 않는 것과 같이, ‘잘했네, 잘했는데 썩 열광할 것 같진 않아’같은 느낌이랄까.

그럼에도 당신 인생의 이야기(테드 창의 중단편 모음집)까지는 한번 읽어보고 싶다는 생각이 들었다. 왠지 기능적으로 내가 원하는 스타일일 것 같다. 자율주행차량에 대한 이야기처럼.

유혹하는 글쓰기

스티븐 킹의 창작론

처음 1/3 정도는 스티븐 킹의 어린 시절부터의 자전적인 내용이 담겨 있는데, 이렇게 키우면 스티븐 킹이 되는구나(이건 경고이기도, 격려이기도…)를 알 수 있는, 이것이야말로 육아서적이구나 생각이 들었다.

이후 작가로서 어떤 마음가짐이어야 하는가, 작가는 어떤 생활을 하는가, 자신에게 글쓰기가 어떤 의미를 갖는가에 대해 이야기 한다. 내가 읽은 스티븐킹이 쓴 첫 책인 것 같다. 읽다보니 그의 글솜씨(비록 번역이 된 글일지라도)가 정말 대단하구나 생각도 든다. 세련되진 않으나 (아내를 끊임없이 웃겨주는) 유머러스한 노인같은 책이다.

내가 올 해 몸살에 걸렸을 때였나? 정말 드물지만 티비 앞에서 채널을 돌리며 시간을 때우다 서프라이즈를 보게 됐는데, 스티븐 킹이 큰 사고를 당한 내용이었다. 헐리우드의 저주.. 뭐 그런 내용이었다. 바로 그 사고를 당한 시점에 쓰던 책이 바로 이 책이라고 한다.

여기에는 글쓰기 워크샵에 대해서도 언급이 잠시 됐는데, 전주영화제에서 본 ‘워크샵’이란 영화도 떠올랐다. 글쓰기에 대한 여러 생각을 하게 해준 그 영화와 이 책은 조금 다른 관점이긴 하다. 그런데 이런 책 밖의 경험 덕분에 글을 막 쓰고 싶다는 느낌도 들었다.

하지만 이 책을 다 읽고나니 난 작가는 못해먹겠다는 생각이 드는데, 꾸준히 써야 하고 꾸준히 읽어야 하기 때문이다. 내가 프로그래밍을 못하는 이유와 비슷하다니…
게다가 수없이 쓰고 거절당하고 버리기도 하는 모습을 보면, 같잖은 거 한 두개 써놓고 이게 무슨 잭이 키운 콩나무가 될 것인양 다루던 어린 시절이 생각나기도. 그것들을 개인 카페에 모아뒀는데, 지금쯤 빛바랜 콩나물이 되어 있을 것이다. 아무렴 어때.

to be continued

정말 오랜만에 독후감을 쓴다.

올 해 SQL 코딩의 기술이나 그들이 어떻게 해내는지 나는 안다도 읽었지만 한번 더 읽고 독후감 쓸 생각으로 벼루고 있다.

그럼에도 불구하고 너무나 인간적인을 읽다 포했다거나 라디오헤드를 그만 읽고 쟁여놓은 사연은 연말 회고 때나 다뤄볼까 한다.

Streaming & Buffering

Streaming이란 응답을 한번에 보내지 않고 chunk로 나누어 보내는 것.

이를 downstream(브라우저 같은 client만을 의미하지 않고 upstream에서 만들어진 데이터를 받는 쪽을 의미하는 상대적인 개념)에서 사용하거나 또 다른 downstream으로 전달하기 위해 설정된 크기만큼 모으는 행위를 buffering이라고 한다. (내 생각이고 정확한 정의는 아니다)

브라우저에서는 body 태그가 나타난 이후 스트림으로 받는 컨텐츠를 받는 족족 화면에 추가해준다. 이 때문에 뒤늦게 추가되는 CSS가 있다면 모든 요소의 로드가 끝날 때까지 스타일이 계속 변하는 페이지도 많이 볼 수 있다. 바로 이놈의 블로그 테마처럼! 곧 갈아치우던가 해야지.

(이렇게 잘못 설계하면 불편함을 초래하지만) 이런 매커니즘은 다운로드를 최종 완료하는 시점을 더 늦추는 대신 빠른 반응 속도를 제공할 수 있고, 사용자들은 더 빨리 로드되는 것처럼 느끼게 된다.
그리고 보내는 쪽에서도 유익한 것이, 서버의 메모리 제한에 상관없이 전체 데이터를 메모리에 두지 않고도 거대한 파일을 클라이언트에 보낼 수 있다.
반면 너무 작은 크기로 잘라 계속 보내게 되면, 네트웍으로 전송하는 비용과 chunk로 자르는 비용과 chunk를 분석하는 비용이 추가가 된다.

괜히 있어야 할 말인 것 같아서 쓸데없이 당연한 말 좀 써봤다.

output_buffering 옵션

php.ini에서 많이 만나봤던 그 옵션이다. output buffering이란 PHP 엔진에서 downstream이라고 부를 수 있는 다음 단계인 apache(mod_php), FastCGI, CLI 등에 즉시 응답을 주는 대신 일정 크기의 버퍼에 데이터를 쌓고, 버퍼가 다 채워지거나 PHP 스크립트의 실행이 끝날 때 전달해주는 옵션이다.

이런 느낌.

공식 매뉴얼을 읽어보면,

You can enable output buffering for all files by setting this directive to ‘On’. If you wish to limit the size of the buffer to a certain size - you can use a maximum number of bytes instead of ‘On’, as a value for this directive (e.g., output_buffering=4096). As of PHP 4.3.5, this directive is always Off in PHP-CLI.

default가 “0”이고, “1”로 설정하면 “On”과 동일하기 때문에 메모리가 허용하는 선까지 버퍼링하는데, 이는 위험하니 보통 4096으로 설정하는 것 같다. 왜 4096이란 숫자가 나왔는지 궁금한데 잘 모르겠다. 보통 이렇게 기본 설정으로 해놓는 듯. 왜??

4096 bytes(4KB)로 설정하면 PHP는 echo나 print 등의 출력을 하더라도 바로 다음 단계로 넘기지 않고 4KB까지 들고 있는다는 말이다.

중요한 점은 PHP-CLI에서는 PHP 4.3.5 버전 이후로 항상 “Off”란다.

이제 로컬 머신에 어떻게 설정이 되어있는지 확인해보자.

서버를 띄우고 phpinfo()를 찍는다.

> echo "<?php phpinfo();" > output.php
> php -S localhost:8888

내친김에 CLI는 정말 항상 0이 되는지도 확인.

❯ php -i | grep buff
output_buffering => 0 => 0

buffering 실험 - PHP 엔진

PHP Streaming and Output Buffering Explained라는 글에서 실험 방법과 코드를 가져왔다.

아까 띄웠던 서버는 죽일 필요없이 output.php를 열어 아래와 같이 수정한다.

<?php
    echo "Hello ";
    sleep(5);
    echo "World!";

브라우저로 http://localhost:8888/output.php에 접근해보면, 5초후 Hello World!가 동시에 노출된다. “Hello “가 output_buffering 제한보다 짧아서 echo를 했음에도 아직 버퍼에만 쌓여있는 상태이기 때문이다.

아까 CLI는 output_buffering이 항상 꺼져있다고 했는데, CLI에서 돌려보면 어떻게 될까? 당연히 “Hello “가 먼저 화면에 찍힐 것을 예상할 수 있다.

❯ php output.php

그럼 이제 output_buffering 설정값인, 4KB를 다 채우는 실험을 해보자.

output.php파일의 내용을 아래 소스로 바꿔준다.

<?php
$multiplier = 1;
$size = 1024 * $multiplier;
for($i = 1; $i <= $size; $i++) {
    echo ".";
}
sleep(5);
echo " Hello World ";

(buffering limit에 한참 모자라는) 1024 byte만 채우고 5초를 쉬기 때문에 이번에도 역시 Hello World!가 동시에 보인다.

$multiplier를 4로 늘려 다시 실행해보자. 이번에는 점(.) 4096개가 먼저 화면에 노출되는 것을 볼 수 있다.

만약 시킨대로 php -S로 서버를 구동하지 않고 웹서버를 통해 서비스했다면, 이런 현상은 못 볼 수도 있다. 아마 8KB로 늘려야 할 지도 모른다. 서버 설정에 관해선 잠시 후에 더 다룰 것이다.

ob_flush(); flush();

ob_flush와 flush는 데이터를 상위 레이어로 보내는 built-in method이다.
버퍼된 데이터는 버퍼가 꽉 차거나 php 실행이 끝나지 않는 이상 비워지지 않는데, 이 메소드가 버퍼를 비우는 일을 한다.

눈으로 확인하기 위해 sleep(5); 전에 ob_flush(); flush(); 를 심자.

<?php
$multiplier = 4;
$size = 1024 * $multiplier - 1;
for($i = 1; $i <= $size; $i++) {
    echo ".";
}
ob_flush(); flush();
sleep(5);
echo " Hello World ";

$size = 1024 * $multiplier - 1;를 했기 때문에 output 버퍼에 다 차지 않았지만, flush를 했기 때문에 4095개의 점(.)이 화면에 먼저 뿌려지는 걸 볼 수 있다.

ob_flush(); flush(); 두 메소드를 같이 쓴 이유?

flush

Flushes the system write buffers of PHP and whatever backend PHP is using (CGI, a web server, etc)

ob_flush

This function will send the contents of the output buffer

flush는 PHP를 사용하는 백엔드, 즉 다음 단계로 데이터를 전달하는 역할을 한다.

output_buffering 설정이 되어 있지 않아도 ob_start를 호출하면 자체적으로 output buffering을 사용할 수 있는데(이 때는 output_buffering으로 설정한 크기를 넘어서도 버퍼에 저장할 수 있다), 이때 쌓인 버퍼가 있다면 ob_flush를 해줘야 한다. 따라서 ob_flush는 flush보다 앞서 실행해야 한다.

웹서버 설정

초반에 PHP 엔진에서 버퍼가 다 차면 그 데이터를 다음 단계(downstream)로 전달한다고 이야기 했는데,

그 다음 단계가 웹서버라고 하면, 웹서버에서는 이렇게 받은 걸 바로 클라이언트로 전달해줄까? 미안하지만 웹서버도 자체 버퍼링을 한다. 그 다음에 끼어 있는 프록시는? ISP는? 브라우저는? 모두 나름의 버퍼링 메커니즘을 갖고 있다.

클라이언트(브라우저 등) - ISP - Proxy - Web Server - Application Server - DB

웹서버는 보통 다음과 같이 사용하게 될텐데,

브라우저 - php 내장서버
브라우저 - Apache - mod_php
브라우저 - nginx - fastcgi + php
...생략

위애서 본 대로 php의 내장서버를 사용하면 자체 버퍼를 두지 않고 바로 클라이언트에 데이터를 보낸다.

Apache + mod_php에서 mod_php에서는 버퍼링을 하지 않지만, Apache는 버퍼링을 한다.

FastCGI는 Apache에 붙여서 사용하든 nginx에서 사용하든 버퍼링 옵션이 있는데,

nginx에서는 4KB(32bit 머신) 혹은 8KB(64bit 머신)의 버피링을 갖고,
Apache에서는 (Apache에서 FastCGI를 물려본 적은 없지만) 문서에 따르면 65536(64KB)이나 된다. (default가 너무 커서 내가 과연 제대로 찾은 건가 싶기도 한데..)

웹서버가 버퍼링하는 모습을 확인하기 위해 아파치를 띄우고 새로운 파일을 만들어 서비스 해보자.

• 아파치를 띄우는 건 알아서…
• 나의 실행환경은 PHP Version 7.0.25-0ubuntu0.16.04.1, Apache/2.4.18 (Ubuntu)

cd 웹서버띄운디렉토리
vim webserver.php

<?php
$multiplier = 1;
$size = 1024 * $multiplier;
for($i = 1; $i <= $size; $i++) {
    echo ".";
}
flush();
sleep(5);
echo " Hello World ";

이제 브라우저에서 열어본다.

• http://localhost/webserver.php
• 웹서버를 몇 번 port에서 열였는지에 따라 URL은 달라질 것이다

output_buffering이 4096으로 설정된 상태이고 echo “.”;을 1024번 했으나, flush()를 실행했기 때문에 바로 화면에 점(.) 1024개가 찍힐 것으로 기대했을 것이다. 그런데 점(.)과 “ Hello World “는 동시에 나타난다. $multiplier를 4로 늘려 4096개의 점을 찍으면 이번에는 점(.)부터 화면에 노출된다.

즉, 아파치에서 클라이언트로 결과를 보내기 전 4096의 버퍼가 존재한다.

gzip 같은 압축 전송의 경우 클라이언트로 보낼 데이터를 모두 모은 후 압축해서 한번에 보낼 수도 있기 때문에 꺼둬야 한다.

gzip을 설정 파일에서도 끌 수 있고, PHP 스크립트에서 @apache_setenv('no-gzip', 1);로 끌 수도 있다.

nginx + FastCGI를 사용할 때는, 아래 설정을 추가해야 가능하다.

fastcgi_buffer_size   1k;                              
fastcgi_buffers       128 1k;  # up to 1k + 128 * 1k
fastcgi_max_temp_file_size 0;
gzip off;

buffer는 PHP 엔진에서 넘어오는 것보다 작게 두고, 이를 넘어가면 파일에 쓰지 않도록 fastcgi_max_temp_file_size를 0으로 설정한다.

주의

압축 전송 모드를 꺼버리는 것은 버퍼링 테스트를 할 때만 참고하자. 실제 서비스에서는 서비스의 성격에 따라 결정해야 한다.

nginx에서는 header('X-Accel-Buffering: no’);를 통해 특정 response에만 적용할 수 있다. Vanish 같은 데선 header('Surrogate-Control: BigPipe/1.0');. (아파치도 이런게 있었던 것 같은데…)

데이터를 만들어지는 대로 flush하고 chunk로 나누어 보내기 시작하면, 클라이언트에 200번대 응답을 주고 전송하기 시작할 것이다. 그런데 한번 200 code 응답을 보냈음에도 중간에 오류가 발생해서 보내지 못할 수가 있다. 각오하자.

데이터가 쌓이는대로 클라이언트에 전달해주면, 보낼 컨텐츠의 전체 길이를 알지 못하게 된다. 전체 길이를 알면 부분 다운로드나 이어받기가 가능해지므로, 상황에 따라 미리 컨텐츠의 데이터 크기를 알아두는 것도 도움이 된다. 여기서 또 주의할 점은 Content-Length는 Content-Encoding(gzip, deflate 등)을 한 이후의 길이를 의미한다는 것이다.

동적으로 생성될 경우 전형적인 압축 스트림은 아래와 같은 헤더를 갖는다.

Content-Type: text/html
Content-Encoding: gzip
Transfer-Encoding: chunked

또 어떤 경우에는 chunk의 크기를 결정해야할 수도 있다. 컨텐츠의 크기나 네트웍 상황에 따라 작은 chunk로 여러번 보내거나 큰 chunk로 적게 보내는 걸 결정해야 하는데, 버퍼 크기를 늘리면 커넥션마다 메모리를 더 많이 사용하게 되고, OS의 메모리 한계에 다다르면 out of memory나 disk에 쓰기 시작할 것이다. chunk가 작으면 chunk를 만들고 분석하는 비용이 더 들 수도 있다.

온갖 곳에 버퍼가 있기 때문에 chunk를 작게 자른다 하더라도 한 트랜잭션 내 어딘가에서 전체 데이터를 버퍼링하고 있다면 앞서 자른 의미가 없어지기도 한다.

브라우저

브라우저에서도 서버가 주는 데이터를 바로바로 화면에 표시하지 않고 어느 정도 모아서 주곤 했는데, 2013년도 stackoverflow의 글에 비해 많이 달라진 것 같다.

여기에 따르면 FF는 1024라고 되어 있지만 현재는 FF도 매우 낮다.

현재의 크롬(65.0.3325.181)은 2byte(= 2byte가 넘으면 렌더링 시작).
FF(58.0.2)는 1byte(= 1byte가 넘으면 렌더링 시작).
curl은 여전히 4096.

결론

버퍼는 어디에나 있다.

참고 :

• PHP Streaming and Output Buffering Explained
• Streaming PHP - disabling output buffering in PHP, Apache, Nginx, and Varnish
• HTTP Streaming (or Chunked vs Store & Forward)

이미지 출처 :

• big_chunk_buffer.jpg

GraphQL의 결과 값을 CDN에 캐싱 하기 (Caching GraphQL results in your CDN)

https://www.vobour.com/graphql의-결과-값을-cdn에-캐싱-하기-caching-graph

apollo 블로그의 글을 번역한 건데, (내가 너무 고지식한 건지) 그 사실을 페이지 끝에 밝혀서 좀 아쉬운 감이 있긴 하다. 그러나 매우 유용한 글을 번역해 주셔서 고마울 따름.

나도 graphql의 약점 중 하나로 캐시를 들고는 했는데, 그래서 restQL같은 놈들은 Native browser caching, CDN and Proxy caching 등을 해준다고 홍보를 하기도.

apollo와 같은 프레임웍에서는 이 문제를 아래와 같이 해결한다.

• Apollo Link의 Automatic Persisted Queries로 POST로 보내야할 많은 데이터를 해쉬 키로 조회할 수 있게 된다
• Apollo Cache Control로 상세하게 cache hints를 줄 수 있다

더 있지만 핵심은 이 정도인 듯?

GraphQL만으로는 프로덕션에서 유용하게 써먹기는 힘들 것 같고, 이런 프레임웍에 얹어줘야 쓸만 할 것 같다. Github의 GraphQL API는 벌써 v4로 올라온 것 같은데, 내부적으로 어떻게 최적화하는지 글이 있으면 좋겠다.

2018년과 이후 JavaScript의 동향 - 라이브러리와 프레임워크

http://d2.naver.com/helloworld/3259111

이제는 매년 훑어볼만한 시리즈가 되어가는 것 같다.

한동안 jQuery를 쓰면 골방에서 방망이 깎는 노인 개발자처럼 이야기하는게 못마땅했는데, 요즘은 슬슬 생각이 바뀌는 중이다. jQuery가 여전히 유용하다고 생각했던 이유는 적어도 한국에선 구형 IE를 지원해야하고, 이 문법에 익숙한 개발자들이 널려 있으며 굳이 (나에게) 익숙하지 않은 React/Angular/VUE를 배워가며 복잡한 단순 UI를 만들 필요가 없었기 때문이다.

그런데 이제 구형 IE를 지원해야 하는 요구가 많이 줄었을 것이라 생각하고(아니라면 위로를…), ES6 이상 쓰는 것도 당연한 일이고(아니라면 위로를..), jQuery가 익숙하지 않은 세대가 많이 유입이 됐고, 굳이 익숙하지 않은 jQuery를 쓰느니 간단히(!) webpack 좀 올려서 vue나 써버리는 사람이 많아졌다. 어느새.

카카오페이지 웹 React 포팅 후기

https://medium.com/@ljs0705/카카오페이지-웹-react-포팅-후기-76402cc5e031

React를 도입할 때 고민해야할 것을 다방면으로 이야기 해줘서 참 좋다. 사실 (언젠가먼훗날내가리액트를공부할날이올것을대비하여) 이런 링크만 가득 있긴 한데, 나름 최신 정보니깐…옛날 링크 좀 지워버려야지.

리액트 도움닫기 한국어 번역서를 출간하며

https://sujinlee.me/the-road-to-learn-react-korean/

좀 전에 안 보는 React 관련 링크 좀 지워버린다 했지만, 벌써 또 하나의 링크를 수집해 놓는다. 리액트에 대한 내용 보다는 번역에 관한 노하우가 담긴 링크다. 멋지다!

성과를 쥐어짜는 관리자

https://brunch.co.kr/@younghakjang/52

고성과 성격파탄자를 어떻게 다룰 것인가…생략…그런 사람을 저성과자로 분류하라…

피드백!

Scroll to the future

https://evilmartians.com/chronicles/scroll-to-the-future-modern-javascript-css-scrolling-implementations

참 골치아프다.

프론트엔드 개발자가 돈을 적게 받는 경향이 있는 것 같은데(주관적인 생각이다), 우리나라는 거칠고 잡다한 일을 해야할 경우 돈을 적게 주는 것 같다. (내가 해봐서 아는데라고 할 수 있는) 세심하게 많은 일을 하는 것보단 그게 무슨 일인지 이해하기 어려울 때 돈을 더 줄 가능성이 높달까.

(사실 다들 얼마나 받는지는 잘 모르겠다)

조직이 건강하다고 느낄 때

https://www.facebook.com/dgtgrade/posts/1776370592421799

팔도 비빔면 소스 만드는 법 비빔면 소스 레시피 공개

http://gall.dcinside.com/board/view/?id=food_noodle&no=49937

생활해킹

늦은 나이에 개발자로 시작할 수 있을까요.

https://steemit.com/development/@hikamaeng/7s6nmg

뒤늦게 개발자를 하려는 동생에게도 보내줬는데, 요점은 대충 해서는 안된다는 것. 그런데 그 대충이 어느 수준인지 뒤늦은 개발자 지망생은 잘 모른다. 나도 잘 모르기 때문에, 어느 수준이 적당하다고 얘기하기도 어렵다. 개발에 흥미를 느껴서가 아니라 현실 도피성이라면 또한 현실 도피하고 싶은 회사에서 기다리고 있다고 봐야…

인스타그램에선 ‘이렇게’ 일한다

http://bridge.500startups.co.kr/인스타그램에선-팀-관리-이렇게-한다/

사실 이런 글 반 이상은 다 뻥인 것 같은데, 이제는 그게 진짜인지 아닌지가 중요하진 않다고 생각한다. 우린 이렇게 하고 싶다 정도로 받아들인다면.

방향이 좋다.

updated

이 글이 의외로 인기(인기란 상대적인 것)가 있어서 여기저기 공유가 되고 있는데, 다시 읽어보니 메쉬코리아의 다른 분들은 어떻게 테스트를 하고 있었다는 건지 궁금할 수도 있겠다. 나는 분명 dd 찍는 게 위험하다고 했는데 말이다.

일단 dd를 찍어 놓고 production에 배포할 일은 쉽게 일어나진 않는다. 다수의 리뷰어가 지켜보고 있기도 하고, (커버리지에 속해 있다면) 유닛 테스트가 돌아가기도 하고, QA를 거치기도 하고, 그렇게 막 배포하지 않을 사람을 뽑기도 한다.

개발 환경은 통일되어 있지 않아서(굳이 다 docker로 맞출 필요가 없다) 각자 마음대로 해도 되고, 이미 xdebug같은 툴을 쓰시는 분도 계실 것이다. 나는 이걸 표준 개발 환경 안에 넣으려고 시도했던 것이고.

내가 이전에 거쳐간 회사에서도 별다른 도구 없이 그냥 코드를 이해하고 개발 잘하시는 분이 많았다. 가끔 찍어볼 일이야 생기긴 하지만 나처럼 자주 breakpoint 걸어 확인하는 스타일은 아니었다. 디버깅을 편하게(편하다는 것은 상대적인 것) 한다고 좋은 코드를 만들어 내는 건 아니다.

그럼에도 불구하고 나처럼 덤벙거리고 부족한 사람(여기서 내가 PHP 개발 경력이 제일 많은데, 제일 못한다!)은 팀에서는 여러 안전장치 안에서 개발하는 습관을 둬야 한다고 생각한다.

새로운 환경에 적응하기

• Xdebug와 Docker for Mac

새 직장(아…그 사람 구한다는 메쉬코리아?)에서의 개발환경은 나로서는 꽤 도전적이었는데, 뭐하나 익숙한 게 없었다.

Backend만 개발하며, PHP7.0, AWS, Mac…

UI가 없는 순수 백엔드(API)만 개발 하다보니 Postman이 주 테스트 도구(혹은 진입점)가 된다.

윈도나 리눅스 remote 서버에 올려 하던 식으로 해봤더니 뭐가 잘 안되곤 해서 매번 dd, var_dump, Log::xxxx() 식으로 코드를 망가뜨리며 테스트를 했었다. 위험하고 불편하다. 그럼 그럴 시간에 잠시 짬을 내서 Xdebug 설정을 완료하는데 노력을 했어야 하지 않았냐는 의문도 들 수 있다. 그런데 일단 대안(코드에 찍어 확인하기)이 있긴 했고, 다른 많은 것을 익혀야 했기 때문에 우선 순위가 밀리고 밀렸다.

그런데 도저히 안되겠다 싶어서 최근에 다시 후벼 파기 시작했고 성과가 있었다.

회사 위키에 적은 것을 조금 바꿔 공유해본다.

Xdebug 설정하기

원리

IDE에서 XDebug 모듈로부터 들어오는 연결 요청을 받기 위해 특정 port를 띄우고 기다린다

Client(브라우저, Postman 등)에서 HTTP request를 할 때 헤더로 XDEBUG_SESSION이라는 쿠키를 실어 보낸다.

PHP 엔진(+XDebug module)에서 XDEBUG_SESSION을 감지하면 config에 설정된 remote host와 port를 찾아 연결을 시도한다

DBGp 프로토콜로 두 모듈 간 통신을 하게 된다(break point로 라인 단위 실행 등)

Communication Set-up

With a static IP/single developer

With remote debugging, Xdebug embedded in PHP acts like the client, and the IDE as the server. The following animation shows how the communication channel is set-up:

기대 효과

1. dd(dump and die) 등의 프로세스 종료 코드나 로그 확인을 위한 코드 변경을 하지 않고 많은 context 정보를 확인할 수 있다.

2. 제시된 context 정보를 통해 실시간 evaluate/watch도 가능하다.

3. 코드를 완벽히 이해하지 않아도 차례차례 순서대로 한줄씩 실행해보면서 전체 프로세스를 익힐 수 있다.

Docker for mac에서의 설정 방법

회사에서는 표준 컨테이너 하나를 띄우고 쓴다

설정 확인

host 환경에도 php가 설치되어 있을텐데, 이건 IDE가 사용하는 cli이고 container 안의 php로 확인해야 한다

❯ docker exec -it 컨테이너명 bash
root@0829de89a35f:/var/www/html#

xdebug 설치 여부 확인

root@0829de89a35f:/var/www/html# php -v
PHP 7.0.22-0ubuntu0.16.04.1 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.22-0ubuntu0.16.04.1, Copyright (c) 1999-2017, by Zend Technologies
    with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans

xdebug 설치 여부 및 설정 파일(xdebug.ini, php.ini 등) 위치 확인

root@0829de89a35f:/var/www/html# php -i | grep xdebug
/etc/php/7.0/cli/conf.d/20-xdebug.ini,

XDebug 옵션 설정

• https://xdebug.org/docs/basic 참고

zend_extension=xdebug.so # to load extension
xdebug.remote_log=/tmp/xdebug.log # 로그 파일 위치. 첫 연동이라면 실패를 대비해서 로그 파일 위치를 지정하자
xdebug.idekey=PHPSTORM # XDEBUG_SESSION 쿠키에 value로 들어갈 문자열
xdebug.remote_enable=1 # remote host에서의 연결을 허용할지 여부
xdebug.remote_host=host.docker.internal # remote host의 주소. container 안에서 호스트로 접근할 때는 이대로 입력하자
xdebug.remote_port=9003 # remote host에서 어떤 port로 연동할지

저장 후 apache 재시동

root@0829de89a35f:/var/www/html# supervisorctl restart apache2

(자기 환경에 맞춰 알아서 재시작 하자)

IDE 설정

Preferences > Languages & Frameworks > PHP > Debug

• debug port 입력. 기본 9000번. 충돌이 나는지 확인하고 다른 port를 입력해도 된다
• 단, 위에서 설정한 옵션 xdebug.remote_port=xxxx 와 맞춰야 한다
• Force break at the first line when no path mapping specified 옵션
  • path mapping이 되지 않으면 이 옵션을 켜야만 한다
  • 매번 최초의 php script 위치부터 시작하므로 매우 귀찮다
  • 아래 server 설정을 추가하자

Preferences > Languages & Frameworks > PHP > Server

Client 쿠키 설정

브라우저

• 크롬이나 FF라면 helper를 이용하면 편하다
  • https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc
  • https://addons.mozilla.org/en-US/firefox/addon/xdebug-helper-for-firefox/

Postman

• host별 cookie에 설정
  • XDEBUG_SESSION=PHPSTORM; path=/; domain=localhost; Expires=Tue, 19 Jan 2038 03:14:07 GMT;

• 일부 request에만 추가하려면 header에 설정

테스트 중인 모습

삽질

나는 Mac도 잘 몰랐고, Docker도 잘 몰랐으므로 도대체 어디서 문제가 생긴 건지 알 수가 없었다. 여러가지 검색을 통해 힌트를 얻을 수도 있었지만, 나는 영어도 잘 모르지 않는가! 꽤 초기에 발견했던 커뮤니티 글을 다시 한번 찬찬히 읽어보고 결정적인 힌트를 얻게 되는데…

linux나 windows에선 xdebug.remote_connect_back=1을 설정하면 remote_host를 지정할 필요도 없이 쉽게 연동되나 Docker for Mac에서는 이 방식이 동작하지 않는다. 이건 Docker for Mac의 구조적인 문제라고 한다.

결국 remote host를 지정해야 하는데 그 방법으로 IP alias를 생성하라는 글이 아주 많은데,

sudo ifconfig en0 alias 10.254.254.254 255.255.255.0

이렇게 하고 remote_host의 값을 10.254.254.254을 지정하면 동작은 잘된다.

그런데 이때 Mac에서 인터넷 연결이 끊기는 문제가 발생했다. 이유는 도저히 모르겠다. 뭔가 충돌이 나는 IP일 수도…

그러다 Docker for Mac의 공식 문서를 보고 해결책을 찾았는데,

Dcker에서는 container 안에서 호스트로 접근할 수 있는 host.docker.internal라는 특별한 DNS name을 제공한다는 것이다. 따라서 위에 설정한 대로 xdebug.remote_host=host.docker.internal을 입력하면 호스트(IDE를 띄워놓은)에 접근 가능하다.

이 과정에서 문제가 무엇인지는 xdebug.remote_log에서 지정된 로그 파일로부터 얻었다. 연동이 잘 안된다면 맨 위에 설명한 것처럼 DBGp로 연결이 이뤄지기까지 어느 단계에서 문제가 생겼는지 확인해보는 게 좋다.

• XDEBUG_SESSION이 잘 세팅되지 않았다면 쿠키/헤더 설정을 확인해보자
• PHP(+Xdebug) 엔진 단에서 XDEBUG_SESSION을 인식을 못한다면, Xdebug 모듈이 로드 안됐을 수 있으니 php -v나 phpinfo()로 확인하자
• XDEBUG_SESSION을 인식은 했는데 request 들어온 곳을 찾아가지 못하는 경우라면,
  • IDE에서 Xdebug connection을 listen하지 않거나
  • container 내부에서 호스트에 연결할 수 없는 상황…은 다양하긴 하다

작년에 많이 욹어 먹긴 했는데, 회사를 옮기고 사내에서 한번 발표해달라는 요청이 있어 두번에 걸쳐 진행했다.

모던PHP 모임에서 발표하면서, 이걸 이해하는데 어느정도 배경 지식을 알고 있어야 이해가 쉬울 것 같다는 생각을 했었기 때문에 1부는 배경지식 편, 2부는 REST에 대한 발표가 됐다.

이전에 했던 발표가 “당신이 만든 건 REST가 아니지만 괜찮아”라는 관대한 중도적 입장을 취했다면, 이번에는 약간은 시니컬하게 돌아섰다.

“어차피 그거 진짜 REST도 아닌데, 뭘 그렇게 hypertext 같은 제약 조건에 공을 들이는 거야?”와 같은 현실적인 질문을 남기고 싶었다. (아 참, 힙스터들은 hypertext 대신 HATEOAS라고 부른다지 아마)

그리고 예전엔 REST란 이름이 self-descriptive하지 않다고 생각했다.

그런데 REST 논문에 나오는 설명을 다시 읽어보니 이정도면 충분한 이름이다라는 생각도 들었다.

…for distributed hypermedia systems

발표자료엔 이런 생각이 충분히 나타나있지 않겠지만 기록으로/기념으로 남겨보자.

2018-02-02 : 그 REST API는 REST한가? (1/2)

2018-03-30 : 그 REST API는 REST한가? (2/2)

본의 아니게 두 발표의 간격이 꽤나 길었는데, 그 험난했던 순간들이 주마등처럼 지나간다.

지금은 괜찮음. 우리 사람 뽑음.

오픈 소스를 대하는 올바른 자세

http://hl1itj.tistory.com/170

오픈 소스는 아니지만 맞춤법 검사기 때도 비슷한 기분이 들었었지. 법적으로 문제없고 우리도 노력했다는 대기업 법무팀의 의견 같은 의견.

오픈소스를 쓰기만 했지 오픈소스 철학은 전무한 나라라서(나 역시도) 이런 논쟁은 계속될 것 같다.

그런데 또 하나 희안한 점은,
링크에서 언급한 소위 ‘도덕적’ 책무를 다하지 못한 대기업의 이런 행위를 옹호하는 사람들인데, 댓글부대 같지도 않고. 법대로 판단해야 하고 악법도 법이라는 사람들이 참 많다.

이러면서 또 일그러진 영웅에 감정이입하고 피해자 너희가 잘 했어야지로 흐르기도 하는데. 요 부분이 참 희안하다. 어떤 심리인지.

이 링크를 페이스북에 공유하며 적었던 글인데, 조금 날 선 느낌도 있고 내 의견을 충분히 이야기하지 않은 느낌도 든다.
이와 관련해서 다양한 의견을 봤고 그 하나 하나가 틀렸다라고 단정지을 수는 없다.

하지만 더불어 살고자 하는 시민 사회에서 법(그게 법률로 지정된 것이든 오픈소스 정신이든)의 테두리 안에서만 사안을 평가하는 것은 공정하지 못하다고 생각한다. 저작권을 위반하지 않았다거나 혹은 오픈 소스 진영에선 원래 그렇게 하는 것이라는 말로 호통치고 뒤돌아 서는 사회는 끔찍하다. 오픈 소스 진영에서 원래 그렇게 할 수 있었던 기반은 그게 돈이든 기여든 상생하려는 노력이 있었기 때문이라고 생각한다.

나는 내가 페북에 쓴 글에서 마지막 문장에서 더하고 싶었던 말이 ‘정의감’인데, 법에 근거해 약자를 비난하는 자의 심리는 정의감이 아닐까 생각이 들었다. 남성이 역차별 당하고 있다는 사람들도 정의감으로 똘똘 뭉쳐있지 않은가! 이번 사안에서 카카오에 문제가 없다고 판단한 분들을 동급으로 생각하는 건 아니고, 그 중에 일부, 올챙이를 한심하게 바라보는 일부 중 일부를 보면서 그 묘한 정의감이 느껴졌기 때문이다.

왜 그게 정의롭다고 생각하게 됐을까 고민해보면 이건 또 피해의식의 관점에서 봐야할 것 같은데, 내가 전문가도 아니고 계속하면 허무맹랑한 소설이 되어버리니 이쯤에서 그만.
대중교통을 이용하면서 느끼는 아줌마들의 그 치열함도 남자도 차별 받는다는 젊은이들도 아직 취업 준비를 하면서 인천 공항 정규직 확대를 반대하는 사람들이나 온통 피해의식에 휩싸여 있는 것 같다. 는 소설을 써본다.

Time Report

http://lovesera.tistory.com/1072

‘시간을 정복한 남자 류비셰프’ 독후감인데 내 눈을 사로잡은 건 저 Time Report다.
요즘 생산성을 높이기 위한 여러 방법을 알아보고 노력 중인데,
저렇게 시간 기록을 해두면 내 생산성의 민낯을 보여줄 것 같아 차마 손이 떨어지지 않는다.

언젠가 시도해보길 희망하면서 아카이브.

독서 노트만 보면 류비셰프는 제프딘이나 척노리스 급으로 생각이 드는데…

책이 막 궁금해지지는 않는다.

배우는 방법을 다시 배우기

http://jhrogue.blogspot.kr/2018/02/b.html

읽기 전에, 무엇을 배우고 싶은지 고려하자

읽어야 할 것이 넘쳐난다. 읽기 전에 무엇을 배우고 싶은지 고려해보니 새삼 읽지 않아도 될 게 많이 보이기도.

학습에 실패한 이야기

http://woowabros.github.io/experience/2017/12/11/how-to-study.html

참 좋은 고민이다.

출근 한시간 이상 걸리는 회사로 이직 후 하루 5시간 이상의 개인 공부를 해본 적이 없는 것 같다. 짧은 호흡으로만 공부를 하다보니 뭔가 제대로 익힌 게 없는 느낌이다.
모든 게 익숙했던 회사에서 모든 게 낯선 회사로 오니 - 게다가 자율 출퇴근이라 - 가장 관리하기 힘든 것이 시간이다.
조금씩이라도 시간을 확보해 나가야겠다.

아인슈타인, 다윈, 니체를 성공으로 이끈 2시간의 법칙

http://newspeppermint.com/2017/09/20/m-2hours/

요즘 월요일 출근 시간에 일주일 동안 해야할 일을 생각해보고 목요일 퇴근 시간에 지난 일주일을 돌아보기 시간을 갖고 있는데, 애초에 2시간 정도로 길게 할 생각은 없었음에도 점점 고민하는 시간이 줄어들고 얼른 끝내서 다른 뭔가를 더 하고 싶다는 열망에 가득차 버리는 것을 경험했다. 조급함이 있는가보다.

오은영 박사의 글로만 읽어서는 잘 안 되는 육아 듣기

https://audioclip.naver.com/channels/349

너무 친절해서 몸둘바를 모르겠지만 최전선에서 육아를 담당하는 분들에게 차분하게 설명하는 이런 방식이 참 따스하다고 느꼈다.

나는 미투 운동이 불편하다

https://steemit.com/kr/@polonius79/7euumt

남자 입장에선 참 언급하기 어려운 주제라서 최대한 말은 아끼고 있다. 지금 이 글도 썼다가 지웠다가 반복하는데, 그냥 응원한다는 이야기 정도만 남겨야겠다. 그게 내가 되더라도 계속 이어졌으면 좋겠다. 그게 내가 되면 좋을 건 없겠지만 그게 맞다. 나는 여성을 대상화하고 성희롱이 당연한 사회에서 분명 살았기 때문에 수많은 동료가 나락으로 떨어지는 것을 보게될 것도 같다. 그게 내가 되면 좋을 건 없겠지만 그게 맞다.

<사피엔스> 저자, 유발 하라리 강력 추천

이라는 문구에 묻어가야 했던 안타까운 책.

유능한 수학 박사이자 종신 교수로 지내다 현실 세계에 수학을 활용한다는 아이디어에 매료되어 헤지펀드 회사에서 퀀트로 지내다 금융계의 몰락(아직 정신 못차렸지만)을 체험하고 수학이 얼마나 파괴적으로 쓰일 수 있는지 충격도 받고 지금은 월가점거운동의 하위조직에서 알고리즘을 감사하고 위험성을 측정하는 기업에서 일하고 있다는 캐시 오닐의 책이다.

꽤나 매력적인 좌파 선생님이다. 번역이 꽤나 깔끔해서 잘 읽히는 것도 있겠지만, 이 양반 글솜씨가 꽤 좋다.

대량 살상 무기(weapons of mass destruction)를 비틀어 대량 살상 수학 무기(weapons of math destruction)라는 용어를 만들고 이를 대량 살상 무기와 같은 무게감을 느끼게 하기 위해서인지 그와 똑같은 축약어 WMD를 꾸준히 사용한다.

WMD가 되기위한 최소 조건으로 불투명성, 확장성, 피해를 든다. WMD들은 어떤 조건으로 수학 모형을 만드는 지 알 길이 없고, 이를 통한 결정으로 발생한 득실을 따져보고 데이터를 조정하는 피드백 과정이 없다. 피해를 받은 사람은 여기서 끝나지 않고 이 데이터를 활용한 또 다른 파괴적 피드백 루프에 빨려 들어간다. 그리고 피해를 받는 것은 사회적 약자들부터.

매우 합리적으로 보이는 빅데이터 기반의 판단/의사결정이 인간의 편견이 그대로 들어간 대리 데이터(직접적인 인과관계를 나타내는 데이터를 구할 수 없어 선택하는, 상관있어 보이는 다른 데이터)를 활용해 불투명하게 관리되고 확장해 나가는 모습을 교육/노동/치안/정치 등 다양한 방면에서 찾아 보여준다. 그리고 WMD들은 서로 데이터나 모형을 가져다 응용하기도.

난 마치 다큐멘터리처럼 빅데이터도 모으는 사람, 분석하는 사람의 관점이 들어갔을 거라는 생각은 많이 해봤지만, 거기서 피해를 받는 사람을 이렇게 깊이 생각해보지는 않았던 것 같다.

그리고 의외로 미국의 교육이나 노동 현실은 우리나라 못지 않게 비인간적이라는 생각도 든다. 우리나라만이 아니라 미국도 이미 약자들에게는 헬이다. 정말 우리나라와 많이 닮았다는 생각이 들었다. 거기다 이 분 남편이 집안일도 안 도와주는 것을 언급하는데, 아…이런 고향의 맛이라니.

사실 중간이후로는 조금 지루하기도 했는데, 이 썩은 시스템이 너무 뻔한 수작을 부리고 있기 때문이다. 다 그렇게 약자부터 빨아먹고 약자부터 약자부터.

인적성검사

이중에 매우 가슴에 와닿은 한가지는 인적성검사인데,

이직하기 전 회사에서 인적성검사를 구인 프로세스에 붙이는 일도 했었지만, 나는 인적성검사를 매우매우 싫어한다. 그 회사 들어갈 때도 검사를 봤는데, 긴장을 했는지 시간 계산을 잘못해서 완전 개판으로 쳐놨다. 아마 100점 만점에 30점 나왔던 것 같은데…
그럼에도 불구하고 날 뽑아다 써주신 건 감사한데, 회사 입장에서 그게 잘 한건지 아닌지는 잘 모르겠지만 내가 적어도 30점짜리 직원은 아니었던 건 확실하다.

인적성검사를 만드는 회사를 보면 이런저런 연구진이 막 열심히 엄청 대단하게 만드는 것처럼 해놨는데, 누가 어떻게 만드는지도 모르겠고 그게 얼마나 효과가 있는지 오류가 정말 없는지 알 길이 없다. 인적성검사 자체는 그렇다치고 그게 업무에 도대체 무슨 연관이 있는지도 모르겠다. 검사를 개판으로 치고 들어왔는데 좋은 직원이거나 아니면 검사는 잘 봤는데 막상 들어와보니 그지같은 직원이었다면, 그 검사에 피드백을 줘야 하지않나? 하지만 그럴리가 없다. 그 검사는 회사 업무와는 전혀 상관없고 영업기밀이라 밝힐 수 없는 내부 알고리즘이며 한두 업체에 커스터마이징 해주기에는 단가도 너무 낮고 각 업체는 영세하다. (검사 결과를 이해하는 인사팀 내부 정책에 피드백을 줄 수 있긴 하다)

나도 가끔 면접에 들어갈 때 인적성검사 표를 들고 갔었는데, 뭔가 그 사람이 마음에 안들면 괜히 인적성검사에서도 안 좋게 나온 부분을 찾기도 했다. 이건 뭐랄까 혈액형 심리테스트에서 맞아맞아 이건 내 이야기야라고 생각하는 심리 같기도. 요즘 추세는 인적성검사가 등수를 나누는 게 아니고 성향 분석을 해주는 것이라고는 하지만, 어차피 각 기업에서는 그걸로 등수를 만들어주기를 원한다. 난 쓰레기만 걸러내면 좋아요 같은 느낌이랄까, 혹은 이왕이면 다홍치마랄까.

결국 제대로된 인사팀이라면 인적성검사로는 충분한 해답을 못 얻는 게 정상이고, 그냥 참고하는 용도로만 받거나 데이터를 쌓아 나중에는 인적성검사 결과를 활용할 수도 있을 거라는 희망을 갖는 수준일 것이다. 과연 도움이 될까 모르겠지만 말이다. 어쩌면 매년 절에서 부적 하나씩 받아오는 어머님 심정으로 인적성검사를 받는 것인지도 모르겠다. 이걸 통과하면 훌륭한 직원이 될 것입니다. 비나이다.

결국 평범한 직원이 유리한 게임같기도 하다. 훌륭한 인재를 놓치는 것보다는 똥같은 직원을 걸러내는 것이 더 중요한 회사도 분명 있으니까 절대 쓰지 말라고는 못하겠다. 인재는 중요하고 그만큼 간절한데 부적하나 걸어두는 것이 뭐가 그리 문제인가 싶기도 하다.

하지만 내가 다니는, 내가 다닐 회사는 데이터에 기반한 결정을 하되 그 데이터를 의심할 줄 아는 회사였으면 좋겠다.

이걸 보는 각계의 인사팀은 우리가 그렇게 아마추어처럼 일을 하겠니라며 혀를 끌끌 차겠지만, 인적성검사가 유의미한 데이터가 될 수 없다는 것 하나는 양보를 못하겠다.

결론

뜬금없이 인적성검사에 열을 올렸지만, 스스로 합리적으로 판단하는 모습을 보여주려는 인간들의 논리에 얼마나 많은 빈틈이 있는지 너무 생생하게 콕콕 잘 짚어주는 책이었다는 걸 말하고 싶고, 많은 데이터를 다뤄야 할 때나 가설을 세울 때 특히나 피해받는 사람이 생길 가능성이 있다면 더욱 신중해야겠다는 교훈을 You Know, I Learned Something Today 하면서 마칠까 한다.

자바스크립트의 동작원리: 엔진, 런타임, 호출 스택

https://joshua1988.github.io/web-development/translation/javascript/how-js-works-inside-engine/

매번 봐도 또 매번 까먹거나 입으로 설명이 안 튀어나오는 자바스크립트의 호출 스택

자바스크립트 비동기 처리 과정과 RxJS Scheduler라는 글에서도 비슷한 내용을 다루는데 둘 다 이해하기 쉽게 쓰여 있다.

Mac@Work 맥을 기반으로 한 업무 10년 경험의 추천 앱 모음

업무에서 Mac을 본격적으로 다루기 시작한 지 이제 막 한달이 됐다.

수년 동안 Mac을 사용한 사람들의 노하우는 항상 궁금한데, 꽤 과하다 싶을 정도로 많이 쓰고 계신 분의 글을 오래오래 들춰보고자 저장.

윈도우는 킬러앱이 고만고만한 편인데, 맥은 너무 다양해서 둘러보는 데도 지친다.

난 일단 버티고 버티다가 생산성 안 나오면 앱을 찾는 편인데,

최근에는 결국 뽀모도로앱 Just Focus과 달력 앱 Itsycal을 설치했다.

이제 화면 분할 앱을 찾고 있는데, 단축키 충돌로 잘 안 쓰게 됐던 Spectacle을 다시 깔아야 고민 중.

물론 당분간 스플릿 뷰(Split View)로 버틸 수 있을 것 같기도.

이외에도 무료 앱 소개 페이지는 엄청 많고 세상은 넓고 앱은 많다.

국내 맥 사용자에게 추천하는 무료 앱 12선

복잡한 기술 스택이 경영진에게 주는 시사점

http://www.popit.kr/복잡한-기술-스택이-경영진에게-주는-시사점/

만약 복잡한 기술 스택이 굳이 필요하다면 말이지만.

기술 분야는 노인 경영인에게 절대적으로 불리하다는 생각도 든다. 노인 폄하인가? 꼰대라는 용어가 적당할 지도.

성공의 의미를 떠나 회사가 돈을 버느냐는 또 기술과는 별개인 경우가 많지만,

아무래도 비용 면에서 이놈의 기술 스택은 부담이 많이 된다. 하드웨어/소프트웨어/인건비 등등.

경영인이 기술 스택을 이해하기는 어렵기도 하고 결국 약은 약사에게 기술은 CTO에게.

CTO는 무슨 일을 하나?라는 글에서는 (좀 많이 큰 회사의 CTO의 역할을 이야기 하는 것 같지만) CEO와 기술자 사이에서 어떤 역할을 해야하는지 잘 나와있다.

그런 역할을 잘 할 수 있는 CTO를 구하기는 너무나 어렵다는 걸 잘 알고 있고,

그렇다고 내가 저런 CTO의 역할을 할 수 있을 거라 생각도 안 하지만 그 고생을 하며 더 얻고 싶은 것도 없어서,

큰 욕심 안 부리고 평직원으로 오래오래 살아야 겠다.

케이스 접근법에 대하여

http://seoworld.net/wp/?p=3085

새로 옮긴 회사는 태초부터 미국물이 섞인 회사라서 그런지 어떤 회의나 세미나에서도 질문이나 자기 의견을 거침없이 말하는 경우가 흔하다. 외국 생활을 한 사람일 수록.

나는 질문이나 의견 내는 것에 심리적인 거부감이 (한국인 치고는) 덜한 편인데,

남들의 의견을 들으면서 동시에 질문이 막 샘솟지는 않는다. 특히 세미나 발표를 들으면 막 몰입해서 듣지 이건 왜 이럴까 저건 왜 저럴까 궁금하지 않다가 질문 시간이 끝나면 하나 둘씩 궁금한 게 생기기도.

영화를 볼 때도 어지간한 반전에는 다 놀랄 정도로 남들이 전해주는 흐름에 흠뻑 빠지는 편이기도 하다.

어쩌면 정보를 메모리에 올리고 정리하는 시간이 늦는 것 같기도 하고.

독서토론회 같은 데를 가면 좀 나아지려나? 회사일에 어느정도 익숙해지면 꼭 참여해보고 싶다.

가독성 높은 글을 쓰는 노하우

https://steemit.com/writing/@pelexus/6462nh

공감이 많이 된다. 이 분의 글쓰기 원칙은 SRP을 비롯 클린 아키텍쳐를 지향하고 있…

프런트엔드 개발자가 되고 싶지 않았던 프런트엔드 개발자의 이직기

https://milooy.wordpress.com/2018/02/07/moving-job/

이 양반이 대단한 개발자는 ‘아직’ 아니겠지만, 꽤 좋은 작가인 것 같다.

내가 많은 여성 작가들에게 느끼는 건데, 섬세하고 감성적인데 친절하고 자기 주관이 있는 글을 쓰신다. 그러니까 ‘여성 작가’ 느낌이다.

여혐 논란이 있을 순 있겠지만, 굳이 여성을 언급한 것은…이 느낌은 정말 남성 작가에게는 발견되지 않는 것 같다. 게이 작가라면 모르겠다. 어쨌든 마초성 0%의 글이라고 하는 게 좋을 지도.

내가 문학이랑은 담을 쌓았기 때문에 글의 예술성은 모르겠고, 기능적으로 참 좋다는 생각이다.

이 분의 글이나 발표는 항상 타이밍도 좋고 자신을 낮추면서 자랑도 잘하고 공감도 잘 된다.

이 분의 업계 포지션(?)이 성장 가능성이 큰 풋풋한 어린 개발자라고 생각하는데, 아이유가 갖고 있었던 그런 느낌이랄까. 감히 ‘IT계의 아이유’ 따위의 자극적인 표현을 쓰려는 건 아니고, 참 테크를 잘 타고 있다 정도로.

아무튼 저기 나온 회사들 반 정도는 알 것 같은데, 선망의 대상이 되는 회사(재벌의 소유물이 아닌)가 꾸준히 느는 것 같아서 기분이 좋다.

대기업 다니는 친구들을 만나고 오면 더욱 여실히 느낀다.

왜 카카오뱅크에 주목하는가 (1/2)

https://brunch.co.kr/@usdlab/13

왜냐면 비교 대상이 엉망이라서…라고 생각도 하지만 카카오뱅크는 꽤 공을 들인 느낌도 많이 든다.

퇴직금도 들어왔으니 올해는 카카오뱅크와 토스를 입출금 외에도 조금 써볼까.

오렌지 주스 테스트

https://johngrib.github.io/wiki/orange-juice-test/

남에게 요구하면 완전 개꼰대. 스스로에게는 독촉해야할 문제라고 생각. 생각은 해도 쉽지 않은 문제.

DDD

최근 DDD 관련 저장해 놓았던 링크들..인데 읽지 않음

Learning DDD as a Team을 소개한 포스트
Eric Evans의 DDD와 Microservices에 대한 발표를 소개한 포스트

바지는 내리고! 치마는 올리고!

http://deulpul.net/4146438

분명한 것은 이러한 사회적 반성의 과정을 통해 인간 세상이 한 단계 업그레이드되고 있다는 점이다. 인류 역사가 진보의 과정이라는 것을 믿지 않는 사람이라도 이런 점을 부정하기는 어렵지 않을까.

나는 죽을 때까지 건배사를 안한다 하더라도 한치의 아쉬움도 없다.

여기서 언급된 건 건배사와 성희롱이 섞인 문제이고, 그 둘이 별개인 것처럼 보여도, 그 둘이 득세하게 된 건 결국 기득권의 가학적 취향 탓이라고 본다.

아무 계획 없던 고등학생에서 어쩌다 IT 업계를 택하게 일하게 된 내 삶은 쉽진 않았지만 꽤 운이 좋았다는 생각이다.

대기업 다니는 친구들을 만나고 오면 더욱 여실히 느낀다.