• 
• ★★★☆☆ 2026-03-07~08 1장의 글로벌 대기업(MS, 아마존 등)의 성공 사례는 좀 뻔한 감이 있어 조금은 지루했다(최근 대량 해고까지 겹쳐서 더 그런 생각이 든다). 그러나 그 뒤에 이어지는 각 장은 내용의 수준은 각자 다르게 받아들일 수 있어도, 최소한 직접 해보고 부딪혀서 성과를 만들었다는 생각은 충분히 할 수 있을만큼 충실히 작성했다고 생각한다. 이 책에서 가장 중요한 부분은 여기 같이 올려둔 세 페이지에서 드러난다고 본다. 도구도 중요하지만 더 중요한 건 문화고, 도구 이전에 사람이 받아들여야 하며, 반복적인 성공의 경험을 해야 한다는 점이다.

• 
• github.com/golbin/TensorFlow-Tutorials
• 장점; 얇은 책이 갖는 전형적인 장점을 갖는다. 수식이나 이론적인 이야기들보다 코드를 통한 실습에 중점을 두어 부담없이 읽을 수 있다. 책 출간 시점까지 최신의 내용을 담으려고 노력했다.
• 단점; 얇은 책이 갖는 전형적인 단점도 갖는다. (물론 개인 실력의 문제이긴 하지만 나의 경우) 읽고 나서 뭘 해보려고 해도 기초가 없이 봤더니 감이 잘 안 잡힌다. 기초가 없는 경우 읽기 전후로 기초 강의를 듣고 반복적으로 보는 게 좋을 거 같다.
• 결론; 당연한 말이지만, 기초가 없는 경우 많은 노력이 필요하다. 그래도 다가가기 어렵다는 생각이 들 때 시작을 하기 쉽게 도와준다는 점 만으로도 가치가 있다고 생각한다.
• tip; 실습할 때 version이 바뀌고 설치도 귀찮은 경우 docker를 이용하면 편리하다. 조금 큰 걸 돌리려고 하면 속도가 많이 느리지만, 간단한 예제 정도는 간단히 할 수 있다.
  • docker로 tensorflow image를 가져와서 실행
    • 
  • jupyter notebook 접속
    • 

• 상황
  • flask API server에서 다른 server(tornado)를 호출해 결과를 만드는 API가 있는데, 결과가 비정상
  • 비정상인 이유는 중간에 timeout이 발생했기 때문
• 아주 간략한 전체 흐름
  • 
  • ePattern API를 시작하면 (내부 콜은 생략하고) Extract API를 호출
  • Extract API는 library call로 sparser 호출
  • sparser가 Entity API를 호출
  • 리턴, 리턴, 리턴이 발생하면 정상 종료
• ePattern API는 requests.get으로 Extract API를 호출
  • 
• sparser는 libcurl의 curl_easy_perform으로 Entity API를 호출
  • 
• timeout 발생 이유
  • 
  • sparser는 Entity API의 리턴을 기다리지만, 여기서 timeout이 발생
  • 왜냐하면 flask server는 ePattern에 대한 리턴값을 Extract API에게서 기다리는 중이라, 이걸 먼저 해결해야 그 다음 Entity API를 처리해줄 수 있기 때문
• 해결 방법
  1. storage API의 흐름을 asynchronous하게 (X)
     • flask development server가 single threaded + synchronous
     • 이걸 async로 만드는 플러그인이나 기타 다른 방법이 있지만, 번거롭기도 할 뿐더러 성능상 이점이 있는지, 안정적인지 알 수가 없음
  2. storage API의 Entity / ePattern을 별도 서버로 만들어서 각각 호출 (O)
     • 가능 하고 간단
     • 지금까지 한 서버에서 호출하면서 url만 다르게 하던 걸 port를 바꿔서 해야 하고, 소스 관리가 조금 귀찮아짐
  3. production을 위해 준비했던 apache server 사용 (O)
     • 원래 서비스용으로 준비했던 apache server를 이용하면, multi threaded로 동작하기때문에 위와 같은 문제가 발생하지 않을 걸로 생각했고, 실제로 해결

Situation

• Necessary to import CSV file into MySQL

Environments

• Redhat 6.6 (CDH5.3 installed)
  • python 2.7.11 / python3.5.1
• Redhat 7.3
  • python 2.7.5 / python3.6.1
• kafka 2.11-0.10.2.0; Download
  • Quickstart
  • execution

• 상황; server 이전으로 인해 cloudera manager로 관리하는 hadoop server들의 ip address가 변경
• server 이전하기 전 처리 내역; cloudera manager에서 cluster및 cloudera management service 정지 후

