개발자 원칙 sprint 10 - 권태형#664
Conversation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
TaeHyoungKwon
added
2026
개발자 원칙
TaeHyoungKwon
requested review from
GeunJuLEE,
benscookie,
chichoon,
dhlee3994,
jongfeel,
tttghost and
ymkim97
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds personal reflections and discussion topics for the first three chapters of the book "Developer Principles" and updates the create_pr.sh script to match the current book's metadata. The review feedback identifies a potential issue in the shell script where multi-line labels could cause errors with the GitHub CLI and suggests several corrections for typos, grammar, and spacing within the markdown files to improve readability.
| LABELS="2026,개발자 원칙 | ||
| 개발자 원칙 - 확장판, 테크 리더 9인이 말하는 더 나은 개발자로 살아가는 원칙과 철학" |
There was a problem hiding this comment.
LABELS 변수에 줄바꿈과 긴 문장이 포함되어 있습니다. gh CLI의 -l 옵션은 쉼표로 구분된 짧은 라벨들을 인자로 받으므로, 줄바꿈을 제거하고 간결한 라벨명을 사용하는 것이 좋습니다. 현재와 같이 쉼표가 포함된 긴 문장을 그대로 사용하면 의도하지 않은 여러 개의 긴 라벨이 생성되거나 API 호출 시 오류가 발생할 수 있습니다.
| LABELS="2026,개발자 원칙 | |
| 개발자 원칙 - 확장판, 테크 리더 9인이 말하는 더 나은 개발자로 살아가는 원칙과 철학" | |
| LABELS="2026,개발자 원칙" |
| - 초반부에 나오는 SOLID, KISS, YAGNI 등에 대한 맹목적 추종을 하지 말라는 것과 IT 업계 개발자들 사이에 설계라는 용어가 명확히 정의되지 않은 상황에 대해서는 개인적으로 공감되는 부분이 이었습니다 | ||
| - but, 책 후반부로 갈 수록, 본인의 방법론에 기초한 주장에 세지는 것을 느꼈고, 본인의 대기업 커리어의 경험에 대한 신뢰를 바탕으로 경험이 맞다는 전제하에 주장하시는 것 같다는 느낌을 받았습니다. 본인 경험하에서 이렇게 했더니 좋았더라 라는게 그렇게 큰 공감이 되진 않았고, 이분의 주장은 규모가 작은 회사에서는 전혀 맞지 않겠다는 생각이 들었습니다 |
There was a problem hiding this comment.
오타('부분이 이었습니다' -> '부분이었습니다')와 어색한 문법('주장에 세지는' -> '주장이 세지는')을 수정하고, 영문 접속사 'but'을 '하지만'으로 변경하여 문장의 일관성을 높이는 것을 권장합니다.
| - 초반부에 나오는 SOLID, KISS, YAGNI 등에 대한 맹목적 추종을 하지 말라는 것과 IT 업계 개발자들 사이에 설계라는 용어가 명확히 정의되지 않은 상황에 대해서는 개인적으로 공감되는 부분이 이었습니다 | |
| - but, 책 후반부로 갈 수록, 본인의 방법론에 기초한 주장에 세지는 것을 느꼈고, 본인의 대기업 커리어의 경험에 대한 신뢰를 바탕으로 경험이 맞다는 전제하에 주장하시는 것 같다는 느낌을 받았습니다. 본인 경험하에서 이렇게 했더니 좋았더라 라는게 그렇게 큰 공감이 되진 않았고, 이분의 주장은 규모가 작은 회사에서는 전혀 맞지 않겠다는 생각이 들었습니다 | |
| - 초반부에 나오는 SOLID, KISS, YAGNI 등에 대한 맹목적 추종을 하지 말라는 것과 IT 업계 개발자들 사이에 설계라는 용어가 명확히 정의되지 않은 상황에 대해서는 개인적으로 공감되는 부분이었습니다\n- 하지만, 책 후반부로 갈 수록, 본인의 방법론에 기초한 주장이 세지는 것을 느꼈고, 본인의 대기업 커리어의 경험에 대한 신뢰를 바탕으로 경험이 맞다는 전제하에 주장하시는 것 같다는 느낌을 받았습니다. 본인 경험하에서 이렇게 했더니 좋았더라 라는게 그렇게 큰 공감이 되진 않았고, 이분의 주장은 규모가 작은 회사에서는 전혀 맞지 않겠다는 생각이 들었습니다 |
|
|
||
| - 저자는 오류를 마주칠 때가 내 개발자로서의 역량을 키울 수 있는 시점으로 보고 있다. 학생 시절에 틀린 문제는 오답노트로 정리해서 내 걸로 만든다의 개념으로 볼 수 있고, 어찌 보면 그렇게까지 대단하게 특이점이 있는 것은 아니다 | ||
| - 그러나, 이게 말은 쉽지만 생각보다 실천하기도 어렵고, 개인적으로는 어떤 주제를 어떤 범위 만큼 어떻게 정리해야 하는지에 대해서 고민하다가 그냥 넘기는 경우가 많은 것 같다 | ||
| - 내 생각에 이걸 실천하기 가장 좋은 것은 회사 업무 환경이다. 회사 업무를 대상으로 내가 겪은 장애 혹은 버그들은 실제 현업 실무 환경에서 발생한 어떻게 보면 매우 가치가 높은 문제상황이기 때문이다. 내가 만들거나 겪은 오류, 버그, 장애가 모두 정리가 되면 내 팀, 더 커지면 내 회사를 기준으로 범위를 넓히면서 까지 해보면 알짜로 중요 현업 문제들을 경험해보고 해결해보는 매우 좋은 경험일 것 같다 |
There was a problem hiding this comment.
'넓히면서 까지'의 띄어쓰기 오류와 문장 중간의 불필요한 이중 공백을 수정하여 가독성을 개선할 수 있습니다.
| - 내 생각에 이걸 실천하기 가장 좋은 것은 회사 업무 환경이다. 회사 업무를 대상으로 내가 겪은 장애 혹은 버그들은 실제 현업 실무 환경에서 발생한 어떻게 보면 매우 가치가 높은 문제상황이기 때문이다. 내가 만들거나 겪은 오류, 버그, 장애가 모두 정리가 되면 내 팀, 더 커지면 내 회사를 기준으로 범위를 넓히면서 까지 해보면 알짜로 중요 현업 문제들을 경험해보고 해결해보는 매우 좋은 경험일 것 같다 | |
| - 내 생각에 이걸 실천하기 가장 좋은 것은 회사 업무 환경이다. 회사 업무를 대상으로 내가 겪은 장애 혹은 버그들은 실제 현업 실무 환경에서 발생한 어떻게 보면 매우 가치가 높은 문제상황이기 때문이다. 내가 만들거나 겪은 오류, 버그, 장애가 모두 정리가 되면 내 팀, 더 커지면 내 회사를 기준으로 범위를 넓히면서까지 해보면 알짜로 중요 현업 문제들을 경험해보고 해결해보는 매우 좋은 경험일 것 같다 |
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
제가 범위를 잘못인지하고 올렸네요 일단 범위까지만 두었습니다 |
| # 2장 | ||
|
|
||
| ## 논의 주제 | ||
| - 회사 업무 / 개인적인 개발 학습을 하면서, 얻은지식, 겪는 경험들이나 실패 상황들(에러, 버그, 장애 등)을 어떤 식으로 관리하고 계신지 얘기해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
되도록이면 기록으로 남겨서 공유하는 방법으로 합니다.
다수의 사람에게 공유하고 얘기해주는 것도 시간이 필요하다 보니 기록은 해 뒀다가 필요할 때 다시 리마인드 하는 차원에서 공유하고 알려주고 하는 방식입니다.
서로 업무 공유가 잘 되고 있는 팀이면 간단하게 말로 해결되는 경우도 많지만 서로 기억이 안나거나 정확하지 않은 상황은 기록을 들춰보고 확인하는 게 도움이 되긴 하더라고요.
슬랙, 노션, 메일 등을 활용해 검색을 하고 그 후에 관련 내용을 찾아서 관리하는 식으로 하고 있습니다.
2 participants
Closes #660