(서평) 일을 했으면 성과를 내라

사회성이 아주 아주 많이 부족했던 나는 여러 지적을 받고, 자기 개발서를 다양하게 읽었다.

딱히 배울게 없고 모호한 이상론이나 지나친 열정론을 주장한 책이 많았다.

특히나 실천적인 측면, 즉 디테일에서는 이사람이 조직 생활을 해본 건가 의심스러운 서적도 꽤 많았다.

그런 생각이 이어지다보니 자기 개발서를 사서 읽을 돈과 시간이 아깝단 생각이 들어 잘 안읽기도했고, 내 가치관 자체가 프로그래밍 실력이 늘면 다른 부분은 조 금 부족해도 된다고 생각한 시기도 있다보니 더 안읽게 됐었다.

시간이 더 흐르면서 태도와 마인드가 실력 향상에 큰 영향을 준다는 것을 깨닫고 있었고, 이에 대한 대화를 나누던 지인의 추천에 읽게 된 이 책은 생각보다 좋았다.

물론 한국에 특화된 내용이 오히려 반감을 사는 부분도 있고, 상사나 관리자, 주변 사람들에게 잘보이고 그들과의 관계를 잘해야 된다는 메시지가 많은 것은 반감을 사기 쉽다.

이 부분에 대해서 나도 반발심리가 있기도 하고.

하지만 의외로 중요한 부분이다.

특히나 ‘당신’이라는 존재가 인정 받지 못하면, 당신이 만든 ‘성과물’도 인정 받지 못한다라는 내용은 아주 아주 큰 공감이 가는 내용이다.

사실은 프로그래머들도 실력으로 압도적인 포스를 내비추는 분들도 있지만 그런 분들은 극소수고 크게 차이나지 않는 실력에 인성에 문제가 있어 감점이 되거나, 디테일이 떨어져 감점인 경우가 많은데 이런 부분에 대한 보강은 이 책에 있는 내용들 중 와 닿는 내용을 선별적으로 적용한다면 충분히 보강될 거라고 생각이 드는 책이다.


