개발자 원칙 sprint 12 - 권태형

[TaeHyoungKwon]

Closes #674

[github-actions]

우측에 있는 Projects, Milestone, Development를 확인 후 할당 해주세요~! 🙇

[gemini-code-assist]

Code Review

This pull request updates the create_pr.sh script to target the 'Developer Principles' (개발자 원칙) milestone and labels, and adds several markdown files documenting reflections on various chapters of the book. The review feedback highlights a critical issue in create_pr.sh where a newline and comma in the LABELS variable could break the GitHub CLI command, and suggests various grammatical, spelling, and spacing improvements to enhance the readability of the Korean text in the markdown files.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

LABELS 변수에 줄바꿈(newline) 문자가 포함되어 있어, gh pr create -l "$LABELS" 명령어를 실행할 때 다음과 같은 문제가 발생할 수 있습니다:

1. 줄바꿈 문자 포함: 두 번째 라벨 이름에 줄바꿈 문자(\n)가 포함되어 GitHub API 호출 시 오류가 발생하거나 라벨이 깨질 수 있습니다.
2. 의도치 않은 라벨 분리: "개발자 원칙 - 확장판, 테크 리더..." 부분에 포함된 쉼표(,)로 인해 GitHub CLI가 이를 두 개의 개별 라벨(개발자 원칙 - 확장판 및 테크 리더...)로 분리하여 인식하게 됩니다.

따라서 줄바꿈을 제거하고, 쉼표 구분자를 올바르게 사용하도록 한 줄로 수정하는 것을 권장합니다.

Suggested change

	LABELS="2026,개발자 원칙
	개발자 원칙 - 확장판, 테크 리더 9인이 말하는 더 나은 개발자로 살아가는 원칙과 철학"
	LABELS="2026,개발자 원칙"

[gemini-code-assist]

띄어쓰기와 문장 부호(.)를 보완하여 가독성을 높이는 것을 제안합니다.

• "힘들 것 같다 그래서" -> "힘들 것 같다. 그래서"
• "추종하기 보다는" -> "추종하기보다는"
• "내것을" -> "내 것을"
• "만드는데" -> "만드는 데"

Suggested change

	- 저자가 주장하는 위와 같은 프레임워크를 내 업무에 활용해보라는 조언은 그 자체가 틀리진 않았지만, 너무 일반화된 주장이기도 해서, 모든 상황에 잘 맞는 것이라고 보긴 힘들 것 같다 그래서 맹목적으로 추종하기 보다는 직접 내가 활용해보고 내 입맛에 맞춰서 조금씩 수정하면서 내것을 만드는데 활용하는 정도로 쓰면 좋지 않을까 생각된다
	- 저자가 주장하는 위와 같은 프레임워크를 내 업무에 활용해보라는 조언은 그 자체가 틀리진 않았지만, 너무 일반화된 주장이기도 해서, 모든 상황에 잘 맞는 것이라고 보긴 힘들 것 같다. 그래서 맹목적으로 추종하기보다는 직접 내가 활용해보고 내 입맛에 맞춰서 조금씩 수정하면서 내 것을 만드는 데 활용하는 정도로 쓰면 좋지 않을까 생각된다

[gemini-code-assist]

문장에 오타("있도")가 있고, 띄어쓰기 및 문장 부호가 생략되어 있어 가독성이 다소 떨어집니다. 의미가 명확하게 전달되도록 다음과 같이 수정을 제안합니다.

• "작업할 수 있도 있는데" -> "작업할 수도 있고"
• "그때 그때 마다" -> "그때그때마다"
• 문장 중간에 쉼표(,)를 추가하여 호흡을 조절합니다.

Suggested change

	- 협업 모드로 작업하기는 너무 다른 사람과 협업을 할 것을 예상해서 행동하라는 말처럼 들려서 크게 공감되진 않았다 과거든 현재든 상황에 따라서는 여러 사람과 협업할 수 도 혹은 나 혼자서 작업할 수 있도 있는데 각 상황에 맞는 최적의 방법을 그때 그때 마다 결정하는게 더 낫다고 생각하기 때문이다
	- 협업 모드로 작업하기는 너무 다른 사람과 협업을 할 것을 예상해서 행동하라는 말처럼 들려서 크게 공감되진 않았다. 과거든 현재든 상황에 따라서는 여러 사람과 협업할 수도, 혹은 나 혼자서 작업할 수도 있는데 각 상황에 맞는 최적의 방법을 그때그때마다 결정하는게 더 낫다고 생각하기 때문이다

[gemini-code-assist]