처음 시작하는 AWS 람다

• 
• 프로그래밍 관련 소식이나 블로그를 보다 보면 몇 년새 AWS에 대한 이야기가 폭발적으로 늘어났다는 걸 알 수 있다. 그와 함께 서버리스 아키텍쳐에 대한 관심도 증가하면서 자연스레 AWS lambda에 대한 소식도 많이 볼 수 있다. AWS lambda에 대해 관심은 있지만, 선뜻 시작하기 어렵게 느껴질 때 보기 좋은 책이란 생각이 든다
• 장점
  • 정말 실제로 사용해본 경험을 바탕으로 썼다는 점이 느껴진다. 특히 lambda를 사용하지 않아야 하는 경우를 설명하는 14장이나, 비용에 대해 알려주는 19장의 경우가 좋았다
• 단점
  • node.js로 예제를 설명했는데, 비교적 간단하다고 하지만, 사용해본 적이 없는 입장에서 약간 거북할 수 밖에 없었다(물론 node.js 사용자라면 반대로 장점)
  • AWS 관련 서비스를 실제로 사용해본 적이 없는 사용자라면, 좀 헤멜수도 있다고 예상한다. 한꺼번에 많은 이야기가 나오니 초반부(hello world 예제) 이후로는 따라가기가 좀 버거웠다. 책의 컨셉 자체가 빠르고 간단하게 볼 수 있도록 군더더기를 제거하고, 각 장도 짧게 구성하려 한 점은 이해할 수 있으나, 대상이 초중급이라면 조금만 더 보기 쉽게 설명하면 좋겠단 생각이 든다

• (NOT YET) 그래픽노블 파리 코뮌 : 민중의 함성
  • 한라 926.068-타297ㄱ
  • 탐라 문868-자87ㄱ

(성공적인 애자일 도입을 위한) 에센셜 스크럼

• 별 생각없이 도서관에 신청했던 책인데, 책이 도착해서 빌리고 보니 마침 요즘 내 상황에 필요한 책이었다. 두껍고 당장 어디에 쓸 건 아니라 자세히는 아니지만, 하룻만에 읽었는데, 너무 복잡하고 자세해서 필요없는 부분도 있었지만, 소득도 있었다. 애자일과 스크럼에 대해 관심이 있다면 확실히 추천할 만한 책이란 생각이 든다
• 맘에 안 든 부분
  • 스크럼 자체가 복잡해서 그런건지, 아니면 저자가 가능한 모든 걸 풀어서 설명하려고 해서 그런지는 모르겠지만, 아무튼 책이 두껍고 복잡한데다, 실제로 업무에 적용하려면 쉽게 할 수 있을지 잘 모르겠다
  • 예를 들어 prioritized와 ordered 중 어느 용어가 적절한지 논란을 하는 게 개발자에게 무슨 의미가 있을까?
• 맘에 든 부분
  • 정말 자세하게 설명한다…는 나에게 큰 장점은 아니지만, 관심이 있는 사람에게는 (열심히 읽으면) 도움이 될 거 같다
  • 하나는 확실하다. 책의 시작이 우선순위를 결정하는 일이라는 점을 통해, 어떤 일을 하건 어떤 프로세스를 사용하건 항상 최우선으로 할 일은 할 일을 정하고, 일의 순위를 결정하는 일이라는 걸 다시 한 번 확인할 수 있었다
  • 이어달리기의 비유, “선수들이 아니라 배턴을 봐야 한다”
    • 모든 선수들이 100% 바쁘게 한다고 해서 릴레이 경주에서 금메달을 딸 수 없다. 바닥에서 뒹구는 배턴은, 제품 개발 상황에 비유하면, 할 준비는 되어 있지만 필요한 자원을 기다리느라 중단된 일과 비슷하다. 배턴이 땅 위에 있을 때는 경주, 즉 제품 생산에서 이기지 못한다
    • 직원이 아니라 일에 초점을 맞춰야 한다는 의미
    • 단 이어달리기 경주 방식으로 다른 사람에게 일을 전달하는 건, 우리가 피해야 할 전통적, 순차적 제품 개발 방식