핵심 내용 요약

  1. 엉덩이로 일하지 말고 머리로 일하라
    • 목표 이미지를 명확히 하는 것이 중요
      • 자체제안 과제의 목표는?
      • 상품기획 교육운영의 목표는?
      • 사업부 지원과제의 목표는?
    • 자신의 목표에 한정하지 말고,회사 및 상사의 목표를 염두에 둬라  
  2. 상사는 사실 피자를 먹고 싶어한다
    • 상사의 애매모호한 지시사항을 구체화된 모습으로 실행
      • 최종 결과물을 내기 전 중간보고해서 방향을 일치
    • 업무 / PJT별로 관련있는 정보(사내정책,회의록,참조자료)는 일괄관리
    • 바쁜 와중에도 상사 및 동료와의 대화 시간을 가져야 함
    • 평소 관심있는 주제를 파악하여 이것 위주로 대화 (농담 따먹기 X)
      • 1명/1주 새로운 사람과 대화하기  
  3. 아무리 맛있는 음식도 유통기한이 있다
    • 나를 대표할 수 있는 identitiy = Speed
    • 시간 내 100% 보다, 빠른 70%에 집중
    • 혼자하는 업무 / fuzzy front end 업무는 특히나 속도로 승부  
  4. 성공은 2000번의 실패를 요구한다
    • 실패하는 사람은 봐줘도 도전하지 않는 사람은 살려두지 않는다
      • 특히 내가 속해 있는 혁신조직은 임원에게 직접보고한 것만 평가에 반영됨
      • 매월 4회 임원에게 직접보고 (프로젝트 진행 2회 + spot issue 2회)  
  5. 권한위임은 리더가 아니라 나의 문제다
    • 말로하지 말고 문서로 표현해보자(논리 정리)
    • 일이 본 궤도에 오르기 전에 이슈를 제안하고 권한위임을 요청
      • 평소 임원이 하는 말 숙지 + 기획 팀/전사 운영방향 파악
      • 내가 하고 있는 일과의 연관성 파악
      • 업무초안 작성 후 임원회의 시 보고 => “내가한다”를 임원/동료에게 숙지
    • 이것만큼은 내가 최고라는 이미지 구축
      • Innovation 및 NPD 전반에 대한 이론적 이해도
        • 1회/월 사내 세미나 실시
          • 1회/분기 사외 강사초청 세미나
          • 1회/년 PDMA 발표
          • 사내 상품기획 club 운영 (‘13년시행)
        • 조사 방법론 (단순 사용자 관찰이외,정량/정성적 방법 활용)
          • Needs 발굴 방법 /
          • 상품 컨셉 최적화 / conjoint 분석, online 선호도 조사  
  6. 숨어 있는 그림자가 일을 망친다
    • M과제의 성공요인을 benchmark하여,S 과제에 활용(류S,미팅)
      • 기술정보 부족은 어떻게 해결하였나?
      • NIH 신드롬은 어떻게 해결하였나?
      • 소 규모 팀(돈,인력)으로 PJT 수행할 경우,어디에 집중해야 하는가?
        • 즉, 돈 많은 팀에서 못하고 있는 것이 무엇이지?
    • E과제 상세 프로그램 및 굴곡 분석
    • 업무의 전체 프로세스를 머릿속에 사전에 통째로 각인시켜라
      • 창의활동(팀) & 창의력 프로젝트(전사)의 운영방안 철저히 숙지해야 함  
  7. 산이 아니라 돌멩이에 걸려 넘어진다
    • 실수 리스트 정리하여 제거하기
      • 다른 보고서에서 발췌한 DATA는 100% 확실한가?
      • 다수 업무 수행시 자료가 부정확하지 않은가?
    • 나만의 깐깐한 심사위원을 곁에 둬라
      • 퍼실리테이션 및 상품기획 프로그램 (이D)
      • 혁신론(Inno.. ,혁신그룹장)
      • 학술논문(삼촌,원석이)  
  8. 혼자하지 말고 품앗이를 하라
    • 업무에 몰입하다 보면, 시야가 좁아지는 경우가 많음 (외부 조언필요)
    • 진행이 어려울 경우 공식석상에서 한번 꺠지고 도움 받자
    • 평소에 사람들 help 치면 도움주자  
  9. 떠오르는 즉시 말하라, 아니면 영원히 입 다물어라
    • 공식적인 자리에서 토론을 자주하면 역량이 향상된다
    • 일단 결정되었으면,적극적으로 지원하라
      • 그래야 앙금이 남지 않음 / 의견차이는 그것으로 한정 & 팀은 팀  
  10. 실력에도 감가상각이 있다
    • 새로운 업무에 대한 지식 과 프로세스가 절실해지는 순간이 온다
    • 상사가 반복적으로 지적한 내용은 반드시 개선 필요
      • 무 표정 / 너무 조용하다 / 몇몇 사람과만 대화한다
    • 1년에 두번 전지훈련을 떠나라
      • 고향 집 말고,자연이 있고 조용한 곳으로 가자 (연수원?)
      • 가능하면 비슷한 고민을 하는 사람과 같이 가자
    • 1년에 1회이상,다른 기업에 지원해보자
      • 시장에서 나의 가치를 쉽게 판단할 수 있음

  • 상사는 이미 당신이 욕하고 있는 것 까지 훤히 다 알고 있다.
    • 뒷 다마 깔 시간에 문제해결 or 능력 향상에 집중 (시간 낭비임)  
  • 연간 성과목표를 한눈에 볼수 있는 상황계기판으로 ‘성과 대시보드’를 만들어 활용하자

  • 이론적 이해 : BOS 상세 주석달기, PDMA Book 번역해서 출판, SSCI 논문제출
  • 실무능력 : S 프로젝트 사업화 연계, 과제지원 프로그램 완성
    • 프로세스, 성공/실패 사례, 관련 동영상, 사업부 사례, 뉴스기사 등  
  • 혁신적인 아이디어는 배움이 길고 짧은 것과는 그다지 상관이 없다. 그 보다 고객과의 접점에서 고객의 니즈와 원츠가 무엇인지 파악하고, 이를 상품화하는 감각에 달려 있는 경우가 많다.
    • 사업부의 needs는 무엇인가? 동시에 전문가로서 인정 받을 수 있는 분야는?  
  • 최소한 경력 10년 안에 ‘자기완결형 성과경영자가’ 되어야 한다.
    • 2014년(과장 1년차) 까지 CFT에게 신뢰받는 Innovation manager가 될 것  
  • 훈수꾼들에게 ‘훈수를 둬야 할 일’이 뭔지 재차 반복해서 말해주어라

  • 처음부터 거창 한것을 기대하지 말고 꾸준히 정보를 공유(e-mail,세미나 등)하여 
  • 새로운 생각을 가질 수 있는 시간이 필요 함  
  • 중단했던 일을 다시 하려면 시동 거는 데 두배의 시간이 걸린다
    • “초안” 작성은 집중해서 최대한 빨리 완료
    • “보완” 작업은 추가자료 분석,Logic check 등을 통해서 여유롭게 실시
    • 다양한 각도로 생각해 볼 것  
  • 내가 인정 받아야 성과도 인정 받는다
    • ‘당신’이라는 존재가 인정 받지 못하면, 당신이 만든 ‘성과물’도 인정 받지 못한다
    • 게으름을 피우며 외모에 신경 쓰지 않는 것은 일종의 직무 유기다
    • 임원보고, 교육운영, PJT 수행 등은 당연히 gentle 한 복장 / 최소 2회(1주)
    • 잠들기 전에 내일 style 결정 (나이 먹을 수록 깔끔하게 다녀야 함)
    • 성실한 사람으로 평가 받아라 (1시간 일찍 출근 / 2시간 늦게 퇴근)
    • 괜찮은 인력으로 인정 받기 위해서는 자신만의 특징을 한가지 이상 있어야 한다
      • TV 산업 전문가 (Trend ~ 시장현황 ~ 마케팅 ~ 기술 ~ 제품/서비스 차별성 등)
      • 주기적으로 공유하는 시간을 가질 것
  • 퇴근하기 전에 일을 하면서 느꼈던 점을 정리해보자
    • 매일 15분 시간투자 (업무회고)
    • 업무수첩 과 회고노트를 별도로 운영하여 현장의 지식을 정제화  
  • 일을 배우는 동안에는 그 자체에만 집중해라 
    • 보고서는 나중에 정리  
  • 일을 하려면 제대로 하고, 아니면 그 시간에 다른 것을 해라
    • “안될지도 몰라” 라는 생각을 갖는 것 자체가 문제임  
  • 업무수행에 방해가 될 요인들은 사전에 제거하고 시간 과 공간을 포함한 주변환경을 재 정리하자.
    • 집 : 정보를 쉽게 접할 수 있는 환경구축
      • 스마트 PC 구입 / 핵심정보는 출력하여 배치 / 화이트 보드를 활용한 정보정리
    • 회사 : 물리적인 환경개선 추진
      • 노트북으로 교체 / 마우스,듀얼모니터,키보드 사이 환경정리 (장기간 일 할 수 있도록)  
  • 자신이 가장 넘어서고 싶은 사람을 라이벌로 삼자
  • 성공한 한 명을 철저하게 연구하여 자신에게 접목하라
    • 배우고 싶은 내용을 정리한 뒤 쉽게 확인할 수 있게 부착
  • 강점정리
    • 일상 생활 중 발생한 모든 사건,지식,경험을 자산화 할 수 있는 능력(메모의 습관화)
    • 경영전략 및 상품기획 방법론에 대한 명쾌한 이해
      • 각 기법 별 강약점 및 비교분석 가능
    • 몰입도 높은 강의역량 / 농담 따먹기 없는 강의 진행 
    • 혁신 프로그램 디자인  
  • 비전에도 블루오션이 있다
    • 업무환경의 특징 : 커뮤니케이션에 기반한 프로젝트, 본질적인 질문, 비 고객, 관찰조사, 전략시각화
    • 대학원 교육 : 기술전략 전반, 4세대 R&D, 기술트리 / 로드 맵, 특허분석
      • 다루는 내용은 많지만 지식의 깊이가 부족한 것이 문제
    • 하고 싶은 것 : 시장 과 기술에 대한 본질적 이해를 바탕으로 사용자 가치를 창출하는 것  
  • 일단 하나의 분야 혹은 Tool에 대한 전문성을 갖는 것이 현재 할 수 있는 최선이라 생각 됨
    • 특정 시점에는 업무를 바꿔서 큰 그림을 이해할 수 있도록 해야 함
      • 마켓분야 : 제품 & 서비스의 본질적인 질문(5W1H), 비 고객 분석
      • 기술분야 : 기술전략에 대한 이론적 이해 및 사례정리
  • 회사생활의 스트레스를 풀어주는 방법을 마련해두어야 한다
    • 수요일 퇴근 후 : 업무 & 대학원 공부에서 벗어난 새로운 경험(말초적인 것도 OK)
    • 타인과 함께 : 비전이 있는 사람과의 대화, 살사, 농구, 재미있는 친구와 소리지르며 드라이브
    • 혼자서 : 낯선 곳에 여행가서 1박, IDEA 제품 구매 및 분석, 좋은경치 보며 달리기(음악필수)  
  • 집에서 발생한 문제는 집에서, 회사에서 발생한 문제는 회사에서 해결해야 한다  
  • 회사에서 실시하는 아이디어 모집 프로그램에 적극 참여하라
    • 말로하면 불평이지만 글로 쓰면 제안이다
      • 가능한 수준에서 지속적인 사내혁신 활동에 참여 (문제 개선의 습관화)
      • 팀/그룹 방향에 대한 제안 => 조직 전략수립에 대한 역량 ↑
      • 제품 개선 IDEA 제안 => 사용자 Needs를 만족하는 상품기획 역량 ↑
      • 사내 브랜드 대사 => 마케팅 캠패인 관련 기초지식 획득  
  • 상사를 포함해 나의 고객이 바라는 것을 생각하며 역량을 키워야 성장할 수 있다.

