스트리트 코더 sprint 7 - 권태형

2026/Street_Coder/taehyoung/1.md

@@ -0,0 +1,8 @@
+# 1장
+
+- 논의주제
+    - 이 책의 저자가 표현하는 좋은 스트리트 코더의 상은 이론적으로도 호기심을 가지고 접근하면서, 회사의 업무도 잘 처리하는 밸런스 형의 실무형 개발자로 특정하는 것 같습니다. 이에 대한 상세내용을 각 4가지로 제안하는데, 본인이 1가지를 추가한다면 어떤게 있을지 얘기해보면 좋을거 같습니다
+- 내 생각
+    - 고객의 니즈를 충족시켜줄 수 있는 제품 개발 속도와 좋은 설계, 좋은 알고리즘, 좋은 품질의 코드는 당연하게도 개발자들에게 모두 중요한 부분이라고 생각한다 둘다 중요하기 때문에, 상황에 따라서 적절히 비율을 맞추는게 좋다고 생각한다. 한가지 확실한 것은 둘중에 하나만 할 수 있거나, 고집한다면, 표준분포곡선 에서 상위 X% 에 드는 개발자는 될 수 없다고 생각한다
+    - 모호성에 대한 MS의 면접질문은 그 모호성을 어떻게 다루는지에 대한 적절한 역량를 평가할 수 있는 질문인지는 잘 모르겠다 이와 별개로, 복잡성과 모호성을 수용하고, 복잡성과 모호성을 어떻게 없앨 것인가가 모든 개발자들이 궁금적으로 마주쳐야만 하는 문제가 아닐까 생각된다
+    - 개발자가 자신이 작업중인 스택에 집중할 뿐 나머지 부분이 어떻게 동작하는지에 관심이 없다고 하는데,애초에 개발자의 회사에서의 포지션은 연구자가 아니라 엔지니어이기 때문에 디테일에 기술의 동작 자체를 조금 모르더라도, 내 업무를 무리없이 잘해낸다면, 큰 문제는 아니라고 생각한다. 이미 구체적인 하위레이어의 코드를 몰라도 추상화된 레이어의 동작을 잘아는 것만으로도 업무 진행해는 충분하기도 하기 때문이고, 하위레이어 코드를 몰라도 이해할 수 있게 하기위해서 추상화 레이어를 만든 것이기 때문이다. 하위 레이어를 자세하게 알면 알 수록, 그 원리를 깊게 이해한다는 뜻이고 매우 좋은 접근이라고 생각하지만, 그 적당선을 어떻게 지킬 것인가?도 개발자의 역량이 아닐까 생각된다

2026/Street_Coder/taehyoung/2.md

@@ -0,0 +1,10 @@
+# 2장
+
+- 논의 주제
+    - 이론이 중요한 것은 현재도 마찬가지이긴 하지만, 그렇다고 해서, AI 시대의 채용에서 이 장에 나오는 기초적인 CS 지식들을 체크하는게 맞는지에 대해선 의문입니다. 앞으로 이런 CS 이론들은 어떤 관점에서 접근하고 학습하면 좋을지 얘기해보면 좋을거 같습니다
+- 내 생각
+    - 이 장에서 저자가 말하는 이론에 신경써야하는 이유는 앞장에서 주장하는 바와 비슷한데, 일반적인 상황 보다 훨씬 구체적으로 의사결정을 해야하는 상황에서는 결국은 디테일한 하위 레벨의 이론들이 중요하다는 뜻이다 몰라도 평소 업무에는 크게 문제 없지만, 더 깊고, 어려운 문제에 대한 의사결정을 하기 위해선 이러한 이론들을 결국에는 알아야 한다
+    - 책에서는 연결 리스트에 대한 면접문제 얘기도 나오는데, 과거부터 개인적으로는 CS 이론에 대한 디테일한 부분을 현업 실무자에게 질문하는게 적절한가에 대해선, 적절치 않다고 생각 했었던 것 같다. 이는 대부분의 B2C 웹 서비스를 만드는 회사들에서 고도의 추상화된 프레임워크와 라이브러리를 사용하여서 개발을 진행하고 있기 때문에, 업무와 더 유관한 질문을 하는게 낫다고 생각한다
+    - 타입과 관련해서는 더 얘기할 부분은 없다. 유지보수를 위해서 개발한다면, 타입을 견고하게 사용하는게 중요하다. 그외 라면 동적 타이핑 언어를 사용하는게 개발 생산성 측면에서 더 이득일 수 있다.
+    - 코딩 스타일 문제와 포맷팅 문제는 AI시대에 들어서면서는 더이상 논의하는게 무의미한 주제가 되버렸다고 생각한다 사람이 읽지 않을 코드의 스타일과 포맷팅에 굳이 더 많은 노력을 기울일 필요가 있을까 라는 생각이다
+    - 주석의 경우는 오히려 AI 시대에 더 관리가 필요하다고 생각하는데, 그 이유는 실제로 잘못 작성된 주석 때문에, AI가 오해를 해서 잘못작성하는 경우가 있었기 때문이다. 그래서 애초에 코드 검토를 생각하고 있지 않다면, 주석을 작성하는 것 보다는 그 내용을 문서에 남기고 검토하는게 더 나을 것 같다

2026/Street_Coder/taehyoung/3.md

