엘레강트 오브젝트

넥스트 스텝의 클린코드를 진행하면서 해당 책의 내용이 많이 인용되기에 윤석님에게 빌려 읽어봤다. (절판이라서 구매할 수 없음)
절차지향적으로 컴퓨터를 위해 코드를 작성하는 것을 멀리하고 유지보수성 을 위해 지켜야 할 규칙들을 설명한다.

공감하는것은 체크로 표시해보았다.

1. -er로 끝나는 이름을 사용하지 마라
   • 클래스의 이름은 무엇을 하는지가 아니라 무엇인지, 할 수 있는 일에 기반해야 한다.
   • -er로 끝난다면 어떤 데이터를 다루는 절차들의 집합일 뿐이다.
2. 생성자 하나를 주 생성자로 만들어라
   • 응집도가 높고 견고한 클래스에는 적은 수의 메서드와 상대적으로 더 많은 수의 생성자가 존재한다.
3. 생성자에 코드를 넣지 마라
   • 인자를 그대로 캡슐화하면 연산 시점을 자유롭게 수정할 수 있어 사용자가 쉽게 제어할 수 있다.
4. 가능하면 적게 캡슐화하라
   • 내부 상태 (또는 식별자)를 최대 4개 이하로 캡슐화하라.
   • 상태의 개수가 클래스를 분할할지 결정하는 신호로 봐야하며, 상태가 없는 객체는 존재해서는 안된다.
5. 최소한 뭔가는 캡슐화하라
   • 상태가 없는 클래스는 OOP에서 멀리해야 할 정적메서드와 비슷하며 오직 행동만 존재하기 때문에 OOP에서는 존재하지 말아야 할 개념이다.
6. 항상 인터페이스를 사용하라
   • 객체간에 인터페이스를 통하여 결합도를 낮추기 위한 내용에는 완전히 공감하지만, 개발 초기부터 API 목록을 잘 뽑아낼 자신이 없다면 일단 콘크리트 클래스로 개발해도 된다고 생각한다.
   • 모든 메서드를 인터페이스를 통해 구현하는 것은 추상화에 대한 능력이 어느정도 있어야한다고 생각한다.
   • 처음에는 어느정도 절차지향적으로 작성하여 리팩토링을 통해 추상화 지점들을 더 잘 찾아낼 수 있다고 생각한다. 이른 추상화를 한다면 큰 그림을 못 볼 가능성이 있다.
7. 메서드 이름을 신중하게 선택하라
   • 뭔가를 조작한 후 반환하거나, 뭔가를 만드는 동시에 조작하는 메서드가 있어서는 안된다는 것이다.
   • 예를 들어, fun write(content: InputStream): Int 처럼 content를 전달받아 어딘가에 작성하고 쓰여진 바이트 수를 반환하는 것처럼 메서드의 목적이 명확하지 않기 때문에 깔끔하게 명사나 동사 둘 중 하나로 이름을 지을 수가 없는 것이다.
8. 퍼블릭 상수를 사용하지 마라
   • 객체들은 어떤 것도 공유해서는 안되며 독립적이어야 하고 닫혀 있어야 한다.
   • 상수라도 객체간에 공유하게 되면 결합도가 상승하고 응집도가 저하되기에 기능을 공유할 수 있도록 새로운 클래스를 만들어야 한다.
   • 이 말은 퍼블릭 상수마다 캡슐화하는 새로운 클래스를 만들어야 한다는 것이다. 수백 개의 단순한 상수 문자열 리터럴 대신 수백 개의 마이크로 클래스를 만들어야 한다는 것이다.
   • 굉장히 맞는 말이지만 OOP에 대한 실력이 낮기에 개발하면서 적용하기가 쉽지않다.. 노력해봐야겠다.
9. 불변 객체로 만들어라
   • 식별자 가변성 문제가 없고 실패 원자성 이 지켜지며, 시간적 결합 을 제거할 수 있다.
   • 그리고 사이드 이펙트 가 존재할 수 없게 되며, 스레드에 안전 하다.
   • 상수 객체와 불변 객체를 혼용해서 표현하곤 하는데, 상수 객체는 불변 객체의 특별한 경우일 뿐이다.
10. 모의 객체 대신 페이크 객체를 사용해라
    • 모키토 같은 라이브러리에 의존하여 모킹을 하는 방법을 지양하고 가짜 객체를 사용하는 점은 굉장히 공감한다.
    • 하지만 가짜 객체를 선언하는 위치가 인터페이스 내부인 것은 공감하지 못 하겠다.
11. 5개 이하의 public 메서드만 (protected 포함) 노출하라
    • 의도는 클래스를 작게 만들어서 유지보수성 , 응집도 , 테스트 용이성 을 챙기는 것이다.
12. 정적 메서드(유틸리티 클래스)를 사용하지 마라
    • 저자는 OOP를 제대로 이해하지 못한 프로그래머를 구별할 수 있는 최적의 지표이며 정적 메서드를 순수한 악이라고 생각한다.
    • 정적 메서드를 작성하지 말고 그 기능을 수행하는 객체를 만들어라고 말한다.
    • 싱글톤 패턴은 (캡슐화를 통한) 의존성을 분리하는 이점 이 있긴 하지만 안티패턴인 이유와 비슷하다.
13. 절대 getter와 setter를 사용하지 마라
    • getter와 setter가 존재하는 클래스는 객체라고 볼 수 없다. 그저 자료구조에 불과하며 어떤 개성도 지니지 않은 단순한 데이터 가방일 뿐이다.
    • 어떤 식으로든 멤버에게 접근하는 것을 허용하지 않아야 한다.
    • 자료구조는 투명하지만 객체는 불투명 해야한다. 가시성의 범위를 축소해서 사물을 단순화 시켜야 한다.
    • 내부 멤버들이 모두 공개된 클래스는 절차적인 프로그래밍 스타일을 사용하도록 부추기는 것이다.
14. 부 생성자 밖에서는 new를 절대 사용하지 마라
    • A가 B에 의존할 때 A의 부 생성자 밖(내부 멤버 함수)에서는 절대 new B()를 사용하지 마라는 것이다.
    • A가 필요한 의존성을 직접 생성하는 대신, 생성자를 통해 의존성을 주입받아야 한다.
15. 절대 NULL을 반환하지 마라
    • 어떤 연산의 결과에 NULL이 포함된다면 클라이언트 코드는 NEP에 대해 불안할 수 밖에 없다.
    • 빠르게 실패하기 와 안전하게 실패하기 중에서 저자는 빠르게 실패하기를 지지한다.
    • 빠르게 실패하기 위해서는 예외로 프로그래밍을 해야하고 코틀린에서도 xxxorNull() 함수가 등장하고 있기 때문에 이 토픽에 대해서는 절반만 공감한다.
16. 체크 예외만 던져라
    • 저자는 언체크 예외를 사용하는 것은 실수이며, 모든 예외는 체크 예외여야 한다고 생각한다.
    • 개인적인 생각으로 체크 예외는 객체 간의 결합도를 증가시키는 행위라고 생각한다.
    • 항상 예외를 체이닝 해라라는 말도 공감하긴 하지만 체크 예외를 런타임 예외로 체이닝하는 방법을 선호하기 때문에 이 토픽에는 공감하지 못했다.
17. final이거나 abstract이거나
    • 사람들은 대부분 캡슐화가 상속보다 더 나은 대안이다 라고 이야기하지만, 상속 자체가 문제가 아니라 상속을 올바르게 사용하는 방법을 찾아야한다.
    • 둘 중 어느쪽도 아닌 메서드는 작성하지 말고 final (블랙 박스) 또는 abstract (글래스 박스)로 선언하면 상속의 단점을 보완할 수 있다.
    • 둘 중 어느쪽도 아닌 메서드는 블랙 박스와 글래스 박스 둘 중 어느쪽도 될 수 있기 때문에 혼란스러울 수 밖에 없다.