(서평) 능률적인 프로그래머

Code Complete, 실용주의 프로그래머 같은 부류의 프로그래밍 실천 지침서의 일종이다.

그와 함께 내가 늘 주장하는 좋은 이야기는 많이 들어 지겨워질 정도라면 정말 반드시 지켜야 할 가치가 있는 것들 이라는 맥락에서 가치 있는 책중 하나다.

혹시나 이 서평을 읽는 분 중, 이 책이 궁금해져서 찾게 되실까봐 미리 언급하자면, 이 책보다 실용주의 프로그래머나 Code Complete가 더 좋다.

책의 페이지 수가 많지 않음에도 불구하고, 장황하고 정돈이 안된 책 이란 생각이 들었다. (실용주의 프로그래머와 비교 했기에 더욱 그랬을 지도 모르겠다.)

특히 사례에 근거하려 했던것 같지만, 조금 날카로움과 디테일에서 아쉬움도 분명히 있다.

이런 책들은 시간이 흐를 수록 그 가치나 의미가 조금씩 쇠퇴하는 경우가 많은데, 그런 주제나 내용도 꽤 담고 있다.

챕터의 사례가 디테일을 다루려다 핵심을 잘못 짚는 느낌이 있었기 때문이다.

개인적으론 회사 동료분께 받은 책이라 짬을 내서 읽게 됐는데, 책이 얇다보니 금방 읽을 수 있다는 점을 제외한다면 굳이 찾아서 읽을 정도는 아니란 생각이 든다.

누누히 언급한대로 대체제가 워낙에 막강하고 현재 시점에서 이 책보다 훨씬 더 유효하기 때문이다.


주요 내용 요약

가속

  • 단축키 잘 써라
  • 클립 보드 잘 활용하라
  • 매크로 잘 써라

집중

  • 산만 요소 제거
    • 소리
      • 헤드폰 끼자
    • 시각
      • 불필요 알림 disable
  • 검색 기능 잘 써라
  • 루티드 뷰로 작업 폴더에만 집중하라
  • 프로젝트 주요 폴더 숏컷 활용하라
    • 윈도우의 경우 바로가기 메뉴 잘 활용하면 될 듯
  • 다중 모니터 사용하라
  • 가상 데스크톱 활용하라

자동화

  • 바퀴 다시 안만들기
    • SVN, Git
    • CruiseControl, Jenkins
    • Trac, Mantis
    • Migle, Redmine
  • RSS 피드 연동
  • Rake, Ant, 비빌드 등의 make 유틸리티를 업무 용도로 전환
  • 쉘 스크립트를 활용하라
  • 스크립트 언어로 반복 작업을 스크립팅하라
    • 수작업으로 하는게 더 빨랐을 지 몰라도, 단순 반복 작업을 손수하다보면 멍청해지고, 가장 능률적 자산인 집중을 놓치게 된다.
  • 자동화 정당성 증명
    • 단위 테스트
    • 기능 테스트
    • 통합 테스트
  • 야크 털깍기로 변질 되지 않는지 경계하라
    1. 서브 버전 로그를 기반으로 문서를 생성하려 한다
    2. 서브 버전 후크를 추가하려다 사용중인 웹서버 버전이 낮아 호환되지 않음을 발견한다
    3. 웹 서버를 업데이트 하려는데 해당 버전은 현재 운영체제 패치 레벨에서는 지원되지 않음을 깨닫고 운영체제 업데이트부터 시작한다
    4. 운영 체제 업데이트는 컴퓨터가 백업을 위해 사용하는 디스크 배열과 알려진 문제가 있다.
    5. 디스크 배열 관련 문제 해결을 위해 시험적 패치를 내려 받는다. 듣기는 하는데 이번에는 비디오 드라이버가 오동작한다.
      • 야크 털깍기가 위험한 이유는 엄청난 시간이 소비되기 때문이다. 왜 업무소요 시간 예측이 그리 잘 빗나가는지 역시 설명된다.
      • 본질을 해결하기 위한 노력에 들어가는 코스트도 계산하라.

