Text
텐서플로우에 은영전을 학습시켜보았다
딥러닝 엔진인 텐서플로우를 이용해서 은하영웅전설 전권을 학습시킨 뒤, 학습한 데이터를 이용해 2-300자 정도의 소설(?)을 쓰게 해 보았다. 물론 이 문장이 이대로 바로 나온 것은 아니고, 열댓번 정도 시도한 뒤에, 그럴듯한 결과물 하나를 선택하고 중간에 완전히 말도 안되는 문장들을 제거한 것이지만.. 의미기반만 조금 더 학습시키면, 확실히 가능할 것 같다. 인공지능으로 소설 쓰는 것. 당장 이 결과만 보면 우습지만, 나같은 문외한도 겨우 몇 일만에 이정도를 만들어 낼 수 있다는 것은, 그렇다면 얼마 지나지 않아 어쩌면 인간보다 나은 결과물을 내는 인공지능이 나올 수도 있다는 말이 아닐까. --- 바로 그 순간 거대한 에너지 중화자장(中化磁場)이 깨졌으며 제 2소대에선 함체의 복합장갑이 관통당했다. 2시 50분, 그때부터 포탄이 초고속으로 스쳤으며, 포탑이나 총좌는 빛과 열에 의해 파괴되고, 작렬하는 파편은 우박이 되어 외벽을 난타했다. 핸드 캐논을 감추어 두었던 것이다. 단호히 자르려는 듯 그는 오로지 얀 웬리 스타일인 일점 집중포격전법을 퍼부었다. 그 누구도 감히 따를 수 없는 완벽한 포진이었다. 이쪽에 조금이라도 틈새가 벌어진다면 방대한 병력을 유기적으로 운용하여 단숨에 회랑을 제압할 것이다. 얀 웬리의 책략이 아닌가 싶어서였다. 오벨슈타인 대령은 한 모금 들이키곤 호흡을 가다듬었다. 모든 것을 때려치우고 싶은 심경이었다. "율리안." "네, 장군님." "페잔의 검은 여우, 그놈의 가죽을 벗겨 군화를 만들어 신어도 시원치가 않겠어." 이렇듯 활발하게 음모를 행사하고 있었을 줄은 전혀 몰랐던 것이다. 신제국력 2년, 우주력 800년 7월 29일. 황제의 시선이 들어오자 휴 소장은 말없이 입을 열었다. "죽이지 않습니다. 당신은 포로입니다." 황제 라인하르트는 두 눈을 감았다.
15 notes
·
View notes
Text
Nodejs 에서 C/C++ 코드를 이용하는 방법
Nodejs 에서 C/C++ 코드(네이티브 바이너리)를 이용하는 방법에는 아래와 같은 세 가지 방법이 있다. 1. addons 사용 : 소스가 C/C++로 되어 있고 소스(헤더)에 접근 가능할 때 2. ffi 사용 : 공유 라이브러리에 접근 가능 한 경우. 또는 소스에 접근은 가능하나 소스가 C/C++이 아닐 경우거나 레거시가 너무 심한 경우 3. fork(child_process) 사용 : 공유 라이브러리나 소스가 없고 실행파일만 사용 가능 할 때 성능은 addons > ffi >> fork 순, 구현 난이도는 반대. 추가적으로 addons 를 사용하는 것이 Javascript 코드를 가장 깔끔하게 만들 수 있다. (라이브러리를 바인딩하기 위한 코드가 없어지므로) ffi 는 node-ffi 를 addons 는 Nan 을 사용하면 편리하다. 생각할 것은, 어떤 방식을 택할 것이냐도 어려운 문제지만, ffi 나 addons 를 사용할 때 async 를 사용할 것이냐 말 것이냐를 선택하는 것이 더 어려운 문제가 아닐런지.
2 notes
·
View notes
Photo
새로운 에디터가 나올 때 마다 이것 저것 써 보고 와~좋다 하지만, 결국은 다시 emacs 나 vim 으로 돌아오게 된다능..
그나마 Sublime Text 는 가끔 쓰는데, 곰곰히 생각해보면 실행 속도 문제가 제일 큰 듯. 터미널에서 vim 속도는 정말 광속이라 항상 가장 먼저 생각날 수 밖에 없다.
3 notes
·
View notes
Text
Serverless 아키텍처의 세상이 온다
AWS Lambda와 API Gateway가 런칭할 때부터 관심은 가지고 있었지만, 대수롭게 생각하지 않다가, 최근에 몇 가지 개인 프로젝트를 하면서 사용해보게 되었는데, 정말 인상적이었다.
"와, Serverless의 세상이 진짜 오는구나."
얼마전에 슬랙 명령어와 개인적으로 사용하는 범용 함수를 간단한 API로 만들어서 사용하려고 했는데, 겨우 이것때문에 EC2등의 서버를 추가하는 것이 좀 부담스러웠다. 그래서 문득 생각난 것이 AWS Lambda 여서 사용해보게 되었다.
"와, 정말 편하다."
아직, 퍼포먼스는 약간 떨어지지만, 관리적인 측면에서 이처럼 편할 수가 없다. 단순히 서버 관리뿐 아니라, 배포나 확장 문제, 또한 보안 측면에서도 거의 신경 쓸 부분이 없다. 물론 이런 것은 Heroku 같은 것을 사용해도 비슷한 효과를 누릴 수 있지만, AWS Lambda는 개별 서버에 배포한다는 개념을 없앴다는 점에서 조금 더 진보한 부분이 있다. "이것이 바로 레알 클라우드 서버야" 라는 느낌이랄까?
또한 작은 기능 단위로 하나씩 만들어서 올려두어야 한다는 점이 개발적인 측면에서도 상당히 좋은 영감을 준다. 반강제적으로 마이크로 아키텍처와 Stateless 개념에 기반하여 만들게 되기 때문에, 의존성을 줄이고 확장성을 쉽게 높일 수 있게 된다. 직접 서버를 운용해야 한다면, 이렇게 작은 기능 기반으로 만드는 것은 서버를 운용하기 까다롭기 때문에 쉽게 접근할 수 없는 방법인데, 서버의 확장에 대한 문제를 고려할 필요가 없으니 쉽게 접근이 가능하다.
이번에 페이스북에서 발표한 메신저 봇 엔진인, wit.ai도 비슷한 면이 있는데, 마치 앱스토어처럼, 개발자는 Lambda에 다양한 함수들을 올려놓고, 사용자는 Lambda에 올려져있는 공개 또는 상용 함수 몇 개와 API Gateway 조합으로 코딩 없이 원하는 기능을 만들어서 사용할 수 있게 되는 날이 멀지 않은 것 같다.
9 notes
·
View notes
Text
생각하며 코딩하기
어제 mecab 랩핑 라이브러리를 만들면서, 명사만을 추출하는 함수를 만들 때, 조건문 부분을 코딩하며 생각했던 사고의 흐름을 소개해본다.
추출 대상이 되는 명사의 태그 종류에는 NNP(고유명사)와 NNG(일반명사)가 있다. 그 외의 태그들도 있지만, 명사만을 추출하는 대부분의 경우는 태그 클라우드 등을 만들기 위함이니 두 가지의 종류만 사용하는 것이 대부분일 것이다.
이 둘 중의 하나의 태그일 때만 로직을 돌게 하려면 조건문을 어떻게 써야할까? if 문을 사용 하는 것이 좋을까? 아니면 딕셔너리 참조등을 사용하는 것이 좋을까?
NNP와 NNG 이외의 다른 태그를 나중에 추가하게 될 수도 있겠지만, 일단은 두 개가 기본이니 거의 바뀌지 않을 것이고, 그렇다면 당장은 명시적인 if 문을 사용하는 것이 좋겠다. 그러면 if 문의 조건은,
if (tag === ‘NNP’ || tag === ‘NNG’) {
이렇게 해야할까? 아니면,
if (tag === 'NNG’ || tag === 'NNP’) {
그럼 둘 중에 어떤 것이 성능이 좋을까? 아무래도 고유명사보다는 일반명사가 대개의 경우 훨씬 더 많을 것이므로, 일반명사의 조건을 앞으로 빼는 것이 좋을 것이다.
그래서 마지막으로 선택한 것이 후자.
이런 방식이 정답은 아니겠지만, 이런식으로 세세하게 로직을 고민하면, 로직의 근본적인 부분까지 고민하게 되어 여러모로 도움이 되는 것 같다.
5 notes
·
View notes
Text
한국어 형태소 분석기 for Node.js
오래전부터 생각만 하다가 최근들어 빨리 프로토타입이라도 한 번 만들어봐야겠다고 생각하고 있는 프로젝트가 있는데, 그 프로젝트에는 한국어 형태소 분석기가 반드시 필요했다.
한가지 놀랐던 것은, 예전과는 다르게 요즘엔 공개된 형태소 분석기가 꽤 많아져서 선택을 하는 것이 오히려 더 어려울 정도였다. (이런 환경을 만들기 위해 애써주신 분들께 정말 감사드립니다. (_ _))
공개되어 있는 다양한 형태소 분석기 중에서 어떤 것을 쓸까 고민했는데, 내가 원하는 기준에서는 mecab-ko가 가장 나았다. mecab이라는 일본어 형태소 분석기를 한국어에 맞게 수정한 버전인데, 일단 로딩 및 파싱 속도가 가장 빠르다는 것이 최고의 장점.
그리고 mecab을 랩핑한 Node.js 모듈이 몇 개 있었는데, 그 중 mecab-async, mecab-ffi 라는 두 개의 모듈이 가장 많이 쓰이는 것 같았다. 다만, 내가 원하는 형식에는 조금 맞지 않아, 야크쉐이빙을 한 번 해 보기로 했다. 내가 원하던 형태는 KoNLPy라서 이 모듈의 인터페이스를 참조해서 만들기로 했다.
그리고 그 결과물 mecab-ya (이제 눈치 채셨겠지만, 사실 이 글은 광고글임다 ㅋㅋ 깃허브에 별점 좀 찍어주십셔 굽신굽신(_ _);;)
mecab-ffi 처럼 ffi 모듈을 이용해서 만들어볼까 했지만, mecab이 워낙 성능이 좋아 ffi 모듈을 이용하는 것과 프로세스를 띄우는 것 차이에 성능차가 거의 없었고, Node.js의 특성상 의존성과 성능측면을 고려하여 프로세스를 띄우는 방법을 쓰기로 했다.
자. 이제 메인 프로젝트를 시작해보..기 전에 밀린 만화책을 보러가자 =3=3=3
5 notes
·
View notes
Quote
凡治衆如治寡 分數是也 鬪衆如鬪寡 形名是也 큰 부대를 마치 작은 부대 운용하듯이 할 수 있는 것은 부대편성에 달려있고, 큰 부대를 마치 작은 부대가 싸우듯이 할 수 있는 것은 명령체계에 달려있다. 故善戰者 求之於勢 不責於人 故能擇人而任勢 전쟁을 잘하는 자는 승리를 형세에서 찾고 사람에게 책임을 묻지 않는다. 따라서 능력있는 자를 택하여 임명하고 그에게 기세를 준다.
손자병법
3 notes
·
View notes
Text
코딩할 때 내가 가장 중요하게 생각하는 규칙. 함수 하나가 한 페이지를 넘지 않게 만들기. (약 30-35라인) 함수 하나가 한 페이지를 넘어가면 반드시 리팩토링을 진행한다. 반복문 내부는 되도록 함수로 변환한다. 이 법칙은 대부분의 경우에 유용하다.
10 notes
·
View notes
Quote
자신이 하는 일에 주인의식을 가지고 프로페셔널하게 행동하고, 고객이 원하는 것이 무엇이든 달성할 수 있도록 돕는다. 다른 개발자들에게 배우고 자신의 지식을 나누며, 경험이 부족한 개발자들을 멘토링하는 것
소프트웨어 장인
3 notes
·
View notes
Quote
You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.
Steve Jobs - http://youtu.be/sr07uR75Qk0
0 notes
Text
프로젝트 관리, 개발 방법론에 대한 소고
내가 접해본 대부분의 프로젝트 관리론, 방법론은 대부분 관리자의 입장에서 관리자가 편하기 위해 만들어진 방법론이라는 생각이 든다. 간단하게 얘기하자면 대부분의 관리 기법은 관리자가 해야 할 일을 실무자에게 떠넘기는 형태가 많다. 일일보고서는 무엇을 위한 것인가? 일이 아니라 관리자를 위한 것이 아닌가? 그런데 그걸 왜 실무자가 하는가? 즉, 대부분의 프로젝트 관리 기법은 실제 일을 "잘" 하는 것과는 별 상관이 없다는 얘기다. 특히나 많은 프로젝트 관리 기법들이 우리나라에 들어오면서 "관리자"의 입장에 맞게 수정된 부분들이 많아서 더 문제랄까. 요즘(?) 많은 곳에서 회자되는 애자일은 개발자를 쥐어짜는 듯한 느낌이고, 그 중 그나마 괜찮은 것을 꼽으라면 칸반보드 사용정도인데, 이마저도 매니저가 부지런하지 않으면 별로 의미가 없다. 관리자가 배워온 애자일(뭐 보통 스크럼?)이 실무에 별 도움이 안된다는 걸 증명할 수 있는 방법은 간단하다. 관리자급이 아닌 실무자 중에 애자일을 지지하는 사람을 본 적이 거의 없다. 내가 생각하기에 관리자는(특히 IT분야의) 그야말로 매니저가 되어야 한다고 생각한다. 연예인, 스포츠선수들의 매니저가 하는 그 일 말이다. 방법론은 사실 잘못이 없다. 관리자가 부지런해야한다. 실무하는 사람들이 보고하기 전에 그들이 뭘 하고 있는지를 항상 알아야하고, 무엇이 부족한지를 물어 채워줘야한다. 나한테 하는 얘기다.
88 notes
·
View notes
Text
개구리 올챙이적 생각
집 앞에 올 초부터 시끄럽게 공사하던 건물이 드디어 완성이 되어간다. 어우.. 이제 좀 조용히 살 수 있겠네. 그 건물은 3층짜리 건물인데 면적도 매우 작고 주차장도 차 한 대 정도 들어갈 정도라서 누가 개인이 살려고 짓나.. 싶을 정도였다. 그런데 오늘 잠깐 몰래(...) 들어가 봤더니 층마다 두 개씩의 원룸 형태. 각각 커봐야 1-2평 정도인 원룸이었다. 와.. 아무것도 없는 지금도 이렇게 좁아보이는데 여기에 이것저것 집기 넣고 하면 어떻게 살지? 라고 했더니 아내가, 나도 결혼 안 했으면 그 정도로도 만족하면서 살았을꺼라고 하더라. 아. 그러고보니 나도 서울에 올라와서 아내를 만나기 전에는, 친척집에서 1평도 안 되는 방에서 얹혀 살거나, 아는 형 원룸에서 얹혀살거나 그랬었다는 걸 잊고 있었다. 돈도 없었지만, 생각해보면 그렇게 살았어도 불편하다는 생각을 크게 하지 않기도 했었고. 누군가에겐 정말 필요한 형태의 집일 수도 있다. 그야말로 개구리 올챙이적 생각 못한다는게 참.. 지금도 넉넉한 집에 사는 건 아니지만, 지금 사는 집엔 주방도 있고 거실도 있는 걸 생각하면 또 얼마나 감사한지. 또, 언제 어느 글에선가 이제 처음 사회 생활을 시작한 직원들에게 가장 필요한 것은, 기숙사를 제공하는 것일 수도 있다는 글이 있었는데, 그 이야기를 다시 한 번 생각해 본 계기가 되었다.
5 notes
·
View notes
Text
JavaScript, Promise 사용을 허하라
우리 회사에서는 Promise를 사용하기 위해 Q 라이브러리를 사용하고 있고, 유닛 테스트를 위해서는 nodeunit을 사용하고 있다.1
특히 Q는 백엔드에서는 모든 라이브러리를 Q로 랩핑해서 사용하는 것을 기본으로하여 Promise 사용을 강제하고 있다. Promise의 장점은 여러가지가 있는데, 내가 생각하는 가장 중요한 장점은 다음의 두 가지라고 생각한다.
callback 로직을 절차형 로직으로 이해하기 쉽게 코드를 만들 수 있다.
예외처리/에러 핸들링을 쉽게 해 준다.
그 중 Promise를 강제로 사용하록 한 가장 큰 이유는 2번의 예외처리 핸들링이다. Express.js와 다양한 Node의 필수 패키지들을 만든 TJ가 Node 진영을 떠나면서 썼던 글(Node.js를 떠나며)에도 나왔듯이, Node는 예외처리/에러 핸들링이 쉽지 않아 Node서버를 자주 죽게만드는 1등 공신이라 할 수 있다.
그런데, Promise를 사용하면 그런 예외처리의 상당수를 쉽게 제어할 수 있다. 그래서 대부분의 로직이 DB/캐시등에 집중되어 있는 웹서비스 개발의 경우, Promise��� 콜백 로직을 모두 감싸면 알 수 없는 예외로 서버가 죽는 경우를 상당부분 막을 수 있고, 로직이 눈에 명확히 드러나므로 디버깅 역시 조금 더 수월하게 할 수 있게 된다.
다음의 예제를 보면, Promise 안에서 예외가 발생한 경우의 처리와 테스트(사용) 로직이 얼마나 깔끔해지는지를 어느정도는 느낄 수 있지 않을까 한다.
테스트 프로젝트 : https://github.com/golbin/q-nodeunit-sample
사람마다 개발하는 방식이 달라서 이것이 반드시 맞는 방법이라 할 수는 없겠지만, 어느정도 사용해 본 결과 Promise는 이제 선택이 아니라 필수로 사용해야 하는 것이 아닐까한다. 신규 프로젝트나 또는 가능하다면 앞으로는 Promise를 강제로 사용하는 것을 추천하고 싶다.
nodeunit을 사용하는 이유는 가장 간단하게 사용할 수 있기 때문이고, Q는 가장 많이 사용되기 때문. ↩︎
4 notes
·
View notes
Conversation
동성혼 합법화와 다양성에 관한 토론
golbin: 나도 동성혼 합법화를 지지하는 입장이지만, 그렇다고 동성혼을 지지하지 않는 사람을 비난하거나 미개하게 생각한다면 그게 더 잘못된 것 아닌가? 정말로 다양성을 인정하는 사람이라면, 동성혼을 인정하지 않는 것도 인정해줘야하지 않나 싶은..
ahastudio: 다양성을 최우선 가치로 여긴다면 그렇겠지만, 대부분의 경우 그 다양성이란 건 몇 가지 검증 단계가 있기 마련입니다. 1+1의 답에 대해 무제한의 다양성을 요구하진 않죠. 우리는 식인, 폭력, 학대에 대해서도 다양성을 열지 않습니다.
ahastudio: 진짜로 다양성이 요구되는 지점은 법적, 물리적으로 특정 권리를 제약하고 있을 때입니다. 흔히 “너는 틀렸어”라고 말하는 건 담론 레벨이고, 앞에서 언급한 것들과는 엄격히 구분돼야 하죠.
golbin: 긴 토론이 필요하겠습니다만, 다양성 인정, 차별에 대한 범주라는 것은 시간이 갈수록 점점 넓어지고 있고, 그 시대에 그것을 받아들이지 못하는 사람이 있는 것 역시 당연하다고 생각합니다. 각기 나름의 다양한 삶을 살아왔으니까요.
golbin: 윤리적인 문제도 마찬가지인데, 이를테면 근친혼이라든가 하는 것도 차별을 받고 있다고 할 수 있는 것이라고 할 수 있지 않을까 싶은데, 이 부분은 대부분이 암묵적으로 당연하다고 생각하는 부분이죠.
golbin: 아무튼 가치관등에 따라 다양성에 대한 정의 역시 ��라질 수 있고, 그러므로 동성혼을 받아들이지 못하는 사람도 충분히 있을 수 있고, 그런 사고방식이 현대에 맞지 않는 것이지 틀린 것이라고 볼 수는 없지 않을까 합니다.
ahastudio: 저는 이런 문제를 만났을 때 그것은 차별이 맞다고 인정하느냐 안 하느냐가 자유주의자인가 아닌가를 가르는 기준이라고 생각합니다. 공통공간에선 결론이 늘 하나라서(대표적인 게 바로 재판이죠), 맞냐 틀리냐에서 벗어나는 건 불가능합니다.
ahastudio: “시대에 맞지 않는다”라고 포장한 건 정치적으로 보면 “틀렸다”는 걸 예쁘게 포장한 것에 불과하죠. 현실에서, 실천적으로, 동성결혼이 법적 허용되냐 마냐에 대한 결론은 하나거든요.
golbin: 그런 관점이라면, 법적으로 허용이 안 된 우리나라의 경우 동성혼은 아직까지는 틀린 일이 되는데요. ㅎㅎ
ahastudio: 아뇨. 그건 제 논리를 거꾸로 읽으신 게 됩니다. 정치적으로 맞냐 틀리냐를 우리는 결정해야 한다는 거고, 그래야 그게 법적/실천적으로 반영됩니다. 우리는 그걸 다양성이란 변명으로 미루면 안 된다는 거죠.
ahastudio: 제가 하는 이야기는, 담론 레벨이 아니라 현실에서는 결국 답이 하나란 겁니다. 이걸 다양성이란 이름으로 포장해봐야 한국 같이 엉터리인 상태가 유지된다는 거죠. 분명히 특정 권리를 제약하고 있는 틀린 상황이죠?
golbin: 즉, 이것이 나에게는 틀린 것이지만 다른 사람에게는 맞는 것일 수도 있다고 봅니다. (물론 저는 틀린거라고 생각합니다만 여튼) 지구가 돈다는 것이 틀린 것이라고 생각했던 과학도 그럴진데, 사고방식이나 가치관은 더욱 그렇죠.
ahastudio: “권리=자유”에 대한 이해가 바로 자유주의와 다른 것을 가르는 경계입니다. 타인의 자유를 침해하는 범죄가 아니라면, 우리의 자유는 제약될 수 없습니다. 이런 게 상대적일 수 없다는 게 바로 근대정치의 기본입니다. 보편인권사상이죠.
ahastudio: 보편인권 이슈를 후퇴시키는 것도 무리고, 이미 벌어지고 있는 현실입니다. 현실을 담론 레벨로 축소하기 때문에 상대주의가 가능한 겁니다. 현실은 그렇지 않죠.
golbin: 아무튼, 그보다 제 논지는 생각의 차이가 있는 사람들을 비난해서는 안된다는 것 입니다. 비판은 할 수 있겠지만요. 더군다나 가치관이나 사고방식 같은 것은 맞고 틀리다는 것으로 재단할 수는 없는 것이라고 생각합니다.
ahastudio: “유태인을 죽이는 것은 정의롭다”란 가치관은 옳다 그르다 따질 수 없을까요? 현실에선 매우 중요한 문제입니다. 상대주의가 적용되는 분야는 이런 곳이 아니죠.
ahastudio: 러브라이브가 옳냐 이이돌마스터가 옳냐 이런 이야기를 하자는 게 아니죠. 미학과 윤리학이 만나는 지점은 있어도 이 둘을 막 뒤섞지 않는 이유입니다.
golbin: 흠. 핀트가 자꾸 나가는 것 같지만 ㅎㅎ 제가 생각하는바도 권리 보장을 위한 차별금지라는 부분에서는 아샬님하고 비슷한데요. 제가 말하고 싶은 요점은 다양성을 존중하지 않는 사람들을 비난하는 것은 옳은 일일까요? 라는 부분입니다.
ahastudio: 골빈해커님의 포지션을 의심하는 게 아닙니다. 제가 계속해서 말하는 건 보편인권=권리=자유 이슈에 다양성은 없다는 겁니다. 모든 내용이 그것의 반복입니다.
golbin: 음, 그러한 권리는 필요 없다는 가치관이나 의견도 있을 수는 있는 것 아닌가요? 그러니까 보편인권 자체를 인정하지 못하는 의견은 있을 수 없다라는 건가요? 그게 아니라면, 그러한 가치관에 대한 다양성을 인정해줘야 하는 것 아닐까요?
ahastudio: “그런 권리”란 게 따로 있지 않습니다. 기본적으로 공화국은 보편인권을 전제로 구성됩니다. 이걸 파괴할 경우 적용되는 게 바로 형법이죠. 현실 문제를 단순 가치관 문제로 후퇴시키면 안 됩니다.
ahastudio: 논의는 단순합니다. “유태인학살”이 옳냐 그르냐를 따질 수 없는 다양성에 속하느냐죠. 아이마스냐 럽라냐와 다른 층위라고 구분하느냐 하는 거죠.
golbin: 음. 그렇다면, 좀 극단적이긴 한데, 보편인권을 전제로 한 공화국인 한국에 태어난 이상 그런 가치관이나 의견을 가지면 안된다는 걸까요? 그럼 다른 나라로 가면 그런 의견을 가져도 되는걸까요? 라는 또 다른 삼천포가 생각나네요. ㅎㅎ
ahastudio: 이것 또한 제 논리를 거꾸로 따라간 겁니다. 우리가 공통영역에서 만든 걸 공화국으로 구현하는 거지, 공화국이 선행하지 않습니다. 제가 아까 이야기한 케이스죠.
golbin: 그렇다면 공화국이 아닌 다른 나라는, 이를테면 인도나 아랍쪽 같은 경우는 차별을 기반으로 한 사회가 공통 영역이었고, 그걸 기반으로 나라가 구현(?) 된 것이지 않나요?
ahastudio: 네, 이건 정말로 삼첨포로 빠졌는데 1) 일단 우리나라는 그렇다란 걸 분리하겠습니다. 2) 인도의 경우엔 공화국입니다. 우리나라와 동일하게 봐도 되죠. 3) 아랍 왕국의 경우엔 국제사회에서 이슈가 됩니다. 바로 UN에서요.
ahastudio: UN은 법적 강제력을 갖고 있지 않지만, 국제연합은 일정한 테두리를 만들어서 운영되고 있습니다. 거기에 세계인권선언이 포함되지요. UN에 가입했지만 그런 건 무시하겠다고 하는 건 늘 비난의 대상이 됩니다.
golbin: 그렇다면 의문은, 모든 나라는 인권에 관해선 궁극적으로는 동일한 가치관을 가져야한다인건가요?
ahastudio: 제가 무엇이 먼저냐를 따지는 걸 보면, 이게 나라에 얽힐 문제는 아니라고 생각합니다. 보편인권은 매우 작고 단단합니다. 이것은 허용범위를 갖는 게 아니라, 불가능을 갖습니다. 서로 충돌하지 않는 범위가 바로 권리=자유의 범위입니다.
ahastudio: 하지만 현실에선 그렇지 않죠. 그 지점을 저는 다양성이 지지하는 게 아니라고 말씀드리고 싶습니다. 그리고, 이건 가치관이 아닙니다. 현실이죠.
golbin: 음. 정리하자면 아샬님 말씀은 동성혼 법제화는 보편인권에 해당하는 것이기 때문에 다양성이 있을 수 없고, 그러므로 그것을 반대하는 것은 인정할 수 없으므로 틀렸다고 말 할 수 있다는 것이겠고요.
golbin: 제 이야기는 사람의 가치관이라는 것은 모두가 같은 경험과 지식으로 공통되게 형성될 수 없으므로 그 사람의 생각을 인정해줘야 한다는 말인데요.
golbin: 제 글에서 정정되어야 할 부분은, 다양성을 인정하라가 아니라, 그 사람의 생각이 현재 그럴 수 있다는 것을 이해하고 존중은 하되, 그러한 생각은 보편인권을 생각했을 때는 잘못된 것이라는 것을 계몽해야 한다. 정도가 되어야겠네요.
golbin: 으아.. 손석희씨가 옆에 있었으면 좋겠네요. ㅎㅎ
ahastudio: 두 개의 단계로 나눠서 생각하는 건 제가 놓친 것 같네요. 골빈해커님의 정리가 깔끔하고 좋은 것 같습니다.
6 notes
·
View notes
Text
함수 체인과 지연 실행
JavaScript 라이브러리 중에 거의 jQuery 다음으로 많이 사용하지 않을까 싶은 라이브러리 중에 underscore 또는 lodash 라는 것이 있다. (두 라이러리는 차후 합치는 것이 논의되고 있다.)
이 라이브러리들은 다양한 데이터들을 체인 형태로 실행 할 수 있게 해 주는 라이브러리로써 로직을 깔끔하게 유지시키는데 좋은 역���을 해 준다. JavaScript 기본 함수에도 배열을 처리하는 map, reduce 같은 것이 있지만, lodash와 underscore가 조금 더 편하게 사용 할 수 있고, 추가로 다양한 유틸리티들이 포함되어 있어서 우리 회사에서도 기본 라이브러리로 사용하고 있다.
그 중 lodash에는 지연 실행(Lazy Evaluation) 기법이 포함되었는데, 이에 대해서 간단하게 설명해보고자 한다.
배열을 처리하는 일반적인 방법은 바로 다음과 같이 for 문 같은 루프문을 사용하는 것이다.
이를 lodash의 map과 filter를 이용해서 함수형 툴체인 기법으로 변경하면 다음과 같이 된다.
이 기법이 익숙하지 않다면 처음엔 약간 이해하기 쉽지 않을 수 있지만, for 루프에 비해 각각의 로직이 명확하게 분리가 되어 있으므로, 차후 디버깅을 하거나 로직을 추가/수정할 때 훨씬 쉽고 편하게 할 수 있다.
다만, 각각의 map/filter 함수마다 루프를 한 번씩 돌고, 또 각각 루프를 돌 때 마다 배열을 새로 생성하므로, 상황에 따라 실행속도가 급격히 느려지거나 메모리를 과도하게 잡아먹는 문제가 생길 수 있다.
이를 해결하기 위해 지연 실행이라는 기법이 생겼는데, lodash의 경우 다음과 같이 사용할 수 있다.
사용법은 간단한데, 첫 함수 사용시 lodash 의 _.map(numbers, function) 대신에 _(numbers).map(function) 이와 같이 lodash의 생성자를 이용해 객체를 만든 뒤 함수 체인을 사용하고, 함수체인의 마지막에 .value() 를 붙여주면 된다.
이렇게 하면 함수체인으로 연결되어 있는 각각의 함수들이 배열의 모든 요소들을 처리한 뒤에 다음 체인으로 넘어가는 것이 아니라, 요소 하나를 처리하고 다음 체인으로 넘기는 방식으로 실행 방식이 변한다.
즉, map에서 첫번째 요소에 1을 더하고 filter 에서 2보다 큰 값인 경우만 다음 map 에서 자승을 리턴. 그 다음 두번째 요소를 같은 방식으로 처리, 그리고 또 그 다음 세번째 요소를 같은 방식으로 처리. 이런 방식으로 for 문과 같은 형태로 루프를 돌게 된다.
따라서 요소 3개가 있는 3개의 함수 체인은 최대 9번(여기서는 8번)의 루프를 도는 반면, 지연 실행으로 실행한 함수 체인은 요소의 갯수만큼인 3번의 루프만 돌게 되어 실행 속도를 획기적으로 줄일 수 있게 된다.
참고로, 맨 마지막 체인에 reduce 등을 넣으면 value를 사용하지 않아도 된다.
또한 다음처럼 함수 체인에 들어가는 함수들을 모두 독립 함수로 빼서 조금 더 함수형 프로그래밍에 가까운 형식으로 만들면, 로직이 복잡한 경우라도 훨씬 더 이해하기 쉽고 유지보수가 쉬운 코드로 만들 수 있다.
글을 쓰고 난 뒤에 구글링을 해 봤더니 Lazy Evaluation에 대한 훨씬 더 쉬운 설명이 있었다. -_-a 다음 글을 보면 훨씬 더 명확하게 이해가 될듯. Introducing Lazy Evaluation
9 notes
·
View notes
Text
변태 회의자들
언젠가 팀원 중 한 명하고 얘기를 하다가 재미난 사실(?)을 알게됐다.
기획팀하고 개발팀하고 회의를 하는데 프론트엔드 개발팀 팀장님하고 나하고 싸우길래 왜 저러지? 하고 벌벌 떨다가, 갑자기 결론이 나면서 화기애애하게 얘기도 하고 그래서 이건 뭔 상황이지? 그랬다고.
이후에 또 다른 기획팀 팀원이 들어왔는데, 나랑 그 팀장님이랑 자리에서 막 싸우길래 '두 분이 사이가 안 좋아요?' 라고 물어봤다고 한다.
알고보니 토론을 격하게 하는거였고, 둘 다, 틀리거나 더 좋은 의견이 나오면 바로 수긍하는 스타일이어서 그런 것이었는데, 남들이 보기에는 오해할 수도 있는 상황으로 보이는 것.
어떤 의견이 진짜로 맞는 것인지 토론하는 것은 전투와 비슷한 것이라고 생각한다. 물론 나와 상대가 싸우는 것이 아니라 논리와 논리를 싸움 시키는 것으로써 말이다. 그리고 나 또는 누군가의 지식과 논리는 당연히 틀리거나 깨질 수도 있고, 회의를 나와서도 생각이 바뀔 수 있는 것은 당연하다. 진리로 믿었던 과학 논리조차 계속해서 깨지고 있는 판에, 당장 내 작은 생각 따위가 뭐라고.
물론 나의 의견을 강하게 주장하려면 애착을 가져야할 것이고, 반면에 나의 의견을 나와 동일시하면 마음에 상처를 받을 수도 있다. 하지만, 사람에 따라 쉽지 않을 수 있겠지만, 그래도 좀 더 나은 결론을 도출해 내길 원한다면 최대한 치열하게 해야 하지 않을까?
나중에 팀장님이 "누가 내 논리가 틀린점을 지적해주면 희열이 느껴져요" 라고 얘기했더니, 그 ���원이 팀장님한테 변태라고 했다는 후문. ㅎㅎ
23 notes
·
View notes