추석 때 한창 인기를 끌었던 ‘추억이란 무엇인가’의 김영민 교수가 작성했던 여러 글이 모여서 만들어진 책 입니다.

전에 제가 존경하는 선배 개발자분께 이런 질문을 받은 적이 있었습니다. “사람은 어차피 죽는다, 어차피 죽을 거면 우리는 왜 살아야 할까? 무엇을 위해? 어떤 목적을 위해 살아야 할까? 고통스럽게 더 오래 살아서 무엇을 성취하고 무엇을 달성하기 위해서?” 쉽게 답을 내리기는 어려웠고 앞으로 남은 시간을 어떻게 보내고 어떻게 살아야 할까에 대해 진지하게 한번 더 생각하게 만들어주는 질문이었습니다. 우리가 스타트업에서 온 몸을 바쳐 일을 하는 이유가 어느 정도 연결되지 않을까요? 고통스럽지만 한번 고민해보시면 재밌는 시간을 보내실 수 있을거에요.

제목만 보고 비슷한 느낌의 책이려나? 하고 골랐지만 사실 심오한 내용이 전부는 아니고 오히려 재밌는 내용이 더  많습니다. 무엇보다 좋은 건 교수님이 책에서 정말 많은 질문을 합니다. 심오하지만 매우 재밌기에 추천드려요, 책의 결론을 내릴 수는 없겠지만 저자가 책에서 반복해서 말하는 포인트는 있습니다.

- "살아가면서 질문을 멈추면 안된다 ~ "
- “스스로와 공동체의 미래를 생각하며 인생을 살 줄 알아야 한다 ~ "
- "그렇지 않으면 이미 죽은 것과 다름 없다."

----

“나는 어려운 시절이 오면, 어느 한적한 곳에 가서 문을 닫아걸고 죽음에 대해 생각하곤 했다. 그렇게 하루를 보내고 나면 불안하던 삶이 오히려 견고 해지는 것을 느꼈다. 지금도 삶의 기반이 되어주는 것은 바로 그 감각이다. 생활에서는 멀어지지만 어쩌면 새에서 가장 견고하고 안정된 시간, 삶으로부터 상처 받을 때 그 시간을 생각하고 스스로에게 말을 건넨다. 나는 이미 죽었기 때문에 어떻게든 버티고 살아갈 수 있다고.”

“상처가 없다면 그것은 아직 아무것도 그리지 않은 캔버스, 용기가 없어 망설이다가 끝낸 인생에 불과하다. 태어난 이상, 성장할 수 밖에 없고, 성장 과정에서 상처는 불가피하다. 제대로 된 성장은 보다 넓은 시야와 거리를 선물하기에, 우리는 상처를 입어도 그 상처를 용서할 수 있게 된다.”

“책을 꼭 읽어야 하나요? 물으면 사실 안 읽어도 된다고 생각을 하기도 합니다만, 책은 인류가 발명한, 사람을 경청하게 만드는 정말 많지 않은 매개 중 하나죠. 그렇게 경청하는 순간 우리가 아주 조금 나은 사람이 될 수도 있다고 보는 겁니다. 자기를 비우고 남의 말을 들어보겠다는 자세요.”

“아침을 열 때는 공동체와 나의 죽음을 생각하는 것이 좋다.
첫째, 이미 죽어 있다면 제때 문상을 할 수 있다.
둘째, 죽음이 오는 중이라면, 죽음과 대면하여 놀라지 않을 수 있다.
셋째, 죽음이 아직 오지 않는다면, 남은 생을 어떻게 살 것인가에 대해 보다 성심껏 선택할 수 있다.
넷째, 정치인들이 말하는 가짜 희망에 농락당하지 않을 수 있다.
다섯째, 공포와 허무를 떨치기 위해 사람들이 과장된 행동에 나설 때 상대적으로 침착할 수 있다.
이렇게 얻은 침착함을 가지고 혹시 남아 있을지도 모르는 자신의 생과 이 공동체의 미래에 대해 생각해보는 거다. 화전민이나 프라이더가 아니라 조용히 느리게, 그러나 책임 있는 정치 주체로 살아보고야 말겠다는 열정을 가져보는 거다.”

“인간이라면 누구나 궁극적으로 지니고 살아야 하는 고독과 이웃하고 있다. 각자의 고독을 확립해야만 인생을 살아갈 수 있다..”

