From 4966dc3eedd1ae5a0ab14116af78aca1320fe768 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EA=B6=8C=ED=83=9C=ED=98=95?= Date: Fri, 15 May 2026 02:18:17 +0900 Subject: [PATCH 1/2] =?UTF-8?q?=EA=B0=9C=EB=B0=9C=EC=9E=90=20=EC=9B=90?= =?UTF-8?q?=EC=B9=99=20sprint=2010=20-=201~3=EC=9E=A5=20=EB=8F=85=ED=9B=84?= =?UTF-8?q?=EA=B0=90=20=EC=98=A4=ED=83=80=20=EB=B0=8F=20=EB=A7=9E=EC=B6=A4?= =?UTF-8?q?=EB=B2=95=20=EC=88=98=EC=A0=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.6 (1M context) --- 2026/Developer_Principles/taehyoung/1.md | 7 +++++++ 2026/Developer_Principles/taehyoung/2.md | 10 ++++++++++ 2026/Developer_Principles/taehyoung/3.md | 17 +++++++++++++++++ create_pr.sh | 6 +++--- 4 files changed, 37 insertions(+), 3 deletions(-) create mode 100644 2026/Developer_Principles/taehyoung/1.md create mode 100644 2026/Developer_Principles/taehyoung/2.md create mode 100644 2026/Developer_Principles/taehyoung/3.md diff --git a/2026/Developer_Principles/taehyoung/1.md b/2026/Developer_Principles/taehyoung/1.md new file mode 100644 index 00000000..850f50b7 --- /dev/null +++ b/2026/Developer_Principles/taehyoung/1.md @@ -0,0 +1,7 @@ +# 1장 + +## 내 생각 + +- 수필형태의 글이다보니, 내용에서 더 깊게 내 생각을 정리해볼 만한 키워드나 주제는 없었던 것 같다 +- 개발자로서 혹은 개발자가 되기 위해서 아직 명확한 방향성을 잡지 못한 사람들 입장에서 어떤 식으로 저자가 개발을 생각해왔고, 대하는지를 느껴보고, 이를 통해서 배워보는 용도로는 좋은 내용들이었다 +- 글 내용 중에 내 생각과 일치한다고 생각했던 부분은 동기부여와 관련된 것이었는데, 내재적 동기와 관련된 부분이었다. 흔히 직업으로서 개발자를 바라볼 때, 일반적인 사람이면 당연하게도 외재적 보상과 그에 따른 동기부여에 관심이 있는 것이 당연하다. 월급 꼬박꼬박 많이 주고, 성과급도 많이 받는 걸 싫어하는 사람이 있을까? 다만, 끈기 있게 지속하기 위해선 이런 외재적 동기부여는 한계가 있다고 생각된다. 도파민이 생각보다 빠르게 꺼진다. 저자는 덕업일치에 대한 얘기를 하는데, 이런 사람들이 어떤 면에서는 부럽기도 한 것 같다. 내가 좋아하는 것을 일로 함으로써, 내재적 동기를 계속 부여 받을 수 있게 되기 때문이다 diff --git a/2026/Developer_Principles/taehyoung/2.md b/2026/Developer_Principles/taehyoung/2.md new file mode 100644 index 00000000..e6cd1fbd --- /dev/null +++ b/2026/Developer_Principles/taehyoung/2.md @@ -0,0 +1,10 @@ +# 2장 + +## 논의 주제 +- 회사 업무 / 개인적인 개발 학습을 하면서, 얻은지식, 겪는 경험들이나 실패 상황들(에러, 버그, 장애 등)을 어떤 식으로 관리하고 계신지 얘기해보면 좋을 것 같습니다 + +## 내 생각 + +- 저자는 오류를 마주칠 때가 내 개발자로서의 역량을 키울 수 있는 시점으로 보고 있다. 학생 시절에 틀린 문제는 오답노트로 정리해서 내 걸로 만든다의 개념으로 볼 수 있고, 어찌 보면 그렇게까지 대단하게 특이점이 있는 것은 아니다 +- 그러나, 이게 말은 쉽지만 생각보다 실천하기도 어렵고, 개인적으로는 어떤 주제를 어떤 범위 만큼 어떻게 정리해야 하는지에 대해서 고민하다가 그냥 넘기는 경우가 많은 것 같다 +- 내 생각에 이걸 실천하기 가장 좋은 것은 회사 업무 환경이다. 회사 업무를 대상으로 내가 겪은 장애 혹은 버그들은 실제 현업 실무 환경에서 발생한 어떻게 보면 매우 가치가 높은 문제상황이기 때문이다. 내가 만들거나 겪은 오류, 버그, 장애가 모두 정리가 되면 내 팀, 더 커지면 내 회사를 기준으로 범위를 넓히면서 까지 해보면 알짜로 중요 현업 문제들을 경험해보고 해결해보는 매우 좋은 경험일 것 같다 diff --git a/2026/Developer_Principles/taehyoung/3.md b/2026/Developer_Principles/taehyoung/3.md new file mode 100644 index 00000000..8c53752c --- /dev/null +++ b/2026/Developer_Principles/taehyoung/3.md @@ -0,0 +1,17 @@ +# 3장 + +## 내 생각 + +- 이분의 글을 읽으면서, 뭔가 느껴진 바이브가 있었습니다. 장 초반에 나오는 이분의 이력을 유심히 살펴보게 되었고, 크고 규모있는 회사 환경, SI 환경에서 오랫동안 근무하면서, 굳혀진 본인만의 스타일과 에고가 있으신 분이겠구나 라고 생각했는데, 역시나 제 예상대로 였습니다 +- 초반부에 나오는 SOLID, KISS, YAGNI 등에 대한 맹목적 추종을 하지 말라는 것과 IT 업계 개발자들 사이에 설계라는 용어가 명확히 정의되지 않은 상황에 대해서는 개인적으로 공감되는 부분이 이었습니다 +- but, 책 후반부로 갈 수록, 본인의 방법론에 기초한 주장에 세지는 것을 느꼈고, 본인의 대기업 커리어의 경험에 대한 신뢰를 바탕으로 경험이 맞다는 전제하에 주장하시는 것 같다는 느낌을 받았습니다. 본인 경험하에서 이렇게 했더니 좋았더라 라는게 그렇게 큰 공감이 되진 않았고, 이분의 주장은 규모가 작은 회사에서는 전혀 맞지 않겠다는 생각이 들었습니다 +- 저는 상황에 따라 적절한 방법론이 있을 수 있다고 생각하는 편이고, 그렇기에 현재 나 혹은 팀, 회사의 상황에 맞게 적절한 해결책들을 생각해내서(그게 책에서 읽은 것이든 경험한 것이든), 적용하는게 좋다고 생각하는 편인데, 이 저자는 본인의 경험상 이 방법이 맞다라는 식의 주장을 펼치고 있다보니, 특히 이런 부분은 공감이 안되었던 것 같습니다 +- 결국에 이분의 글은 설계를 꼼꼼히 하라는 말이고, 책 후반부는 그냥 여러 분야에서의 설계를 어떻게 해야하는지에 대한 기계적인 조언 및 정답에 대한 내용들을 쭉 적어두었는데, 내용을 읽으면서, 솔직히 마음속으로 누가 이걸 모르나;; 라는 생각이 들었습니다. 사실 이런 정답 같은 것들이 현실세계에서 여러 변수들 때문에 생각대로 안되는 경우가 많고, 독자입장에서는 이것을 해결한 경험담 같은 것들을 듣고 싶다는 생각에 책을보는건데, 그냥 정답을 나열 하는식으로 적어둔것을 보고 많이 별로라고 생각했습니다 솔직히 말하면, 그 내용도 별로 도움되는내용도 아니기도 했고… +- 제가 만약에 이분과 서로 질문과 답변을 할 수 있는 시간이 있다면, 아래 내용을 물어볼 거 같습니다 + - 17가지 설계항목을 제시하셨는데, 실제 제품이 설계대로 동작하지 않으면 어떻게 하나요? 제품을 고치나요? 설계를 고치나요? + - 최초 설계 대로 개발이 되더라도, 추후 유지보수 관점에서 요구사항이 변경되면, 설계도 변경될 수 있습니다. 애초에 확장성을 고려한 설계였다면, 변경이 안되겠지만, 예측못한 요구사항이 발생한다면, 결국 설계가 변경될 수 밖에 없는데, 이런 경우에 어떤 식으로 관리하나요? / 애초에 고칠 설계라면, 굳이 설계를 열심히 할 필요가 있나요? + - 장애 대비 설계 파트에서, 실제로 장애 발생 시 수치에 따라 정해진 등급대로 행동하도록 지정해야한다고 했는데, 그 수치와 등급은 어떤 기준으로 어떻게 정하나요? + - 변환 설계에 나온 장애 등급을 규정하는 사후 처리 프로세스를 설계하기 이전에, 어떻게 하면 의존성을 최소화할 수 있는 코드 설계를 할 수 있을지를 먼저 고민해야하는거 아닌가요? + - 가용성 설계에서 MTBF와 MTTR 값을 100일, 12시간으로 설정했는데, 근거는 무엇이고 경계값에 걸리면 문제있는걸로 봐야하는건가요? + - 기획서를 아주 상세히, 요구사항을 꼼꼼하게 기술해야하는 것의 기준이 무엇인가요? +- 결국 소프트웨어 개발 구현과 설계에 대한 문제는 상황에 따른 How 가 중요한데, 이분은 What 만 나열한 것 같고, 서울대 가려면 공부를 열심히 해야한다 수준의 답변이라고 생각됩니다 diff --git a/create_pr.sh b/create_pr.sh index 188f2143..5b22c355 100755 --- a/create_pr.sh +++ b/create_pr.sh @@ -8,9 +8,9 @@ ASSIGNEE="@me" PROJECT="2026 Academic Conference" # 이부분을 수동으로 변경해서 사용 -LABELS="2026,Street Coder: The Rules to Break and How to Break -스트리트 코더 - 프로그래밍 세계에서 살아남기 위한 개발자 생존 가이드!" -MILESTONE="Street Coder: The Rules to Break and How to Break" +LABELS="2026,개발자 원칙 +개발자 원칙 - 확장판, 테크 리더 9인이 말하는 더 나은 개발자로 살아가는 원칙과 철학" +MILESTONE="개발자 원칙" # 사전 검증 check_prerequisites() { From 9d29e4281da7b9192f5a130255ef43fbb364f73c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EA=B6=8C=ED=83=9C=ED=98=95?= Date: Fri, 15 May 2026 02:46:54 +0900 Subject: [PATCH 2/2] =?UTF-8?q?=EA=B0=9C=EB=B0=9C=EC=9E=90=20=EC=9B=90?= =?UTF-8?q?=EC=B9=99=20sprint=2010=20-=203=EC=9E=A5=20=EB=8F=85=ED=9B=84?= =?UTF-8?q?=EA=B0=90=20=EC=82=AD=EC=A0=9C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.6 (1M context) --- 2026/Developer_Principles/taehyoung/3.md | 17 ----------------- 1 file changed, 17 deletions(-) delete mode 100644 2026/Developer_Principles/taehyoung/3.md diff --git a/2026/Developer_Principles/taehyoung/3.md b/2026/Developer_Principles/taehyoung/3.md deleted file mode 100644 index 8c53752c..00000000 --- a/2026/Developer_Principles/taehyoung/3.md +++ /dev/null @@ -1,17 +0,0 @@ -# 3장 - -## 내 생각 - -- 이분의 글을 읽으면서, 뭔가 느껴진 바이브가 있었습니다. 장 초반에 나오는 이분의 이력을 유심히 살펴보게 되었고, 크고 규모있는 회사 환경, SI 환경에서 오랫동안 근무하면서, 굳혀진 본인만의 스타일과 에고가 있으신 분이겠구나 라고 생각했는데, 역시나 제 예상대로 였습니다 -- 초반부에 나오는 SOLID, KISS, YAGNI 등에 대한 맹목적 추종을 하지 말라는 것과 IT 업계 개발자들 사이에 설계라는 용어가 명확히 정의되지 않은 상황에 대해서는 개인적으로 공감되는 부분이 이었습니다 -- but, 책 후반부로 갈 수록, 본인의 방법론에 기초한 주장에 세지는 것을 느꼈고, 본인의 대기업 커리어의 경험에 대한 신뢰를 바탕으로 경험이 맞다는 전제하에 주장하시는 것 같다는 느낌을 받았습니다. 본인 경험하에서 이렇게 했더니 좋았더라 라는게 그렇게 큰 공감이 되진 않았고, 이분의 주장은 규모가 작은 회사에서는 전혀 맞지 않겠다는 생각이 들었습니다 -- 저는 상황에 따라 적절한 방법론이 있을 수 있다고 생각하는 편이고, 그렇기에 현재 나 혹은 팀, 회사의 상황에 맞게 적절한 해결책들을 생각해내서(그게 책에서 읽은 것이든 경험한 것이든), 적용하는게 좋다고 생각하는 편인데, 이 저자는 본인의 경험상 이 방법이 맞다라는 식의 주장을 펼치고 있다보니, 특히 이런 부분은 공감이 안되었던 것 같습니다 -- 결국에 이분의 글은 설계를 꼼꼼히 하라는 말이고, 책 후반부는 그냥 여러 분야에서의 설계를 어떻게 해야하는지에 대한 기계적인 조언 및 정답에 대한 내용들을 쭉 적어두었는데, 내용을 읽으면서, 솔직히 마음속으로 누가 이걸 모르나;; 라는 생각이 들었습니다. 사실 이런 정답 같은 것들이 현실세계에서 여러 변수들 때문에 생각대로 안되는 경우가 많고, 독자입장에서는 이것을 해결한 경험담 같은 것들을 듣고 싶다는 생각에 책을보는건데, 그냥 정답을 나열 하는식으로 적어둔것을 보고 많이 별로라고 생각했습니다 솔직히 말하면, 그 내용도 별로 도움되는내용도 아니기도 했고… -- 제가 만약에 이분과 서로 질문과 답변을 할 수 있는 시간이 있다면, 아래 내용을 물어볼 거 같습니다 - - 17가지 설계항목을 제시하셨는데, 실제 제품이 설계대로 동작하지 않으면 어떻게 하나요? 제품을 고치나요? 설계를 고치나요? - - 최초 설계 대로 개발이 되더라도, 추후 유지보수 관점에서 요구사항이 변경되면, 설계도 변경될 수 있습니다. 애초에 확장성을 고려한 설계였다면, 변경이 안되겠지만, 예측못한 요구사항이 발생한다면, 결국 설계가 변경될 수 밖에 없는데, 이런 경우에 어떤 식으로 관리하나요? / 애초에 고칠 설계라면, 굳이 설계를 열심히 할 필요가 있나요? - - 장애 대비 설계 파트에서, 실제로 장애 발생 시 수치에 따라 정해진 등급대로 행동하도록 지정해야한다고 했는데, 그 수치와 등급은 어떤 기준으로 어떻게 정하나요? - - 변환 설계에 나온 장애 등급을 규정하는 사후 처리 프로세스를 설계하기 이전에, 어떻게 하면 의존성을 최소화할 수 있는 코드 설계를 할 수 있을지를 먼저 고민해야하는거 아닌가요? - - 가용성 설계에서 MTBF와 MTTR 값을 100일, 12시간으로 설정했는데, 근거는 무엇이고 경계값에 걸리면 문제있는걸로 봐야하는건가요? - - 기획서를 아주 상세히, 요구사항을 꼼꼼하게 기술해야하는 것의 기준이 무엇인가요? -- 결국 소프트웨어 개발 구현과 설계에 대한 문제는 상황에 따른 How 가 중요한데, 이분은 What 만 나열한 것 같고, 서울대 가려면 공부를 열심히 해야한다 수준의 답변이라고 생각됩니다