알고리즘 과 실행 대신 객체 와 행동 의 관점에서 사고해야한다.
절차적인 프로그래밍과 OOP의 중요한 차이점은 책임을 지는 주체가 무엇인가 이다.
우리는 그저 누가 누구인지만 정의하고 객체들이 필요할 때 스스로 상호작용하도록 제어를 위임하는 것이다.
객체는 살아있는 유기체 이며, 다른 유기체들과 의사소통 하면서 그들의 작업을 지원하고, 다른 유기체들 역시 이 객체에게 도움을 받는다.
이렇게 각 객체들은 서로를 필요로 하기 때문에 결합된다는 것 이다.

객체란 디스크에 있는 파일, 웹 페이지, 바이트 배열, 해시맵, 달력의 월과 같은 실제 엔티티의 대표자 이다.
어떤 일을 해야 한다면 객체에게 그 일을 하도록 요청하고, 수신한 요청을 처리하기 위해 객체 스스로 무엇을 할지 결정해야 한다.

진정한 객체지향에서 인스턴스화란 더 작은 객체들을 조합해서 더 큰 객체를 만드는 것을 의미한다.
객체들을 조합해야 하는 단 하나의 이유는 새로운 계약을 준수하는 새로운 엔티티가 필요하기 때문이다.

객체 분리 란, 상호작용하는 다른 객체를 수정하지 않고도 해당 객체를 수정할 수 있도록 만든다는 것을 의미한다.

저자의 단정적인 문체와 공감하지 못하는 내용도 포함되어 있어 거부감이 들순 있지만 객체지향 프로그래밍에 대해 어느정도의 주관이 생길 수 있는 책이라고 느꼈다.
얇지만 OOP에 대해 고민들을 할 수 있는 책이다. 오브젝트 읽기 전에 읽으면 좋을 책이라고 생각한다.

인프런 스프링 DB 1편

실무에서 RW 분리를 진행하는 업무를 진행하면서 리드온리 힌트로 쿼리 라우팅을 통해 DataSource를 분리하는 방법을 찾아 해결했다.
하지만 DataSource와 TransactionManager에 대한 이해가 없었어서 답답하여 사놓은지 1년만에 강의를 다 듣게 되었다.

1. 드라이버 구현체에 따른 커넥션 생성
2. 커넥션 풀
3. DataSource를 통한 추상화
4. 커넥션과 세션, 트랜잭션에 대한 이해
5. 트랜잭션 매니저와 트랜잭션 동기화 매니저
6. 트랜잭션 프록시
7. DB 관련 예외 계층과 예외 변환기
8. TransactionTemplate과 JdbcTemplate

현재 많은 개발자가 애용하는 @Transactional에 대한 변쳔사를 설명한다.
@Transactional를 자주 사용하지만 선언전 트랜잭션 관리 를 통해 어떤 문제를 편하게 해결하고 왜 발전하게 되었는지를 이해할 수 있는 좋은 강의였다.

공부란 무엇인가?

회사 책장의 책들을 보다가 제목을 보고 무슨 내용일까 궁금해서 읽어봤다.
이 책은 공부에 대해 본질적인 질문을 하는 것 같다.
(목적에 도달하기 위한) "과정에 들어가는 노력과 시간 자체가 삶이라는 점을 망각하며 삶을 현재와 동떨어져 전개되는 무엇으로 보도록 길들여진다" 고 아래의 비유와 함께 설명한다.

마치 날씨가 너무 좋은 날 경치가 아름다운 길을 돌아보지 않고 바삐 지나치는 것이 그 시간에 대한 모욕인 것 처럼,
기껏 수능 시험을 얼마나 잘 보았나, 혹은 얼마나 명문 대학에 입학했는가 정도라면 그것은 그보다 흥미로운 지적 체험이 없었다는 자기 고백일 뿐이다.

• 낙화암에서 떨어진다고 모두 꽃은 아니다 (에필로그 중에서)

내용을 서술하는 방법이 직설적이고 저자의 생각을 편하게(거침없이) 설명해준다.
기술 책이나 이 책에 비해 선비같은 책들만 보다가 이런 책을 접하니 재밌고 신선했다.

인상깊은 내용들이 있었다.
공부가 즉각적인 쓸모와 거리가 멀면 멀수록, 묘한 '간지'가 난다고 한다. 누구나 쉽게 배울 수 있는 것지 않을 것들을 공부하는 사람은 정신의 척추 기립근이 잘 세워진 것 처럼 느껴진다.
기자가 등반가에게 "설산을 오르는 것이 대체 무슨 의미가 있나요?"라고 물었을 때 "그렇게 묻는 당신의 인생은 무슨 의미가 있는가?" 라고 대답하는 아주 멋진 사람 처럼 말이다.

그리고 토론의 정의를 설명하고 참여자의 필요한 자세를 설명하는 4부(생각의 심화)가 도움이 많이 되었다.
나는 토론을 하다보면 나도 모르게 불필요한 방어기제가 나온다. 내 의견에 반대되는 의견이 나온다면 감정적으로 동요가 크다는 것을 요즘 느끼고 있다.
토론은 다양성을 무한정 확보하는 것이라기보다는, 다양한 의견을 취합하여 좀 더 나은 지점으로 나아가는 것이라는 것을 기억해야 한다.

예리한 비판을 제기해야 할 순간에 불필요한 공격성을 드러내면, 그것은 미성숙의 표지일 뿐이다.

비판에 대한 생각도 필요하다.

상대를 무시하는 가장 흔한 방법은 져주거나 침묵하는 것이다. 상대를 존중하는 사람만이 비판한다.
결함으로 인해 삶이 아름다워지는 것은 그 결함을 인정할 때 뿐이다.

비판을 하는 사람도 덕성이 필요하다.

1. 상대 주장의 약점보다는 강점과 마주하여 비판적인 논의를 해야 한다.
2. 비판을 불필요하게 길게 할 필요는 없다.
3. 비판이나 비난, 불평만 하는 것은 어떤 바보라도 할 수 있다. 건설적인 제안이나 대안을 제시하는 것이 좋다.
4. 불필요하게 공격적인 언사를 남발해서는 안된다.

위에서 말한 것 처럼 경치나 아름다운 길을 돌아보지 않고 앞만 보고 달리는 사람들, 목적에 심취하여 과정에서 달콤함을 찾지 못하는 사람들에게 추천하고 싶다.

모던 자바 인 액션

• 08월 21일 1주차: 책 알아보기
• 08월 28일 2주차: 1장 ~ 2장 - 동작 파라미터화
• 09월 04일 3주차: 3장 - 람다 표현식, 메서드 참조, 형식 검사와 추론
• 09월 18일 4주차: 4장 ~ 5장 - 스트림 활용
• 09월 25일 5주차: 6장 ~ 7장 - 스트림으로 데이터 수집, Collector, Spliterator
• 10월 02일 6주차: 8장 ~ 9장 - 컬렉션 API 개선, 람다를 활용한 디자인 패턴
• 10월 09일 7주차: 10장 ~ 12장 - 자바 DSL, Optional, 새로운 날짜와 시간 API
• 10월 16일 8주차: 13장 ~ 14장 - 디폴트 메서드, 자바 모듈 시스템
• 10월 23일 9주차: 15장 ~ 16장 - Future와 CompletableFuture, CompletableFuture 예제
• 10월 30일 10주차: 17장 - Flow 예제
• 11월 06일 11주차: 18장 ~ 19장 - 함수형 프로그래밍, 영속 자료구조, 패턴 매칭 등
• 11월 13일 12주차: 20장 ~ 21장 - 자바와 스칼라 비교

책이 꽤 두꺼워서 12주 동안 진행했다.

