개발자 원칙 sprint 12 - 이근주#680
Conversation
|
우측에 있는 |
![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 a book review for Chapters 6 to 9 of "Developer Principles". The reviewer's feedback focuses on correcting the Markdown heading hierarchy to ensure a consistent document structure, and improving Korean spelling, spacing, and terminology for a more professional tone. All comments are constructive and provide actionable suggestions.
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.
|
|
||
| --- | ||
|
|
||
| # Chapter 6 - 목표를 달성하는 나만의 기준, GPAM |
There was a problem hiding this comment.
문서의 마크다운 계층 구조를 올바르게 유지하기 위해 # Chapter 6을 ### Chapter 6으로 변경하는 것을 제안합니다. 상위 제목이 # 개발자 원칙 독후감(H1) 및 ## 6 ~ 9장(H2)이므로, 하위 챕터는 H3 레벨이 적절합니다.
| # Chapter 6 - 목표를 달성하는 나만의 기준, GPAM | |
| ### Chapter 6 - 목표를 달성하는 나만의 기준, GPAM |
|
|
||
| 다만 생각해보니 올해 딱히 목표를 세우지 않아서 일단 목표를 세우기로 했다. | ||
|
|
||
| # Chapter 7 - 프로덕트 중심주의 |
There was a problem hiding this comment.
문서의 마크다운 계층 구조를 올바르게 유지하기 위해 # Chapter 7을 ### Chapter 7으로 변경하는 것을 제안합니다.
| # Chapter 7 - 프로덕트 중심주의 | |
| ### Chapter 7 - 프로덕트 중심주의 |
|
|
||
| 회사에서 사용하는 프로덕트 중심 사고방식을 개인 생활에도 적용할 수 있다는 점이 흥미로웠다. 나 또한 최근에는 EDA(Event-Driven Architecture)에서 아이디어를 얻어 행동을 연결하는 습관을 만들려고 노력하고 있다. 예를 들어 "밥을 먹으면 바로 식기를 치운다.", "집에 들어오면 바로 씻는다."처럼 특정 행동이 다음 행동의 트리거가 되도록 만들어 미루는 습관을 줄이고 있다. | ||
|
|
||
| ### 논의사항 - 이러한 개발 프로세스를 생활에서 사용한 경험이 있으신가요? |
There was a problem hiding this comment.
Chapter 7이 H3(###)으로 변경됨에 따라, 하위 항목인 논의사항은 H4(####)로 변경하여 계층 구조를 맞추는 것이 좋습니다.
| ### 논의사항 - 이러한 개발 프로세스를 생활에서 사용한 경험이 있으신가요? | |
| #### 논의사항 - 이러한 개발 프로세스를 생활에서 사용한 경험이 있으신가요? |
|
|
||
| ### 논의사항 - 이러한 개발 프로세스를 생활에서 사용한 경험이 있으신가요? | ||
|
|
||
| # Chapter 8 - 제어할 수 없는 것에 의존하지 않기 |
There was a problem hiding this comment.
문서의 마크다운 계층 구조를 올바르게 유지하기 위해 # Chapter 8을 ### Chapter 8으로 변경하는 것을 제안합니다.
| # Chapter 8 - 제어할 수 없는 것에 의존하지 않기 | |
| ### Chapter 8 - 제어할 수 없는 것에 의존하지 않기 |
|
|
||
| 이러한 원칙은 개발뿐 아니라 일상에서도 적용할 수 있다고 생각한다. 내가 통제할 수 없는 요소보다는 직접 관리하고 개선할 수 있는 요소에 집중하는 것이 장기적으로 더 안정적인 선택이라는 점을 배웠다. | ||
|
|
||
| 하지만 제어할 수 없는 것에 의존하지 않는 것은 좋지만, 또 너무 의존하지 않기 위해 모든 것을 다 만들려고 하면 일처리가 늦어진다. 예를 들어 다른 스타트업은 외부 tool을 많이 사용하여 더 빠른 서비스 오픈을 할 수 있는 반면, 네이버는 모든 것을 내부적으로 만들어서 사용하려다보니 서비스 오픈 속도가 그만큼 떨어진다. 무엇이 정답인지 정말 모르겠다. |
There was a problem hiding this comment.
문장의 가독성과 맞춤법, 그리고 표현의 객관성을 높이기 위해 몇 가지 개선을 제안합니다.\n\n1. 맞춤법 및 띄어쓰기: '사용하려다보니'는 '사용하려다 보니'로 띄어 쓰는 것이 올바릅니다.\n2. 용어 개선: '외부 tool'은 '외부 솔루션' 또는 '외부 도구'로, '서비스 오픈'은 '서비스 출시'로 변경하면 더 자연스럽습니다.\n3. 표현의 객관성: 특정 기업명을 직접 언급하기보다 '자체 솔루션 개발을 선호하는 기업'과 같이 일반화된 표현을 사용하면 글의 전문성이 더 높아집니다.
| 하지만 제어할 수 없는 것에 의존하지 않는 것은 좋지만, 또 너무 의존하지 않기 위해 모든 것을 다 만들려고 하면 일처리가 늦어진다. 예를 들어 다른 스타트업은 외부 tool을 많이 사용하여 더 빠른 서비스 오픈을 할 수 있는 반면, 네이버는 모든 것을 내부적으로 만들어서 사용하려다보니 서비스 오픈 속도가 그만큼 떨어진다. 무엇이 정답인지 정말 모르겠다. | |
| 하지만 제어할 수 없는 것에 의존하지 않는 것도 중요하지만, 의존성을 지나치게 피하려다 보면 모든 것을 직접 개발하게 되어 일처리가 늦어질 수 있다. 예를 들어 일부 스타트업은 외부 솔루션을 적극적으로 활용하여 빠른 서비스 출시를 이뤄내는 반면, 자체 솔루션 개발을 선호하는 기업은 모든 것을 내부적으로 만들어 사용하려다 보니 서비스 출시 속도가 상대적으로 느려지기도 한다. 무엇이 정답인지 정말 모르겠다. |
|
|
||
| 하지만 제어할 수 없는 것에 의존하지 않는 것은 좋지만, 또 너무 의존하지 않기 위해 모든 것을 다 만들려고 하면 일처리가 늦어진다. 예를 들어 다른 스타트업은 외부 tool을 많이 사용하여 더 빠른 서비스 오픈을 할 수 있는 반면, 네이버는 모든 것을 내부적으로 만들어서 사용하려다보니 서비스 오픈 속도가 그만큼 떨어진다. 무엇이 정답인지 정말 모르겠다. | ||
|
|
||
| # Chapter 9 - 달리는 기차의 바퀴 갈아 끼우기 |
There was a problem hiding this comment.
문서의 마크다운 계층 구조를 올바르게 유지하기 위해 # Chapter 9을 ### Chapter 9으로 변경하는 것을 제안합니다.
| # Chapter 9 - 달리는 기차의 바퀴 갈아 끼우기 | |
| ### Chapter 9 - 달리는 기차의 바퀴 갈아 끼우기 |
|
|
||
| 또한 기술 부채는 시간이 지나면 자연스럽게 해결되는 문제가 아니라, 누군가 의식적으로 관리해야 하는 문제라는 점에도 공감했다. 현재 우리 팀에서는 내가 이러한 개선 작업을 주도하는 편인데, 이를 방치하면 결국 팀 전체의 생산성이 떨어지고 그 영향은 나에게도 돌아온다. 그래서 기능 개발뿐 아니라 지속적인 리팩터링과 구조 개선에도 시간을 투자하려고 노력하고 있다. | ||
|
|
||
| ### 논의사항 - 기술 부채에 대해서 다들 어떻게 해결하고 있나요? |
There was a problem hiding this comment.
Chapter 9가 H3(###)으로 변경됨에 따라, 하위 항목인 논의사항은 H4(####)로 변경하여 계층 구조를 맞추는 것이 좋습니다.
| ### 논의사항 - 기술 부채에 대해서 다들 어떻게 해결하고 있나요? | |
| #### 논의사항 - 기술 부채에 대해서 다들 어떻게 해결하고 있나요? |
2 participants
No description provided.