내가 그거 해봐서 아는데

경험이란 가장 쉽게 세울 수 있는 근거다.

하지만 또 다른 측면에선 현재 상황이 그 경험이 온전히 같을 수 없다.

즉 근거는 경험에 의한 설득과, 그 경험이 얼마나 현재 상황과 적합한지, 또 그 경험으로 인해 내린 결론이 어떤 과정이었고 그 고찰이 합리적이었는지 검토해야 한다.

보통 시간이 오래 지난 일일 수록 미화되어 기억되기 쉽다. 기록을 직후에 남겼다고 치더라도, 자기 합리화가 동반된 기록일 가능성을 배제할 수 없다.

그렇다고 과거의 경험에 어려운 것이, 훌륭한 개발자라면 반드시 그 경험에서 반성할 점과 개선할 점을 기록해놨거나 기억하고 있을 거란 점이다.

주로 과거의 경험이 단편 적이거나, 기록이 부족하거나, 잘한 부분만 기억하는 경우는 그 경험에 근거한 판단이 합리적인지 의심해봐야 한다.

그 경험의 깊이가 부족하거나, 제대로 된 회고와 깨닳음이 없는 경험이라면 무슨 의미가 있을까?

또한 자신이 직접 하지 않는 경험, 주로 옆 동료나 옆팀에서 진행한 경험마저 자신의 것으로 여기고 말하는 경우가 많은데, 그런 사람의 말은 신뢰가 어렵다.

주변의 경험을 근거로 한다는 것이 잘못된 접근이란 것이 아니다.

핵심은 어떠한 선택과 경험에서 무엇을 포인트로 잡고 시도했고, 그 포인트에 대한 장점과 단점을 명확히 도출해내야 한다. 나의 시간도 한정 되어 있기 때문에, 모든 것을 경험해볼 수 만은 없다.

그렇기에 그 경험에 드는 코스트를 낮추기 위해선, 강연을 듣는다 거나, 블로그 포스팅, 오픈 슬라이드, 옆에서 지켜보는 경험 등으로 대체 할 수 있다.

그 과정에서 반드시 주관과 관점, 그 관점을 기준으로 한 장단점을 명확히 파악해야, 다른 사람을 설득하고, 같은 실수를 반복하지 않는 포인트가 될 수 있다고 생각한다.

그러기 위해선 뭐가 실수였는지, 뭐가 합리적인 선택이었는지 이해하는 습관을 지니는 것이 좋지 않을까?

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 서적 순위도 읽어보며 다른 분들의 관심사가 어떤지도 검토하긴하지만, 이는 읽을 책을 고르면서 얻는 부가 효과정도로 봐야합니다. 기술 동향 파악이나, 빠른 정보 습득과는 거리가 있습니다.

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