1. Stream, Collector를 활용하는 방법과 Collector를 커스터마이징 하는 방법
2. 병렬 스트림에서 태스크를 분할하는 방법
3. 디폴트 메서드의 다중 상속에 대한 해결 규칙
4. Optional에서도 스트림 기능을 사용할 수 있다는 것
5. 개선된 날짜 API와 커스터마이징하는 방법
6. Future와 CompletableFuture 활용 방법
7. Flow API를 직접 구현해보는 경험

배운 내용(현재 기억나는 것들)은 위와 같다.
Stream과 Optional에 대해 익숙하겠지만 Collector 와 Spliterator , CompletableFuture 그리고 Flow API 와 같이 관심 가지지 않으면 알 수 없는 것들을 이 책은 예제와 함께 직접 커스터마이징 할 수 있도록 도와준다.

그리고 부록의 내용도 좋다.
한 스트림에서 여러 결과를 얻는 방법 과 익명 함수 대신 람다를 써야하는 이유 를 설명한다.

• 부록 C : 스트림에 여러 연산 병렬로 실행하기 예제, 정리
• 부록 D : 람다와 익명함수를 JVM 바이트코드는 어떻게 최적화 되는지

2년전에 이 책으로 스터디를 진행한적이 있는데 도중에 탈주하여 이때까지 덮어놓았다가 이번에 다시 읽게 되었다.
앞부분 조금만 읽고 책의 내용을 다 아는것 마냥 "스트림에 대해 설명하는 책이겠지" 라고 대충 생각하며 펼쳐보지 않았었는데, 왜 이제야 읽기 시작했는지 후회할 정도로 좋은 책이였다.
개인적으로는 토비의 스프링 다음으로 좋은 책이라고 생각한다.

자바 개발자라면 꼭 읽으라고 추천하고 싶다.

유연함의 힘

NEXTSTEP 뉴스레터에서 이 책을 추천하여 뭔가 성장에 대한 이야기이지 않을까 싶어서 읽어보았다.

성장과 편안함은 절대 공존할 수 없다. 끊임없이 위험을 감수할 의지가 있는 사람과 조직만이 현재는 물론 미래에도 성공할 수 있다.
안전지대로 돌아갈지 성장할지는 각자 선택할 몫이다.
우리는 끊임없이 성장을 선택해야 하고 반복해서 두려움을 이겨내야 한다.

이 책은 유연함의 기술 에 대해 설명하는데 유연함의 기술은 아주 넓은 의미를 가지고 있다.

1. 사람마다 경험에서 얻어내는 교훈은 다 다르다. 현재 무엇을 경험 중이든 그것을 활용해 스스로 성장하려고 노력하여야 한다.
2. 통제할 수 없는 외부 원인을 탓하고 집착하지 마라.
3. 성과 증명 마인드셋을 버리려 노력하고, 학습 마인드셋 을 의식하고 개발시켜라.
4. 다가올 경험을 어떻게 생각할지 명확히 분석하라.
5. 피드백을 적극적으로 구하고 수용해라. 스스로의 한계와 약점, 잘못과 실수를 솔직하게 인정하라.
6. 목표 자체는 하나의 과정이고 도중에 겪는 성공과 실패를 포함한 학습 과정은 전체적인 맥락이다.
7. 성찰을 통해 자신의 경험을 샅샅이 해부하고 거기서 미래를 위한 아이디어를 찾아내라.
8. 안전지대에 머물러있으려 하지 말고 벗어나여 경험하고 경험에서 깨달으라.
9. 스트레스를 받거나 불안하고 두려울 때 그 감정을 흥분이나 열정으로 재해석하라. "무척 기대가 커"

즉, 기존의 행동을 포기하고 새로운 행동을 받아들이는 능력이 유연함의 힘의 대부분이다.

사람마다 경험에서 얻어내는 교훈이 다른 것과 스트레스를 받거나 불안할 때 그 감정을 재해석하라 는 내용이 나에게 정말 필요했던 내용이었다.
재미없는 업무를 하거나 나에게 도움이 안될 것 같은 업무를 받게되면 그 업무하는 모든 시간이 스트레스였다.
하지만 위 내용을 읽고 생각을 조금 바꿔보았을 때 편한 느낌을 느꼇다.
실제로 재미없거나 도움이 안될 줄 알았지만 하다보면 그 안에서 재미있는 일, 도움이 되는 일을 발견해낼 수 있었다.

이런 유연함의 힘은 "심적 여유"에서 나오는 것이 아닐까 싶다.
스스로의 삶을 살아가는 방식과 생각을 한번 되돌아보고 싶다면 강력 추천한다.

코틀린 핵심 프로그래밍

오현석님의 코틀린 핵심 프로그래밍이 출간되어 맹대표님 스터디에 참여하면서 읽게 되었다.
모임 내용을 정리하고 책에 나오는 내용들을 테스트 코드로 직접 작성해보면서 읽었다.
그리고 이론적인 내용도 정리해보았다.

이 책을 읽을 때 처음에는 "입문서인가?" 했는데 뒤로 갈수록 매운 맛이 난다. (저자 피셜 입문서는 아니라고 한다.)
코틀린 인 액션에서는 짧은 설명으로 넘어가는 주제들 중 이 책에서는 자세하게 설명하는 내용도 있어서 코틀린 인 액션과 같이 읽는 것도 좋지 않을까 싶다.
그리고 코틀린의 Sequence와 Stream, Coroutine에 대해 설명하진 않지만 제네릭스와 컬렉션 함수 에 대한 내용이 자세하여 읽을 이유는 충분하다.
해설은 없지만 연습문제도 제공한다.

디자인 패턴의 아름다움

고품질 코드를 작성하는 것에 초점을 맞춰 다섯 가지 관련 주제인 객체지향 프로그래밍 패러다임, 설계 원칙, 코딩 규칙, 리팩터링 기술, 디자인 패턴을 모두 포괄적으로 설명한다.
"이런 디자인 패턴이 생겨난 이유는 무엇인가?", "어떤 종류의 프로그래밍 문제를 해결하는데 사용되는가?", "적용시 장단점은 무엇인가?"와 같은 질문을 이해하고 적용할 수 있도록 안내한다.

나는 디자인 패턴 책으로 유명한 GoF의 디자인 패턴 과 헤드퍼스트의 디자인 패턴 책을 읽지 않아 차이점을 알순 없지만 이 책을 읽으면서 좋았던 점은 SOLID 원칙에 대한 자세한 내용과 패턴에서 소개하는 예제들이 좋았다.

1. 리스코프 치환 원칙을 지키기 위한 자세한 설명
2. 팩토리 패턴에서 BeanFactory 예제
3. 프록시 패턴에서 자바의 동적 프록시 예제
4. 데코레이터 패턴에서 JavaIO 라이브러리 예제
5. 옵저버 패턴의 비동기식 비차단 옵저버 패턴과 EventBus 예제
6. 템플릿 메서드 패턴에서 InputStream 클래스 예제
7. 템플릿 메서드 콜백 패턴에서 JdbcTemplate 예제
8. 책임 연쇄 패턴에서 스프링의 필터와 인터셉터 그리고 MyBatis의 인터셉터 예제

패턴을 배우는 동시에 우리가 자주 사용하지만 따로 시간을 내지 않으면 내부 원리는 알기 힘든 기능들에 대해 예제를 작성해줘서 더 재밌었던 것 같다.
그리고 비슷한 패턴간의 차이점이나 해당 패턴을 사용했을 때 생기는 문제점과 극복할 수 있는 방법들도 중간중간 소개를 해줘서 좋았다.

스터디를 통해 경험이 많은 사람들의 이야기를 들으면서 읽은 탓에 더 좋은 느낌을 받은것도 있다.

• 모임 내용

