Dev Toy 시작하기

개발자의 자기 개발. 다양한 방법이 존재한다.

책 읽기, 업무에서 배우기, 학원 다니기, 토론하기 등등 아주 다양한 방법이 존재한다.

그 중에서 나는 Dev Toy가 아주 중요하다고 생각한다.

업무와 나의 관심사, 나의 기술적 탐구심을 충족 시킬 수 있다면 아무 문제 없다. 하지만 그런 경우는 흔치 않다.

그리고 그것이 충족 된다고 하더라도, 나는 Dev Toy가 매우 의미 있고, 가치 있다고 생각한다.

  1. 온전히 나의 생각만 반영된 개인 프로젝트의 자유도는, 프로그래머로써 성취감을 충족 시켜준다.
  2. 기술 선정에 자유롭다. 누가 뭐라해도 내가 원하는 기술과, 패키지 선정, 개발 툴, 코딩 스타일로 작업 할 수 있다.
  3. 내가 중요한 가치에만 집중 할 수 있다. 예를 들어, 나는 빠르게 유틸리티를 많이 만들고 싶다면 다른 고려 사항 없이 빠른 결과물에 집중해서 작업 할 수 있다.

이외에도 다양한 장점이 있었다. 특히나, 개인적인 개발욕에 대한 충족을 이룰 수 있었고, 회사 업무에서 아쉬웠던 점을 꽤나 많이 보강하는 기회가 됐다.

Dev Toy를 안 하게 되는 이유는, 업무에 지쳐서 프로그래밍은 회사 업무로도 충분하다고 느끼는 경우도 많았고, 또 한편으로는 혼자 하는 작업이 해봤자 얼마나 쓸모 있는 걸 만들 수 있겠냐는 생각도 작용하더라.

지금처럼 패키지 기반으로 다른 사람의 작업물을 조립하고, 내 아이디어나 개선 사항에 대해서만 코딩하면 되는 편한 환경에서는 개인 작업물로도 충분히 좋은 제품을 만들 수도 있다고 생각한다.

만약 부끄럽다면 당장엔 private 프로젝트로 시작 한 뒤, public 프로젝트(github 라던지)로 옮겨 가는 것도 나쁘지 않다고 생각한다.

중요한 것은, 제약이 없는 상황에서 자유롭게 자신의 생각과 아쉬웠던 과거의 문제들을 개선한 무언가를 만드는 노력이라고 생각한다.

만약 당신이 업무로 인해 프로그래밍이 지겨워졌다고 하더라도, Dev Toy는 지쳐 있는 당신 마저 프로그래밍 본연의 재미를 다시금 느끼게 해줄 것이다.

합리적 반박

합리적 반박이란 무엇일까? 우선 비합리적 반박을 얘기해보자.

그 제안은 이런 단점이 있어서 안되

라고 말을 끝내는 경우가 주로 비합리적 반박이다. 사실 단점이 없는 솔루션은 거의 없다.

대부분은 몇가지 가정이 동반되거나, 몇가지 단점, 몇가지 선택을 하고 다른 부분을 포기한 결론을 낼 수 밖에 없다.

특히나, 취향에 근거한 선택을 해야 하는 경우는 더더욱 어렵다.

그건 내 취향이 아니니 싫어

라고 말할 순 없으니, 다른 사람의 제안의 단점을 부각시킴으로써 그 선택지를 배제하려는 경우가 많다.

이런 토론이 흔히 막장 토론으로 가는 원인 중 하나가 되곤 하는데, 이 경우에도 합리적인 결론으로 도달하려면,

나는 그 제안A가 이런 이유로 적합하지 않다고 생각하고,

나는 이런 장점을 가진 제안 B를 하고싶다. 제안 B도 이런 단점이 있지만, 나는 제안 A가 가진 단점보다, 제안 B의 단점이 더 적다고 생각한다.

라고 대안과 함께 제안하는 것이 옳다.

이렇게 대안과 함께 이견을 제시하는 경우에는 토론으로 이어질 수 있고, 각 제안이 가진 단점과 장점에 대한 생각을 엿볼 수 있는 반론이다.

이런 식의 반론은 토론을 통한 결론을 도출하는 데에 도움이 될 수 있다.

자신이 토론할 때 어떤 식으로 반론을 제기하는지 한번쯤 고민해보자. 다른 사람에게 막무가내 고집을 부리고 있는지, 다른 사람을 설득하고 있는지 말이다.

삶을 지속적으로 개선하기

