diff --git a/2026/Developer_Principles/taehyoung/6.md b/2026/Developer_Principles/taehyoung/6.md
new file mode 100644
index 00000000..9ee81bb6
--- /dev/null
+++ b/2026/Developer_Principles/taehyoung/6.md
@@ -0,0 +1,8 @@
+## 논의 주제
+
+- GPAM, SMART 등의 프레임워크가 말로만 들었을때는 그럴듯 하면서도 실제로 실천해서 큰 효과를 보기힘든 이유 중에 가장 큰 비중은 정량적 평가를 위한 측정의 기준을 세우기가 생각보다 쉽지 않다는 점이라고 생각합니다. 본인이 위 프레임워크를 활용한 경험이 있다면, 어떤 식으로 정량적 평가를 위한 측정 기준을 세우는지, 그 노하우 혹은 힘들었던 점을 얘기해보면 좋을거 같습니다
+
+## 내 생각
+
+- GPAM 이라는 프레임워크를 알고 쓴건 아니지만, 막연한 회사 업무 혹은 개인적인 프로젝트를 진행 할 때 무의식적으로 생각해서 사용했었다. 이 프레임워크가 강력한 이유는 뭐부터해야하지? 라는 생각이 들 때, 이것부터 해봐 라는 답을 주기 때문이다. 이에 더해서, SMART 라는 것도 말하는데, 측정가능한 목표를 세우기 위해서 사용되는 유명한 프레임워크이다. 회사에서는 OKR 등을 정할 때, 사용했었던 프레임워크 였다
+- 저자가 주장하는 위와 같은 프레임워크를 내 업무에 활용해보라는 조언은 그 자체가 틀리진 않았지만, 너무 일반화된 주장이기도 해서, 모든 상황에 잘 맞는 것이라고 보긴 힘들 것 같다 그래서 맹목적으로 추종하기 보다는 직접 내가 활용해보고 내 입맛에 맞춰서 조금씩 수정하면서 내것을 만드는데 활용하는 정도로 쓰면 좋지 않을까 생각된다
\ No newline at end of file
diff --git a/2026/Developer_Principles/taehyoung/7.md b/2026/Developer_Principles/taehyoung/7.md
new file mode 100644
index 00000000..6f9bbd28
--- /dev/null
+++ b/2026/Developer_Principles/taehyoung/7.md
@@ -0,0 +1,10 @@
+## 논의 주제
+
+- 없음
+
+## 내 생각
+
+- 저자는 단순히 예제를 풀고, 특정 기술을 배우는 등의 학습 보다도, 제품을 직접 기획하고 만들어보는 능동적 형태의 학습에 더 높은 가치를 두고 있다. AI 활용을 통한 탑다운 학습법이 많이 활용되고 있는 시점에서 이 말은 현재 시기에 더 알맞는 학습 방법론 이라고 생각한다
+- 망설일 바에는 실패하자 라는 말에는 적극 동의한다
+- 협업 모드로 작업하기는 너무 다른 사람과 협업을 할 것을 예상해서 행동하라는 말처럼 들려서 크게 공감되진 않았다 과거든 현재든 상황에 따라서는 여러 사람과 협업할 수 도 혹은 나 혼자서 작업할 수 있도 있는데 각 상황에 맞는 최적의 방법을 그때 그때 마다 결정하는게 더 낫다고 생각하기 때문이다
+- 조직과 팀의 선택과 관련된 내용은 결국은 제품을 처음부터 끝까지 만들어보는 경험이 중요하다는 말을 하고 싶으셨던거 같다
\ No newline at end of file
diff --git a/2026/Developer_Principles/taehyoung/8.md b/2026/Developer_Principles/taehyoung/8.md
new file mode 100644
index 00000000..a3135209
--- /dev/null
+++ b/2026/Developer_Principles/taehyoung/8.md
@@ -0,0 +1,8 @@
+## 논의 주제
+
+- 최근에 생활적인 측면이든, 코드 설계의 측면이든 제어할 수 없는 것과 제어할 수 있는 것을 구분 지어서 생각해본 경험이 있다면 얘기해보면 좋을거 같습니다
+
+## 내 생각
+
+- 사실 제어할 수 없는 것에 의미를 두지 말자는 라는 것은 아주 예전부터 개인적으로 가지고 있던 신념이였는데, 최근 들어서는 기대만큼 잘 지키진 못했던 것 같다 예를 들면 회사, 팀의 상황과 의사결정과 관련해서 분명하게 이해가 잘 되지 않는 부분들이 있었는데, 내가 제어하지 못하는 부분임에도 불구하고, 이걸 해결하지 못하는 것에 대한 스트레스를 받는 상황이다. 이번에 이 파트를 읽으면서, 다시금 내가 제어할 수 없는 것과 제어할 수 있는 것을 생각해보게 된 것 같다.
+- 이 글에서 원칙에 대한 것도 나온다. 본인만의 원칙이 구조적으로 잘 만들어진 개발자의 경우에 고민의 시간을 최소화하면서, 80~90점 소프트웨어를 약속된 기간 내에 만들어낼 수 있다는 것이다. 내 개인적인 원칙은 나 혹은 나의 팀에서 생각해낼 수 있는 모든 경우의 수에 대해서 커버 했다면, 더이상 의심하지 않고 배포 한다는 것이다. 나와 나의 팀이 생각해낼 수 있는 모든 경우의 수를 이미 확인 했고, 더이상 없다면, 혹시 이슈가 발생하더라도 미미한 이슈일 것이기 때문에, 배포를 망설일 이유가 없다고 판단하는 것이다
\ No newline at end of file
diff --git a/2026/Developer_Principles/taehyoung/9.md b/2026/Developer_Principles/taehyoung/9.md
new file mode 100644
index 00000000..88f1625b
--- /dev/null
+++ b/2026/Developer_Principles/taehyoung/9.md
@@ -0,0 +1,10 @@
+## 논의 주제
+
+- 없음
+
+## 내 생각
+
+- 저자가 제시하는 행동 강령 중 제일 내가 많이 쓰는 것은 1번이다 1번은 업무를 더 효율적으로 한다는 측면에서, 동작하게 만드는 최소한의 코드와 개선을 나누어서 설계 및 코드 작성 하는 식으로 반영하고 있다. 2번과 3번은 어느 측면에서는 동의하지만, 내 업무를 하는 과정 중에는 그렇게 우선순위가 높은거 같진 않다
+- 2번에 대해서 반대하는 입장은 아니지만, 현실적으로 3순위 내의 원칙으로 뽑기에는 다른 중요한 것들이 훨씬더 많다고 생각한다. 1번에서 일단 동작하도록 만들라는 말은 다르게 말하면, 동작하는 것외에 작업은 부채로 남겨두라는 말이다 이부분에서 이미 1,2번 간에 모순이 존재 하는데, 2번을 지나치게 강조하는 사람의 입장에서는 이 부채를 남기는 것을 극도로 싫어하는 경향이 있기에, 내 스타일과는 잘 안맞는다고 생각했다. 물론 기술부채를 그대로 두자는 말은 아니다. 기술부채 그 자체 보다 현재 내가 해야하는 목표에 더 집중하는게 더 중요하다고 생각한다. 기술부채를 아무리 갚아도 기술부채는 반드시 생겨난다 그래서 개인적으론 기술부채가 생길 수 밖에 없다는걸 인정하고 어떻게 잘 공존하면서, 처분할지를 고민하는게 좋을거 같다.
+- 3번은 학습의 측면에서는 동의하지만, 업무의 측면에서는 동의하기 힘들다. 기한 내에 요구사항이 기대대로 동작하는 제품을 만들어야하는 개발자 입장에서 이미 있는 바퀴를 재활용하지 않고 새롭게 만들어 쓸 이유가 없다고 생각한다. 시간이 많이 남는가? 현재 있는 바퀴가 내 업무 작업 의도에 맞지 않는가? 등의 사유가 아니라면, 바퀴를 새로 만들려는 시도는 자기 만족밖에 안된다고 생각한다. 회사 업무 보다 개인의 학습 환경 하에서 삽질을 많이 해보자
+- 마지막에 말하는 많이 읽고, 많이 쓰고, 많이 생각하자의 주어는 코드 인것 같다. 하지만, 이 대상이 AI와 AI가 만들어내는 결과물이지 않을까 생각된다
\ No newline at end of file
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() {