(디자인 패턴 책은 이번이 처음이지만) 디자인 패턴 자체가 가독성을 지키면서 확장에 유연한 코드를 작성하기 위한 컨셉 이라고 생각한다.
각 패턴들에 매몰되어 패턴 자체를 외워가면서 학습하는 것이 아니라 어떤 문제를 어떻게 해결하는지 에 대해 전체적인 그림을 이해하는 것 이 중요하다고 느꼈다.
"이 패턴을 써볼까?"라고 먼저 사용할 패턴을 정하고 설계하는 것 보다 "이 문제는 이 패턴의 장점을 활용하면 이렇게 해결할 수 있겠는데?"라고 생각하는게 더 유연한 설계를 하는 방법이라고 생각한다.

이 책은 자바와 스프링에 대해 친숙하고 다양한 예제들을 접하고 싶다면 해당 책을 추천하고 싶다.

이 책을 읽으면서 정리한 내용들이다.

1. 좋은 코드, 고품질 코드란?
2. 객체 생성 관련 패턴
3. 구조 관련 패턴
4. 행동 관련 패턴

이제 디자인 패턴에 뛰어들기를 읽으면서 예제를 더 업데이트할 생각이다.

자바에서 코틀린으로

업무를 진행하면서 자바와 코틀린 중에 선택할 수 있었다.
새로 개발하는 작업들은 모두 코틀린을 지향하고 있기도 하고, 이 기회에 코틀린을 써보고 싶어 코틀린을 선택했다.

시기적절하게 코드숨 커뮤니티에서 스터디 모집 공지가 올라왔다.

소개를 보면 코틀린을 처음 접하는 상황에서 진행하기는 버거워 보였지만 일단 신청했다.
실제로 쫓아가기도 바빳고, 좋은 이야기들을 많이 해주셨는데 소화하기도 힘들었던 것 같다.

총 13주간 진행한 자바에서 코틀린으로스터디를 회고해보려 한다.

• 모임 내용 정리

코틀린을 몰라도 따라갈 수 있나?

공식문서에서 "Kotlin은 간결하고 읽기 쉽고 배우기 쉽습니다." 라고하듯이 문법을 배워서 작성하는 것은 자바를 사용했다면 코틀린 자체를 빨리 이해할 수 있는 것은 맞다.
하지만 코틀린을 코틀린답게, 객재지향 프로그래밍과 함수형 프로그래밍을 적절히 선택하여 코틀린답게 작성하는 것은 매우 어려운일이다.

함수형 프로그래밍의 ㅎ도 모르는 입장에서 코틀린의 문법과 코틀린이 해결하려는 문제를 동시에 이해하기는 힘들었다.

• 대수적 효과
• 모나드

딱딱한 자바만 사용하다가 코틀린을 만나면서 자바에 비해 문제를 해결하는 문법적인 방법이 많다는 것을 느꼈다.
이 책은 코틀린의 기능을 친절하게 설명해주는 책은 아니고 자유도가 높은 만큼 저자 입장에서 자바를 코틀린으로 전환하거나, 자바와 코틀린의 기능적 차이, 코틀린의 특정 기능을 사용하는 목적과 이유를 설명하려 하는 것 같다.

코틀린에 대한 이해가 깊고 함수형 프로그래밍에 대해 관심을 가지는 인원들과 같이 하는것이 아니라면 해당 책을 읽기에는 놓치는 것이 많을 것 같다.
혼자 책으로 공부하려 했다면 이 책보다는 코틀린 인 액션 이나 코틀린 완벽 가이드로 진행했을 것 같다.

책을 읽고 얻은 것은?

1. 코틀린에서 널과 예외를 대처하는 자세
2. 코틀린의 함수 타입과 개념 (고차함수, 일급함수) , 람다와 친해지기
3. 예외를 Result와 같이 값으로 반환하는 예외를 다루는 방법 (+ Result4K)
4. 클래스로 캡슐화를 하기 보다는 코틀린 표준 라이브러리를 사용하기 위한 타입 별명 적용
5. 자바와 다르게 코드 트랜잭션, 컨텍스트에 신경쓰고 가능한 짧게 가져가기
6. 함수 체이닝
7. 인라인 함수 (컴파일 시점에 함수 본문의 바이트코드를 삽입하여 준다.)
8. 코틀린은 기본적으로 클래스 상속에 닫혀있고, 합성적인 스타일을 장려
9. 값 이론과 객체 전파, 방어적 복사

아는만큼 보인다라는 말이 있듯이, 자바 함수형 프로그래밍과 스트림을 정확하게 이해하지 못하는 수준인 나의 입장에서 얻은 것들은 이 정도가 대표적인 것 같다.

코틀린의 기능을 언제, 어떤 기준으로 사용하는지 주관적인 기준이 생겼다.

• 마법같은 코틀린 컴파일러를 통해 컴파일된 class를 자바 코드로 디컴파일해서 확인하면서 학습하는 것이 큰 도움이 되었다.

모임을 참여하고 얻은 것은?

책을 이렇게 음미하면서 잘근잘근 씹어먹는 스터디는 처음이였다.
아마 코틀린과 함수형 프로그래밍에 능통하신 맹대표님과 책을 번역하신 오현석님, 그리고 백지훈님이 계셔서 가능하지 않았을까 싶다.
세 분이 토론하면 살벌하다

이번 모임을 통해 책을 비판적으로 읽는 시각과 읽기 모임의 정석을 경험한 것 같다.
지식을 습득하려는 목적으로 책을 읽으면서 책의 내용에 항상 순응하고 "오 이렇게 쓰나보다" 하고 넘어가는 부분들에 대해, 사람들이 모여 진지하게 토론하는 자체가 좋은 경험이였다.
목표는 두 시간에 두 개의 장을 나가는 것이 목표였지만, 두 시간을 넘기거나 두 장을 못 나가는 경우도 허다했다.
그만큼 토론에 진심인 분들을 보며 "책을 이렇게 까지 읽을 수 있구나, 이 주제로 이 정도의 얘기를 할 수 있구나"를 느꼈다.
해당 토론에서 튀어나오는 키워드들만 주워 먹기도 벅찼다.

핵심

책을 다 읽고나니 스터디 초중반에 말씀해주셨던 아래의 내용이 책을 관통하는 내용이였다는 것을 알 수 있었다.

코틀린은 가변성 + OOP를 바탕에 깔고 있는 언어이기 때문에 아에 가변성을 쓰지 않을 이유는 없다

1. 전체적인 프로젝트의 흐름은 객체지향을 쓴다
2. 객체지향을 쓸 때도 꼭 필요한 경우가 아니라면 가변 필드 + 가변 객체를 쓰는 일은 지양한다
3. 객체 사이의 통신에 사용하는 메서드는 가능하면 명시적 수단 (파라미터와 반환 값을 사용)을 활용하고 부수효과(side effect)를 만들지 않는다
4. 한 함수 / 메서드 내부에는 가능한 불변성을 활용한다
5. 여러 원소를 저장할 컬렉션에 대한 집계, 필터링, 변환 등의 로직을 직접 구현하기 보다는 표준 컬렉션 라이브러리를 활용한다

상태를 경계에 잘 가둬서 처리하느냐 → 객체지향
상태 변화를 없애고 값 객체, 불변으로 처리하느냐 → 함수형
함수 경계 안에서는 불변객체와 컬렉션을 쓰고 각종 순수 함수를 도우미로 써서 함수형으로 처리하면 좀 더 코드를 쉽게 작성할 수 있고,
전체적으로는 객체지향적으로 사고하면서 모듈간의 결합도를 최소화하고 응집도를 최대화한다는 기본 원칙을 지켜나가는 스타일이 이미 자바 개발자인 분들에게는 최선이 될 것이다.

• 자바에서 코틀린으로 옮긴이 오현석

