더 나은 프로그래머 되는법 5주차 - 권태형 #565
Conversation
TaeHyoungKwon
requested review from
jongfeel,
hemil0102,
ymkim97,
aquamagic9,
fkdl0048,
tttghost and
dhlee3994
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @TaeHyoungKwon, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request incorporates the author's notes and thoughts on the latest chapters and appendices from the 'Becoming a Better Programmer' study material. It adds several new Markdown files detailing personal insights, discussion questions, and opinions related to the book's content on topics like human factors, communication, declarations, code aesthetics, attitude, and various appendix topics including AI, teamwork, learning, and career strategies.
Highlights
- New Study Notes Added: Added new Markdown files containing personal reflections and discussion points for chapters 34 through 39 and appendices 1 through 8 of the 'Becoming a Better Programmer' book.
- Weekly Study Contribution: This PR represents the author's contribution for the fifth week of the study group, addressing the content covered in the specified chapters and appendices.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configureGemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
이 Pull Request는 '더 나은 프로그래머 되기' 책의 34장부터 39장, 그리고 부록 1부터 8까지의 내용에 대한 마크다운 형식의 정리 노트를 추가합니다. 리뷰는 주로 마크다운 서식 개선, 한국어 문법 및 구두점 수정, 그리고 전반적인 내용의 명확성 향상에 중점을 두었습니다. 주요 제안 사항으로는 오타 수정, 구두점 주변의 띄어쓰기 조정, 일관된 문장 종료 방식 적용, 각 파일 끝에 개행 문자 추가 등이 있습니다. 이러한 변경 사항들은 노트의 가독성을 높이는 데 도움이 될 것입니다.
|
Warning Gemini encountered an error creating the review. You can try again by commenting |
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
| # 논의 내용 | ||
|
|
||
| - [질문] | ||
| - 회사에 기술적으로 혹은 경험적으로 훌륭한 프로그래머가 없다고 가정할 때, 훌륭한 프로그래머를 찾기 위해서 이직을 하는 것은 옳은 선택으로 볼 수 있을까? |
There was a problem hiding this comment.
단지 이 이유만이라면 이직의 이유로 충분하지는 않을 것 같네요.
훌륭한 프로그래머 외에도 출퇴근시간, 연봉, 복지, 일하는 도메인, 업무 포지션, 회사 인지도 등등 다양한 조건이 복합적으로 작용해야 하기 때문이죠.
현재 그런 프로그래머가 없다고 해도 곧 그런 분이 입사할 수도 있는 것이고
중장기적으로 그런 프로그래머가 생길 수 있는 회사 분위기가 바뀔 수도 있는 것이고
어쩌면
스스로 훌륭한 프로그래머가 될 수도 있기 때문이죠.
정 안되면 회사 외부에서 찾아서 멘토링을 받던가 커뮤니티 활동을 통해 자극을 받아서
사내에 전파하는 것도 방법이고
그것도 어렵다 하면 같이 일하는 동료 한 명이라도 전파해서 훌륭한 프로그래머가 되거나 되게 만들어 주면 되지 않을까 싶습니다.
There was a problem hiding this comment.
이 회사에서는 더 이상 (크게) 배울 것이 없다. 라는 느낌을 받은지 조금 됐습니다. 그 동안 신입들에게 금요일마다 세션을 열어보기도 했지만 이직이 확실한 것 같습니다...
이직 사유가 "훌륭한 프로그래머를 찾기 위해서"만이라면 조금 섣부른 판단일 수 있다고 생각합니다. 하지만 제가 지금 겪고 있는 상황처럼 "더 이상 성장하기 힘들 것 같다"가 이유라면 타당한 이직 사유가 될 수 있다고 생각합니다.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 나와 같이 일하는 동료와의 업무역량의 차이가 있을 때, 본인은 어떻게 하시는지에 대해서 얘기해보면 좋을 것 같습니다(본인의 역량이 좋든, 혹은 나쁘든) |
There was a problem hiding this comment.
우선 나와 그 동료의 현재 수준에 대한 객관성을 확보합니다.
업무 처리 속도나, 특정 조건을 달성하는 기준을 만들어서 서로 리뷰하는 식으로 하는 건 직접적인 방법이 될 것이고
제 3의 동료와 대화해 보면서 가늠해 보는 간접적인 방법도 있을 수 있습니다.
그랬을 때 어떤 기준이던 평균 이하라고 판단이 된다면
어떻게 더 노력할 것인지를 협의하고 달성해서 지속적으로 회고와 리뷰를 통해 더 나아졌다는 걸
기록으로 남기고 동료나 본인 스스로도 그렇게 자신있게 얘기할 수 있는 분위기가 형성되면 좋을 것 같습니다.
본질적인 질문으로 넘어와서 어떻게 할 건지에 대한 답은
역량을 주관적이던 객관적이던 평가하고 서로 실력이 나아지는 방법을 찾는 길을 모색한다가 방법입니다.
There was a problem hiding this comment.
추가로 동료끼리 이런 건전한 대화를 하고 리뷰 및 스터디로 발전한다면 뭘 하든 역량은 향상될 거라 믿습니다.
하지만 보통 동료들끼리는 서로의 실력에 대해 직접 언급하는 건 민감한 문제로 인식하므로
아는데도 모르는 척 그냥 저냥 지내는 사람들이 더 많았습니다.
특히 팀장이나 리더급 임원이 지적해서 개선의 여부에 대해 1:1 미팅을 하지 않는 이상은 그냥 방치되는 것도 많이 목격한터라.
좋은 방향으로 발전하고 싶은지 아닌지의 마음에 따라 달라질 것 같네요.
| - 동작하는 코드, TDD 등을 언급하며, AI는 구체적인 코드를 작성하는데에 집중하고, 핵심적인 설계 부분은 인간이 담당해야함을 말한다 | ||
| - 이부분에 대해서는 굉장히 동의하는 바이다. 앞으로 LLM 모델이 발전하면 할수록, AI 코드 구현 능력은 점점 더 발전할 것이기 때문이다. | ||
| - 그래서, 개발자들이 AI 때문에, 직업을 잃을 것이라는 전망은 일부 설계역량이 떨어지는 코드 작성 자체만 하는 개발자들이지 않을까 생각된다. 외국에도 보면, 외주 SI 업체들이 많은데, 그 인력들이 아마도 AI 로 대체되지 않을까 라는 생각이다 | ||
| - 반대로, 전체 큰그림을 보고, 설계를 할 수 있는 개발자이면서, 혼자서 AI를 다뤄서 개발할 수 있는 역량까지 있다면, 굳이 회사에서 일을 하지 않고, 개인단위의 1인 사업자들도 많이 생기지 않을까? 하는 예상이다 |
There was a problem hiding this comment.
회사에서 AI를 다루는 개발자 분과 small talk를 하다 보니 태형님이 얘기하는 생각과 똑같이 얘기하더라고요.
요즘은 MCP가 실행까지 다 해버리고 실행하다가 잘못된 부분까지 판단해서 결과를 내 주니까
사람이 경험으로 얻어야 하는 통찰력 까지도 필요가 없지 않나 하는 생각까지 도달하게 되었습니다.
|
|
||
| [질문] | ||
|
|
||
| - 직군 간에 사일로 현상 없이, 팀워크가 갖춰진 팀을 구성하는 본인만의 방법 혹은 경험이 있다면 말해보면 좋을 것 같습니다. |
There was a problem hiding this comment.
프로젝트 팀이 구성되도 직군별 팀의 영향력이 커서 프로젝트 팀은 아주 약간 연결고리만 가져간 적도 있었고
반대로 프로젝트 팀이 기존에 속해 있던 직군별 팀의 영향력이 무시되거나 차단되는 환경에서 일한 적이 있었는데
확실히 다른 직군 끼리 모여도 같은 목표를 달성하기 위해 모였다면 어떤 기술을 할줄 알고 어떤 전공인지는 크게 중요하지 않았었던 기억이 있습니다.
태형님이 얘기한 cross-functional 팀이 좋았던 경험을 저도 느꼈었습니다.
| # 내 생각 | ||
|
|
||
| - `주변 상황에 끌려 다니지 않고 자신 만의 길을 묵묵히 걸어가며 문제 해결에 집중하는 사람` 이 목표라고 말하고 있고, 이러한 사람이 결국 해내는 개발자가 되고, 이런 개발자가 훌륭한 개발자라고 말한다. 나 또한 이분의 말에 매우 동의하는 바이다 | ||
| - 글이 억지로 늘려놓은느낌도 들고, 장황해서 아쉬웠다 다른분들은 어떻게 보셨는지 궁금하다 |
There was a problem hiding this comment.
저의 경우는 그래도 경험을 바탕으로 좋은 insight를 주려고 글을 썼다는 느낌은 있었습니다.
하지만 앞선 개발자 분들에 비해 강하게 뭔가 와닿는 느낌은 없었습니다.
There was a problem hiding this comment.
넵 요부분 번외로 논의 주제로 넣으려고 했는데, 제가 깜빡하고 안 넣었네요
다른 분들은 8개 글들을 읽으면서, 내용이 좀 아쉬웠던 글은 없으셨는지, 그 아쉬웠던 이유는 무엇인지 등을 한번 물어보고 싶었습니다. 이유는 저는 아쉬웠던 글이 있었다보니, 다른 분들의 생각과 비교해보고 싶다는 생각이 있어서 입니다
- 이유 상세:
- 각 상황마다, 책마다 다르지만 요즘은 책을 읽을 때 비판적인 시선으로 많이 보고 있습니다. 그러다보니, 글의 내용 혹은 주장의 근거가 빈약하거나, 논리적이지 않다고 생각되면 비판적인 관점에서 글에 대한 논평을 하게되는 것 같습니다.
- 최근에 GeekNews에서 성공한 사람들은 목표를 쫓지 않음; "한계를 설정"함 글을 읽고, 저는 내용에 어느정도 동의를 했는데요. 관련 해커뉴스 번역된 댓글들을 보면, 제 생각과는 반대로 다양한 비판적인 관점들을 볼 수 있는데 매우 흥미로웠습니다. 그래서 요번 부록을 읽으면서도 다른 분들의 의견이 궁금했었네요 ㅎㅎ
| # 내 생각 | ||
|
|
||
| - 크게 와닿을 만한 부분은 없었다. 말씀해주신 내용 중에서 틀렸다고 말할 부분은 없는 것 같다 누구나 아는 정답을 그대로 쓴것 처럼 보였는데, 개인의 사례 같은게 있었다면 더 좋았을 텐데라는 아쉬움이 있다. | ||
| - 사례가 없어서 아쉬운 이유는 본인의 주장만있고, 그 근거는 없기 때문에 이분이 말씀하는 내용을 본인은 제대로 하고 있는게 맞는것인지? 라는 의문이 들기 때문이다 |
There was a problem hiding this comment.
저는 좋은 내용을 길게 잘 풀어서 설명해 줬다의 느낌이었고
요약하면 다음의 키워드로 글을 썼다는 느낌이 강했습니다.
- 지속적인 학습
- 경험
- 프로젝트 참여
- 코드 리뷰
- 네트워크
- 커뮤니티 참여
- 멘토링
- 자기계발
- 목표 설정
- 회고
- 역량 어필
|
|
||
| [질문] | ||
|
|
||
| - 개발자의 학력, 학위와 개발역량 간의 상관성이 있다고 생각하시나요? 본인의 경험을 기준으로 얘기해보면 좋을것 같습니다 |
There was a problem hiding this comment.
저도 없다고 보는 편인데, 지금도 저보다 학력, 학위가 낮은 분들이 더 열정이 있고 성실하며 능력이 있는 분들이기 때문입니다.
다만 개발에 한정해서는 그럴 수 있고 그렇지 않은 영역은 또 다른 얘기일 수 있습니다.
오랫동안 태형님과 독서모임 하면서 얘기했던 이야기이기도 한데 연구쪽이 그렇습니다.
연구 개발과 성과를 달성하는 목표는 개발 역량 보다는 오히려
공부하는 방법, 데이터를 보고 유추, 추론하는 능력, 원인과 결과를 판단하고 다음 문제가 무엇일지 정의하고 분석하는 능력 등
실제 코드 작성이 아닌 부분에서의 능력은 확실히 지식의 양, 경험, 공부하는 방법의 효율성 등에서 차이가 있었고
그건 고학력 고학위자일 수록 상대적으로 뛰어났었습니다.
(절대적 기준이 아닌 상대적 기준입니다. 예로 반드시 고려대 석사가 서강대 석사보다 절대적으로 뛰어나지 않습니다)
There was a problem hiding this comment.
제가 느낀 좋은 학력을 가지신 분들의 특징은 어떤 문제가 주어졌을 때, 포기하지 않고 좀 더 끈질기게 도전해서 어떻게든 성공시킨다? 라는 측면이 더 강했던 것 같습니다. 마인드셋 차이로도 볼 수 있을 거 같은데, 흔히 말하는 성장형 마인드셋인 경우가 많았던 것 같습니다.
말씀주신대로,실제 코드 작성이 아닌 부분 외의 역량을 상대적으로 평가해봤을 때는 저도 학력이 좋은 분들의 좀 더 나은 결과를 냈었던 것 같네요(그냥 제 경험하에서 정성적으로 생각해봤을 때)
다만, 제 답변에도 썼지만, 아웃라이어, 핵심인재의 경우는 제 경험상에선 학력이랑은 상관관계가 없다보니, 저는 관련이 별로 없다고 생각하는 편 입니다
There was a problem hiding this comment.
'싫어하는 걸 참고 꾸준히 할 수 있는 능력'을 한마디로 증명해주는게 학력이라고 생각합니다.
학력이 무조건 성실/실력/열정 등을 보장해주지는 않지만, 꽤 정확성이 높은 필터 중 하나라고 생각합니다.
(저는 학력이 높지 않습니다.)
| # 논의 내용 | ||
|
|
||
| - [질문] | ||
| - 회사에 기술적으로 혹은 경험적으로 훌륭한 프로그래머가 없다고 가정할 때, 훌륭한 프로그래머를 찾기 위해서 이직을 하는 것은 옳은 선택으로 볼 수 있을까? |
There was a problem hiding this comment.
이 회사에서는 더 이상 (크게) 배울 것이 없다. 라는 느낌을 받은지 조금 됐습니다. 그 동안 신입들에게 금요일마다 세션을 열어보기도 했지만 이직이 확실한 것 같습니다...
이직 사유가 "훌륭한 프로그래머를 찾기 위해서"만이라면 조금 섣부른 판단일 수 있다고 생각합니다. 하지만 제가 지금 겪고 있는 상황처럼 "더 이상 성장하기 힘들 것 같다"가 이유라면 타당한 이직 사유가 될 수 있다고 생각합니다.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 나와 같이 일하는 동료와의 업무역량의 차이가 있을 때, 본인은 어떻게 하시는지에 대해서 얘기해보면 좋을 것 같습니다(본인의 역량이 좋든, 혹은 나쁘든) |
There was a problem hiding this comment.
아는데도 모르는 척 그냥 저냥 지내는 사람들이 더 많았습니다.
이 문장을 보고 뜨끔했습니다. 그냥 제가 좀 더 일을 많이 하는게 나은 것 같습니다. (스터디 제안도 해봤지만 오래 못하시더라구요.)
|
|
||
| [질문] | ||
|
|
||
| - 개발자의 학력, 학위와 개발역량 간의 상관성이 있다고 생각하시나요? 본인의 경험을 기준으로 얘기해보면 좋을것 같습니다 |
There was a problem hiding this comment.
'싫어하는 걸 참고 꾸준히 할 수 있는 능력'을 한마디로 증명해주는게 학력이라고 생각합니다.
학력이 무조건 성실/실력/열정 등을 보장해주지는 않지만, 꽤 정확성이 높은 필터 중 하나라고 생각합니다.
(저는 학력이 높지 않습니다.)
github-project-automation
bot
moved this from In review
to Done
in 2025 Academic Conference
Close #559
논의 내용1 - (34~39)
[질문]
[질문에 대한 개인 의견]
훌륭한 프로그래머 주변에 의도적으로 머물라라는 팁에 동의하면서도, 최근에는 훌륭한 프로그래머와 같이 일하는 것에 너무 집착할 필요는 없다는 생각을 가지고 있다.논의 내용2 - 부록
[질문]
[질문에 대한 개인 답변]