좋은 개발자의 정의는 다양하다.

머리가 좋은 사람, 근면 성실한 사람, 열정 적인 사람, 기발한 사람 등등…

나는 좋은 개발자보다 중요한 것이, 평범한 개발자로써 일을 잘 해내는 방법을 아는 거라고 생각한다.

나를 포함한 대다수는 평범한 개발자다. 남들보다 뛰어나거나 특출 난 것들은 모두 좋은 경험과 기회가 이뤄준 것이지 타고난 재능이 아니다.

이런 평범한 사람들이 일을 잘하는 방법은 바로 지속적인 개선이다.

나의 경우에는 업무에서 먼저 시작했다.

손이 많이 가는 작업이 많아서, Windows hotkey 프로그램을 만들어 쓰기 시작했고, 스크립트를 짜서 단순 작업을 자동화, GUI 프로그램에 소스가 없으면 매크로를 짰다.

편리한 유틸리티를 찾고, 내 입맛에 딱 맞고 공수가 덜 드는 환경을 구축해주는 프로그램으로 하나씩 바꿔 나갔다.

한번 찾은 정보를 정리하기 위해 북마크로 시작했고, 위키로 정리, 지금은 원노트를 4중 카테고리화해서 사용하는 방법을 사용 중이다. (필기장 분리, 섹션 그룹, 섹션, 하위 페이지 2 depth 응용)

이외에도 다양한 데이터가 어디에 있는지를 명확히 하고, 그 위치에 내가 정한 룰에 맞게 데이터가 정리되어 있는지 주기적으로 정리한다.

그 작업 과정에서 번거로움이 있으면 어떻게 개선할지 또 다시 고민한다.

출퇴근 길도 어떻게 하면 조금 더 빠르게 적은 시간을 낭비할지 고민한다. 출퇴근 시간에 무엇을 해서 loss 타임을 줄일지 고민한다.

당연히 나만 이렇게 하고있지는 않을 거라고 생각한다. 하지만 의외로 삶의 번거로움을 불변 요소로 여기는 경우도 많고, 특히 업무에서 적용되지 않는다.

회의가 내 업무 관리가 어렵다면, 내 업무에 반복이 많다면, 비효율이 많다면 반드시 제거하기 위한 고민을 해야 한다.


  1. 업무에서 길을 잃지 않기.
  2. 두가지 이상의 업무가 동시에 들어온다면, 우선 순위에 맞게 처리하기.
    • 나중에 처리할 업무를 따로 관리하기.
  3. 한번 처리한 업무의 히스토리를 기록하며 일하기.
    • 동일 업무 발생시, 히스토리를 따라서 소요 시간을 줄인 뒤, 이에 대한 자동화나 공수를 줄일 방법 찾기.
  4. 도구를 이용해서 해결 할 수 있는 일인지 고민하기.
    • 고안한 도구가, 다른 방법까지 해결할 수 있거나, 비용 투자 대비 (학습, 구매 비용 등) 효과적인 해결책이 있는지 시간을 정해 놓고 찾아보기.
  5. 집중이 안될 때 할 수 있는 일 찾기.
    • 내가 하지 않고 있는 일을, 다른 팀원들이 해결해주는 문화라면 좋겠지만 일반적으로 그렇지 않다.
    • 미뤄둔 일 중에, 단순 반복 작업, 솔루션이 찾아져 있어 실천만 하면 되는 작업을 분류하고, 그 작업들을 해결하라.

이런 과정을 반복하다 보면 확실히 업무 효율이 좋아졌고, 업무 처리량도 늘어났다.

업무 시간을 효율적으로 사용하고 업무를 관리해야, 나의 다른 여가 시간을 확보해줄 수 있다.

그렇게 여유를 만들어 내야, 일상도 개선 할 수 있다. 업무에 치이기만해서는 일상을 개선하기 어렵다.

일상의 개선에도 위에 언급한 것 외에도 여러가지 포인트를 찾을 수 있다.

  • 책읽기가 번거롭다, 책을 들고 다니기 어렵다
    • Ebook으로 대체
  • 게임 디스크 교체가 번거롭다 (디지털 다운로드)
  • 이외에도 가능한 것은
    • 리모트로 대체
      • WOL로 컴퓨터 켜기, 무선으로 최대한 대체
    • 자동화 할 수 있는것
      • 스케쥴러로 자동화 등등
    • 알람으로 대체할 수 있는 것
      • 규칙적 알람은 최대한 규칙화해서 스크립팅하거나 알람 툴의 반복 기능 사용등