값 컨텍스트로 프로그래밍하면 그 여파가 미치는 곳은 코드의 디자인적인 측면이나 설계까지 전부 영향이가고,
더 나아가 코드를 사용하는 방법 마저도 달라지고 필요한 자료구조도 달라진다.
단지 저장에 해당되는 부분만 값으로 대치한다고 끝이 아니다. 값 컨텍스트를 도입하려면 값을 다루는 모든 프로그래밍 스킬도 배워야 한다.
값과 함수형을 고려할 때는 조직 내 사람이라는 문제를 간과하지 않아야 한다.
값 컨텍스트를 펼치고 함수형 프로그래밍을 팀에 도입한뒤 "넌 이거 왜 못해?"라고 하는 것은 폭력이 될 수 있다.

• 맹기완 대표

소감

언어에 대해 새로운 인사이트를 얻게해주시고, 경험과 조언들을 아낌없이 쏟아내주신 스터디원 분들과 맹대표님, 오이사님 그리고 스터디에 참석할 수 있게 공유해주신 윤석님에게 감사하다.
스터디에서 주제를 공급하기보단 소비만하는 스터디원이였는데 쫓아내시지 않은것도 감사하다.

스터디를 하면서 팀원들과 코틀린에 대한 이야기를 몇번 나누었었는데, 코틀린의 기능을 제한적으로 사용할 때도 있고, 자율적으로 사용할 때도 있다.
코딩한다는 행위 자체가 정답이 있는 행위가 아니다. 혼자 일하는 것이 아닌 이상 코드리뷰를 통해 회사 내의 컨벤션을 맞춰가거나 팀원들과 조율해나가야 할 것이다.
실무에 코틀린을 사용하면서 진짜 간단한 작성도 고민을 하게 됐으며, 이걸 이렇게 사용하면 장단점이 뭐지? 의도가 잘 드러날까? 고민을 하는 자세가 이 모임 덕분이 아닐까 싶다.
코틀린으로 개발하고 있는 나를 뒤에서 스터디원분들이 지켜보고 있는 느낌?

추가로 오현석님이 코틀린 핵심 프로그래밍 책을 내신다고 하셨다.

알고리즘 개정 4판

처음 알고리즘에 관심을 가지게 된 계기가 기업용 코딩 테스트를 통과하기 위해서였다.
코딩 테스트를 통과하기 위한 알고리즘 공부는 지문에서 키워드를 모으고 최대 입력, 허용 가능한 시간과 공간을 확인해서 적합한 알고리즘을 판단하는 연습의 반복이다.
코딩 테스트를 위한 알고리즘 공부는 이 책에 비해 얕고 넓다. 이와 같은 학습은 사용하는 알고리즘과 자료구조는 늘어나지만 자료구조 구현 레벨까지 학습을 하지않아 단편적인 공부에 해당한다.

하지만 이 책은 추상화 데이터 타입, API의 개념 그리고 시간복잡도부터 천천히 빌드업하여 자료구조와 알고리즘을 설명해나간다.
알고리즘의 문제해결에 집중하다보면 절차지향적으로 작성하게 되는데, 저자는 자료구조를 구현할 때 API 목록을 먼저 뽑아내고 그에 맞게 구현해나가는 것도 인상깊었다.
자료구조와 알고리즘만 설명해주려하기 보다는 외부 클라이언트 코드와 내부 구현을 분리하려는 자세도 학습시켜주려 하는 것 같았다.
그리고 알고리즘과 자료구조의 변화 과정과 다양한 구현 방법을 설명해줘서 많은 생각을 할 수 있었던 것 같다.
아래의 이미지는 책을 통해 배운 내용들이다. (책에서 제공하는 목차와 다를 수 있다.)
붉은색 박스는 알고리즘을 의미하고, 푸른색 박스는 자료구조를 의미한다.

그리고 각 챕터마다 연습문제, 창의적인 문제, 실험 으로 몇십문제씩 제공된다. 책에서 해설을 제공하고 있진 않지만 어떤 분이 모든 문제에 대한 해설을 작성한 레포를 만드셔서 참고하면서 봐도 좋다.
이번 책을 통해서 평소에 자주 사용하지만 내부 구현은 확실히 몰랐던 정렬과 우선순위 큐, 균형 트리, 문자열 패턴 매칭을 학습하게 됐다.
겨우 1회독이라서 책에서 소개하는 많은 알고리즘과 자료구조, 연습문제들을 모두 이해하지는 못 했지만 알고리즘과 자료구조에 대해 흥미가 다시 생긴 것 같다.
이제 인덱스 우선순위 큐, 2-3트리, 레드블랙트리, B-트리, 문자열 패턴 매칭, 정규표현식 매칭 알고리즘을 순서대로 다시 학습하여 완벽히 이해하고 넘어가는 것이 목표이다.
아래는 읽으면서 정리한 내용이다.

• 정렬
• 해시 테이블
• 그래프
• 트라이
• 우선순위 큐

공부할 주제는 차고 넘치는데 알고리즘을 왜 공부하는지, 실무에 직접적인 도움이 되는지 궁금한 분들도 있을 것이다.
도메인이나 직무에 따라 다르겠지만 이때까지 실무에 BFS와 DFS를 사용한 적이 딱 한 번 밖에 없어서 다른 개발자에게 선뜻 추천하기는 쉽지않은 것 같다.
이 책은 총 932페이지인 만큼 두껍고, 이해하기 어려운 내용들도 많고, 시간도 많이 걸리는데

• 이 책을 공부할 시간에 실무에 맞닿아있는 기술 스택을 공부하는게 더 효과적이지 않나?
• 실제로 알고리즘과 자료구조는 많은 곳에서 사용되고 있긴하지만, 그렇다고 해서 사용만 잘 하면되지 우리가 내부 구현을 다 알아야 돼?

라고 물어볼 수 있다. 책을 다 읽고 난 입장에서 봐도 맞는 말이다. 실무에 도움이 안될지도 모르는 이 책을 공부하기에는 시간 낭비일 수 있다.

하지만 개인적인 생각으로는 알고리즘과 자료구조도 네트워크, 운영체제, 데이터베이스와 같이 유통기한이 긴 지식에 해당한다고 생각한다.
이 유통기한이 긴 지식은 건축 기초공사에 비유하곤 하는데, "건축물을 지탱할 수 있도록 단단한 지면을 만드는 것 처럼, 개발 지식도 확장하기 위해서는 지반을 단단히 다져야한다" 라고 막연하게 믿고있다.
막연하다라고 표현한 이유는 이런 학습들은 당장 확인할 수 없는 복리 효과이기 때문이다.

"복리의 힘은 오랜 시간 (10년 이상) 동안 꾸준히 비가 오나 눈이 오나 해야 효과가 보이기 시작한다."
"자꾸 잘하는지 도움이 되는지 확인하지 않는 것이 중요하다. 그냥 하는 거다."

• 출처 : 기용님의 "커리어를 긴 호흡으로 바라보기"

"누구나 프로그래머가 될 수 있지만 누구나 좋은 프로그래머가 될 수 있는 것은 아니다."
"자동차를 잘 운전하기 위해 꼭 차를 조립할 수 있어야 하는 것은 아니지만, 최상위 클래스 F1 드라이버가 되려면 드라이빙에 필요한 신체나 정신적인 능력은 물론 레이스에 적합하게 차를 설정하기 위한 다양한 공학적 지식도 필요한 것 처럼, 좋은 프로그래머가 되기 위해서는 도메인 지식은 물론 컴퓨터의 동작 원리나 컴퓨터공학 전반에 대해 잘 이해할 필요가 있다."

• 한 권으로 읽는 컴퓨터 구조와 프로그래밍 옮긴이 오현석