정식화

  1. DRY 버전 제어
    • 바이너리까지 버전관리 시스템을 사용할땐 너무 커져서 관리 코스트와 비용이 증가함.
      • 이진 파일은 네트워크 시스템에 올리고, 개발 컴퓨터가 참조하는 방식도 생각해보라.
  2. 빌드 PC 두기
  3. 간접 참조
    • Maven, gradle, nuget, npm, gem, pip 등등의 패키지 시스템을 말함
  4. 가상화 사용
    • VMWare, VirtualBox등을 통한 Vagrant 등으로 환경 재현을 의미
  5. DRY 교류 저항 불일치
    • 데이터 매핑
      • Hibernate, Ibatis 등의 OR 매퍼 사용시 세 군데에 반복 저장 1) 스키마, XML 매핑 문서, 클래스 파일
      • 문제 해결을 위해 원본을 하나만 두고 이를 기반으로 산출 해야 함
        • 스키마 기반 코드 생성기
          • Rake Migration의 경우 정의를 기반으로 스키마, 모델 파일등을 생성하므로 불일치가 발생하지 않는다.
          • dbDeploy를 이용하면 버전별 차이와 롤백 기능 등을 지원한다.
  6. DRY 문서화
    • 유효하지 않은 문서는 잘못된 정보를 퍼트릴 위험이 있다.
    • SVN2Wiki
      • SVN 저장 내용 기반의 자동화 문서이므로, 살아 있는 문서가 된다.
    • 클래스 다이어그램
      • 가능한 모든 기술 문서를 자동 생성하자
      • 같은 사본을 절대 둘 이상 두지 말자.
      • Doxygen 등을 이용해서 문서화 하라
    • 데이터베이스 스키마
      • 스키마 기반 코드 생성기 툴을 사용하라

테스트 주도 설계

  • 단위 테스트는 코드의 정결함을 유지하는 좋은 방법.
    1. 진화하는 테스트
    • 유닛 테스트가 이미 결합도를 낮춰놓았으므로 요구 사항이 바뀌거나 추가 되었을 때 대응이 용이하다.
      1. 코드 검사

정적 분석

  1. 바이트 코드 분석
    • 컴파일 된 코드에서 버그 패턴을 읽어낸다.
    • 정확성
      • 가능 버그 표시
    • 나쁜사례
      • 필수 또는 추천 코딩법 위반. (equals() 메소드만 재정의하고 hashCode()는 재정의 하지 않은 경우 등)
    • 교모함
      • 혼란 스러운 코드. 색다르게 사용했거나, 이상하고 서툰 코드.
  2. 소스 분석
    • 가능 버그
      • 빈 try…catch 블록 같은
    • 데드 코드
      • 사용하지 않는 지역 변수, 매개 변수, private 변수
    • 부최적 코드
      • 비경제적 문자열 사용
    • 지나치게 복잡한 코드
      • 지나치게 긴 메서드.
      • 너무 많은 멤버를 포함한 클래스.
    • 중복 코드
      • 복사해 붙여넣기로 ‘재사용’
  3. 파놉티 코드로 측정 지표 산출
    • 파놉티 코드 같은 측정 지표 산출 도구를 사용하라
  4. 동적 언어 분석
    • 순환 복잡성 (사실상 모든 블록 기반 언어가 공통으로 가진) 및 코드 검사에 집중한다.

좋은 시민 의식

  1. 캡슐화 깨기
    • 가능하면 열지 말자
    • 그래도 열어야 하면, 메소드로 열자
    • 단순 프로퍼티 (getter, setter)를 확인하는 테스트 코드는 사용하지 말자.
  2. 생성자
    • 특정 형식의 유효한 객체가 되기 위해 필요한 요소가 뭔지 알려주는 역할이다.
  3. 정적 메소드
    • 블랙박스, 독립 실행형 상태 비저장 메소드.
    • 고정성 (staticness)와 상태 저장 (state)를 혼동하면 큰 문제가 발생한다.
  4. 범죄 행위
    • 메소드를 너무 작게 분리하면 실패인지 판가름 하기 힘든 오동작을 더 막기 쉽다.
      • 예를 들어 월과 일을 따로 메소드로 호출하는 java.util.Calendar는 2월 31일 입력 시, 3월 2일로 변환해버린다.
        • 이를 한 메소드로 통합시에는 예외를 발생시키면 된다.

YAGNI

  • 쓸데 없을 걸이란 뜻
  • 오버 엔지니어링 하지 말고 필요한 기능을 잘 만들고 완성도를 높이는 데에 집중하라는 뜻.

고대 철학자들

  1. 아리스토텔레시의 본질과 비본질 속성
    • 본질적 복잡성
      • 풀고자 하는 문제의 핵심이라 어려워도 용서가 된다.
    • 비본질적 복잡성
      • Gorufcorrhjk 직접 관계가 없으면서 어쨌든 풀어야 하는 모든 문제를 뜻한다.
  2. 오캄의 면도날
    • 여러 가설이 있을 경우 가장 간단한 게 정답일 확률이 높다는 주장이다.
    • 맨먼스 미신
      • 지체되는 개발 프로젝트에 인력을 더하는 건 개발을 늦출 뿐이라는 주장.
  3. 디미터의 법칙
    • 가장 친한 친구 몇 명하고만 소통할 것
      1. 개체 자신의 메소드
      2. 매개 변수로 넘어온 개체의 메소드
      3. 메소드 내 생성 개체의 메소드
  4. 소프트웨어 전승 지식
    • 고서를 많이 읽자
      1. 맨먼스 미신
      2. 실용주의 프로그래머
      3. 벡의 스몰토크 최상의 방법 패턴
      4. 기타 등등