“진정한 평가의 시간은 죽음을 앞두고서야 찾아옵니다. 그러면 미래에 우리가 죽음을 앞두고 스스로의 삶을 평가할 때 적용되어야 할 평가 기준은 무엇일까요? 제가 생각하는 근본적인 평가 기준은 삶의 이야기입니다. 그럼 어떤 것이 좋은 이야기일까요? 성공으로만 점칠된 이야기라고 해서 좋은 이야기는 아닙니다. 실패담도 좋은 이야기가 될 수 있습니다. 좋은 이야기를 위해서는 자신의 삶에서 일어난 일련의 일들에 대한 망각도 필요합니다. 인생에서 일어난 일을 요령 있게 망각하고 기억할 때 좋은 이야기가 남겠지요. 그래서 용기와 도전이 필요한 것 같습니다."

----

앞으로 종종 대화가 피하고 싶어질 때 “추석이란 무엇인가?” 의 마지막 내용과 같은 자세로 질문을 해봅시다. 껄껄

지각하지 말자! 지각이란 무엇인가?
연애는 언제하냐! 연애란 무엇인가? 외로움이란 무엇인가?
좋아하는 이성 스타일이 뭐니? 좋아한다는 것은 무엇인가? 이성이란 무엇인가? 스타일이란 무엇인가?
밥 먹자! 밥이란 무엇인가? 먹는다는 것은 무엇인가?
이번주 업무 왜 이러니? 이번주란 무엇인가? 업무란 무엇인가?

2019.04.07 14:08. RSS feed. Trackback 0 came from other blogs. Leave a Response.
Posted in 독서. Top

댓글을 달아 주세요

(1)

'클린 코드 : 애자일 소프트웨어 장인 정신' 은 개발자 필독서로 뽑히는 여러 책 중 한 권입니다. 클린 코드를 짜기 위해 여러 정석적인 내용이 많이 들어있습니다.

----

"핵심은 팀이나 공동체에서 서로 동의하는 합리적인 원칙을 세우기 위한 소통에 있다."

"사소한 곳에서 발휘하는 정직은 사소하지 않다."
 - 코드를 하나의 단어, 문장, 함수로만 생각하면 모든 코드가 사소해 보입니다. 하지만 이 사소한 코드들이 뭉쳐 아키텍처를 이루고 시스템을 만듭니다. 그리고 고객에게 배포되죠. 그러니 애초에 코드를 쓸 때 한 단어, 한 문장을 쓰는 손짓에 집중하고 정직하게 작성해라 라는 느낌으로 받아들이면 될 것 같습니다.

"품질은 하늘에서 뚝 떨어진 위대한 방법론이 아니라 사심 없이 기울이는 무수한 관심에서 얻어진다."

"품질을 개선하기 위한 사소한 활동이 간단하다고 해서 단순하다는 뜻은 아니다. 쉽다는 의미는 더더욱 아니다."
 - 어디가서 "버그가 발생할 리 없습니다." / "좋은 품질을 어렵지 않습니다." 이런 얘기를 함부로 하는 개발자가 있다면 거리를 멀리 둘 것..

"주석은 나쁜 코드를 보완하지 못 한다."

"나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못 하다"
 - 간혹 다른 운영팀에서의 요청이 시스템에 안 좋은 영향을 미칠 수 있다면 우리는 STOP을 외치고 충분히 고민해야 할 필요가 있고 논쟁을 통해 좋은 방향을 만들어낼 책임이 있습니다.

"나쁜 코드도 돌아는 간다. 하지만 코드가 깨끗하지 못 하면 개발 조직은 기어간다. 매년 지저분한 코드로 수많은 시간과 상당한 자원이 낭비된다."

----

역시나 거듭 빠지지 않던 내용은

 - "설계에 가장 많은 시간을 쏟아야 한다."
 - "믿음 있는 테스트와 함께해야 한다." (TDD 와 테스트 코드)

개개인의 성장이 뒷받침되어 서비스의 품질도 향상되고 이러한 개발팀의 노고가 고객들에게 이어졌으면 좋겠습니다.

(2)

"코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다. 어쩌면 '돌아가는 코드'가 전문 개발자의 일차적인 의무라 여길지도 모르겠다. 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 대해 지대한 영향을 미친다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기  어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다."
 - 개발에 대해 잘 모르시는 분들이 가장 간과하는 것 중 하나 입니다. 왜 가독성을 위한 리팩토링을 하는 것이고, 왜 스타일에 집중하는지? 우리 팀원들은 공감하고 있어서 정말 다행입니다.