• 몇 가지 기억할 부분
  • 스프린트
    • 
    • 스크럼 프레임워크의 뼈대로, 짧거나 지속적인 기간을 가지며, 한 번 시작한 이상 바뀌어서는 안 되는 목표를 가지며, 팀이 정의한 완료에 최종적으로 도달해야 한다
    • 목표를 제대로 정하고, 한 번 정하면 무조건 완료해야 한다는 뜻일까? 빈번하게 바뀌는 상황에 대응하려면, 스프린트가 짧아야 하기 때문에 최대 1개월로 정의하는 걸까?
  • 제품책임자
    • 
    • 제품 리더십의 중심점이며 권한을 부여받은 사람으로 최소한 두 가지 방향을 볼 수 있어야 한다
    • 제품 관리자로서 조직의 이해관계자들, 고객, 사용자들의 목소리를 대변할 수 있을 만큼 그들의 필요와 우선순위를 반드시 잘 이해해야 한다
    • 무엇을 만들어야 하며 어떤 순서로 만들지를 개발 팀에게 반드시 전달해야 한다. 반드시 제품 기능 인수 기준이 명시되었는지 확인하고 이 기준을 검증하는 테스트가 기능 완료를 결정하기 위해 나중에 실행되는지 확인해야 한다. 테스트를 자세히 작성하지는 않지만, 상위 수준의 테스트가 작성되었는지 확인하고, 이 테스트를 사용해 언제 기능이 완료되었다고 판단한다
    • 즉 일부 비즈니스 애널리스트, 일부 테스터
  • 스크럼마스터
    • 
    • 
    • 애자일 코치로, 개발 팀과 제품 책임자 양측의 역할 모두를 코칭해 역할 간 장벽을 없애고 제품 책임자가 직접적으로 개발을 주도할 수 있게 한다
    • 스포츠 팀의 코치와 비슷하게, 팀이 스크럼을 어떻게 사용하는지 관찰하고, 팀이 다음 수준의 능력에 도달할 수 있도록 돕기 위해 할 수 있는 모든 일을 한다
    • 스스로 문제를 해결할 수 있도록 돕기 위해 있지만, 팀이 문제를 해결할 수 없다면 스크럼마스터가 이를 주도적으로 해결한다
    • 제품 책임자와의 관계는 스포츠 팀 구단주와 팀 코치의 관계와 같다. 제품 책임자가 스크럼을 이용해 비즈니스 결과를 최대화할 수 있도록 돕고, 기대치를 관리하고, 제품책임자가 팀이 필요한 것을 제공하도록 하고, 제품 책임자의 불만과 변화에 대한 요구사항을 듣고 팀을 위해 이를 행동 가능한 개선점으로 해석한다
      • 이 부분은 이해가 잘 가지 않음
    • 서번트 리더, 프로세스 지휘자, 방해 보호막; 이 부분은 이해가 가기는 하지만, 방해 보호막의 역할을 현실적으로 어떻게 할 수 있을까?
• OKR과의 충돌(?)
  • OKR은 지금까지 이해한 바로는 달성할 수 없는 목표(목표의 60~70%만 달성하면 성공으로 간주)를 세우고 노력하는 건데, 스크럼의 경우 스프린트는 무조건 완주해야 하는 목표를 세우고 스프린트를 반복하는 거라면, 이 둘을 같이 하려는 리더는 어떻게 이해해야 할까?

뭉크

• 
• 도서관에서 우연히 발견하고 아주 재미있게 읽은 책. 뭉크에 대해 새로운 면도 알게 되었고, 재미있게 읽었다. 뭉크의 생애를 주로 어디서 그의 예술작품이 기인했는지에 초첨을 맞춰 그렸다는 생각이 든다
• 예술가들에게서 흔히 볼 수 있는 점
  • 여성편력. 분야에 관계없이 정말 흔히 볼 수 있는 특징(?) 책임감 없이 헤어지고, 나중에 그리워하는 것도 마찬가지
  • 정신병에 걸릴 지경인 가정환경
    • 
    • 
    • 
  • 아버지에 대한 감정
    • 
• 약간 다른 점
  • 의외의 정치력? 장학금을 받기 위한 타협
    • 
  • 살해의도? 루드비히 카쉬튼에게 총을 쏘려고 함
• 그림
  • 눈에 보이는 게 아니라 자기가 본 것을 그리기 위한 여정
    • 
    • 
    • 
  • 절규
    • 삶에 대한 견디기 어려운 불안. 세계에서 가장 심하게 병이 든 자화상. 미친 사람만이 그릴 수 있다
    • 
    • 크라카타우 화산 폭발
      • 
      • 뭉크의 〈절규〉는 단순히 심리의 반영일까
  • 같은 주제의 그림을 반복해서 그리는 건 디버깅?
• 기타
  • 100년 넘은 집
    • 
  • 기성 세대에 대한 불만
    • 

만들면서 배우는 워드프레스