권위에 도전하기

  1. 성난 원숭이 떼
    • 항상 그렇게 해왔으므로 그렇게 하는 것이 많다는 얘기.
      • 항상 그렇게 해왔으니까요는 충분한 이유가 되지 못한다
      • 왜 항상 그리 해왔는지 이해한다면 이유가 되고, 그렇다면 반드시 계속하자.
  2. 유창한 인터페이스
    • 도메인 특정 언어 (DSL) 양식 유형의 하나
    • 하나의 완전한 생각을 길게 연속되는 코드로 엮어 구어체로 유리화 시키듯 문장을 만든다.
  3. 반 객체
    • 객체 및 객체 계층 구조가 대부분의 문제를 위한 훌륭한 추상화 기법을 제공해 주는 반면, 바로 그 때문에 더 복잡해지기도 한다는 요지다.
    • 팩맨의 예
      • 명백한 해결책
        • 유령에게 지능을 부여
      • 간단한 해결책
        • 미로에 지능을 넣는 쪽
      • 이것이 반 객체식 접근.

메타 프로그래밍

  1. 자바와 리플렉션
    • 리플렉션으로 메소드를 호출할 경우, 훨씬 더 지능적인 팩토리 클래스 작성 및 런타임 클래스 로딩이 가능.
    • 이를 이용하면 대다수 플러그인 아키텍처에서 구체적 클래스 없이도 컴파일 타임에 특정 인터페이스를 준수하는 뭔가를 새로 작성 할 수 있다.
  2. 루비의 extend 활용
    • 더 짧은 코드를 위해 기존 클래스의 메소드나 동작 확장

컴포즈드 메소드와 SLAP

  • 컴포즈드 메소드
    • 모든 실제 절차는 private 메소드에서 구현
      • 외부에서 접근해야 되는 경우 public메소드가 private 메소드를 호출
    • 코드를 더 작고, 응집력 있고, 읽기 쉽게 분해하도록 장려함.
  • SLAP
    • 메소드 내의 모든 코드가 같은 추상화 수준을 가져야 함을 뜻한다.
    • 저수준 데이터 베이스 연결을 하면서, 고수준 비즈니스 코드나 다른 웹서비스 직통 연결이 들어가서는 안된다는 얘기.

다종 언어 프로그래밍

  • 컴퓨터 언어는 정체하면 죽어버리는 상어와 같다.
  • 범용 언어 외에 하나 이상의 특수 목적 언어를 사용한 어플리케이션 개발을 뜻함.
  • 올라의 피라미드
    • 안정 > 비공식 > DSL순의 피라미드
    • 목적들을 위한 다른 언어로 개발된 것을 제어하는 DSL을 만들고 관리하는 것을 말함.

안성 맞춤 도구 찾기

  • 개발 목적에 최적화된 IDE를 찾아라
  • Cygwin, ubuntu bash, mingw 등을 잘 활용하라

팀 생산성을 위한 패턴

  • 콘웨이의 법칙
    • 하나의 컴파일러를 만들기 위해 4개의 팀을 만든다면, 4개의 컴파일러를 얻게 될 것.
  • 땅콩 버터와 마천루
    • 기능이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스
    • 마일 스톤 형태와 같이 초기 단계에서는 땅콩 버터 방식으로 인프라를 구축하고, 인프라 구축 이후에는 다음과 같이 한다.
      • 땅콩 버터 방식을 유지하되, 릴리즈가 거듭 될 때 마다 더불어 사용 가능한 시나리오 들을 점진적으로 증가시켜 테스트 하는 방식이 좋은 예가 될 것이다.
  • 적재 적소에 팀원 배치하기
    • 개인의 작업 방식, 기술 선호도 등을 발견하고, 잘 고려하여 구축하고자 하는 시스템의 구조적인 레이어나 기술에 할당하는 것이 매우 중요하다.
  • 분할 후 정복 (높은 생산성을 유지하라!)
    • 장기적인 목표를 단기적인 목표로 나누어 팀원들에게 목적 의식과 방향성을 제시해야 한다.
    • 그리고 개발자들은 이 마일스톤에 집중해서 문제를 완벽히 이해하고 해결하기 위한 문제 공간을 만들어, 거기에 집중할 수 있도록 끊임없이 독려해야 한다.
  • 단결력 있는 팀
    • 이러한 문제 공간에 끊임없이 팀원들을 참여시키고 흥미를 가질 수 있게 자극한다면 팀의 응집력은 자연스럽게 증대 될 것이다.
    • 실제 사용자와 팀원들이 대화하게 하라
    • 가끔씩 현장 방문을 통해 팀원들이 시스템이 가지고 있는 도메인 특성이나 문화를 경험하게 하라
    • 잠자고 있는 도멩니 전문가를 찾아서 대화하라
    • 문제 공간에서 중요한 결정 사항 등을 검증하고 공유하라
  • 숨어 있는 잠재력에 주목해라.
    • 결과물에도 다양한 측면에서 여러 가지 행위 들에 적정한 가중치를 두어 팀의 진척도를 측정해야 한다.
    • 잠재력을 끌어내기 위해서는 피그말리온 효과를 이용하는 것이 좋다
  • 인수인계는 이렇게
    • 떠나는 개발자가 미완료한 일, 버그, 문서 작업을 빨리 진행 할 수 있도록 다른 일을 시키면 안된다.
    • 인수인계는 새로운 사람보다는 같이 일을 해온 동료나 팀원에게 분배하는 것이 좋다.
    • 틈틈이 문서와 산출물을 점검하고, 주기적인 지식 공유를 할 수 있게 해야 한다.
  • 공간 확보의 중요성
    • 문제에 완벽히 집중하기 위해서는 15분의 시간이 필요하다.
    • 방해 요소를 제거하기 위해 공간 확보가 되면 좋다.

(서평) 리딩 - 알렉스 퍼거슨