"좋은 소프트웨어 시스템은 읽기 쉬운 문서로 이뤄진다는 사실을 기억하자, 스타일은 일관적이고 매끄러워야 한다. 한 소스 파일에서 봤던 형식이 다른 소스 파일에도 쓰이리라는 신뢰감을 독자에게 줘야 한다."

개념적 유사성을 기반으로 세로 순서, 세로 밀집도, 수직 거리, 가로 공백과 밀집도, 가로 정렬과 같이 제가 미처 많이 생각하지 못 했던 것 또한 나름의 이유와 함께 설명되어있는 부분도 많이 인상적이었습니다. 또 코드의 가독성을 단순 개선이 아닌 목적과 이유를 말하고 설득시킬 수 있게끔 발전시킬 수 있는 가능성을 책에서 찾을 수 있는 것이 매우 기분이 좋았..고..

저번과 마찬가지로 옳은 말씀만 많았지만 그래도 좋았습니다. 이제부터는 추상화, 클래스, 객체, 동시성, 테스트 코드, 휴리스틱 등의 어려운 말씀을 하시려고 하는 느낌이 들어 마음의 준비를.. 하려고 하고 저번 독서 공유 때 썼던 "사소한 곳에서 발휘하는 정직은 사소하지 않다."을 다시 한번 다짐하며 마무리!

(3)

“소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다”

“깨끗한 테스트의 다섯가지 규칙
 - 빠르게: 테스트는 자주 돌려야 하기 때문에 빨라야 한다, 자주 돌려야지 초반에 문제를 찾아내고 고치고 정리를 빨리 할 수 있다. 빠르지 못하면 사람이 지친다.
 - 독립적으로: 각 테스트는 독립적으로 어떤 순서로 실행해도 괜찮아야 한다.
 - 반복가능하게: 테스트가 돌아가지 않는 환경은 없어야 한다.
 - 자가검증하는: 결과는 무조건 성공 아니면 실패다. 스스로 가늠이 되어야 하며 핑계는 필요 없다.
 - 적시에: 테스트가 불가능하도록 실제 코드를 설계하지 않도록 적시에 단위 테스트를 고려하며 설계한다."

"테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다. 가끔 실제 코드보다 더 중요하다. 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 때문이다.”

“좋은 리팩토링
 - 좀 더 길고 서술적인 변수 이름
 - 핑계 주석을 추가하지 말고 함수 선언과 클래스 선언부를 주석이라 생각하고 설계에 집착해보자
 - 공백과 형식 맞춤은 가독성을 위한 중요한 수단이다.”

 

 

2019.04.07 14:04. RSS feed. Trackback 0 came from other blogs. Leave a Response.
Posted in 독서. Top

댓글을 달아 주세요

"철학이란 무엇인가, 철학적인 생각이란 무엇인가”라는 두 주제를 붙잡고 얘기하는 책입니다. 역사적인 얘기도 나오고 여러 내용들이 재밌게 구성되어 있지만 너무 같은 얘기로 질질 끄는 감이 없지 않아 있습니다. (그만큼 강조하고 싶으신 거겠지만..) 저자가 전달하고자 하는 이야기를 좀 더 간추려 보면 다음과 같습니다.

 - “철학을 공부하고 믿고 실천한다고 해서 철학적인 삶을 사는 것은 아니다.”
 - “생각의 결과를 배우는 것이 아니라 생각할 줄 아는 것이 철학이다."
 - “집단으로부터, 공동체로부터 독립할 수 있는 개인이 되어야지 성장 가능한 집단과 공동체를 만들 수 있다."
 - “질문하지 못 하는 사람은 종속적이고, 단편적이고, 지배받고, 성장할 수 없는 사람이다.”

질문이 얼마나 중요한 역할을 하는지, 집요함, 몰입, 관찰력이 얼마나 중요한 것인지 300 페이지에 걸쳐 얘기하고 있습니다. 개인에게
 하는 잔소리가 아니라 위 능력들이 스타트업의 모든 인력들에게 정말 필요한 능력이 아닐까 생각하며 책을 읽었습니다.

--

*철학을 하는 목적은 철학적인 지식을 축적하는 일이 아니라, 직접 철학하는 것이다.

*우리가 접하는 모든 철학적인 저작들은 어떤 철학자가 해놓은 생각의 결과물들인데, 보통 그 생각의 결과물들을 그대로 받아들여 내면화하는 것을 철학하는 것으로 오해하곤 한다. 하지만 단언컨대 그것은 ‘철학하기’ 일 수 없다.