문맥상 어색한 표현("말자는 라는 것은", "신념이였는데")과 종결 어미 후 문장 구분(.)이 누락된 부분을 수정하여 가독성을 높이는 것을 제안합니다.

• "말자는 라는 것은" -> "말자는 것은" 또는 "말자라는 것은"
• "신념이였는데" -> "신념이었는데" ('신념'은 자음으로 끝나므로 '이었는데'가 올바른 맞춤법입니다.)
• "못했던 것 같다 예를 들면" -> "못했던 것 같다. 예를 들면"

Suggested change

	- 사실 제어할 수 없는 것에 의미를 두지 말자는 라는 것은 아주 예전부터 개인적으로 가지고 있던 신념이였는데, 최근 들어서는 기대만큼 잘 지키진 못했던 것 같다 예를 들면 회사, 팀의 상황과 의사결정과 관련해서 분명하게 이해가 잘 되지 않는 부분들이 있었는데, 내가 제어하지 못하는 부분임에도 불구하고, 이걸 해결하지 못하는 것에 대한 스트레스를 받는 상황이다. 이번에 이 파트를 읽으면서, 다시금 내가 제어할 수 없는 것과 제어할 수 있는 것을 생각해보게 된 것 같다.
	- 사실 제어할 수 없는 것에 의미를 두지 말자는 것은 아주 예전부터 개인적으로 가지고 있던 신념이었는데, 최근 들어서는 기대만큼 잘 지키진 못했던 것 같다. 예를 들면 회사, 팀의 상황과 의사결정과 관련해서 분명하게 이해가 잘 되지 않는 부분들이 있었는데, 내가 제어하지 못하는 부분임에도 불구하고, 이걸 해결하지 못하는 것에 대한 스트레스를 받는 상황이다. 이번에 이 파트를 읽으면서, 다시금 내가 제어할 수 없는 것과 제어할 수 있는 것을 생각해보게 된 것 같다.

[gemini-code-assist]

띄어쓰기 및 문장 부호가 누락되어 문장이 다소 길고 읽기 어렵습니다. 다음과 같이 다듬으면 가독성이 훨씬 좋아집니다.

• "훨씬더" -> "훨씬 더"
• "동작하는 것외에" -> "동작하는 것 외의"
• "말이다 이부분에서" -> "말이다. 이 부분에서"
• "존재 하는데" -> "존재하는데"
• "없다는걸" -> "없다는 걸"
• "좋을거 같다" -> "좋을 것 같다"

Suggested change

- 2번에 대해서 반대하는 입장은 아니지만, 현실적으로 3순위 내의 원칙으로 뽑기에는 다른 중요한 것들이 훨씬더 많다고 생각한다. 1번에서 일단 동작하도록 만들라는 말은 다르게 말하면, 동작하는 것외에 작업은 부채로 남겨두라는 말이다 이부분에서 이미 1,2번 간에 모순이 존재 하는데, 2번을 지나치게 강조하는 사람의 입장에서는 이 부채를 남기는 것을 극도로 싫어하는 경향이 있기에, 내 스타일과는 잘 안맞는다고 생각했다. 물론 기술부채를 그대로 두자는 말은 아니다. 기술부채 그 자체 보다 현재 내가 해야하는 목표에 더 집중하는게 더 중요하다고 생각한다. 기술부채를 아무리 갚아도 기술부채는 반드시 생겨난다 그래서 개인적으론 기술부채가 생길 수 밖에 없다는걸 인정하고 어떻게 잘 공존하면서, 처분할지를 고민하는게 좋을거 같다.

- 2번에 대해서 반대하는 입장은 아니지만, 현실적으로 3순위 내의 원칙으로 뽑기에는 다른 중요한 것들이 훨씬 더 많다고 생각한다. 1번에서 일단 동작하도록 만들라는 말은 다르게 말하면, 동작하는 것 외의 작업은 부채로 남겨두라는 말이다. 이 부분에서 이미 1, 2번 간에 모순이 존재하는데, 2번을 지나치게 강조하는 사람의 입장에서는 이 부채를 남기는 것을 극도로 싫어하는 경향이 있기에, 내 스타일과는 잘 안맞는다고 생각했다. 물론 기술부채를 그대로 두자는 말은 아니다. 기술부채 그 자체보다 현재 내가 해야하는 목표에 더 집중하는게 더 중요하다고 생각한다. 기술부채를 아무리 갚아도 기술부채는 반드시 생겨난다. 그래서 개인적으론 기술부채가 생길 수밖에 없다는 걸 인정하고 어떻게 잘 공존하면서, 처분할지를 고민하는게 좋을 것 같다.