아웃 스탠딩의 "왜 부트캠프는 개발자 인력난을 해소하지 못하는 걸까요" 글에서도 비전공자를 긁지않은 복권에 비유하면서 CS 이론에 대한 이야기가 나온다. 유료 글이라 내용을 인용하기가 힘드니 회원가입하고 무료로 한번 읽어보기를 추천한다.

이 책 한 권을 읽었다고 해서 코드 퀄리티가 드라마틱하게 상승하고, 시간과 공간을 효율적으로 작성하고 해결하려는 문제에 맞는 자료구조를 적절히 선택한다는 보장은 없다.
알고리즘이라는 것이 실무에서는 몰라도 큰 상관이 없을 때도 많다. 실무에서는 유지보수성과 협업이 중요한데, 성능은 좋지만 필수적이지 않은 곳에 복잡한 알고리즘을 작성하여 협업 능력을 떨어뜨릴 수 있다.
하지만 현재 업무 환경에서 필요없다고 해서 배우지 않아도 되는것은 아니지않을까? 알고리즘 자체를 등한시한다면 실제로 필요한 곳에 적용할 시도조차 못하게 되니 복리 효과를 기대하고 싶다면 한 번은 읽어보는 것이 좋을 것 같다.

이 책을 추천하는 이유 중 로버트 세지윅이 저자라는 점도 한 몫한다.
1회독으로 모두 흡수하기에는 힘들 것 같다. 길게 1~2년 정도 꾸준히 볼만한 가치는 충분한 책인 것 같다.

도메인 주도 설계란 무엇인가?

왜 DDD가 오늘날 더욱 중요하다고 생각하십니까?
옛날에는 웹 개발이 보편적이지 않기도 했고, 일반적인 기능의 웹 개발을 할 때도 신경써야할 부분이 많았습니다.
지금은 웹 사용의 기초적인 수준에 대해서 많은 사람들이 이해하고 개발자가 비즈니스에 집중할 수 있도록 도와주는 기술들이 많이 만들어졌습니다.
이러한 환경으로 인해, 많은 사람들이 다시 비즈니스 로직에 도전하기 시작하고 있습니다.
기본적으로 DDD는, 사용자들이 밀접하게 관계되어 있는 도메인 이슈에 집중해야 한다는 원칙을 기반에 둡니다.
도메인이란 우리가 이해하기 위해 혼신의 힘을 다해야만 하는 가장 중요한 부분입니다.
DDD는 팀 전체가 함께하는 거대한 작업이라는 것을 잊지 말아야 하고 모든 것에 적용하려고 하지 마세요.
실험을 많이 하고 실수를 많이 할 것이라고 예상하세요. 모델링은 창조적인 작업입니다.

• 에릭 에반스

이 책은 도메인 주도 설계라는 주제의 기초를 요약한 소개서이다.
도메인 전문가에게 도메인 지식을 끌어내어 아키텍트가 설계하고, 그 설계한 내용에 따라 개발자가 구현을 해나가는 흐름에 있어, 정확한 도메인 모델링을 어떻게 하고, 그 모델을 코드로 어떻게 변환할 것인가? 가 주제이다.

엔티티, 값 객체, 도메인, 모델, 서비스, 모듈, 집합, 리포지토리 등 이 용어에 대해 설명하며 DDD를 전체적으로 (추상적이지만) 훑어준다고 생각하면 좋다.
처음 DDD를 읽을 때 낯선 용어 때문에 힘들었는데, 대략적으로 각 책임들을 설명해줘서 좋았다.

• 대략적으로 정리했다.

처음부터 완벽한 모델링은 존재할 수 없으니 때때로 도메인에 대한 새로운 통찰이 생기고 모델간의 관계가 발견될 때, 리팩터링을 통해 설계에 반영되어야 한다고 강조한다.

"개발자들에게 도메인의 비즈니스 로직은 지루하고 보상이 없는 것일 수 있지만 도메인의 비즈니스 로직은 도메인의 심장이다."
"만약 핵심 비즈니스 로직이 제 역할을 하지 못한다면, 멋진 기술적 부가 기능은 모두 무용지물이 된다."
"정교한 도메인 모델과 핵심 도메인은 단번에 만들어지지 않는다. 핵심이 한층 명확하게 통합되기 위해서 정제와 지속적인 리팩터링이 필요하다."

실제로 기술에만 집중했었던 것 같아서 위의 내용을 읽고 뜨끔했었다..
DDD에 관심을 가지고 있다면 웜업 느낌으로 가볍게 읽을 수 있을 것 같아 추천하고 싶다.

프로그래머의 뇌

프로그래밍은 가장 까다로운 인지 활동 중 하나로 간주된다.
즉, 문제를 추상적으로 해결하는 동시에 프로그램을 작성하는데, 이런 일은 대부분의 사람이 자연스럽게 가질 수 없는 수준의 주의력을 요구한다.
프로그래밍을 하는 동안 일어나는 실수는 수없이 잦다. 우리가 범하는 많은 오류는 인지적 문제에 뿌리를 두고 있다.

이 책은 인지과학과 연구 결과에서 얻은 두뇌의 작용을 프로그래밍과 프로그래밍 언어에 대한 맥락에서 설명한다.
새로운 프로젝트를 맡게 되었을 때를 생각해보면 (클린 코드의 유무를 떠나서) 로직과 비즈니스를 이해하기 위해 부단히 노력한다.
이 책을 통해 그 노력안에 엄청 복잡하고 많은 과정이 일어난다는 사실과 그 과정들에 대해 알아갈 수 있다.

1. 장기 기억 공간(LTM), 단기 기억 공간(STM), 작업 기억 공간의 인지 과정
2. 코드를 빨리 이해하기 위한 코드 청킹 연습 , 시각화를 통한 영상 기억 공간의 활용 , 절대적인 지식의 양
3. 장기 기억 공간은 네트워크 망 구조로 되어 있다.
4. 긴 간격을 두고 반복 읽기 (반복 학습 하기) → 더 많은 시간을 학습해야 한다는 것이 아니라 더 오랜 간격을 두고 학습해야 한다
5. LTM으로부터 기억을 가져오는 두 가지 서로 다른 기제, 저장 강도 (학습해내는 것) 와 인출 강도 (기억해내는 것) → 저장하는 것보다 그것을 얼마나 잘 발견하느냐, 인출 강도에 집중해야 한다.
6. 청킹되지 않는 문제를 풀려고 할 때 발생하는 과부하 상태 인지 부하의 종류
7. 초급자와 숙련자는 코드를 읽는 방식부터 다르다 → 이해 전략으로 시각화(상태표 등) , 중요한 부분을 스스로 결정하고 스스로 질문하기
8. 네이밍에 대한 강조
9. 리팩터링 코드 스멜이 인지 부하를 초래하는 이유
10. 초급 프로그래머와 피아제의 인지 발달론

인지 과정에서 일어나는 많은 과정에 대해 이해하는 것은 많은 도움이 될 것이라 생각한다.
만약 복잡한 문제 또는 이해하기 힘든 코드 구조를 맞닥뜨렸을때 스트레스를 받거나 화내기 보다는 "청킹이 잘 안됐나?", "어떤 부분에서 인지 부하가 온거지?", "내가 어떤 지식이 부족하지?" 라는 생각을 할 수 있는 돌파구를 찾아준 느낌이다.
그리고 내가 쓴 글이나 이미 읽은 책은 잘 안읽는 경향이 있는데, 이 책을 읽고 조금 간격을 두고 반복적으로 읽어야함을 느꼈다.

위의 내용 중에 흥미가 생기는 부분이 있거나 이해하기 힘든 문제를 만났을 때 어떻게 해야할지 모른적이 있다면 이 책을 읽어보기를 추천한다.

업무 시각화