여러가지 제약으로 인해 개선 되기 힘든 것들이라도 최대한 적어 두고 고민하려 한다. 내가 모든 것들을 효율적으로 하며 사는 것은 아니지만, 그러기 위한 노력과, 개선의 결과가 나에겐 보람이고 성취감 중 하나다.

특히 정리의 습관을 근거로 한 개선, 자동화나 알람을 통한 개선은 단계를 거칠 수록 더 그 편리함에 내 자신이 감탄하게 되기도 한다.

생산성에 관심이 많은 분이라면, 한번쯤 내가 제안한 삶을 지속적으로 개선하는 방법에 대한 고민을 해보는 건 어떨까?

정보 수집

나는 새 기술에도, 헌 기술에도, 변화의 흐름에도, 경험에 대한 이야기도, 사실상 내가 이해 할 수 있는 범주의 개발 이야기에 관심이 많다.

그 근간은 새 정보를 어디서 얻느냐인데, 그에 관한 이야기를 짧게 해보고자 한다.

  1. 새 정보 찾아다니기
    • 업무 관련 키워드로 구글링한 블로그 Feedly로 구독
    • 키워드별로 검색하고 해당 글들 목록을 추려서 전달해주는 크롤러를 개발하면 어떨지 고민중.
    • Disco.me에서 추천 글을 읽는 과정에서, 괜찮은 블로그 찾으면 Feedly에 구독 추가.
  2. 등록된 블로그 정보 확인
    • RSS로 구동 등록된 정보들을 주기적으로 읽음. 주로 평일엔 잠시 Task 전환 시점마다 읽어봄.
  3. Feedly로 구독된 글들을 읽는 과정에서 좀 더 심도 있게 읽어보고 싶은 글들은 pocket으로 담아둠.

  4. Pocket을 일일 확인하여, 다시 위키 방식으로 OneNote에 정리.

  5. 주기적으로 onenote를 확인하고 갱신한다.
    • 카테고리 재분류가 필요하거나, 잘못되었거나 이젠 적용되지 않는 구 자료의 경우 갱신함.
    • 현재는 이 부분을 DB로 관리하고 색인하는 웹 앱을 만드는게 좋을 거 같아 고민 중.

위 과정을 통해서 새 정보를 습득하는데, 주로 한상곤님이 블로그로 주기적으로 뉴스를 모아서 올려주셔서 크게 도움이 됐습니다.

또한 기존에 관리하던 RSS에서 awesome-devblog에 등록된 블로그들을 몽땅 구독만해도 꽤나 많은 정보를 얻을 수 있었어요. 이 기회를 빌어 감사의 말을 전합니다.

Disco.me에 대해서 한마디 하자면, 딱히 취향에 맞는 큐레이션 서비스 같은 느낌으로 글이 잘 선별되진 못했습니다. 또한 중복되는 글 (읽었는지, 훓고 넘어갔는지 판별하진 못하는거 같아요)이 계속 추천되어 좀 아쉬웠습니다.

그리고 종종 yes24, 강컴, 알라딘 등의 IT 서적 순위도 읽어보며 다른 분들의 관심사가 어떤지도 검토하긴하지만, 이는 읽을 책을 고르면서 얻는 부가 효과정도로 봐야합니다. 기술 동향 파악이나, 빠른 정보 습득과는 거리가 있습니다.

이상 제가 사용하고 있는 정보 수집 방법이었습니다.

(서평) 코딩 호러의 이펙티브 프로그래밍

스택 오브 플로우의 창시자로 알려져 있는건 조엘 온 소프트웨어로 더 유명한 조엘 스포스키였다.

내가 좀 잘못 알고 있었던 부분으로, 공동 창업자이자 테크니컬한 부분을 모두 담당한건 제프 앳 우드였다.

스택 오버플로우가 어디인가? 가장 유명한 개발자 커뮤니티 아니던가?

그런 스택 오버플로우가 어떤 고민과 고찰을 했는가에 대한 책이라니 구매하지 않을 수 없었다.


이 책의 원제는 Effective Programming : More Than Writing Code 인데, 사실 과거에 꽤나 긴 시간동안 most important is coding라고 생각해왔었다.

프로그래머들에게 충분한 자원과 지원이 이루어지면 프로젝트는 잘 굴러간다고 믿었지만, 그 것이 사실이 아니란 것을 깨닳는 데에는 아주 오랜시간이 걸리진 않았다.


