안영회

흔한 프로그래머의 작명에 대한 사뭇 진지한 이야기

얼마 전에 있던 작명에 대한 논의를 소재로 프로그래머의 일상이고, 더러는 중요하지 않게 해치우는(?) 작명에 대해 진지한 글을 하나 써보려고 합니다. 찾아보니 과거에도 비슷한 경험을 쓴 바 있지만 이번에는 조금 다른 느낌으로 다가온 일화를 소개하고 의미를 덧붙이려고 합니다. 작명에 대한 갈등이 발생할 때 두 개발자가 서로 다른 이름 체계로 각각 코드를

개취인정이 주는 배움과 협업에 대한 힌트

일상 경험을 그대로 담은 글이다. 블로그를 오래 써온[1] 필자는 '이 순간 스치는 아이디어를 쓰고 싶다' 하는 식의 충동을 느낄 때가 있다. 마치 사진을 찍고 싶은 충동과 비슷할 수 있는데, 글로 남기고 싶을 뿐이다. 오늘도 평소와 다르지 않은 일상을 시작하는데, 소소한 경험이 글 쓰고 싶은 생각으로 이어졌다. 어떻게

소프트웨어의 가치를 근로자의 노동 시간으로 측정할 것인가?

* 아직 소프트웨어를 모르는 대한민국 기업의 위기를 읽지 않으신 분은 이를 함께 읽어주세요. 얼마전 주 52시간 근로 제도 논쟁[1]이 있었습니다. 그 중에서 특별히 ICT 업종은 예외를 인정해준다는 정부의 방침이 기사화 되면서 페친들의 비난이 줄을 이었습니다. 사회생활 초기부터 늘 스스로 야근을 했던 제 입장에서는 근로 시간에 대한 규정은 관심 밖의

Dooray 서비스를 이용한 서비스 개발조직 협업 개선

요즘 일상에서 가장 많이 쓰는 도구는 Dooray 서비스다. 지난 번에 지극히 개인적인 활용을 다룬 글을 올리긴 했지만, 두레이의 일반적인 쓰임새는 개인 작업 관리용이 아니라 협업 도구다. 약 19개월정도 써온 사용자1)로서 두레이를 쓰면서 이 점은 좋으니 널리 알리고 싶다거나 이렇게 써보면 좋겠다고 느낀 내용을 몇 가지를 써본다. * 화면 기획서를 공유하며

[HBR 독후감] 스티치픽스 CEO, 개인의 스타일을 대중에게 파는 법外

HBR 한글판 5-6월호(통합본)를 읽고서는 굳이 글로 써 발행할 가치가 있나 싶었습니다. 개인적으로는 되짚어보는 의미는 있겠으나 독자에게 주는 가치가 모호해서요. 그래도 초심을 떠올려 계속합니다. 좋은 내용이 많은데 읽히는 사람이 없다는 사실을 확인했으니 제가 흥미를 느껴 읽고 느낀 부분에 대해서라도 소개해서 유익한 내용에서 얻은 영감을 많은 분들이 업무 현장에서

소프트웨어를 모르는 대한민국 기업의 위기

* 속편 성격인 소프트웨어의 가치를 근로자의 노동 시간으로 측정할 것인가? 를 올렸습니다. 함께 읽어주세요. 몇 주전 개발자들 사이에서 가장 시끄러웠던 뉴스 중 하나는 마이크로소프트가 깃헙github을 인수했다는 소식입니다. 개발자들은 보통 그 사건에 대해 자기 생각을 갖고 있습니다. 반면에 경영자를 비롯해 대한민국 기업을 이끄는 수많은 사람들은 그게 무슨 의미인지 알지 못합니다. 소프트웨어가 기업에서

[HBR 독후감] 새로운 브레인스토밍 방법 소개 外

지난 글에 이은 두 번째 연재입니다.  마찬가지로  Harvard Business Review 한국판 3/4월 통합본에서 애자일 관련 기사를 제외하고 인상 깊었던 글 3건에 대해 느낀 바를 기록합니다. 브레인스토밍의 새 패러다임 첫번째 기사는 브레인스토밍의 새 패러다임입니다. 부제를 보면 하고자 하는 말이 더욱 명확해집니다. 바로, '돌파구를 여는 통찰을 원한다면 답이 아닌 질문에

[HBR 독후감] 애자일 이야기

HBR 한국판이 있습니다. Harvard Business Review라는 꽤 유명한 경영월간지인데, 필자는 지난 15년간 개발자 출신 IT 컨설턴트였던지라 띄엄띄엄 여력이 있을 때마다 한글판을 사서 보곤 했습니다. 그런데 어느 때부터인지 한국판은 격월간으로 나오고, 또 대형 서점에 가보면 눈에 안 띄는 매대로 점차 밀려나고 있음을 확인할 수 있었습니다. 직원을 부르지 않고 찾으려면 상당한 탐색

개인 작업 관리를 Trello에서 Dooray로 옮기기

10년 가까운 기간 동안 팀 협업 도구로는 주로 이슈 트래커를 썼다. Jira, Redmine, Github 등을 쓰고 Confluence 위키 제품을 보완하는 도구로 써왔다. 그런 가운데도 따로 개인 시간 관리를 할 필요를 느꼈다. 회사 일외에 개인적으로 일정을 챙길 필요가 있고, 가끔은 회사 일이지만 혼자만의 작업이 필요한 경우도 있었다. 또한, 회사 일인지 아닌지

상태와 이벤트라는 모호한 말이 낳은 결과 찾아내기

전편에 이은 일상 협업 이야기 시리즈입니다. 즉흥적으로 참조 아키텍처를 선정해서 해보자고 동료들에게 제안한 다음에 벌어지는 일은 역시(?) 기대와는 다르게 펼쳐졌습니다. 즉흥성이 갖는 한계를 또 확인하는 순간이었습니다. [1] 동료가 복잡한 상태 정의 내용을 저에게 보여주었는데, 자료를 보는 내 자신의 감정이 불편했습니다. 지금에 와서 생각해보면 불편해할 일이 아닌데 복잡한 숙제가 던져진 듯한

일상 협업 이야기: 참조 아키텍처 써먹기 편

출근 후 받아보는 메일링 리스트에서 Kafka Streams ... 라는 제목에 낚입니다. Kafka, Streams 모두 제가 꽂히는 단어죠. 암튼 별 생각없이 쓱 읽는데, 영문인데다 수학공식까지 나오기 시작하자 정독은 포기합니다. 다만, 아래 그림에 시선을 고정합니다. 그리고, 아래 그림을 이해하는데 필요한 내용만 골라서 읽습니다. 써먹고 싶다는 강렬한 충동일 일어서죠. 빠르게 응용(모방)해보기 마침

[이전 글] MDD는 과연 무엇이고 어떤 용도로 사용할 것인가?

안내: 이 글은 운영을 중단한 개인 블로그에 2016년 6월 17일 올렸던 글입니다. 다음에 기고할 글과 연관이 있어 옮겨 둡니다.   요즘 중국에 체류 중이어서 블로깅을 할 수 없었다. 내 글이 누군가에게 가치가 있느냐를 떠나 그냥 하고 싶은 말이 있어 쓰고 싶던 차에 한국에 귀국한 김에 짧은 생각을 기록한다. MDD(Model-Driven-