• 한빛 미디어에서 리뷰를 제안해서 읽어보게 되었다. 워드프레스는 관심만 있었지 실제로 써보지는 못했는데, 좋은 기회가 될 거 같아 바로 하겠다고 말씀을 드려서 책을 받게 되었다.
• 책을 처음 받고 우선 대략 훑어보니, 개발자용 책은 아니고, 무료나 가능한 적은 비용으로 자신의 홈페이지를 운영할 사람들을 대상으로 한 책이었다. 호스팅부터 시작해서 설치, 사용 방법 및 필요한 플러그인에 대해 가능하면 자세하게 설명한 걸로 보였다. 나는 무료 호스팅 서비스를 사용할 계획이 없어서, 어떤 방식으로 설치를 해볼까 하다가 docker를 사용해 설치하면 간단하게 테스트할 수 있을 거 같아, 이 방법을 쓰기로 결정했다.
• 검색을 하면 다음과 같은 link를 쉽게 찾을 수 있고, 해당 설명대로 docker-compose.yml만 만들고, docker compose up -d 명령을 주면 아래와 같이 docker가 구동이 된다.
  • Quickstart: Compose and WordPress

• book.daum.net link
• 요즘 들어 책 읽는 속도가 정말 엄청나게 느려졌다. 나이가 들어서 느려지기도 했고, 예전만큼 책 읽는데 시간을 쓰지 못하는 탓이기도 하다. 그래서 읽을 책을 고르는 데 더 신중해야 하기도 한다. 쌓여있는 읽을 책 리스트는 엄청나게 많지만, 다 읽을 수가 없으니.
• 생각의 지도는 가장 최근에 구입한(몇 달 전) 책이다. 여전히 이름만으로 택하는 거의 유일한 저자의 책이다. 미학자로서 쓴 책들은, 처음 그의 책을 읽은지 수십년이 지났지만 여전히 유효하고 오히려 더 재미있다. 이번에도 읽고 나니, 내가 뭔가 더 잘 알게 된 건 없어도 책 자체가 재미있고, 뭔가 뿌듯하다. 이번 책도 개정판인걸 보면 정치 관련 발언 논란이 있어도 인기가 식지는 않은 거 같다.
• 씨네 21에 연재했던 글을 모은 책이라 짧은 글을 주제별로 묶어서 10개 장으로 이뤄져 있다. 생각같아서는 모든 글을 정리하고 싶지만, 가장 기억에 남는 두 가지만 정리해봤다.
• 4부 13 - 눈에 뵈는 아무 증거 없어도 - 신앙주의에 관하여
  • ‘불합리하기 때문에 믿는다는 말’은 사실 아리스토텔레스의 ‘누군가가 믿기 힘든 말을 하더라도 혹시 그것이 진실일지도 모른다고 생각하라’는 말을 배경으로 뒀다고 한다. 그냥 믿으라는 말이 아니라, 조심스럽게 생각하라는 뜻이었으나 잘못 인용해왔던 것.
  • 물론 신앙이 합리적이라면 이미 과학의 범주에 포함이 되거나 필요없어졌을테니 일견 맞기는 하다. 하지만 외부자들의 입장에서 보면 믿음에서 증거를 얻고, 증거는 믿음을 통해진다는 건 명백한 순환논법의 오류이니(히브리서 11:1, 2절을 예로 들었음), 신앙인들과 비신앙인들의 충돌은 필연적일 수 밖에 없다.
  • 창조과학은 신앙에 증거를 제시하려는 방법인데, 신앙주의가 반대하는 게 ‘증거가 있어야 믿는다’는 이라는 걸 생각해보면, 증거주의에 발판을 둔 창조과학이 하는 일 - 현대 과학의 불완전함을 드러내는 - 자체가 논리적 오류나 비약이다.
  • ‘믿음이 증거를 앞선다’는 신앙주의는 수학의 공리와 같은 걸 생각해보면 꼭 틀린 것은 아니기는 하다. 수학에서는 공리를 통해 정리를 증명하고, 정리를 통해 명제를 증명하는데, 공리는 ‘증명 없이 참인 명제’이기 때문에 수학이라는 이성도 그 기초는 믿음에 근거한다고 볼 수 있기 때문이다. 법도 명령/조례의 올바름은 법률에 따라 판단하고, 법률은 헌법에 따라 판단을 하지만, 헌법 그 자체는 그런 증명이 필요가 없다. 헌법의 진리는 혁명이나 전쟁, 쿠데타에 의해 완결되기 때문이다. 비트겐슈타인에 따르면 언어가 작동하려면 화자들이 기본적인 신념을 공유해야 참/거짓을 따지는 언어놀이가 가능하다고 한다.
  • 그런데 수학은 전 인류가, 헌법은 국민 전체가, 언어의 기본적 신념은 언어공동체가 공유하기 때문에 증명 없이 참으로 통하는 전제들을 받아들일 수 있지만, 종교의 경우 신도와 비신도가 있고, 신도간에도 종파의 차이가 있어 공리에 해당하는 부분을 공유할 수 없기 때문에, 증거없이 믿는 다는 게 불가능해지고, 신도에게는 공리이지만, 비신도에게는 증거를 봐야 믿을 수 있는 사건이 된다는 점.
  • 여기서 약간 맥락이 다를 수 있지만, 시오노나나미의 종교의 유대인 철학의 그리스인 법의 로마인 설명이 생각이 났다. 종교는 믿는 사람들에게만 유효하고, 철학은 이해하는 사람들에게만 유효하지만, 법은 누구에게나 적용이 된다는.