*생각의 결과들이 어떤 구체적인 세계를 토대로 형성된 것인지를 이해한 후, 지금의 세계에서 나에게 포착된 시대의 문제를 지성적인 높이에서 계속 생각해보는 것이 철학이다.

*생각의 결과를 배우는 것이 철학이 아니라, 생각할 줄 아는 것이 철학이다. 정해진 진리를 받아들이는 것은 진리를 대하는 태도일 수 없다. 자기만의 진리를 구성해보려는 능동적 활동성이 진리를 대하는 태도다.

*종속적 주체는 자신의 주인 자리를 신념이나 이념 혹은 가치관에 양보한 상태다. 진정한 자아와 자신을 이끄는 자아가 분리되어 있다. 이런 분리 상태에 있는 사람은 자발적이고 책임성 있는 존재가 되지 못한다. 반성적 윤리의식이 매우 취약해져 남 탓을 하는 것만으로도 자신이 무엇인가 의미 있는 일을 하고 있다고 착각한다.

*철학적이지 못 한 사람 - 누군가의 지식을 소유해서 재사용하거나 거기에 몰두하고 빠져드는 사람 (일반적인 모범생들)
*철학적인 사람 - 지식 자체의 맥락과 의미를 따지고, 그것이 세계 안에서 벌이는 작동과 활동성을 보는 사람 (창의적인)
 - 스타트업은 상당히 철학적인 시선, 생각, 질문을 요구한다.

*"’장자’를 감명 깊게 읽었다니 다행이네. 그런데 ‘장자’에 감명을 받고 나서 기껏 한다는 생각이 장자처럼 살아보는 일인가? 분명히 알아야 할 것은 장자는 절대 누구처럼 산 사람이 아니네”

*일등은 판을 지키는 사람이고, 일류는 새판을 짜는 사람이다. 짜진 판 안에서 사는 데 만족하는 것은 전술적 차원에 머무르고, 판을 짜 보려고 하는 것은 전략적 차원으로 상승한다.

*왜 생각이 꼭 합리적이어야만 하는가? 왜 기존에 있는 어떤 것들과 반드시 조화를 이루어야 하는가?

*꿈을 꾸는 삶이란 바로 ‘나’ 로‘나’로 사는 삶이다. 내가 한 인간으로 잘 살고 있는지, 독립적 주체로 제대로 서 있는지, 누군가의 대행자가 아니라 ‘나’로 잘 살고 있는지, 수준 높은 삶을 살고 있는지, 철학적이고 인문적인 높이에서 살고 있는지를 확인해야 한다.

*나는 지금 어떤 꿈을 꾸고 있는가?

*나와 삶이 내 꿈을 실현하는 과정으로 되어 있는가? 아니면 해야 하는 일들을 처리하는 과정으로 되어 있는가?

2019.04.07 14:00. RSS feed. Trackback 0 came from other blogs. Leave a Response.
Posted in 독서. Top

댓글을 달아 주세요

*아키텍트 (Architect) - 아키텍처(Architecture)를 설계 하는 사람
*아키텍처 = 건물의 구조 (서비스의 구조)
*아키텍트 = 건물의 구조를 설계하는 사람 (서비스의 구조를 설계하는 사람)

*이 책은 97명의 선배들의 인터뷰 담겨져 있는 글 입니다. 30% 정도의 내용만이 High Tech 얘기였고 그 외에는 중상 난이도 정도의 기술 얘기, 사람, 리더십, 커뮤니케이션, 설계, 비즈니스에 대한 얘기가 많았습니다. 그 만큼 소프트웨어 개발이 어렵다는 얘기가 아닐까요? 모든 것이 똑똑한 엔지니어 몇 명이 모여 해결할 수 있는 문제 였다면.. ㅠ 우리는 정말 어려운 일을 함께 하고 있습니다.

*한국에서는 흔하지 않은 역할 이지만 해외에서는 ‘아키텍트’ 라는 역할의 개발자들이 많은 것 같습니다. 설계 능력과 트러블 슈팅 능력이 뛰어나신 분들이 주로 맡는 역할 입니다. 그 만큼 소프트웨어의 복잡성에 대해서 이해하고 있고 그 어려움을 적절하게 풀어가려고 하는 좋은 환경이 만들어져 있는 거라 생각합니다.

