-
Notifications
You must be signed in to change notification settings - Fork 5
더 나은 프로그래머 되는법 5주차 - 김영명 #566
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
e1ba58f
e97f032
ec83b22
c915706
36ee588
4e5d0e7
be319b4
37f4189
f174242
7cab415
d6c48e2
8f8a739
9345986
56290fc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,150 @@ | ||
| # 더 나은 프로그래머 되는 법 | ||
| ## 34장 ~ 39장, 부록 - 국내 개발자 8인의 이야기 | ||
| --- | ||
| ## 34장 - 사람의 힘 | ||
| 프로그래밍은 온전히 기술적인 도전뿐만이 아니라, 사회적 도전이기도 하다. | ||
| 하나의 코드베이스에서 협업하는 사람들에 의해 필연적으로 코드의 형태가 만들어지게 되듯이, 자신의 모습도 함께 일하는 사람들에 의해 만들어지기 마련이다. | ||
|
|
||
| > *훌륭한 프로그래머들 주변에 의도적으로 머물라.* | ||
|
|
||
| 훌륭한 프로그래머들이 있는 환경에 스스로를 담금으로써 다음과 같은 결과물을 얻을 수 있다. | ||
| * 확산되는 열정 | ||
| * 영감을 주는 동기 부여 | ||
| * 전염되는 책임감 | ||
|
|
||
| 현재 내가 취업을 준비하는 과정에도 이러한 환경을 찾고자 노력하고 있는 중이라고 생각한다. | ||
|
|
||
| ## 35장 - 생각이 중요하다 | ||
| 책의 저자에게 최선을 다해 일하도록 의욕을 복돋아주었던 유일하면서도 가장 중요한 요소는 의무감이었다고 한다. 그리고 그 의무감의 대상은 구성된 필자의 팀이었다. | ||
|
|
||
| > *작업의 품질을 보증하기 위해 다른 프로그래머들에 대한 의무감을 가지면, 코드 품질을 환상적으로 높일 수 있다.* | ||
|
|
||
| 가장 중요한 것은 의무감의 필요성을 인지하는 것이다. | ||
| 일단 그 필요성을 인지하고 나면, 최선을 다해 작성한 코드 품질에 관해 다른 사람에게 자신있게 대답할 수 있다. | ||
|
|
||
| 프로그래머 상호 간의 의무감을 위해서는 일정 수준 이상의 용기가 있어야 한다. | ||
| 비판을 기꺼이 받아들여야 한다. 또한 비판을 적절히 수행하기 위해 전략적이어야 한다. | ||
| 코드의 품질에 가져올 이득은 그만큼 크고 심오할 수 있다. | ||
|
|
||
| ## 36장 - 말하기! | ||
| 프로그래머라는 직업은 모든 부분에서 의사소통과 관련이 있다. | ||
| 의사소통의 품질에 따라 성공과 실패가 결정된다 해도 과언이 아니다. | ||
| 소프트웨어 그 자체 코드를 작성하는 행위야말로 의사소통의 한 형태이다. | ||
|
|
||
| 프로그래머가 작성한 코드뿐만으로 의사소통이 이루어지지 않고, 프로그래머들은 팀으로 함께 작업하며 더 큰 조직과도 협업한다. | ||
| 우리는 언제나 다른 사람과 이야기하기 위해 메시지를 작성하고, 때에 따라서는 몸짓으로 뜻을 전하기도 한다. | ||
|
|
||
| > *좋은 의사소통에 의해 좋은 코드가 만들어진다. 의사소통의 형태가 코드의 형태를 만들어낼 수 있다.* | ||
|
|
||
| 고객들과의 대화도 역시 중요하다. | ||
| 개발자는 고객이 원하는 바를 이해해야 소프트웨어를 올바르게 만들 수 있다. | ||
| 고객에게 물어봐야 하고, 그들의 요구 사항을 확인하기 위해 그들의 언어로 작업해야 한다. | ||
|
|
||
| ## 37장 - 선언문 | ||
| > *선언문은 어디에나 존재한다. 소프트웨어 개발에 관한 다양한 선언문으로 인해, 개발자의 직업은 소프트웨어 개발의 무역, 실제 예술, 공예, 과학보다는 오히려 정치에 더 가까워지고 있다. … 문제는 기초적인 코딩 원칙들에 대해서조차 정치적 싸움이 벌어지고 있다는 점이다.* | ||
|
|
||
| 애자일 선언문, 장인 정신 선언문, GNU 선언문, 리팩터링 선언문 등 다양한 선언문들이 존재한다. | ||
| 그들은 잘 작용하는 관습과 이상, 표준의 집합을 찾아서 자연스럽게 한데 모으고, 다른 사람들과 공유하여 개발자 직업을 향상시키려 한다. | ||
| 코딩 규칙의 경우와 마찬가지로, 이런 문서 주변에서는 전혀 도움이 되지 않는 성전(holy war)이 벌어질 수 있다. | ||
|
|
||
| > *납득할 만한 개발 선언문들을 지지하되, 맹목적으로 따르거나 독단적으로 다루지 말라.* | ||
|
|
||
| 그 어떤 선언문이든 원칙에 대한 폭넓은 선언일 뿐, 유일한 진리의 길은 절대 아니다. | ||
|
|
||
| ## 38장 - 코드 찬가 | ||
| 제대로 일하지 못하거나 일부러 코드를 더 나쁘게 작성하는 것처럼 보이는 팀원과 일할 때는 어떻게 반응해야 하는가? | ||
| 소프트웨어의 팀 리더가 그러한 문제를 인지하지 못하거나 이해하지 못한다면 어떻게 해야 하는가? | ||
| 코딩 경력과 관련해 큰 축복을 받은 것이 아닌 이상, 도저히 해결 방법을 찾을 수 없는 질척한 상황에 놓일 것이다. | ||
|
|
||
| > *보통, 소프트웨어 개발과 관련해 까다로운 부분은 기술적인 측면에 있지 않다. 결국 사람의 문제다.* | ||
|
|
||
| 만약 프로그래머가 업무를 이해하지 못한 것처럼 보이고 상황을 더 악화시키고 있음을 이해하지 못한다면, 그에 대해 반드시 반응해주어야 한다. | ||
|
|
||
| 코드에 신경 쓰지 않는 코더에게 둘러싸여 있다면, 자신만이라도 건전한 태도를 유지하라. | ||
| 삼투압 현상에 의해 나쁜 습성을 흡수하지 않도록 주의하자. | ||
|
|
||
| ## 39장 - 태도가 핵심이다 | ||
| 개발자가 수많은 지식과 특정 기술에 대한 이해를 얻었다 해도 다음과 같은 적절한 태도가 병행되지 않는다면 아무 소용이 없다. | ||
| 그것은 바로 프로그래밍을 잘 하고자 하는 소망과 열정이다. | ||
|
|
||
| > *좋은 프로그래머와 나쁜 프로그래머를 구분하는 요소는 바로 ‘태도’다. 프로그래밍 언어에 대한 복잡한 지식이 반드시 유지 보수 가능한 코드를 보장하지는 않는다. 프로그래밍에 대한 설계 지식이 많다고 해서 언제나 고상한 설계에 도달하지는 않는다. 당신의 코드가 ‘좋은’ 것인지, 그리고 당신이 함께 일하기 좋은 사람인지를 결정하는 기준은 바로 당신의 태도다.* | ||
|
|
||
| 좋은 코드에 주의를 기울이고 더 나은 방법을 찾자. | ||
| 언제나 배우고, 설계 방법을 배우고, 코드를 작성하는 방법을 배우고, 같이 일하는 방법을 배우자. | ||
|
|
||
| ## 미래 기술의 열쇠, 생성형 AI를 활용한 프로그래머 | ||
| 생성형 AI의 발전으로 인해 개발자의 시대는 변하고 있다. | ||
| 특히 더 이상 주니어 엔지니어가 필요하지 않을 수 있다고 한다. 생성형 AI에게 핵심 역할 또는 부가적인 작업을 맡길 수 있는데, 후자의 방식을 통해 주니어 엔지니어의 역할을 넘길 수도 있다. | ||
|
|
||
| 자연어를 이용하여 AI에게 정확하게 명시하지 않은 요구 사항까지 정교한 코드를 생성하는 것은 꽤 어렵다. 따라서 여기에는 근본적인 한계가 존재한다. | ||
| 그렇다면 테스트 코드를 이용하여 이를 극복하는 방안으로 가져갈 수 있다(TDD). | ||
|
|
||
| 요새 AI와 함께하는 바이브 코딩이 꽤나 트렌드이며, 나도 한번 시도해보며 현재 생성형 AI의 힘이 어디까지 왔는지 확인해보고, 여기서 주니어 엔지니어가 가져야 할 자세를 생각해봐야겠다. | ||
|
|
||
| ## 훌륭한 프로그래머이자 팀플레이어 되는 법 | ||
| 사람들이 모여 팀을 이루고 일을 할 때는 항상 문제가 발생하고 다같이 머리를 맞대어 해결해야 하는 상황이 발생한다. | ||
| 진유림님은 이를 해결할 수 있는, 1차원적인 것보다 더 높은 수준의 해결책을 마련하기 위해서는 근본적인 문제를 알아내고 원인을 파악해야 한다고 한다. 즉 본질을 탐구해야 한다. | ||
| 혼자가 아닌 팀 차원에서 공감대를 형성하고 목표 달성을 위한 최선의 방법을 찾아내야 한다. | ||
|
|
||
| 이외에도 어떤 관계가 얽혀있는지, 이해관계자들이 말하지 않은 속마음은 무엇인지를 탐색하며 본질을 찾아가는 예시가 쓰였다. | ||
|
|
||
| 해당 부분들을 읽으면서 34장 사람의 힘이 생각났다. 의도적으로 훌륭한 프로그래머들 주변에 머물라는 책 저자의 조언이 있다. 진유림님은 주변 사람들을 관찰하고 거기서 팀플레이어다운 행동들을 보고, 본인이 실천해가며 기록했다. | ||
|
|
||
| ## 개발자의 학습, 성장에 관하여 | ||
| 성장이란 정의와 이를 어떤 자세로 추구해야 하는지 적어주셨다. | ||
| 성장은 사람들마다, 시기마다 본인이 내릴 수 있는 정의가 여러 가지이며 당시 이소영님은 ‘나만의 관점이 많아지는 것’이라고 하셨다. | ||
|
|
||
| 성장을 위해서는 학습이 빠질 수 없는데, 정보의 호수 속에서 무엇을 위해 학습할지 정하는 것은 정말 어렵다. | ||
| 정한다 할지라도 그 부분이 현재 자신의 고민과 맞지 않아 어느 순간 한구석에 방치되기 쉽다. | ||
| 따라서 학습을 위한 학습이 아니라 문제 해결을 위한 학습부터 시작하여 지식을 습득해보는 것이 훨씬 효과적이다. | ||
|
|
||
| 이소영님이 말하시는 가장 강력한 무기는 꾸준함과 사소한 습관들 중 루틴 찾기가 가장 와닿았다. | ||
|
|
||
| ## 개발자로서 지속적인 성장과 성공을 위한 전략 | ||
| 개발자로서 지속적인 학습과 기본기를 꾸준히 강화함으로써 성장이 이루어져야 한다고 한다. | ||
| 그러기 위해 프로젝트, 코드 리뷰 등의 실전 경험을 하고 네트워킹과 커뮤니티 참여, 자기개발 등을 함께 하는 것을 강조하셨다. | ||
| 이번 글은 내용 자체는 정말 공감하나 앞에 있던 글들과는 다르게 진나영님의 사례가 없어 특별한 느낌을 받지 못했다. | ||
|
|
||
| ## 결국 해내는 개발자 | ||
| 글의 저자 서지연님이 봐온, 목표하는 “훌륭한 개발자는 주변 상황에 끌려 다니지 않고 자신만의 길을 묵묵히 걸어가며 문제 해결에 집중하는 사람”이다. | ||
|
|
||
| 명확하지 않고 불분명한 목표는 결국 이루기 어렵다. | ||
| 더 구체적이고 결과물에 대해 명확한 설정을 추가하여 목표에 어디까지 도달했는지 현재의 위치를 알아내는 것이 좋다. | ||
|
|
||
| 목표를 설정하면 실행이 중요하다. 큰 목표를 이루는 유일한 방법은 아주 작은 일의 반복이기 때문에 꾸준히 작은 성취들을 이루어 가자. | ||
|
|
||
| 지금 저 높은 곳에 있는 시니어 개발자도 계단을 하나씩 하나씩 밟고 올라간 것을 잊지 말자. | ||
|
|
||
| ## 개발자 커리어에서 한 번쯤 생각해보면 좋은 5가지 | ||
| **커뮤니케이션과 관심** | ||
| 한 명의 팀원으로 일하는 이상 우리의 전문성을 가지고 팀의 해결책을 찾지 않으면 근본적인 해결책이 되기 어렵고 팀의 장기적인 성과 달성이 어렵다. 이에 대한 해결책으로는 ‘사업 도메인에 대한 관심’이다. | ||
|
|
||
| **팀 영향력** | ||
| 본인의 주 업무는 기본으로 수행하는 것을 바탕으로, 프로젝트에서 배운 사실을 팀원들에게 공유하거나 스터디에서 배운 내용이나 개발 방향성을 토론하는 것을 시작으로 영향력을 확장해 나갈 수 있다. | ||
|
|
||
| **컴포트 존** | ||
| 초기에는 도전적이었던 프로젝트는 결국 성공하게 되면 어느 시점이 지나서 그에 대한 챌린지가 줄어들게 된다. | ||
| 안정적인 업무들이 나쁜 것이 아니라 너무 이른 나이에 안주하게 되면 훌륭한 개발자와는 거리가 멀어진다. | ||
|
|
||
| **꾸준함과 개선** | ||
| 완벽한 개발자가 되기 위해 급하게 무리하기 보다는 “내가 계속 유지할 수 있는 한 두개의 습관부터 시작해서 경험을 통해 원칙을 세워나가는” 것이 중요하다. | ||
|
|
||
| **번아웃을 이겨내기** | ||
| 번아웃이라는 것을 어떻게 관리하느냐에 따라서도 개발자의 덕목을 잘 유지할 수 있는 중요한 포인트가 된다. | ||
| 번아웃을 꼭 경계하고 내 인생의 지속가능성을 고려하자. | ||
|
|
||
| ## 글로벌 리더십을 가진 프로그래머 되기 | ||
| 리더십, 프로그래머, 글로벌 등 각각에 가장 중요하게 영향을 미치는 것은 결국은 효과적인 의사소통이다. | ||
| 서주영님은 탁월한 의사소통 능력을 지닌 사람들의 소통 방식을 주의 깊게 관찰하고 롤모델로 삼아 개인적인 성장에 큰 영향을 주었다. 비슷한 맥락으로 커뮤니티 참여, 세미나 발표도 꾸준히 하며 소통하는 능력을 길렀다. | ||
|
|
||
| 영어에 대해서도 강조하셨다. 서주영님은 26살이라는 늦은 나이에 처음으로 외국인과 영어로 대화하기 시작했지만 외국인과 노출을 적극적으로 늘려 실력을 최대한 단기간에 키웠다. 나는 영국에서 5년 반을 살아본 경험 덕분에 그나마 다른 동급 주니어 개발자들에 비해 차별적인 장점을 가졌다고 생각하고 이를 잘 쓸 수 있도록 해야겠다. | ||
|
|
||
| ## 회사에서 나의 역할을 만들어나가는 법 | ||
| 주한나님은 “마이크로소프트”의 시니어 데이터 사이언티스트라는 직함으로만 보면 엘리트 코스와 순탄한 커리어가 있을 것만 같았다. 하지만 이것은 완벽히 틀린 추정이었고 이와 정반대의 길을 걸어오셨다. 본인이 처한 상황에서 최선의 선택을 하려고 했고, 회사에서는 자신이 잘 할 수 있고 다른 사람들이 기피하는 일을 먼저 맡으며 인정 받았다. | ||
|
|
||
| 생각보다 방법이라는 것이 다양하다. 정문으로만 들어가려고 하면 너무 힘들다는 것만 느낄 수 있다. | ||
| “모로 가도 서울만 가도 되고, 조금 늦더라도 원하는 방향으로 갈 수 있는 여러 가지 방법을 모색하면 된다.” | ||
|
|
||
| ## [논의 내용] | ||
| * 훌륭한 프로그래머의 정의에 대해서 고민해보았지만, 생각보다 딱 떨어지게 떠오르지 않습니다. 사람들마다 다르게 정의할 것 같은데, 본인이 생각하는 훌륭한 프로그래머란 어떤 사람인지 말해보면 좋을 것 같습니다. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 저는 세상에 있는 문제를 잘 관찰, 인식, 이해해서 그걸 컴퓨터 시스템으로 만들어야 겠다는 생각을 하고 실제로 그걸 실천할 수 있는 사람이라고 보고 싶습니다.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 내 해결법에 대한 장,단점을 명확하게 파악하는 분들을 보면 얼마나 많은 노력을 했을지 상상이 안되더라구요. 그런 분들을 보면 참 훌륭한 프로그래머라는 생각이 들었습니다. |
||
| * 이소영님의 ‘개발자의 학습, 성장에 관하여’에서 말하시는 가장 강력한 무기는 꾸준함과 사소한 습관들 중 루틴 찾기가 가장 와닿았습니다. 저는 1년을 조금 넘게 취준생으로 살면서 정말 꾸준하게 알고리즘을 풀어왔고, 하루를 시작하는 루틴으로 문제 몇 개를 꼭 풀고 다른 개발 학습을 시작했습니다. 그 결과 지금까지 그나마 무너지지 않고 지속적으로 달려올 수 있었고, 눈에 띄게 코테 통과율도 높아졌습니다. **다른 분들은 재직하시면서 현재 어떠한 루틴을 가지고 꾸준하게 실천하고 계시는지 궁금합니다.** | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 지금까지도 계속 하고 있는 루틴은 제 업무와 관련있거나, 제가 관심있는 시중에 나오는 모든 개발 서적을 전부 팔로잉 하는 것 입니다(매일하는 것은 아니고, 비정기적으로 한 1~2주에 한번씩은 보는 것 같네요) 예전에는 조금이라도 더 배우고 알고 싶어서 했었던게 지금은 습관이면서 취미(?)가 되었네요 (서점에 무슨 기술 서적이 나왔는지 보는걸 즐깁니다 ㅎㅎ)
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 책 읽는 루틴 정말 좋아 보입니다. |
||





There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
한마디로
문제해결력이 높은 사람으로 말할 수 있을 것 같습니다회사를 기준으로 범위를 좁혀 보면, 회사의 여러가지 문제들을 적절하면서도, 적당한 해결책으로 문제를 잘 해결하는 사람이 훌륭한 프로그래머라고 생각하는데요
결국 프로그래머가 회사에서 하는 일들을 추상화 해서 생각해보면, 문제 상황을 정의하고, 그 문제를 잘 푸는 것으로 볼 수 있기 때문에, 결국엔 문제해결을 잘하는 프로그래머가 훌륭한 프로그래머라고 볼 수있다고 생각 합니다