Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions 2026/Street_Coder/ymkim97/chapter1_2_3.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
# 스트리트 코더
## 1장 ~ 3장
---
## 논의 내용
* 유용한 안티패턴에서 저자는 빚(기술 부채)을 지지 말라고 하는데요, 현실적으로 이게 가능할지가 의문입니다. 자신이 아무리 잘 지키려해도 회사라는 곳에서는 빠른 기간내에 돈을 벌어야하는 것이 최우선의 목표이기도 하고, 다른 팀원 또는 자신이 선택을 조금이라도 실수하는 순간에도 기술 부채가 발생할 수 있는데(스노우볼), 이렇게 말하는 저자의 의도를 현업에서는 어떻게 해석하고 받아들여야 할까요?
Comment thread
ymkim97 marked this conversation as resolved.
Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

기술 부채를 안만드는 방법은 알려주지 않았으므로
최대한 코드가 경직성을 가지면 안된다의 맥락으로 이해해 보면 좋을 것 같기도 합니다.

기술 부채 관련해서 두 가지를 언급해 드리면

첫 번째, 제가 작년에 읽었던 < 소프트웨어 엔지니어 가이드북 > 책에서 13.3 기술 부채 내용이 있습니다.

가이드북이기 때문에 기술 부채를 방지하는 가이드가 존재합니다. (하지만 뻔한 이야기입니다. 실천하기가 어려울 뿐)
또 적당한 기술 부채를 실용적인 방안으로 속도와 품질의 절충안으로 여기는 시각도 있습니다.
이 부분도 보면 기술 부채 관련된 이해가 높아질 것 같습니다.

두 번째 역시 작년에 읽었던 < 이펙티브 소프트웨어 아키텍처 > 책입니다.

여기서는 기술 부채에 대한 색다른 시각을 얘기해 주고 있습니다.
6.5 변경을 수용할 수 있는가? 소주제로 "기술 부채" 내용이 있습니다.

부채(debt)에 대한 의미를 더 해석해본 것인데, 실제 부채 의미를 가지려면 신용카드로 감당할 수 없는 비용을 결제해 여행 다녀온 후, 값지 못하고 파산하는 엔딩이 맞다로 얘기합니다.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

사실 이런 조언류로 책을 구성할 때는 반례에 대해서 반박할 수 없다는게 가장 큰 모순점이라서, 그냥 저자의 의견이 그렇다 정도로 받아들이는게 맞을거 같습니다

말씀하신대로, 회사에서 매 상황상황 마다 의사결정을 다르게 될 수밖에 없는 상황인데, 이를 일반화해서, 기술부채를 반드시 남기지 않는 쪽으로 결정을 한다면, 그건 주객이 전도된 행위 일거 같습니다

제 개인적으로는 기술부채는 만들어질 수밖에 없고, 오히려 상황에 따라서는 유용하기도 합니다. 그래서 기술부채를 어떻게 갚을것인지 까지 설계를 해서 기술부채를 만든다면, 더 좋은 선택이라고 생각하는데요 문제는 부채는 갚지 않으면서 대책없이 늘리기만 하고, 이걸 본인이 처리하지 않고 다른 사람들에게 떠넘기기를 하는 이 사람의 행태가 문제이지 않을까 싶습니다 이런 상황에서 인수인계 받은 개발자는 애궃은 기술부채를 탓할텐데, 저는 기술부채자체가 문제는 아니라고 생각합니다


## Chapter 1 - 거리로
책의 이름이 왜 스트리트 코더인지, 해당 단어의 뜻이 무엇인지 먼저 설명해준다.
소프트웨어 업계에서는 결국 경력과 경험으로 훌륭한 소프트웨어 개발자가 될 수 있다는 것을 알려준다.
CS 학위는 이론은 많이 알지만 실용성이 부족하여 때때로 그들이 배운 것에 의문을 제기하는 태도가 부족할 수 있다는 말이 정말 인상적이었다.
나에게 해당되는 말인가 싶어 더 그렇게 느꼈던 것 같다.
저자는 30년이라는 엄청나게 긴 시간의 경력을 가지고 있으나 책은 23년도 쯤에 쓰여져 패러다임의 변화 등을 잘 반영했다.
Comment thread
ymkim97 marked this conversation as resolved.
Outdated
프로그래머는 소프트웨어를 직접 만들어 보는 것과 공부하는 것 사이의 딜레마에 직면한다고 했는데, 이 역시 최근 나의 모습이라고 생각한다.
책을 통해서 저자의 경력을 통한 인사이트를 간접적으로나마 느껴보고, 보다 더 빠르게 개발자로서 성장할 수 있기를 기대하게 되었다.

## Chapter 2 - 실용적인 이론
책이 좀 더 본격적인 내용에 들어가기전에 넓은 범위는 아니지만 어느정도의 CS를 소개하는 챕터였다.
Comment thread
ymkim97 marked this conversation as resolved.
Outdated
빅오 표기법, 이진 검색과 같은 알고리즘, 배열, 리스트, 큐 등의 데이터 구조를 다룬다.
실은 이보다 더욱더 많은 중요한 CS들이 있고 당연히 이 책의 하나의 장에 넣는 것은 무리가 있으나, 저자의 의도는 결국 기본기가 탄탄한 개발자가 되어야 한다는 것이라고 느꼈다.

조금 아쉽거나 특이하다고 느꼈던 것은 여기에 사용된 언어였다.
요즘 많이 사용되는 언어들과는 대비되는 C#, .NET으로 예제가 쓰였다는 것이다.
마이크로소프트에서 근무했던 저자의 주 언어이기 때문이지 않을까 추측되었다.
그러나 이번 기회를 통해 저 언어들이 꽤나 자바나 코틀린과 비슷하다는 것을 배우게 되었다.

## Chapter 3 - 유용한 안티패턴
해당 챕터의 내용을 읽으면서 클린 코드 책이 생각났다. 그만큼 약간 비슷한 내용이 보여서였던 것 같다 (주석을 사용하지 마라, 이름을 잘 선택하라 등).

> *만약 내가 프로그래밍의 세계에 단 하나의 메시지만을 보낼 수 있다면 그것은 우리가 배우는 모든 것, 즉 그들의 유용성, 이유, 장점, 비용에 대해 의문을 품으라는 메시지일 것이다.*

30년 경력을 지닌 저자로부터 나온 이 말을 그냥 지나치기에는 아쉬울 것 같아서 두고두고 기억해보고 싶어졌다.

안티패턴이라는 단어를 보면 무조건 피하고 쓰지 말아야 할 것 처럼 느낄 수 있으나, 꼭 그렇지만은 않다는 것을 말해주고 있다.
Comment thread
ymkim97 marked this conversation as resolved.
Outdated
그래야 모범 사례와 우수한 디자인 패턴을 사용해 도움이 되는 경우와 도움이 되지 않는 경우를 더 잘 이해할 수 있기 때문이다.
소개되는 안티패턴들은 크게 어렵거나 생소하지 않고, 어느정도 개발 경험이 있으면 들어보았거나 느꼈을 것들이라고 보였다.
Loading