*이 책을 읽으면서 부러웠던 점은 국내에서도 이런 현실적인 문제점들을 같이 공유하고 해결하려는 노력들이 많이 이루어졌으면 좋겠다는 생각이 참 많이 들었습니다. 아직 국내 IT 환경은 적절한 대우를 받지 못 하는 인력들이 훨씬 많습니다. 또 그런 목소리를 낼 수 있는 공간도 많이 부족하구요. 저의 여러가지 역할 중 한 가지가 이런 운동에 앞서야 하고, 더 강하게 목소리를 내야 한다고 생각하고 있습니다. 이런 운동들이 많아지고 순환이 계속해서 이뤄지면 발전을 이룰 수 있는 토대가 형성될 것이고, 더 좋은 인재들이 발굴되지 않을까요?

----

*고객의 요구사항보다 여러분의 이력에 더 우선순위를 두지 말라.

*가장 큰 문제는 기술이 아니다.
> 프로젝트의 성공과 실패 모두 사람이 만든다, 사람들이 성공하게 만드는 데 무엇이 도움이 되는지 고민해야 한다.

*모든 것은 궁극적으로 실패하게 된다.
> 소프트웨어 내 버그는 무조건 생긴다. 일단 결함이 발생할 수 있다는 것을 인정한다. 결함 모드를 미리 설계할 수 있는 대응력을 길러야 한다.

*정량화시켜라.
> ‘빠르다’, ‘응답성이 좋게’, ‘확장성 있도록’ 은 요구사항이 될 수 없다. 상대방에게 정확하게 요구하자.
> 마찬가지로 ‘빠르다’, ‘응답성이 좋게’, ‘확장성 있도록’ 은 목표가 될 수 없다. 정확하게 상대방을 설득하자.
> 시스템이 이러한 속성들을 포함하도록 하고 균형을 맞추며 정확히 얼만큼의 성능인지 수치화를 할 수 있어야 한다.
> 정량화가 어렵다? 그럼 정량화 할 수 있는 것을 찾아 바꾸거나, 할 수 있는 방법을 고민하는 것이 우선이다.

*한번에 딱 맞는 해결책은 없다.
> 영역에 맞는 감각을 지속적으로 계발하고 연습해야 한다.

*비즈니스 도메인 이해하기
> 기술 뿐 아니라 문제 영역의 비즈니스 도메인도 이해해야 한다.
> 비즈니스 도메인 지식 없이 비즈니스의 문제, 목표, 요구들을 이해하기 힘들다.
> 소프트웨어 아키텍트들은 임원과 비즈니스 사용자와 대화 시 도메인 언어를 사용해야 한다.
> 상담 받는데 이런 것이 불편하지 않을까? 편하지 않을까? -> 상담을 받아 보지 않은 실무자가 어떻게 알 수 있을까?

*운영과 유지 보수에 집중하라
> 유지보수는 어플리케이션 생명주기 중 80% 이상을 차지한다.
> 운영 팀의 학습 비용을 최소화시키는 방향을 항상 염두에 둬야 한다.

*간단한 것은 간단하게 하라
> 오버 엔지니어링을 피하자.
> 엔지니어의 능력 중 (1) 가장 어렵고 (2) 가장 중요하고 (3) 가장 높은 평가를 받을 수 있는 능력은 **적절한** 해결책을 찾는 것 이다.

*탄탄한 비즈니스 사례를 만들어라
> 비즈니스가 우선이다.
> 신뢰를 얻어야 한다.
> 확실한 가치 제안 / 정량화된 측정 지표 제작 / 적절한 일정

*훌룡한 소프트웨어는 만들어지는 것이 아니라 성장하는 것이다
> 동작하는 하나의 작은 시스템에서부터 천천히 개발하고 테스트하고 성장해야 한다.
> 거대한 시스템 설계도를 가지고 시작하는 것은 거의 장점이 없다.

*개발에 있어 형식에 얽매이는 행위야말로 삽질이다
> 이론에만 충실한 방법론자들과 형식에 대한 삽질을 유도하는 팀을 피한다.
> 소프트웨어는 100% 품질을 보장할 수 없다.
> 모든 것은 '필요한 수준’ 의 적정 선 만큼 이루어져야 한다.
> 각자의 경험과 해결책들을 다양하게 소화하고 조화롭게 이끌어가는 것이 중요한 포인트.

2019.04.07 13:58. RSS feed. Trackback 0 came from other blogs. Leave a Response.
Posted in 독서. Top

댓글을 달아 주세요