나는 다른 부분보다 4부 프로그래머를 제대로 채용하는 법가 매우 관심이 갔다. 채용 결정권자는 아닌 때도 많았지만 면접관으로 참관할 때가 적지 않았고, 그 과정에서 많은 고민이 있었다. 실제로 최근 국내 많은 회사가 코딩 테스트를 진행하고 있는데 (이에 대한 회의론도 적진 않지만), 필요하겠구나 싶을 만큼 의외로 코딩을 잘 못하는 케이스가 많았다.

심지어는 이 책에서와 마찬가지로 채용하고나니 코딩을 전혀 못하는 케이스도 실제로 봤고, 면접 때와 실제 장단점을 반대인 경우도 봤다.

제대로 된 채용보다 중요한 것은, 최악의 채용을 하지 않는 것인데, 이는 쉽지 않은 문제다.

절대로 경력이 쌓인다고 좋은 프로그래머가 저절로 되지 않는다.

그렇기에 이를 판단하는 기준과 수단은 높아지고 있고, 이 허들로 인해 진짜 괜찮은 프로그래머의 소소한 단점으로 인재를 놓치는 일도 비일비재하다.

현재의 채용 과정과 허들은 누구에게도 좋지 않지만, 그렇다고 허들을 없애는 것도 좋은 대안이라 볼 순 없다.


위에서 언급한 것과 마찬가지로, 나는 개발에 있어 코딩이 가장 중요한 덕목이라고 여겨왔다.

하지만 1인 개발이 아닌 이상에는 사람 문제가 더 크고, 그에 대한 챕터가 바로 5부 팀이 함께 일하도록 만들기이다.

마이크로 매니지먼트 부터 시작해서, 자율 방임 등 다양한 시도가 프로그래밍 팀에 있어왔음에도 여전히 결론은 상황에 맞는 선택을 하자와 같은 모호한 중립적 입장의 결론만 남아있을 뿐이다.

은총알은 없다, 맨먼스 미신 등에서 지적하는 문제의 근간은 소통 비용이 클 수록 개발 효율은 감소한다이다.

관리, 회의, 협업, 보고 모두 효율을 저해한다.

하지만 일정 부분은 필요하다. 그 사이의 적절한 중간 지점을 찾는 것은 어렵다.


시스템을 구현 하는 입장에서, 기능적인 스펙보다 더 중요한 것은 사용자다.

그에 대한 챕터가 7부 사용자를 염두에 두고 설계하기이다.

애플리케이션은 결국, 작은 디테일의 모음이란 말은 매번 주장하지만, 지켜지기 어렵고 중요시 여기지기 어렵고, 누군가는 다른 외부요인보다 중요하지 않다고 한다.

아무리 남들과 차별화 된 컨텐츠, 시장 점유율, 뛰어난 가성비를 자랑하고 있다고해도, 어플리케이션의 완성도에 문제가 있다면 그 빈틈은 언제든 꿰뚫릴 수 있는 큰 문제로 번지기 쉽다.

사용성에 대한 고민도, 사실 개발자들은 많이 하지 않는다. 코드의 일관성, 클래스 구조, 코드 가독성, 아키텍쳐 구조 등 내부적 문제에 대한 관심은 아주 크지만, 사용성에 대한 고민은 그만큼 크지 않은 것이 일반적이다.

이 문제는 결국 잘 만든 기반을 사용자가 외면함으로써 모든 노력이 수포로 돌아가기 쉬운 결정이다.

이 챕터에서의 내용들은 다 공감이 크게 갔는데, 그 중에서도 버전 1은 엉망이야, 하지만 어쨌든 출시하라고는 심금을 울리는 명언이다.

어떠한 소프트웨어도 버전 1에서 사용자를 감동 시킨 적은 흔치 않다.

그렇기 때문에, 출시하고 개선해나가는 과정에서 사용자를 만족시켜야 한다. 지속적으로 나아지고, 그 방향성이 사용자와 공감대를 이루고 있다면 그 소프트웨어는 결국 훌륭한 소프트웨어가 된다.


이외에도 수 많은 이야기들이 우리가 개발하면서 겪게 되는 수많은 문제에 대한 경험담이자 솔루션이다.

내 개인적으론 이런 프로그래밍 관련 에세이를 좋아하는데, 그 중에서도 작년 읽은 책 중에 유독 맘에 든 책이다.


서적 링크 : http://www.yes24.com/24/goods/8611802