프로그래머 철학을 만나다

현재의 행복을 이야기한다. 미래는 불확실하다불확실성을 인정하고 불확성실성을 줄여나가는 것을 이야기하는 듯 하다

스크럼, 에자일, ATDD, TDD, 중용, 실천적인 지혜

목차 기준에서 다시 볼 부분 하일라이트

목차

01 자존감

자기 자신의 주인이 되지 못하는 사람은 진정으로 자유로울 수 없다. - 에픽테토스 (Epictetus, 55? ~ 135?)

• 무력감

• 불안의 원인

  자신의 내면이 외부로부터 공격 받아 다치지 않도록 보호하는 것이 핵심이다. 외부 환경의 불합리로 자신의 생각과 행동이 지배 당하면 아무것도 할 수 없다.

• 내면을 파괴하는 힘

  팀장의 문제 제기 덕에 프로젝트의 문제점이 초기에 가시화 되어 그에 대한 대비책을 준비할 수 있었던 점이다

• 권위의 함정

• 내면의 외적 통제

  "만일 누군가가 너의 몸을 [우연히] 마주친 사람에게 떠넘긴다면 너는 화가 날 것이다. 그런데 너 자신의 정신을 우연히 만나는 사람에게 떠넘겨서, 그래서 결과적으로 그 사람이 너를 욕보인다면 너의 정신은 교란되고 혼란스럽게 되는데, 너는 [이것에 대해서] 부끄러워하지 않겠는가?" - 엥케이리디온 도덕에 관한 작은 책 - 에픽테토스

• 자존감(自尊感, self-esteem)

  미 육군의 리더쉽 메뉴얼에는 "리더는 스테레스 상황에서도 평정심을 유지하고 자신이 긍정적으로 영향을 줄 수 있는 일들에 에너지를 쏟으며, 자신이 영향을 끼칠 수 없는 일을 걱정하지 않는 것이 무척 중요하다"는 항목이 있다

  자존감은 "무엇인가 해낼 수 있다"는 자기 능력감과 "자신이 사랑받을 가치가 있다"는 자기 가치감으로 구성된다

• 소프트웨어 개발의 주인으로 사는 법 에픽테토스의 통제할 수 있는 영역과 없는 영역을 소프트웨어 개발자에게 적용해 보면 표1 과 같을 것이다
• 코드
• 개발환경
• 통제할 수 없는 영역

• 받아들이기

  끝으로 존재에는 이유가 없다. "나는 왜 태어났을까?", "왜 하필 이런 환경에서 태어났을까?"는 우리의 선택도 아니고 통제 할 수 있는 범위도 아니다. 직시하고 받아들인 후 "어떻게 행복하게 살 수 있을까?"에 집중하며 살아야 한다. 우리 모두는 그럴 만한 가치가 있는 사람들이며 그렇게 자신을 위해서 살아도 비방받지 않는 사람들이다. 그 사실을 스스로 믿으면 된다.

02 지속적 발전

이론과 실천 중에서 무엇이 더 효과적인가? - 무소니우스 루푸스(Musonius Rufus)

• 실천하는 철학
• 사회가 개발자에게 요구하는 철학
• 뛰어난 기술력
• 변화하는 기술을 빨리 이해하고 적용하는 능력
• 뛰어난 의사소통 능력 및 협상능력
• 창의력과 문제해결 능력
• 열정
• 복종
• 개발자가 추구해야 할 철학
• 철학 훈련

• 코드 리뷰

  "지금 급해서 이렇게 처리하지만 '다음'엔 반드시 개선해야 한다"라고 적겠지만 그 코드를 읽고 있는 지금까지 '다음'이란 시간은 오지 않았고 앞으로도 요원할 것이다.

  개인 코드리뷰는 적절한 시간에 꾸준히 수행해야 하며 개발 과정에서 다음과 같은 순간에 적용하는 것이 효과적이다

  개인 코드 리뷰 순간

  • 코드 커밋 전
  • 정적분석 직후
  • 오류를 수정한 직후
  • 정리하는 시간

  개인 코드 리뷰 시 확인하면 좋은 항목

  • 의미 있는 변수/함수 이름
  • 하드코딩 데이터
  • 함수의 통일성
  • 통일된 데이터 형식 사용
  • 복잡도
  • 오류 처리 방식 통일
  • 자원 해제 확인
  • 코딩 컨벤션 준수 확인

• 회고

  경청, 즐거운, 자존감

• 육체 훈련

  사람은 걷고, 걷기 위해 존재한다 - 이브 파칼레

• 어제와 다른 오늘 그리고 내일
• 말.말.말

03 화에 대하여

화는 혼자서는 결코 어떤 모험도 감행하지 않으며 오직 마음의 동의가 있어야만 야기된다. - 세네카(Lucius Annaeus Seneca, BC4~AD65)

