본문 바로가기
Book & Lesson

[책] 더 나은 프로그래머 되는법 부록.국내 개발자 8인의 이야기

by 카프리썬_ 2024. 5. 17.
728x90
728x90

 

아래 글은 <더 나은 프로그래머 되는법>을 읽고 요약한 내용이며 개인적인 생각이 담겨있습니다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.


 

    미래기술의 열쇠, 생성형 AI를 활용한  프로그래머 - 베어로보틱스 염재현 

    생성형AI때문에 더이상 주니어 엔지니어가 필요하지 않을수도 있다. 

    기존에 하던 일들이 생성형AI로 대체가 된다. 

    생성형AI에게 핵심역할을 맡기던지, 부가적인 작업을 맡기는지 

    아이디어를 내는 과정은 전자를 활용하지만, 후자의 방식을 추구해야한다. 

    부가적인 작업은 어떻게든 동작하는 코드를 작성하는 것. 이게 주니어 개발자의 주된 업무. 

     

    생성형AI시대에 개발자들이 테스트 주도 개발을 해야한다. 

    테스트 코드를 작성하고, 그 테스트를 통과하는 구현코드를 함께 작성해야한다.

    아무리 AI라고 한들 자연어를 이용해서 어떻게 동작해야하는지 정확하게 명시하기 어려운점에서 근본적인 한계가 있다.

    원하는대로 제대로 작성이 되었는지 확인하는건 사람이 해야할일

     

    소프트웨어 서비스들이 부품처럼 활용하기 쉬워지면서 더 큰 그림에서 소프트웨어를 설계하는 것이 중요해졌다.

    회원가입, 로그인도 직접 구현할 필요 없이 서비스의 핵심에만 집중하면 된다. 

    어떻게 이 부품을 잘 가져와서 좋은 구조로 붙이는지, 부품의 효율과 비용을 고민하는게 더 중요하다.

     

    환경이 바뀌어도 기본적인 개념과 사용자에 대한 이해가 있어야한다는 점은 변함이 없다. 

     

    훌륭한 프로그래머이자 팀플레이어 되는 법 - 토스 진유림 

     

    코드작성은 프로그래머가 해야할일중 하나.

    연차가 올라갈수록 코딩 자체보다 코딩 외 개발업무의 비율이 커진다. 

     

    타인의 팀플레이어 다운 행동을 수집했다.

    1.근본문제를 먼저 파악하고, 전문성을 더해라. 맥락을 파악하고 전문성을 더해 해결책을 보강해라. 

    2.의존관계를 명료하게 드러내고, 듣는이가 궁금한 내용에 대한 해결책도 함께 전달해라. 

    3.말하지 않은 것을 알아내라. 

    팀원에 대한 걸 알아내기 - 역량체크인 주간미팅에 회고

    최근에 해본 노력 / 못하고 있어 아쉬운 것 / 내 업무를 느리게 만드는것

    팀장에 대한 걸 알아내기 - 상황을 떠올리기 쉽고, 구체적인 행동을 묻는 질문을 던져라. 

    "이런 문제가 있는데 제가 할수있는일이 있을까요?" 대신 "이런 문제가 요즘 있다고 느껴지는데, 팀장님은 어떠세요?"

     

    업무를 전후에 물어보면 좋을 질문

    - 근본문제가 무엇인가?

    - 어떤 관계가 얽혀있는가?

    - 그들이 말하지 않는 속마음은 무엇인가? 

     

    한달간 동료의 멋진행동 3개를 모아봐라. 관찰하고 객관화 하는것만으로도 큰 의미가 있다. 

    지금 생각난김에 일을 하면서 생각난 동료들의 멋진행동 3가지
    1. 일의 '끝'을 중요하게 생각하는 팀장님.
    일이 마무리가 될 때 쯤 끝의 기준을 정해주신다. 여기까만 하고 넘어가자. 이 목표까지만 달성해서 v1으로 끝내고 다음 v2로 넘어가자. 
    계속 붙잡고 늘어지거나, 결국 끝에가서 늘 마무리 못하고 흐지부지하는 일들이 많았는데 감사하게도 이런 가르침을 통해 배우고 있다.
    2. 매너의 정석으로 의사소통 하는 법을 알려주신 시니어 개발자님.
    상대방에게 기분 나쁘지 않게 부탁하고 자신의 감정도 드러내지 않으며 원만한 의사소통, 깔끔한 대화법이 멋지시다. 
    상대방을 향한 말투와 언어에 자신의 기분을 섞는 사람이 종종 있는데, 훌륭한 시니어 덕분에 나는 그렇지 않기 위해 노력하고 있다. 
    3.하고 싶은 일에 아직도 눈이 초롱초롱하게 빛나는 동료.
    나와 비슷한 연차임에도 불구하고 아직까지 하고 싶은 게 많고 궁금한게 많은 모습이 멋지다. 나도 저럴때가 있었지 하면서 괜히 아련해지지만 이렇게 끊임없이 자극을 늘 받을 수 있는 동료가 있어서 감사하다. 

     

    개발자의 학습, 성장에 관하여 - 토스 이소영

    발자의 성장이란 무엇인가? 내가 성장하고 있는지를 어떻게 측정할수 있을까?

    이 질문에 대한 본인만의 답을 찾는것이 성장의 첫걸음이다.

    성장에 대한 최초 정의를 나만의 관점이 많아지는것이라고 내렸다. 경험에 따라 성장에 정의가 바뀔수도 있다. 이런 과정중이다. 

     

    무엇을 학습해야할까? 

    학습을 위한 학습이 아니라 문제해결을 위한 학습부터 시작하라. 

    업무나 프로젝트를 하다보면 시간이 부족해서 완전히 이해는 되지 않았지만, 해결되는 방법을 적용해서 해결하는 경험이 있다. 

    혹은 자세한 원인분석보다는 해결에 초첨을 맞춰야하는 경우도 있다. 

    이런 순간을 지나치지 않고 완전히 이해될때까지 학습의 꼬리를 물다보면 넓은 범위의 지식을 습득할수 있고, 이러면 온전히 내것이된다.

     

    무엇에 집중하지 않을것인가?

    쏟아지는 모르는것들을 전부 익힐 필요도 없고, 할수도 없다.

    내가 소화할수 없는 범위 이상 욕심내면 어떤것도 소화할수없다. 동시에 여러개의 영역을 깊이있게 익힐수는 없다.

    집중하지 않을영역에 과감하게 무관심해야 집중할 영역에 확실히 집중할수 있다.

     

    가장 강력한 무기는 꾸준함이다. 

    어느한 분야를 잘하게 되는 과정에서 반드시 필요한 능력은 꾸준함이다.

    개발자도 마찬가지다. 오늘하루10시간을 열심히 했다고 하루만에 성장하지 않는다. 

    꾸준함은 강력함 만큼이나 실천하기 어렵다.

    억지로 꾸준히 하려고 하는것은 대부분 실패했다.다른 우선순위에 밀리지 않을 동기부여를 주는 일이 꾸준히 하기 쉬운일이다. 

    꾸준히 하는게 중요하다고는 늘 생각했지만,왜 꾸준히 하기 어려운지는 생각해본적이 없는것 같다. 
    생각해보니 정말 억지로 꾸준히 하려고 하는건 정말 실패했다.
    그런데 그냥 내가 하고싶어서, 재미있어서 했던 것들은 꾸준히 됐다. 
    그냥 하다보니 어느샌가 꾸준히 하고 있게 된것이다. 블로그도 그중 하나이다.

     

    문제해결에 집중하다보면 모든 코드와 기능이 비용이라는 사실을 간과한다.

    문제를 해결하는 것보다 중요한것은 문제를 해결해야하는지, 해결했을때 비용이 오히려 더 커지지 않는지를 생각해보는 것이다. 

     

    어떻게 하면 좀더 잘할수 있을까? 를 고민하라

    모든개선의 시작은 '측정'이다. 어떤 단계에서 시간을 많이 쓰는지. 왜 그렇게 오래걸렸는지 진단해봐라.

    집중이 덜 되는 시간에 할일, 집중이 잘되는 시간에 할일을 나눠서 집중력을 높여라.  

    측정과 기록의 힘은 생각보다 굉장하다. 
    절약의 시작은 가계부 작성인것 처럼 실제로 내가 어디에 어떻게 시간을 사용하고 있는지, 얼마나 시간을 낭비하고 있는지를 수치적으로 측정해서 직접 두 눈으로 봐야한다. 이번주 나의 일상 타임 트래커를 한번 해봐야겠다. 

     

    데일리 루틴을 만들어라. 하루를 예측한대로 보낼수 있다. 반복되는 하루 루틴이 심적으로 안정감을 준다. 

    개발 루틴을 만들어라. 시간이 많이 소요되는 부분은 설계에 대한 고민이였다. 효율성을 위한 루틴을 찾아라. 

    잘읽히는 코드란 무엇인가? PR을 하기전에 셀프 코드 리뷰를 시작해라.

    요즘 루틴의 중요성을 깨닫는다.
    엠비티아이 극P인데도 불구하고, 오늘 하루가 내가 예상한대로 흘러갔을때 만족감을 느낀다.
    나는 부끄럽지만 아직도 PR을 하기 전에 간간히 오타를 내거나, 실수하는 부분이 잦다...
    이걸 PR을 하기전 셀프리뷰 루틴을 만들어서 해결 해볼까 한다. 기본적으로 PR하기 전에 제대로 검토해보는건 당연하겠지만, 코드의 구조나 읽기 쉬운지까지 셀프리뷰하는 수준으로 습관을 들여야겠다.

     

    코드를 작성하기 전에 방향성을 먼저 잡아라.

    구조를 먼저 생각하면 시간을 아낄뿐 아니라 구현한대로 생각하지 않고, 생각한대로 구현할수 있다.

    좋은 코드를 빠르게 작성하려면 모순적이게도 코드를 가장 늦게 작성하는 것이다. 

    냅다 코드부터 작성하지 말고, 우선 생각하고 큰틀을 먼저 잡는게 정말 중요하다.
    처음에 방향성을 제대로 잡고 나아가야 나중에 시간낭비 하지 않을수 있다. 
    하지만 내가 신입인 시절엔 방향성도 보고하지도 않고 끝에가서 다시 뒤엎는 케이스가 많았던것 같다.
    지금 생각해보면 정말 비효율적으로 일했나 싶다....요즘에서야 느끼지만 시간은 정말 없다. 시간 좀 아껴쓰자;;ㅋ

     

    무조건 정답이라거라는 생각은 무조건 틀리다는 생각만큼 위험하다.

    두려움 속에서 용기 있게 수정해라. 두려움이 있다면 두려움을 없앨수 있는 장치를 만들어라. 

    중요한것은 팀과 코드가 정체되지 않도록 계속 문제를 발견하고 해결해나가고자 하는 의지이다.

     

    개발자로써 지속적인 성장과 성공을 위한 전략 - 어센트 코리아 진나영 

    개발자로서의 성장은 두가지 축에서 이루어져야한다.

    1.지속적인 학습을 통해 기술의 최전선에서 경쟁력 유지

    2.기본기를 꾸준히 강화하는것. 

     

    기술 커뮤니티에 참여해서 지식의 바다에서 항해해라.

    경험이 많은 멘토를 찾아 개발자로서 성장 여정에서 나침반을 가져라. 

     

    결국 해내는 개발자 - 비마이프렌즈 서지연 

    테크업계에 대한 엄청난 상승과 하락. 그리고 새로운 기술의 등장은 겨우 4년안에 일어난 일.

    변화의 속도가 너무 빠르다. 하지만 이러한 현상은 계속해서 나타났고, 이 변화의 속도는 더 빨라지고 있다. 

     

    결국 개발자가 된다는 것은 평생 공부해야한다는 뜻이다.

    어라..사주에서 평생 공부해야하는 팔자라던데.. 아무래도 나..천직인가봐 >< 

     

    훌륭한 개발자는 주변상황에 끌려다니지 않고, 자신만의 길을 묵묵히 걸어가며 문제 해결에 집중하는 사람이다.

    기술은 도구이고, 개발자는 문제를 풀어내는 해결사이다. 

    해결사는 도구를 적절히 잘 사용할뿐이다. 더 나은 방법이 잇다면 새로운 방법으로 결국 해내는 개발자가 훌륭한 개발자이다. 

     

    결과물에 대한 명확한 설정이 없으면 현재 위치를 알 수가 없다.

    정복해볼거야! 마스터할꺼야! 라는 목표보다는 리액트로 대시보드를 만들어서 배포까지 만들어보겠다. 

    테스트 코드를 잘 짜겠어! 라는 목표보다는 테스트 커버리지를 70%로 올리겠다. 

    측정가능하고 눈에 보일수 있는 목표를 설정해야한다.

    굉장히 찔렸다. 딱 그대로 '테스트 코드를 잘 짜겠어!' 라고 목표를 설정했기 때문이다. 그래서 구체적으로 목표를 다시 설정하자면 'QA이슈가 하나라도 안생기도록, 스테이징 테스트 코드 자동화를 적용해서 배포까지 하겠어' 
    이번에 prod 데이터으로 개발했는데, staging에서버그가 많이 발견되었다...

     

    큰 목표를 이루는 유일한 방법은 아주 작은 일의 반복이다.

    한번에 모든것을 이루는 일은 없다. 오히려 한번에 이루려고 목표점만 바라보면, 큰 목표에 압도당해 위축되고 미루게 된다.

    이런사람 게으른 완벽주의자. 할거면 제대로 해야한다는 생각에 일을 미루고, 지나치게 높은 기준을 세워 시간부족이슈.

    처음 시작은 분명 성공할수 밖에 없는 작은것들로 시작해본다.

    이렇게 쌓아가는 작은 성취가 내가 어떤 방향으로 가고 있는지, 앞으로 어떤 방향으로 나아갈지에 대한 이정표가 된다. 

    '해봤으니 됐어'가 아니라 '해냈으니 됐어'가 되도록 계속해서 성과물을 만들어내야한다.

     

    그저 '안다'라는 지식의 가치는 계속 떨어진다. 어차피 AI, LLM이 다 알고 있기 때문에.

    지식보다 경험과 기술이 더 귀중한 가치. 문제를 해결하고, 그 의미를 해석하고, 지식을 독창적인 결과로 만들어내는 능력이 중요하다.

     

    꾸준하게 결과를 내는 사람은 결국에 해내는 사람이다. 

    기술과 시장은 변할수 있지만 사람의 태도는 변하지 않는다.

     

    실패를 실패로 만들지 않기 위해서는 본인에게 너그러워야한다. 

    그럴수 있지, 오히려 지금 실패해서 다행이야. 조금 부족한 자신을 인정해야한다. 

    내가 나에게 너그럽고 다시 이러설 용기를 준다면 우리게에 성장할기회는 무궁무진하다.

    인정. 굉장히 중요한 마음가짐이라고 생각한다. 
    나도 신입때를 생각해보면 부족한 나를 인정하기가 어려웠다. 그래서 계속 자괴감에 빠져 괴로워하기만 했다. 
    근데 지금 생각해보면 신입이 잘하는게 오히려 이상한건데 왜이렇게 힘들어했는지 모르겠다.
    당연히 그럴수 있고, 다음부터 안그러면 된다. 나에게 지나치게 엄격하게 생각하지 말고 귀엽게 봐주도록!

    개발자 커리어에서 한번쯤 생각해보면 좋은 5가지 - 볼트업 박순영

    개발자입장에선 요구사항을 제한된 리소스로 구현해야되서 타 팀원들과 소통할때 방어적으로 대응하기 쉽다. 

     

    이에 대한 첫번째 해결책이 관심이다. 즉 사업자 도메인에 대한 관심

    이런 주도적인 관심으로 타 팀원이 그 도메인에 대해 고민하는 부분과 경험을 관찰할수 있다.

    도저히 관심이 없는 도메인이라면 2가지 선택

    팀이동이나 업무 환경을 바꾸는 방식과, 도메인에서 약간 거리는 있지만 연관성이 있는 비교적 흥미있는 지점 선택하는 것.

     

    두번째 해결책은 영향력이다. 영향력을 확장해라. 

    팀원들의 업무 시간을 줄여주거나 편의성을 제공해주면서 영향력의 범위를 넓혀가면 

    니즈를 파악하고 필요한 요구사항을 바로 구현해내는 연습을 하는것이다. 

     

    안정적인 업무들이 나쁜것은 아니지만, 이런 환경에 너무 이른 나이에 안주하는것은 

    마치 돼지 저금통에 자금이 충분히 모이지 않았는데 저금통을 깨는 상황과 비슷하다.

     

    내가 계속 유지할 수 있는 한두개의 습관부터 시작해서 경험을 통해 원칙을 세워나가라. 

    원칙이란 코드구조에 대한 가장 중요한 원칙을 하나 정한다거나, 같은 실수를 하지 않기 위해 기록을 한다거나 등 

    예를 들면. 실패일기. 내가 잘못한거만 기록하는게 아니라 반복하지 않으려면 어떤 습관을 준수하면 좋을지 기록.

     

    번아웃을 어떻게 관리하는 방법 

    조직이동이나 이직으로 환경을 바꾸거나, 일생각으로부터 완전히 벗어나서 할수 있는 취미활동을 주기적으로 하는것.

    아예 다른분야의 수업을 듣고 공부하거나, 몸을 움직이는 활동으로 권태감에 빠지지 않도록 노력.

    번아웃 관리도 좋은 프로그래머가 되기 위한 하나의 역량이라고 생각한다. 
    괜히 면접에서 취미생활을 물어보는게 아니다. 그럼에도 나는 아직도 뭐하나 즐기는 취미생활이 없다..(아 글쓰기요?)
    너무 일에 몰입하고 그 일만 생각한다고해서 일이 그 어떤 어려움이 없이 순탄하게 진행되는건 아닌것 같다.
    심지어 그렇다고 더 빨리, 더 많이 성장하는것도 아닌것 같다. 그냥 몸만 망하지고 정신만 피폐해지는것 같다ㅜㅜ

     

    글로벌 리더십을 가진 프로그래머 되기 - 구글 서주영

    현재 프로그래머는 단순히 지식을 습득하고 기술을 활용하는 역할에 만족할수 없다. 

    다양한 문화적 배경을 가진 사람들과 주도적으로 협업하여, 개인이 일하는것보다 더 좋은 결과를 만들어내며 혁신을 이끌어내야한다. 

    즉, 글로벌 리더십을 가진 프로그래머가 되어야한다. 

     

    효과적인 의사소통은 중요하다. 

    다양한 상황에서 자신의 생각을 명확하고 논리적으로 표현할줄 알아야한다. 

    기술적인 지식을 상대방의 이해수준에 맞춰 효과적으로 전달할수 있어야한다.

    또한 요구사항을 명확하게 파악하고, 다른사람의 의견을 존중하는 태도도 필수적이다.

    의사소통 잘 하는 사람은 기술적인 지식과 이해수준을 상대방에 맞춰 배려하는 사람이라고 생각한다.
    혼자 이해하는건 쉽지만, 내가 이해한걸 상대방에게 설명하는건 정말 어렵다.
    대부분의 대화가 어려운 이유는 상대방의 이해수준까지 생각하지 못해서 그렇다고 생각한다.  
    보통 말하는 사람은 자기가 이해한거를 뱉어내려고만 한다. 상대방이 이해하는건 상대방 몫이라고 생각한다.
    하지만 상대방의 상황과 수준을 맞춰서 배려하는 것이야말로 의사소통을 잘할 수있는 방법이 아닐까 싶다.

     

    각자의 입장을 파악하고 그들의 관점에서 설득력 있는 의견을 제시하는 능력은 주니어에서 시니어로 성장하는 과정에서 중요하다.

    조직에서 원하는 것을 잘 이해하고, 조직의 목표를 이루기 위해 자신의 업무가 얼마나 중요한지 소통하는데 능하다. 

    타인의 의견을 존중하고, 다양한 관점을 가진 사람들을 포용하고, 명확하고 효과적인 의사소통을 통해 협력을 이끌어내는 핵심능력.

    구글에서는 의사소통도 핵심 역량 지표라고 한다. 
    개발자 뿐만 아니라 그냥 의사소통은 협업을 하는 어떤 직군이건 중요할것 같다. 
    내 의견도 명확하게 전달해야하고, 상대방의 의견도 존중하면서, 같이 협업해나가는게 모든 일에 통용되는것 같다. 

     

    영어소통에 익숙해야한다. 

    업무 수행에 도움이 되는선에서 영어로 효율적으로 의사소통을 할수있는 능력까진 갖출필요가 있다. 

     

    리더십 역량이 중요하다.

    기술적인 전문성을 뛰어넘어 프로젝트의 목표와 방향성을 명확하게 제시하고,

    팀원에게 동기부여하며 프로젝트를 성공적으로 이끄는 영향력. 

    리더의 관점에서 사고하면 리더십을 가장 쉽게 익힐수 있다. 

    나의 현재 위치가 아니라 임원이라면 어떤 판단을 내릴지 먼저 생각해보는것이다. 

     

    글로벌리더십은 어느날 갑자기 형성되는것이 아니다. 

    의식적이고 지속적인 노력과 깊은 고찰, 그리고 꾸준한 자기개발로 점진적으로 향샹되는 능력이다. 

     

    회사에서 나의 역할을 만들어나가는 법 - 마이크로소프트 주한나

    보통 어떤일을 하면 이런저런 자격을 갖춰야한다고 생각한다.

    하지만 좋은 대학교나 학위는 내가 좋은 개발자임을 증명하기위해서 편리한것이지 나를 좋은 개발자로 만들어주지는 않는다.

     

    자리가 사람을 만드는게 아니라 사람이 자리를 만드는 케이스가 더 흔하다.

    원하는 사람을 찾아 고용하기 보다 기존 팀원들이 원하는 사람이 되도록 만드는게 더 쉽다. 

     

    모로 가도 서울만 가도 되고, 조금 늦더라도 원하는 방향으로 갈수 있는 여러가지 방법이 많다. 

     

    728x90
    반응형