한국에서도 인기 있던 세계 최고의 팀이었던 맨체스터 유나이티드를 만든 퍼거슨이 팀을 이끌면서 느낀 많은 판단과 감상에 대한 이야기를 다룬 책이다.

너무나 위대한 팀 맨체스터 유나이티드를 만들었던 퍼거슨이지만, 그 역시 어리석다고 볼 수 있는 판단도 몇번이나 했었다.

그럼에도 그가 위대한 감독이 된 것은 그가 몇가지 철학을 가졌고 그 철학을 온전히 지켰기 때문이다.

그 대상이 퍼거슨의 아이들, 그리고 맨유의 아이들 중 하나였던 베컴이라고 할 지라도 같은 원칙이 적용됐다.

기본적으로 사람을 대하는 기술이 뛰어났음은 물론이고 그 룰을 벗어나는 이에 대한 규율과 징계가 일관적이었기에 그의 메시지가 온전히 잘 전달됐다고 본다.


그렇지만 경기는 모든 선수단이 공평하게 뛸 수 없다.

분명히 퍼거슨도 몇몇 선수를 특별하게 다뤘음에도 큰 탈이 나지 않았던 것은, 이 책에서 다뤄지지 않은 몇가지 원칙과 방법이 더 있었을 것 같다.

아쉽게도 이 책에선 그가 특별하게 다뤄지는 선수 에 대한 상대적 박탈감을 느낄 수 있는 이들을 어떻게 케어했는진 알 수 없었다.

내 궁금증은 해소 되지 못했지만 다행히도 그가 훌륭한 감독이 되기까지의 시행착오와 경험에서 많은 것을 배울 수 있었다.

흔히 초보 관리자들이 빠지는 여러가지 실수에 대해서도 큰 도움이 될 내용이 아주 많았다.

특히 마인드 컨트롤과, 마음 가짐에 대해서 아주 많은 것을 얘기하고 있다.

리더에게도 물론 좋지만 구성원에게도 이런 마음가짐은 도움이 될 훌륭한 책이다.


아래는 이 책에 대한 목차와 몇가지 주요 챕터 요약이다.


목차


  1. 최고가 되기 위한 기본 
    • 경청 - 경청은 공짜로 얻을 수 있는 최고의 가치 
    • 관찰 - 한 걸음 떨어져 큰 그림을 볼 수 있는 자리에 서라 
    • 독서 - 리버풀과의 경기를 승리로 이끌었던 전략의 비밀 
  2. 나를 일으켜 세우는 헝그리 정신 
    • 규칙 - 규칙을 포기하는 순간 성공과는 영원히 이별이다 
    • 연습 - 결혼식 날에도, 아이가 태어났을 때도 운동장에 있었다 
    • 열정 - 왜 누군가의 열정은 다른 이보다 뜨거운가? 
    • 신념 - 상대 팀이 우승한 것이 아니라 우리가 우승을 놓친 것이다 
  3. 최상의 성과를 내기 위한 요소들 
    • 조직 - 승리에는 완벽한 조직과 인내가 필요하다 
    • 준비 - 퍼기 타임? 철저한 준비로 기회를 만들었을 뿐 
    • 교육 - 최고를 대신할 신인발굴에 촉각을 세워라 
  4. 리더는 혼자가 아니다 
    • 팀워크 - 다양성 안에서 빛을 발하는 존재들 
    • 주장 - 내가 손꼽는 최고의 주장들 
  5. 리더가 추구할 가치 
    • 탁월함 - 구체적인 목표를 언급하지 않는 이유 
    • 동기부여 - 리더십의 본질은 감춰진 5%의 능력을 이끌어내는 것 
    • 겸손 - 나는 승리할 때마다 다시 처음이라 생각했다 
  6. 평가의 기준 
    • 채용 - 불운을 극복하고 좌절에서 일어나는 모습을 보라 
    • 인맥 - 최고의 인재들을 발견할 수 있었던 비결 
    • 해고 - 이별에도 매너가 필요하다 
  7. 집중이 필요한 순간 
    • 시간 - 언제나 제일 먼저 출근하는 습관 
    • 방해 - 성공과 삶의 균형은 양립할 수 없는 선택 
    • 실패 - 고통은 승리를 향한 욕망을 입증한다 
    • 비난 - 격려는 비판만큼 중요하다 
  8. 메시지를 장악하라 
    • 대화 - 상대에 따라 달라지는 말하기의 기술 
    • 작문 - 매년 2,000통의 크리스마스 카드를 보내다 
    • 답변 - 언론을 대할 때는 분명하고 단호하게 
  9. 관리하지 말고 이끌어라 
    • 구단주 - 감독의 존폐를 결정하는 절대 권력자 
    • 통제 - 통제는 손끝에서 나오는 게 아니다 
    • 위임 - 리더십과 관리의 차이는 무엇인가 
    • 의사결정 - 결정력이 있는 사람을 곁에 두라 
  10. 냉철한 판단을 내리는 법 
    • 영입 - 모든 리더는 세일즈맨이다 
    • 절약 - 돈으로 문제를 해결한 적은 한 번도 없었다 
    • 연봉 - 난 네 봉지를 받는데, 누구는 다섯 봉지를 받는다면… 
    • 협상 - 결과를 예측할 수 없는 피 말리는 전쟁 
    • 에이전트 - 나는 에이전트를 믿지 않는다 
  11. 함정을 조심하라 
    • 혁신 - 가자미 두 조각과 토스트 그리고 꿀 
    • 정보과잉 - 데이터란 기준을 가늠하기 위한 자료일 뿐 
    • 기밀유지 - 내 관을 들어줄 여섯 명의 사람이면 족하다 
  12. 또 다른 관계 
    • 라이벌 - 라이벌을 대하는 최고의 방법 
    • 글로벌 - 영국 리그 해외 선수 영입의 역사 
  13. 변화의 순간들 
    • 도착 - 다시 맨유의 감독을 맡는다면 바꿀 두 가지 
    • 떠남 - 38년의 감독 생활을 마무리하며 
    • 도전 - 은퇴 후 펼쳐진 새로운 인생 
  • 에필로그 
    • 지금, 퍼거슨의 리더십 스타일에 주목해야 하는 이유  