• 협업

  소프트웨어 개발분야에서 잉여가치를 생산하려면 각자의 역할을 충실히 수행하며 협업 상대의 전문성에 도움받아 각 역할의 한정된 시각을 상호보완해야 한다.

• 협업을 저해하는 요소

  레온 페스팅거의 말 처럼 "인간은 합리적인 존재가 아니라 합리화하는 존재"이기 때문이다.

  하지만 산출물이 생산을 완료했다고 업무가 끝나지 않는다. 자신의 산출물을 타인에게 인도하면서 이해시키거나 설득하는 작업이 필요하다. 예를 들어 기획자의 경우 기획서를 작성하고 해당 기획서를 개발, QA 등 관련자에게 전달하고 설명해야 한다. 또한 기획서대로 개발이 진행되는지 확인해야 한다.

  역설적으로 누군가 열심히 일한 결과를 누군가는 열심히 비판해 주어야 소프트웨어를 제대로 개발할 수 있다. 하지만 이러한 작업을 서로에 대한 비난으로 받아들여 화가 나게 되면 협업은 요원한 일이 되어버린다.

• 루키우스 안나이우스 세네카

  세네카는 화가 주체할 수 없는 격정이 아니며 화가 나기 직전 이성으로 통제할 수 있는 시기가 있다고 설명했다.

  "화는 혼자서는 결코 어떤 모험도 감행하지 않으며 오직 마음의 동의가 있어야만 야기된다는 것이 우리(스토아 학파)의 견해다. 부당한 일을 당했다고 생각하는 것, 그것에 대한 보복을 열망하는 것, 그리고 사람이 위해를 입어서는 안 된다는 것과 남에게 해를 끼친 자는 보복을 당애햐 한다는 두 가지 명제를 결합시키는 것."

• 화에 대하여 결국 소프트웨어 개발과정에서 발생하는 냉소, 비협조, 위협 등은 화를 표출하는 또 다른 방식일 뿐이다.

• 화의 유용성과 화의 해악

  간혹 상대방에 대한 질책이나 비판을 화로 오인하는 경우도 있는데 질책과 비판은 사물의 옮고 그름을 판단해 가리고 그를 꾸짖어 바로잡는 행위이다. 가급적 부드러운 말로 사람의 행동을 올바르게 이끌어 질책을 받는 사람으로 하여금 잘못을 버리고 올바른 것을 추구하게 만들어야 하며 원칙적이면서도 날카롭고 단호한 어조로 말하되 어디까지나 훈계의 수준에서 멈추어야 한다.

• 화의 원인

  세네카는 화의 원인 중 가장 높은 영향력을 가진 것으로 "나는 잘못한 것이 없다"는 생각을 꼽았다.

  근거 없는 낙관론

  동기유발 산업의 기원과 문제점을 알고 싶다면 바버라 에러 라이크의 저서 <긍정의 배신>을 읽어보기 바란다.

• 화를 억제하고 다스리는 방법

  화의 억제와 다스리기의 시작은 화의 원인을 이해하고 인정하는 것이다.

  현실적 낙관론

  피드백을 부정적이라 느끼는 것은 자신이 그것을 부정적으로 받아들이기 때문이다.

  세네카는 화에 대한 최고의 치유책이 유예와 숨김이라고 주장한다

  하지만 자신의 화를 잘 다를 수 있더라도 상대방이 분노를 제어하지 못한다면 협업은 불가능하다.

  충분한 시간을 갖고 감정을 회복하여 문제의 해결 방법을 고민할 수 있으며 상대방도 시간에 따라 감정이 누그러지면 시간을 제공해준 당신에게 호의를 갖게 된다.

• 소프트웨어 개발에 대하여

  좋은 소프트웨어를 개발하고 싶다면 소프트웨어 개발에 참여하는 다양한 역할을 이애해야 한다.

  좋은 소프트웨어가 긴말한 협업의 산물임을 항상 명심한다면 화를 보고 쉽게 다룰 수 있다.

• 말.말.말

04 미래에 대하여

우리들 각자는 미루다가 인생을 낭비하며, 여가를 누리지도 못하고 죽는다. - 에피쿠로스(Epikuros, BC341 ~ BC270)

• 미래의 역습

• 미래를 상상하는 일의 양면성

  인간의 의식 구성을 조사한 결과 인간은 생각하는 전체 시간 중 12%를 미래를 상상하는 데 사용한다.

  인간이 미래의 불길한 일을 예측하는 이유는 두 가지다. 첫 번째는 불길한 일을 미리 예상해 봄으로써 그 일이 현실이 되었을 때의 충격을 줄이려는 목적. 불길한 일을 예측하는 두 번째 이유는 그러한 일을 막기 위함이다.

• 불안을 느끼는 이유