• 9부 - 예술의 진리
  • 작가 이름과 작품명을 줄줄 외워대는 ‘지각’으로 예술을 대하지 말라. 송곳같은 ‘감각’을 되살려 예술에 숨어있는 진리를 마주하라
  • 언제나 원하지만 얻지 못하는, 나에게는 너무나 어려운 일. 고흐같이 내가 정말 좋아하는 작가를 대할 때나 아주 조금 이해할 수 있다. 물론 그 전에 저런 감각을 얻기 위한 훈련이 정말 필요한데, 직접 작품을 대하고 느끼고 반추하는 등의 경험(훈련, 연습이란 말은 나에게는 과하니까)이 없으면 거의 불가능한 일인데, 그럴 환경이 되지 않으니 정말 아쉽다.

Agile Scrum

• Mac

• 만약 헤밍웨이가 자바스크립트로 코딩한다면
• 한빛미디어 리뷰어에 신청했는데, 당첨이 되고 나서 받은 책이라 읽게 되었다. 자바스크립트는 정말 기초만 알고, 사용하지도 않기 때문에 내가 책을 선택할 수 있었다면 아마 하지 않았을 것이다. 게다가 일종의 편견이긴 하지만, 개발 서적을 개발자가 아니라 번역가가 하는 경우(이 책의 저자는 그래도 좀 나은 게 개발자 영어라는 페이스북 그룹을 운영하는 분으로 나프다에도 출연)는 보통 기술적으로 오류가 있는 경우가 많아 좋아하지 않기도 한다.
• 하지만, 왠지 폼 나보이는 책 제목에, 리뷰를 써야 한다는 의무감이 겹쳐 읽기 시작했는데, 의외로 금방 읽을 수 있었다. 빨리 읽을 수 있었던 이유는 유명한 작가들에 관한 이야기가 재미있기도 하고, 자바스크립트를 모르니, 코드를 읽기는 하지만, 이해가 안 되는 부분을 하나씩 분석해볼 시간이 없어 그냥 읽고 넘겼기 때문이다.
  • 코드에 관심이 있다면 If Hemingway Wrote JavaScript: Explained.
• 저자는 문학에 대해 관심이 많고, 아주 잘 아는 거 같다. 코드를 보면 자바스크립트를 모르는 사람이라도, 정말 다양한 스타일로 썼다는 걸 알 수 있다. 하지만 문제는 독자도 잘 알아야 이해할 수 있다는 점이 문제이다. 자바스크립트를 사용하며(이런 개발자는 많겠지), 동시에 문학에 대해 잘 알고(대폭 감소), 작가의 스타일을 이해하며(대폭 감소), 그 미묘한 문학적 차이까지 이해하려면 과연 얼마나 남을까? 게다가 이건 번역서라 원래는 해당 작가의 언어로 책을 읽어야 한다는 걸 생각하면…
  • 이건 일단 알고 모르고를 떠나 현업에서 정말 보기 싫은 코드 스타일… https://github.com/angus-c/literary.js/blob/master/book/adams/prime.js

Covariant, Contravariant

• function간의 subtype 관계는 어떻게 형성되는가에 관한 문제
• 이해가 안 가서 그림을 그려서 이해해보려고 했는데, 이해가 안 되도 바로 알 수 있게 한 마디로 정리해줬다.
  • function argument는 contravariant, return value는 covariant
• 
  • 
• 
  • 
  • 
  • 

Troubleshooting

Test

Next you can update your site name, avatar and other options using the _config.yml file in the root of your repository (shown below).