시각을 활용하면 문제를 명확히 할 수 있고, 의사결정이 쉬워진다.
인간의 두뇌는 시각으로 인지한 것에서 패턴과 구조를 찾도록 설계됏기 때문에 시각화는 업무를 개선할 수 있는 가장 기본적인 방법 중 하나다. 업무에 시각화를 적용하기 위해 시각화를 설계하는 것은 업무 흐름을 개선할 수 있는 방법을 찾기 위한 실험이다.
칸반보드를 설계하는 데 '모범 사례'가 실제로 존재하지 않는 이유다.
칸반보드와 기타 발표 자료를 만들 때 흥미를 끌 수 있게 시각화해 사람들의 참여를 유도해야 하고, 실험을 통해 자신의 상황과 조직에 더 적합한 사례를 찾는 것이 더 나은 방법이다.

실무에서 시각화(칸반 등) 정보를 토대로 업무를 진행하고 있지 않고, 칸반에 익숙하지 않아 책 내용이 많이 와닿지 않은 것 같다.
그래도 다른 스터디원들의 경험이나 회사에서 어떤 식으로 사용하는지들을 들을 수 있어서 좋았다.

1. 너무 많은 진행 중 업무
2. 계획에 없던 업무
3. 방치된 업무
4. 상충하는 우선순위
5. 알려지지 않은 의존성

위 다섯 가지의 이유 때문에 업무가 지연된다고 이야기한다.
시각화를 통해 업무가 지연되는 이유들을 구성원들에게 더 잘 전달할 수 있고 시각화한 정보가 정확한 통계치가 되기 때문에 설득하기가 더 쉽다고 한다.
그리고 시각화를 통해 어딘가에 기록을 하면 "내가 뭘 빠뜨리지 않았나?", "이런것도 해야 되는데" 라는 생각이 들지 않아 현재 진행하는 한 가지의 일에만 집중할 수 있다.

지금 당장 시각화를 통해 협업을 할 수 없으니 개인적으로 업무와 개인 계획 내용을 칸반으로 만들어 사용해보고 있다.
어딘가에 기록해놓으니 확실히 마음이 편안해지는 느낌을 느꼈다.
책을 읽고 시각화의 효과와 (개인적으로) 칸반을 시작하게 되었으니 나에겐 굉장히 효과적인 책이였다.

이 책은 혼자 읽기 보다는 서로 다른 회사를 다니는 스터디원들과 같이 읽기를 추천한다.
칸반에 대해 궁금하거나 업무 프로세스를 개선하고 싶은 생각이라면 이 책을 추천한다.

데브옵스 핸드북

(경험이 아직 부족해서 공감가는 내용이 많지 않았지만) 인상깊은 내용들도 많고, 실제 기업의 개선 사례도 설명해줘서 재밌었다.

• 기술 부채를 해결하지 않는 조직은 일상 업무에서의 문제가 해결되지 않은 채로 작업을 하다가 부담이 가중돼 더 이상 새로운 작업을 완료할 수 없게 된다. 즉, 기술 부채의 현재 이자만 상환하게 된다.
• 스페셜리스트보단 제네럴리스트가 되어라.
• 팀 규모를 작게 유지하라 (피자 두 판의 법칙)
• "자동화 테스팅 없이 코드를 작성하는 경우, 코드를 테스트하기 위해서는 더 많은 시간과 비용이 소비된다."
• 블루/그린 배포
• 교살자 애플리케이션 패턴 적용에 대한 사례
• 텔레메트리 중요성
• 넷플릭스의 카오스 몽키
• 비난 없는 포스트모템을 진행하고, 문서화하도록 하여 공유하라
• 테스트 코드에 대해
• ...

핵심은 문제를 빠르게 발견하고 수정하도록 빠른 피드백을 받을 수 있는 (기술적,인적) 환경을 만드는 것이다.
데브옵스가 정확히 뭐지? CI/CD가 뭐지? 글로벌 회사는 데브옵스를 어떻게 적용할까? 라는 고민을 한적 있다면 추천하고 싶다.
주니어가 읽어도 좋지만 리드급이 읽으면 더 좋을 것 같다.

한 권으로 읽는 컴퓨터 구조와 프로그래밍

간략하게 정리하면서 읽었다.

추천의 글과 옮긴이의 말을 보면서 자극 만땅으로 받고 책을 폈지만 중후반부터 정신이 혼미해진다.
저자는 이 책에서 많은 기초적인 내용을 다룬다고 설명한다.

초반에서 중반까지는 전자 회로부터 빌드업하여 내부구조, 컴퓨터 아키텍처와 운영체제까지 얕게 설명해준다.
고민조차 할 수 없었던 이야기들이 나온다. 예를 들어 실제로 비트는 어떻게 저장되나? 와 같은 고민이다.

중반에서 후반까지는 좋은 내용도 많지만 갑자기 이런 내용이 왜 나오지? 하는 내용들이 있다.
저자 말대로 넓고 얕은 내용을 설명하여 관심있는 주제는 얕아서 문제고 특정 내용은 기반지식이 없으면 이해조차 할 수 없는 챕터도 있었다.

그래고 컴퓨터 구조 책을 처음으로 다 읽어봐서 뿌듯하다
각 잡고 읽는 책이기 보다는 출퇴근할 떄 가볍게 읽어도 될, 컴퓨터 구조라는 학문을 시작하는 책이라고 생각한다.

토비의 스프링 부트 - 이해와 원리

큰 맥락으로 보면 @SpringBootApplication 어노테이션이 제공해주는 마법같은 일들을 알려주는 강의이다.

• 스프링 부트가 스프링을 어떻게 잘 사용하고 있는지
• 스프링 부트의 자동 구성이 어떤 식으로 실행되고 로딩되는지
• 스프링 부트의 기술 마다 자동으로 구성되는 빈들은 어떤게 있는지
• 자동으로 구성되는 설정 정보들이 어떻게 관리되는지

실무에서 대충 감으로 이해하던 내용들이 많았다.
스프링 부트가 뭐냐고 물어보면 "스프링을 편하게 써줄 수 있게 해주는 프레임워크"라고만 생각했었는데 조금 더 자세하게 설명해줄 수 있을 것 같다.

처음 접한다면 모르는 기술적인 단어들이 많이 나와서 스프링과 자바에 익숙하지 않다면 힘들수도 있을 것 같긴 하지만
스프링 부트의 컨셉과 구성 정보를 관리하는 구조에 대해 알 수 있어 굉장히 좋은 강의였다.

HTTP 완벽 가이드

해당 책의 스터디는 이슈 기반으로 진행되었다.
대략적인 정리를 하면서 읽었다.

책이 2002년에 출간되었고, 번역본은 2013년에 출간된 만큼 요즘이랑 비교하면서 읽기에는 무리가 있다.
하지만 많은 사람들이 추천하는 이유가 있다.

전반적인 네트워크 지식을 익힐 수 있고, HTTP가 진화하면서 기존 근간 기술들은 변하지 않기 때문에 읽을 가치는 충분하다.

1. TCP 커넥션에 대한 개념
2. 프록시, 게이트웨이, 터널에 대한 이해
3. HTTP 헤더에 대한 이해
4. I/O 아키텍처에 대해 얕게..

위의 내용이 대표적으로 생각나는 것 같다.
혼자서 읽었으면 진작에 포기했을 것 같은데 다른 분들과 같이 질문을 준비하고 토론을 하면서 읽으니 잘 버틴 것 같다.

코틀린 스터디로 인해 13장까지 읽고 도중 하차하여 14,15,18,20장만 추후에 읽어야겠다.

대체 뭐가 문제야?