• 불안의 원인

  지금까지 살펴본 바와 같이 인간은 미래 예측에 별로 소질이 없으며 미래에 집중한다고 행복이 보장되지도 않는다. 이에 미래라는 불확실성에 벗어나 현재를 행복하게 살아가는 것의 중요성과 실천 방법을 살펴보자.

• 에피쿠로스

• 현재를 행복하게 살아가는 개발자

  ATDD, TDD

  고결이 무엇인지 정의내리기는 어렵지만 개발자에게 있어서 고결함이란 누구에게 보여도 부끄럽지 않는 코드를 작성하는 일 아닐까?

• 현재에 집중하는 관리자

  많은 경험, 높은 지식, 뛰어난 협업 능력을 갖춘 관리자가 가장 잘 하는 일은 '문제의 해결'이지 '미래 문제의 예측'이 아니다

• 과도한 목표 설정과 관리자의 망상
• 인센티브의 허상
• 소프트웨어 프로젝트의 현재와 미래 관리
• 스크럼(Scrum)
• 현재에 충실한 개발
• 번다운차트(Burn down Chart)를 이용한 예측
• 개발자의 행복한 삶

05 논리적 소프트웨어 개발에 대하여

무지를 아는 것이 곧 앎의 시작이다. - 소크라테스(Socrates, BC470~BC399)

• 소프트웨어 개발
• 논리적 오류(logical fallacies)
• 임시방편의 오류
• 인신공격의 오류
• 무지에 호소하는 오류
• 권위에 호소하는 오류
• 대중에 호소하는 오류
• 감정에 호소하는 오류
• 무력에 호소하는 오류
• 선결문제 요구의 오류
• 확증 편향의 오류
• 보편적 요인에 따른 오류
• 원인과 결과의 혼동으로 생기는 오류
• 비유사성에 따른 오류
• 다의(多意)에 따른 오류
• 잘못된 이분법에 따른 오류
• 성급한 일반화의 오류
• 완곡어법의 오류
• 모호성과 중의성의 오류
• 인과(因果)의 오류
• 붉은 청어 오류
• 미끄러운 비탈길 오류
• 허수아비의 오류
• 피장파장의 오류

• 소크라테스의 문답법

  요구사항 파악, 기획검토, 설계 검토/코드 리뷰, 그 외 협의 및 토론

• 정리하며

06 실천적인 지혜에 대하여

아는 것에 의해서가 아니라 아는 것을 실천할 때 비로소 지혜로운 사람이 될 수 있다. - 아리스토텔레스(Aristoteles, BC384~BC322)

• 지적인 미덕과 도덕적인 미덕

  지식을 쌓는 것과 그 지식을 활용하는 건 엄연히 다르기 때문이다.

  아리스토텔레스는 미덕을 '지적인 미덕'과 '도덕적인 미덕'으로 구분하였다. 지적인 미덕은 교육에 의해 생기거나 성장하는 미덕이며 도덕적 미덕은 실천하고 활용하여 습관이 되어야만 이룰 수 있는 미덕이다. 노력과 실천없이는 도덕적 미덕은 저절로 생겨나지 않는다. 그리고 도덕적 미덕은 사람의 본성을 벗어나지 않는다는 특성도 있다.

• 프로세스의 함정

  프로세스가 문제 해결의 유일한 정답이 아니다. 그럼에도 프로세스를 선호하는 이유는 그것이 제일 쉬운 해결책이라는 오해와 책임을 면하려는 의도가 결합된 결과라 생각된다.

  운영하고 적용하는 사람 모두 책임감 있게 프로세스를 살피고 관리하지 않으면 프로세스는 본래의 목적을 상실하고 생산성만 저하시키는 괴물로 둔갑하기 일쑤이다.

• 아리스토텔레스의 실천적인 지혜

  아리스토테레스는 '중용'의 중요성을 강조했는데, 중용은 단순히 산술적 중앙 지점을 의미하는 것이 아니다. 지나침과 모자람의 관계적 중간을 의미한다.

  중용을 이용하여 매사의 목적에 적절한 해법을 찾고 이를 생활에서 실천하면서 발전시켜나가면 '실천적인 지혜'를 얻을 수 있다.

  실천적인 지혜는 지식을 올바르게 실천하는 경험을 통해 얻게 되는 통찰력을 의미한다.

• 마치며…

에필로그

이 책을 퇴고할 즈음에는 새로운 환경에서 도전을 시작할 계획이다. 장밋빛 미래가 펼쳐질 것이란 기대는 없으며 지금보다 더 혹독한 시련과 실수를 경험할 수도 있겠지만 어떤 상황이라도 삶의 주인이 온전히 나임을 알고 주변에 인생의 방향을 위탁하지는 않을 것이다.

• 추천도서 목록