개발자 원칙 sprint 11 - 김영명#669
Conversation
ymkim97
requested review from
GeunJuLEE,
TaeHyoungKwon,
chichoon,
dhlee3994,
hemil0102,
jongfeel and
tttghost
|
우측에 있는 |
![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 two markdown files summarizing Chapters 0 to 5 of "Developer Principles" along with discussion topics. The review feedback focuses on correcting Korean spelling, spacing (such as "못 할" to "못할", "일하는게" to "일하는 게", and "있을테니" to "있을 테니"), fixing typos, and improving sentence structures for better readability.
| 나도 꽤 개발에 대한 흥미와 관심이 많아 공감하는 부분들이 많았다. | ||
| 이 분의 특별한 부분은 신입 개발자로부터 시작해서 테크 리더까지 살아가면서 점차 다듬어져가는 전문가에 대한 정의였다. | ||
| 확장판으로 AI와 관련된 비교적 최근 이야기도 볼 수 있었다. | ||
| AI가 개발자를 대체하지는 못 할 것이라는 말을 내가 듣고 싶었던 것을 알 수 있었다. |
There was a problem hiding this comment.
못 할의 올바른 맞춤법은 붙여쓴 못할입니다. 또한 문장 뒷부분의 표현을 더 자연스럽게 다듬는 것을 추천합니다.
| AI가 개발자를 대체하지는 못 할 것이라는 말을 내가 듣고 싶었던 것을 알 수 있었다. | |
| AI가 개발자를 대체하지는 못할 것이라는 말이 내가 듣고 싶었던 말이었음을 깨달았다. |
|
|
||
| ## 논의 내용 | ||
| * 본인은 덕업일치라고 생각하는지? 그렇다면 왜 그렇게 생각하는지? | ||
| * 저는 덕업일치라고 생각합니다. 아직은 연차가 높지는 않지만 회사에서 개발자로 일하는게 정말 재밌습니다. 직접 만든 기능에 트래픽이 들어오고, 이를 통해 사용자들에게 도움이 된다는 사실이 너무 뿌듯하며, 개발 또는 컴퓨터 자체가 항상 재밌고 흥미로워서라고 생각하기 때문입니다. 그렇기 때문에 기술과 개발 또는 관련 도메인을 공부하는 것이 일과 연결될 수 있다는 것에서 참 감사하고 있습니다. No newline at end of file |
There was a problem hiding this comment.
의존명사 게 앞의 띄어쓰기(일하는게 -> 일하는 게)를 수정하고, 문장의 인과관계와 표현을 매끄럽게 다듬는 것이 좋습니다.
| * 저는 덕업일치라고 생각합니다. 아직은 연차가 높지는 않지만 회사에서 개발자로 일하는게 정말 재밌습니다. 직접 만든 기능에 트래픽이 들어오고, 이를 통해 사용자들에게 도움이 된다는 사실이 너무 뿌듯하며, 개발 또는 컴퓨터 자체가 항상 재밌고 흥미로워서라고 생각하기 때문입니다. 그렇기 때문에 기술과 개발 또는 관련 도메인을 공부하는 것이 일과 연결될 수 있다는 것에서 참 감사하고 있습니다. | |
| * 저는 덕업일치라고 생각합니다. 아직은 연차가 높지는 않지만 회사에서 개발자로 일하는 게 정말 재미있습니다. 직접 만든 기능에 트래픽이 들어오고, 이를 통해 사용자들에게 도움이 된다는 사실이 너무 뿌듯하며, 개발 또는 컴퓨터 자체가 항상 재미있고 흥미롭기 때문입니다. 그렇기 때문에 기술과 개발 또는 관련 도메인을 공부하는 것이 일과 연결될 수 있다는 점에 참 감사하고 있습니다. |
| 하지만 직접 프로젝트를 진행하면서 사용했던 기술들은 시간이 지나도 꽤 기억과 몸에 남는다. | ||
| 결국 암묵지로 체화하는 것이 장기적으로 깊이 있는 개발자가 되는 것 같다. | ||
|
|
||
| “0.5.0 결과를 향하면서 과정을 기록하기” 는 저번 스프린트에서 느꼈던 것처럼 나 자신에 대해서 반성했다. |
There was a problem hiding this comment.
조사 는 앞의 불필요한 공백을 제거하고, 문맥상 주어와 서술어의 호응이 맞지 않는 부분(‘~ 기록하기는 ~ 반성했다’)을 자연스럽게 다듬는 것이 좋습니다.
| “0.5.0 결과를 향하면서 과정을 기록하기” 는 저번 스프린트에서 느꼈던 것처럼 나 자신에 대해서 반성했다. | |
| “0.5.0 결과를 향하면서 과정을 기록하기” 부분을 읽으며, 저번 스프린트에서 느꼈던 것처럼 나 자신에 대해 반성했다. |
| 내 성장을 위한 계획이 뚜렷하게 그려지지 않을 때, 그때는 새로운 회사와 환경을 찾을 결심을 하는 용기를 가져보아야겠다. | ||
|
|
||
| ## 논의 내용 | ||
| * 이전 스프린트 때 잠시 얘기했었지만, 본인의 기록 방법에 대해서 공유해보면 좋을 것 같습니다. 저는 노션, 옵시디언에 회사에서 진행했던 작업들을 기록해보고는 있지만, 생각보다 잘 적지 않아서 다른 방법을 찾아보고 있습니다. 또한 모든 것을 기록하기에는 무리가 있을테니 어떠한 것들을 중점으로 기록하는 것이 자신을 돌아보는데에 도움이 될지 고민 중이네요. No newline at end of file |
There was a problem hiding this comment.
돌아는데에는 오타입니다. 돌아보는 데로 수정하고, 의존명사 데와 터 앞의 띄어쓰기(있을테니 -> 있을 테니)를 올바르게 적용하는 것이 좋습니다.
| * 이전 스프린트 때 잠시 얘기했었지만, 본인의 기록 방법에 대해서 공유해보면 좋을 것 같습니다. 저는 노션, 옵시디언에 회사에서 진행했던 작업들을 기록해보고는 있지만, 생각보다 잘 적지 않아서 다른 방법을 찾아보고 있습니다. 또한 모든 것을 기록하기에는 무리가 있을테니 어떠한 것들을 중점으로 기록하는 것이 자신을 돌아보는데에 도움이 될지 고민 중이네요. | |
| * 이전 스프린트 때 잠시 얘기했었지만, 본인의 기록 방법에 대해서 공유해보면 좋을 것 같습니다. 저는 노션, 옵시디언에 회사에서 진행했던 작업들을 기록해보고는 있지만, 생각보다 잘 적지 않아서 다른 방법을 찾아보고 있습니다. 또한 모든 것을 기록하기에는 무리가 있을 테니 어떠한 것들을 중점으로 기록하는 것이 자신을 돌아보는 데 도움이 될지 고민 중이네요. |
| 내 성장을 위한 계획이 뚜렷하게 그려지지 않을 때, 그때는 새로운 회사와 환경을 찾을 결심을 하는 용기를 가져보아야겠다. | ||
|
|
||
| ## 논의 내용 | ||
| * 이전 스프린트 때 잠시 얘기했었지만, 본인의 기록 방법에 대해서 공유해보면 좋을 것 같습니다. 저는 노션, 옵시디언에 회사에서 진행했던 작업들을 기록해보고는 있지만, 생각보다 잘 적지 않아서 다른 방법을 찾아보고 있습니다. 또한 모든 것을 기록하기에는 무리가 있을테니 어떠한 것들을 중점으로 기록하는 것이 자신을 돌아보는데에 도움이 될지 고민 중이네요. No newline at end of file |
There was a problem hiding this comment.
도구는 사실 크게 신경 쓰지 않습니다.
회사마다 팀마다 선호하는 도구가 있고 내용을 작성하고 연결하고 검색하는 데 있어서 크게 불편하지 않기 때문입니다.
< Software Architecture: The Hard Parts > 에 ADR을 언급한 부분이 있습니다.
아키텍처 결정 기록인데 이걸 써보면 좋을 것 같습니다.
그 외 내용들은 자세하게 적기 보다는 다시 확인했을 때 파악이 될 정도만 적어봐도 될 것 같습니다.
그리고 중요한 건 문서도 유지보수가 필요하다는 점인데, 유지보수가 되어야 하는 문서 중심으로 작성을 해 보면 좋다는 생각입니다.
예1) 기술적인 해결 방법 => 그 이후 버전이 바뀌면서 변경된 내용을 추가로 작성
예2) 장애로 인한 버그 해결 방법 => 다시 재현됐을 때 기존 버그 수정 해결 방법의 문제점과 이번에 올바르게 해결한 방법 추가로 작성 등
There was a problem hiding this comment.
기본적으로 업무관련해서는 daily-log를 남기고 있고, 이를 옵시디언으로 관리하고 있습니다
그 외 기술 이슈에 대한 것은 요즘에는 /til 이라는 스킬을 만들어서, 일하면서 나중에 다시 확인할만한 이슈들을 llm 통해서 정리하도록 하고 제 notion에 작성토록 하는 식으로 기록을 쌓고 있습니다
스킬 내용 일부를 첨부하자면 아래와 같습니다
# /til — Today I Learned 자동 정리
태형님의 학습/사건 기록을 4-Layer 구조로 정리하여 Notion `TIL Log` 데이터베이스에 새 페이지로 추가하는 워크플로우.
## 핵심 원칙
TIL은 "그날 발생한 사건들 중 기억에 남기고 추후 분석하고 싶은 것"을 보존하는 학습 자산이다. 단순 메모가 아니라, 사건을 **추상화·자기진단·역질문**으로 확장해 미래의 자신에게 가치 있는 노트로 남기는 데 목적이 있다.
## Usage
- `/til` — 현재 대화 컨텍스트에서 TIL 대상을 추출하여 작성
- `/til <대상>` — 명시적인 대상(예: PR URL, 키워드, 책 제목) 지정
- 자연어 트리거: "TIL 만들어줘", "이거 TIL로 정리해줘", "방금 거 TIL로 남기자" 등
...
...
## Layer 1 · 사건 기록
### 문제
무슨 사건/질문이 발생했는가. 어떤 맥락에서 부딪혔는가.
### 해결책
어떤 해결책이 적절하다고 판단되는가 (또는 이미 나온 해결책의 명시).
### 조건 (전제·제약·문맥)
이 문제를 풀 때 반드시 고려해야 할 전제·제약·문맥.
---
## Layer 2 · 일반화 (외부 시점)
### 한 단계 위에서 본 관점
이 사건을 한 단계 추상화하면 어떤 일반 문제로 치환되는가.
다른 어떤 문제들이 같은 일반화 아래 묶이는가.
### 일반화된 원리
그 추상 영역에서 통하는 원리·패턴·의사결정 프레임.
---
## Layer 3 · 학습 갭 & 역량 보강 (내부 시점)
### 이 사건에서 드러난 내 약점
어떤 개념이 흐릿했는가, 어디서 막혔는가.
### 백엔드 개발자로서 보강해야 할 개념·스킬
영역별로 묶어서 (예: 인프라 / 부하 테스트 / JVM 메트릭 / 관찰성 등).
### 다음 액션
- [ ] 책/아티클/실험/실습 등 구체적 학습 행동
---
## Layer 4 · 역질문 (이해 점검 & 발전)
1. (Layer 1·2의 핵심 개념을 다시 묻는 질문)
2. (가정에 의문 던지는 질문)
3. (확장·발전·다른 시각의 질문)
...
---
> **Re-check**: Layer 4 질문 중 즉답이 안 되는 게 있으면 Status를 `재방문 필요`로 두고 다음 회차에 답을 채워 넣는다.
3 participants
No description provided.