몇챕터 주요 요약


관찰

보이는 대로 믿어야 한다고 흔히 말하지만, 사실 쉬운 일이 아니다.

놀랍게도 우리가 보는 것, 아니 좀 더 정확히 말해 우리가 보고 있다고 생각하는 것은 수많은 편견과 선입견에 영향을 받는다.

주변의 평가에도 관심을 기울이는 동시에 다른 사람들의 생각에 흔들리지 않도록 언제나 직접 내 눈으로 관찰하는 방법을 택했다.

규칙

장기적인 관점에서 원칙은 임시방편보다 중요하다. 열한 명의 뛰어난 선수들이 훈련에 최선을 다하고, 체중을 유지하고, 충분히 숙면을 취하고, 정확한 시간에 경기장에 나타나기만 한다면, 승리의 절반은 이미 이룬 셈이다. 

그러나 놀랍게도 많은 구단들이 이 간단한 일을 해내지 못한다.

연습

안타깝게도 일부 선수들은 긱스나 호날두에 버금가는 놀라운 재능을 지니고 있었는데도 감정적, 정신적으로 강인하지 못해서 유년기의 상처와 내면의 아픔을 극복하지 못했다.

방해

나는 다른 사람들의 요구를 외면하지 못하거나 여가 시간을 다 누리면서 큰 성공을 거둔 사람들은 만나보질 못했다.

내가 말하고자 하는 것은 성공에만 집착하면 건강한 라이프스타일이나 영원한 행복이 따라올 것이라는 뜻이 아니라, 남들보다 더 잘하기를 열망하면서 동시에 삶의 균형을 유지하는 것은 현실적으로 불가능하다는 말이다.

며칠 전 청울림의 강의에서도 들었던 내용이다. 즐거움의 사슬 끊기(=성공을 위한 절박함)

실패

성공보다 실패에서 훨씬 배울 것이 많다는 옛말은 틀리지 않았다.

대화

나는 육체적, 정신적 활력을 항상 중요하게 여겼기 때문에, 선수들이 피곤해 보여도 좀처럼 ‘지쳐 보인다’는 말을 하지 않았다. 그 말을 입 밖에 꺼내는 순간, 선수들은 실제로 피곤하다고 느끼게 된다.

오히려 그 반대로 이야기했다. “자넨 아무도 따라잡을 수 없을 만큼 강해.”

정보과잉

나는 때로 사람들이 정보에 집착하는 모습에 깜짝 놀라곤 한다. 환자가 음식을 먹다가 기도가 막혀 죽어가고 있는데, 응급실 의사는 병상 옆에 놓인 모니터만 뚫어져라 보고 있는 장면이 떠오른다.

당연하게도 의사는 생명을 살릴 수 있는 방법을 모색하고, 주변의 모든 가능성을 총동원하여 상황을 되돌려야 한다.

아무리 정확하고 분명한 데이터가 있다고 해도 >말이다. 데이터란 기준을 가늠하기 위한 자료일 뿐.

라이벌

맨체스터 유나이티드 감독 초기에, 나는 최고의 목표가 리버풀을 때려눕히는 것이라고 떠들고 다녔다.

이 이야기는 노래처럼 계속해서 퍼져나갔다.

어찌됐든 이 말이 씨가 되었는지, 맨체스터 유나이티드와 리버풀 간의 세기의 라이벌 구도에서 우위를 차지하게 되었다.

나의 업무 관리법

업무 일지와 각종 노트에 대해서는 정리한 바가 있다. 노트에 이어서, 업무 진행하는 데에 있어서 지속적으로 개선/보강해나가고 있는 업무 정리/요약 법을 간략히 공유해본다.


일일 시간대별 계획 수립 (예시. 상황에 따라 조절해야 함.)

  • 오전 - 집중을 하기 위한 준비. 전날 마무리 덜 된 내용들에 대한 재검토
    • 짧은 회의
    • 면담
    • 잡무 - 전날 업무 진행중이던 상황
  • 오후
    • 주요 업무
    • 창조적인 일
    • 중요한 회의
  • 저녁
    • 독서
    • 문화생활

자료 학습 방법

  1. 훓어보기 (10분 내외)
    • 스피드 중시
    • 속독
  2. 정리하기 (30분 내외)
    • 이해 중시
    • 속독
    • 표시와 자료 정리
  3. 복기하기 (1시간 이상)
    • 요점 암기
    • 정리된 자료 학습 및 다듬기. * 각 단계마다 어디에 파고들어야 할지 핵심 키워드를 잘 찾는 것이 효율에 좋다. * 만약 2단계 정리하기에서 정리 되기 어려운 자료라면 빨리 포기하는 것이 나을 수 도 있음.
    • 어떤 부분으로 인해 내가 원하던 자료가 아닌것인지, 혹은 자료 재 작성 요청을 해야 하는 것인지 등의 명확한 이유가 있어야 한다.

회의/토의 관련 내용 정리 하는 방법

  • 맥락별 요약
    • Nested하게 구성해서 정리하는 것이 좋다.
  • 내가 이해가 부족한 키워드 정리.
  • 설명이 모호하다 느껴지는 부분들 정리.
    • 질문 내용도 잘 정리할 필요가 있다.
    • 정리가 안되어있다면 질문 자체를 놓치거나, 질문하고자 하는 의도를 놓치기 쉬움.
      • 또한 답변 내용이 의도를 벗어나는 것도 놓칠 가능성도 있기에 이 과정을 모두 기록하면 좋다.
  • 체크해서 추후 회의나 업무 과정에서 검토해야 될 내용 따로 정리하고 마킹.
    • 색이나 bold 등으로 체크.
    • 따로 분류해 두는 것도 방법.