"문제란 바라는 것과 인식하는 것 간의 차이다."
"우리는 문제를 해결하려고만 하지 문제의 본질과 문제를 해결했을 때 생길 수 있는 다른 문제들에 대해서 생각하지 않는다"
"문제를 정확한 정의를 내렸다고 결고 확신하지 말라. 그러나 그것을 얻기 위한 노력은 계속해야 한다."
"문제를 이해할 때, 잘못될 수 있는 경우를 적어도 세 가지 이상 생각해 내지 못한다면 당신은 문제를 이해하지 못한 것이다."

나는 문제를 정의하는데 시간을 보내기보다는 거의 성급하게 해결안을 찾는 것에 매달린다.
해결안을 찾는 도중에 발생하는 문제들에 대해 몰두하게 되어 본질적인 문제를 잊기도 한다.

이 책은 무엇이 문제인가, 그것은 어떤 문제인가, 누구의 문제인가, 문제는 어디에서 비롯되는가를 설명한다.
문제를 인식하고 그 문제를 해결하기 위한 방법이 낳는 다른 문제들에 대한 인식, 내가 세운 이 해결책이 진짜 문제를 해결하는 것인지, 내가 인식하지 못한 문제들이 더 존재하는지, 내가 세운 해결책이 도덕성과 관련있는지에 대해 사례를 통해 설명한다.

책의 내용 중 엘리베이터 얘기가 인상 깊은데, 문제를 건의한 사람이 제안한 문제 해결책 중에서 말도 안되는 "옆 건물의 엘리베이터 시간을 훔치자" 라는 제안을 한다.
이 말도 안되는 제안은 (마지막 즈음에 밝혀지지만) 옆 건물 주인도 바라던 것이였다. 회사에서 이런 비슷한 경험이 있는데 나는 실없는 해결책인 줄 알았지만 그런 것도 한 방법이라고 얘기를 해주셨다.
"유머감각이 없는 사람의 문제를 해결하려고 노력하지 말라."

• 우아한 형제들 김범준 대표의 EO 영상에서 나오는 엘리베이터 이야기가 (이 책을 인용했는지는 모르지만)이 책에서 등장한다.

문제를 단수에서 복수로 보는 사고의 전환이 필요하고, 문제를 해결하며 되돌아보는 자세가 필요하다.
이 책에서 세상에는 두 종류의 사람, 일을 하는 사람과 할 일을 만드는 사람이 있다고 한다.
할 일을 만드는 사람이 되지 않아야지

책이 얇고 읽기 쉬워서 문제 해결에 대한 고민을 한 경험이 있다면 읽을 이유는 충분하다.

이너게임

이너게임에 대한 나의 연구를 한마디로 요약한다면 ‘사람을 좀 더 효과적으로 변화시킬 수 있는 방법을 발견했다’는 것이다.
이너게임의 원리는 테니스에서 포핸드, 백핸드, 또는 서브를 어떻게 바꿀 것인가를 연구하면서 발견되었지만, 이 원리는 테니스 외의 다른 여러 분야에 응용될 수 있다.
이 책은 우리가 일하는 방법을 어떻게 바꿀 것인가에 대한 것이다. 달리 표현한다면, 일이 우리를 위해 존재하게 만드는 방법에 관한 것이다.

Timothy Gallwey는 테니스를 코칭하면서 터득한 코칭의 기술, 집중에 대한 방법과 일터에서 즐거움을 느끼고, 그 즐거움 속에서 배우고 성장하며 성과를 내는 방법, 비평가적 인지에 대해 설명한다.
일반적으로 코칭을 한다는 것은 훈련생은 코치에게 고민을 전달하고 코치는 고민을 해결하기 위해 훈련생을 모델링하며 훈련생은 코치에게 평가를 받는다.
이런 코칭의 단점이 클라이언트는 자신의 문제를 해결하지 못 하는 이유 또는 발생한 이유 등에 집중하여 방어적으로 문제에 접근한다.
이로 인해 클라이언트는 자신의 문제에 대한 인지 수준을 높이지 못한다는 것이다.
이때 코치는 클라이언트가 비평가적 인지를 하도록 유도하며 클라이언트가 스스로 상황을 주도하도록 만들고 인지 수준을 더욱 높이도록 가이드 하는 것이 코칭 효과가 좋다는 것을 깨닫는다.
그렇다고 이 규칙이 테니스에만 적용되는 것이 아니다. 개개인의 일상과 업무 속에서도 적용할 수 있다.
이 글에서 교수가 한 학생을 코치하는 내용을 보면 이너게임에서 말하는 코칭과 유사하다는 것을 알 수 있다.

간략하게 정리하면 내부에서 일어나는 셀프1과 셀프2의 싸움에서 셀프1을 무시하고 셀프2에만 집중하여 비평가적 인지를 유지해야 한다는 것이다.
셀프1과 셀프2에 대한 정의는 책 전반적으로 많이 설명되는데

• 셀프1 : 지시하고 평가하는 쪽, 타인이 나에게 요구하는 우선순위, 타인에게 인정받으려 하는 욕구
• 셀프2 : 자신의 실체, 자신의 내면에 존재하는 본질적인 우선순위,
• 비평가적 인지 : 어떤 현상을 평가하지 말고 자신과 자신의 행동을 있는 그대로 느끼고 받아들이는 것

책에서 읽은 내용을 일상생활, 업무속에 적용하려 할 때 굉장히 어렵다라고 느꼈다.
나는 매순간을 스스로를 평가하고 책망하였었다는걸 알 수 있었다.
하지만 스스로 평가를 내리는 습관을 인지하는 것이 비평가적 인지를 갖추는 첫 걸음이라고 한다.

1. 스스로가 항상 부족하고 멍청하다고 책망하고 평가하여 해야하는 일에 대해 집중을 하지 못하고 계획조차 세우지 못한 경험
2. 일에 집중하기도 힘들고 재미를 느끼기 힘들었던 경험
3. 일에서 얻을 수 있는 것은 오로지 성과(급여)라고 생각하는 사람
4. 몰입을 경험하고 싶은 사람

위의 사항에 해당한다면 이 책을 추천해주고 싶다.

데일 카네기의 자기관리론

중요한 일을 앞두고 스트레스를 많이 받았다.
준비해야 할 일을 하지 못하고 걱정과 잡생각만 하면서 계획조차 세우지 못했다.

데일 카네기는 "인간관계론"으로 처음 알게 됐다. "인간관계론"이나 "자기관리론"이나 뭔가 엄청 대단한 정보를 전달해주기 보다는 읽으면 당연한 것이라고 생각하지만 평소에 놓치고 있는 것들, 깊게 생각하지 않은 것들을 상기시켜주는 내용이라고 느꼈다.
1장을 읽고 공감을 하나도 하지 못한다면 "당연하고 진부한 이야기들을 왜 말하지?"라고 생각할 수 있다.
책에서도 말하지만 위와 같은 생각이 든다면 책을 다 읽게 되더라도 얻는 것은 없으니 책을 쓰레기통에 버리라고 한다.
난 엄청 재밌게 읽은 것 같다. 출퇴근 시간에 책 읽을 생각에 조금 신난 적도 있다.
평소에 걱정이나 불안을 달고 살거나, 과거나 미래에 집착하고 있다면 이 책을 읽으라고 추천하고 싶다.

아래는 가장 인상 깊은 내용이다.

"그 어떤 일이라 해도 그 사람이 무한한 열정을 가진 일이기만 하면 그는 성공할 수 있다."
"자신의 일에서 보수 이외에 다른 아무런 보람도 얻지 못하는 사람이 가장 불쌍한 사람이라고 생각합니다."
"자신의 천직을 찾아낸 사람은 축복 받은 사람이다. 더 이상의 축복은 바라지 마라"

내 생에 단 한 번

동욱님의 나를 위해 남을 도와주기 게시글에서 내 생에 단 한 번 책의 내용중 한 챕터로 예를 들어주셨는데 책의 내용이 너무 마음에 들어 바로 구매하고 읽어보았다.