@@ -0,0 +1,11 @@
+# 3장
+
+- 논의 주제
+    - 책에서 나온 내용들 중에, 대부분은 앞으로 사람이 판단할 문제라기 보다 코드를 직접 작성하는 AI가 직접 판단할 문제로 보입니다. 이중에서 그래도 사람이 판단을 개입해야하는 부분이 있다면 어떤 부분으로 보셨는지 얘기해보면 좋을거 같습니다
+- 내 생각
+    - 코드를 변경하던지, 변경하지 않던지 두가지 모두 문제를 발생 시킬 수 있다. 코드를 변경하지 않을 때는 처음 잡아둔 코드 구조와 현재 도메인이 다르면 다를 수록 고통을 겪을 확률이 높다. 반면에 코드를 변경하는 경우에는 코드 변경의 난이도와 상관없이 사람이 코드를 변경하면 버그를 일으킬 확률이 1%라도 증가하기 때문에, 이또한 문제가 발생해서 고통을 겪을 수 있다. 어떤 선택을 하던지 문제는 발생할 수밖에 없는데, 그래서 각 상황 마다 어떤 적절한 선택을 할지를 고민해야만하고, 이 고민 끝에 적절한 선택과 실천을 할 줄 아는 사람이 개발자 역량이 뛰어난 사람이라고 볼 수 있지 않을까 생각된다
+    - 경계를 존중해야하는 것은 맞지만, 경계를 잘못나눈 상황에서는 존중보다는 적극적인 개선이 필요하지 않을까 생각된다 책에서는 코드레벨에서의 경계를 말한다. 코드레벨에서의 경계는 업계에서 자주 사용되는 경계를 나누는 구조가 이미 많이 사용되고 있고, 패턴화 되어있기 때문에 다루기 쉬운데, 현실세계를 반영하는 도메인 경계는 각 사람마다, 상황 마다 다르게 해석되고 나뉠 수 있기 때문에 적절한 경계가 무엇이냐에 대한 논쟁은 항상 나올 수밖에 없다고 생각한다 그래서, 존중은 하되 항상 의심하고 개선하는 방안을 고민하는게 필요하지 않을까 생각된다
+    - 책에서 말하는 정원 가꾸기의 목표는 개발자가 코드를 볼 때 코드를 더 잘이해하기 위함이다. 그래서 현재 AI 에이전트로 코드를 작성하는 순간에는 이 조언이 적절치 않은 조언이라고 생각한다 왜냐하면, 더이상 개발자가 코드를 보지 않아도 되기 때문이다. 과거의 기준에서는 맞는 말일 수 있지만, 현재 AI가 만연한 환경에서는 요런 것들은 좀 더 고민이 필요한 부분이라고 생각된다
+    - 상속을 사용하지 말라는 조언이 나온다 이부분에 대한 판단도 AI에게 맡기고 사람이 고민하지 않도록 하자
+    - AI가 읽기 어려워하는 코드와 사람이 읽기 어려워하는 코드는 같으면서도 다르다고 생각한다 같은 부분은 컨텍스트의 한계가 어느정도 있다는것이고, 다른 부분은 사람이 가지는 복잡함에 대한 인지적 한계를 AI는 컨텍스트가 허용되는 한 사람보다 훨신 더 잘 파악한다는 것이다 그런 의미에서 책에있는 if-else 문은 어떤 형태로 쓰이든 AI가 읽기엔 어려운 코드가 아니기 때문에 문제가 없다고 생각한다
+    - 주석 대신에 원천이 되는 PRD, SPEC 문서를 명확하게 자연어로 작성하자

create_pr.sh

@@ -8,9 +8,9 @@ ASSIGNEE="@me"
 PROJECT="2026 Academic Conference"
 
 # 이부분을 수동으로 변경해서 사용
-LABELS="2026,Software Architecture: The Hard Parts
-소프트웨어 아키텍처: The Hard Parts, 분산 아키텍처를 위한 모던 트레이드오프 분석"
-MILESTONE="Software Architecture: The Hard Parts"
+LABELS="2026,Street Coder: The Rules to Break and How to Break
+스트리트 코더 - 프로그래밍 세계에서 살아남기 위한 개발자 생존 가이드!"
+MILESTONE="Street Coder: The Rules to Break and How to Break"
 
 # 사전 검증
 check_prerequisites() {
@@ -19,12 +19,12 @@ check_prerequisites() {
         echo "설치 방법: brew install gh"
         exit 1
     fi
-    
+
     if ! git rev-parse --git-dir &> /dev/null; then
         echo "오류: Git 저장소가 아닙니다."
         exit 1
     fi
-    
+
     if ! gh auth status &> /dev/null; then
         echo "오류: GitHub에 로그인되어 있지 않습니다."
         echo "로그인: gh auth login"
@@ -64,14 +64,14 @@ get_issue_id() {
 get_body() {
     echo "PR 본문을 입력하세요 (여러 줄 입력 가능, 입력 완료 후 Ctrl+D):"
     BODY=$(cat)
-    
+
     if [ -z "$BODY" ]; then
         read -p "본문이 비어있습니다. 계속하시겠습니까? (y/N): " confirm
         if [[ ! "$confirm" =~ ^[Yy]$ ]]; then
             exit 0
         fi
     fi
-    
+
     # Issue 연결 키워드 자동 추가
     if [ -n "$BODY" ]; then
         BODY="${BODY}"$'\n\n'"Closes #${ISSUE_ID}"
@@ -98,11 +98,11 @@ dry_run() {
 # 메인 실행
 main() {
     check_prerequisites
-    
+
     get_title
     get_issue_id
     get_body
-    
+
     # Dry-run 확인
     read -p "PR을 생성하기 전에 미리보기를 보시겠습니까? (Y/n): " show_preview
     if [[ ! "$show_preview" =~ ^[Nn]$ ]]; then
@@ -113,7 +113,7 @@ main() {
             exit 0
         fi
     fi
-    
+
     # PR 생성
     echo "PR을 생성하는 중..."
     if gh pr create \