컨디션 난조시 30분 낮잠 자기

  • 일이 잘 안될 때는 점심시간 즈음해서 30분정도 숙면을 취하는 것이 좋다.
  • 낮잠을 자기 전에 커피를 마셔 두면 30분후에 일어나기 좋다.
  • 자세가 중요하므로 엎드리기 보다는 뒤에 기대는 것이 좋으며, 안대를 사용하면 더 좋다.

하루를 마감하는 한 줄 일기 (이 부분은 굳이 업무 관련일 필요만은 없음.)

  1. 오늘 기뻤 던 일
  2. 오늘 잘 한 일
  3. 오늘 잘못 한 일
  4. 오늘 감사한 일

(서평) 프로그래머의 길 멘토에게 묻다.

프로그래머 생활을 하며, 어느덧 다른 분들의 멘토링을 해야 될 일이 종종 생기곤했다.

아직 나도 한참 더 성장해야하고, 많은 도움과 멘토링이 필요하다는 생각을 갖고 있는지라 조심스레 질문하시는 것 위주로 답변드리다가 우연히 이 책을 발견했다.

이 책에서 주요 내용에 대해 정리했는데 그에 대한 견해를 정리해본다.


자유시간에 부숴도되는 장난감을 만들라

Dev Toy 또는 Toy Project라 불린다. 회사 업무는 내 마음대로 할 수 없다.

마음껏 프로그래머로써의 역량과 배움, 표현력, 자유분방함을 만끽하며 즐기고 싶다면 반드시 했으면 좋겠다.

마음껏 만들고 부수는 과정에 대한 부담감이 없어, 얻어가는 것이 훨씬 많다.

마음 맞는 사람들을 찾아라

생각이 다른 사람끼리 맞추는 것은 쉽지 않은데, 이를 굳이 여가 시간에도 할 필요는 없다.

본인의 성향을 깨닳아라. 자신과 생각이 비슷한 사람을 만나면 시너지가 나고, 즐거워 진다.

배운 것을 공유하라

블로그도 좋고, 위키도 좋고, 간단히 정리한 문서도 좋다.

다시 정리하는 과정에서, 인사이트를 얻게되고, 피드백에서도 많은 교훈을 얻게 된다.

고전을 공부하라

실용주의 프로그래머, Code Complete, 맨먼스 미신을 비롯한 수많은 서적이 가져다 주는 교훈은 지금도 유효하다.

책에서 배우고, 선배 프로그래머들의 같은 실수를 반복하지 않는 것은 매우 중요하다

자신만의 지도를 그려라

  • 경력의 다음단계 목표를 계속 그려나가라
  • 지속가능한 동기부여가 가능한 목표를 가져라

자신이 현재 하고 있는 업무로 무엇을 얻을 것인지가 매우 중요하다. 업무는 항상 즐거운 요소만 있는 것이 아니기에, 자신의 목표를 위한 과정이라고 생각하면 동기부여가 될 수 있따.

하루에 30분여를 브레인 스토밍이라던지, 플로우차트 정리라던지, 업무 관련 토론이라던지 하는 가벼운 업무로 할당하면 성장 속도에 부스팅을 할 수 있다.

이렇게 짧은 목표로 동기부여를 하면, 점진적 발전을 느낄 수 있을 것이다.

여우의 머리보다는 사자의 꼬리가되어라

최고의 자리에 만족하지마라. 사자의 머리가 될 수 있다면 좋겠지만, 여우의 머리에 만족하진 말자.

피드백 루프 만들기

지속적인 개선을 위한 과정을 만들어라.

더 중요한 것은 지속적인 개선을 받아들이고 즐기는 것이다.

능력의 폭을 넓혀라

  • Rss
  • 트위터
  • 유저그룹
  • 컨퍼런스
  • 유투브나 팟캐스트

배움의 인사이트는 다른 사람의 공유된 정보들에서 얻기가 쉽다.

다양한 루트로 다른 훌륭한 선배 개발자 분들의 정보와 지혜, 지식을 습득하자.

연습 또 연습

  • 실수해도 마음편한 환경에서 방해받지않고 기예를 연마할 시간을 확보하라

위에서 언급한 Dev Toy (Toy Project)로 하면 좋다.

오픈소스 문화에 녹아들라

  • 다른사람의 코드를 많이보고 사고방식과 해결책을 이해하라

github를 비롯한 각종 오픈 소스를 자주 사용하고 접해보자.

다른 이의 코딩 스타일, 접근 방식, 해결 과정 등 배울 것이 아주 많을 것이다.

일하면서 성찰하라

  • 사색하는 개발자가 되라
  • 어떻게 일하고 있는지 자기 자신에 대한 성찰이 필요하다

자신이 어떤 방식으로 일하고 있는지, 어떤 장단점을 선택했는지 알아야 한다.

또한 자신의 단점이 현재 상황에서 치명적인 것인지, 자신의 장점이 어떠한 이득을 가져다 주고 있고, 어떤 부분을 보완해야 할지 알려면 자기 자신을 잘 알 필요가 있다.

배운것을 기록하라

  • 블로그
  • 노트
  • 위키

기록 과정에서 몇번의 인사이트와 개선점을 얻게 된다.

가능한한 많이, 그 대신 효율적으로 다시 보기 쉽게 정리하도록 지속적인 개선 해보자.

익숙한 도구에 집중하라

나의 경우에도 최적화 된 도구를 찾는 데에 매우 큰 관심이 있다.

손에 맞는 도구는 생산성에 두배 이상의 차이가 난다고 본다.

특히 스크립팅등의 자동화로 해결해야 되는 일들이 제거되기에 좋은 도구 사용은 의미가 크다.


결국 반복적인 키워드는, 지속적인개선이다.

꾸준함과 향상이 있다면 결국엔 좋은 프로그래머가 된다는 얘기다.

자신이 훌륭한 프로그래머가 되고 싶다면, 이 책에 있는 것들을 하나 하나 실천해보면 어떨까?