ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • DEVGROUND JUNIOR 2019 참여 후기 (3)
    IT행사 2019. 12. 19. 14:12

    DEVGROUND JUNIOR 2019 참여 후기 (1) 

       개발자가 갖추어야 할 9가지 기술 / AI: 막막해하는 당신에게 

    DEVGROUND JUNIOR 2019 참여 후기 (2)

       내가 주니어 개발자 때 알았더라면 좋았을 것들 / 성장을 바라는 웹 프론트엔드 개발자를 위한 제언

    DEVGROUND JUNIOR 2019 참여 후기 (3)  - 현재 글

      오픈소스 속에서 성장하기  / 절망 드리븐 성장: 함께 일하고 싶은 개발자가 되기까지

    DEVGROUND JUNIOR 2019 참여 후기 (4)

      개발자도 DB 모델링을 알아야 할까요? / AI/데이터 시대를 사는 개발자를 위한 생존 가이드


    오픈소스 속에서 성장하기

    강대명 유데미

    다음으로 '혀로그래머' 강대명 님의 세션이 진행되었다. 강대명 님은 '지금부터 하는 이야기는 꼰대의 이야기이니, 적당히 걸러들으세요.' 라며 분위기를 환기시켜주셨다. 데카르트의 명언 "나는 생각한다 고로 존재한다"를 인용하며 자신의 말도 의심하며 들어줬으면 좋겠다고 하셨다. 

     

    주니어 시절에는 "어떻게 해야 성장할 수 있을까?"를 고민하고,

    중니어 시절에도 "어떻게 해야 성장할 수 있을까?"를 고민하고, (중니어라는 표현이 재밌다😆)

    시니어 시절에는 "내 성장이 멈춘 건 아닐까?"를 고민한다고 한다. (현재 강대명 님의 고민!)

     

    우리는 언제 성장한다고 느낄까? 

     - 남이 짠 코드가 쉽게 이해될 때

     - 모르는 게 자꾸 생길 때 

     - 작년에 내가 짠 코드를 보면서 욕할 때

    반대로 우리는 언제 정체되어있다고 느낄까?

     - 작년에 내가 짠 코드가 이해 안 될 때..

     

    성장을 위한 방법?

     회사를 다니고 있다면 회사 업무를 통해 성장하는 것이 가장 좋고, 공부(책 읽기, 콘퍼런스 참여)나 토이 프로젝트를 하는 것도 추천해주셨다.

     

    오픈소스에 도전한 이유?

     강대명 님은 오픈소스를 시작한 이유가 호기심이면 좋겠지만... 사실은 퇴직 후 줄어드는 통장잔고가 가장 큰 이유였다고 한다.

     공부를 하려고 보니 필요한 솔루션도 없고.. 재취업을 하기 위한 자신감을 갖기 위해 오픈소스에 뛰어들게 되었다고 한다.

     

    Redis

     Redis는 CentOS5.3에서 빌드되지 않는 문제점이 있었고, 이것을 고치는 것이 첫 패치였다고 한다.

     이러한 빌드 문제를 고치기 위해, 아래와 같은 방법으로 접근하셨다고 한다.

      1. 재현하기

       - 정말로 CentOS 5.3에서 안되는가?

       - 나만 안 되는 건가 다른 사람도 안 되는 건가?

       - 클라우드 서버나 VirtualBox에서 재현 환경을 구축해보자.

      2. 왜 안되는지 이유를 확인

       - linux에서 사용하는 sync_file_range는 특정 리눅스 커널 버전(2.6.17) 이상에서만 동작한다

      3. 해결 방법 찾기

       - 해결 방법을 찾았는데, 정말로 해결되었는가?

       - 더 간단하고 좋은 방법은 없을까?

      4. 수정 후 테스트

     

     이러한 과정을 거치고 나니 배운 점이 있다고 한다. 해당 주제에만 집중하고 다른 것(오타, 띄어쓰기, 다른 문제들)은 고치지 말라는 것이다.

     또 Redis를 하면서 다양한 자료구조, HashTable, SkipList, 남들이 올리는 이슈들에 대해서 배울 수 있었다고 한다. 

     오픈소스에 사용된 기술에서 이 분야의 여러 문제점을 미리 경험해 볼 수 있다.

     

    오픈소스는 어떻게 접근해야 할까?

     유명한 오픈소스(Spark, Kafaka..)는 남들에게도 매력적이기 때문에 어렵고,

     큰 프로젝트는 알아야 할 것이 너무 많다. 

     내가 사용하는 오픈소스 중에서 고르는 것이 좋다고 한다.

     

     내가 사용하는 오픈소스의 장점

       - 장애를 많이 겪어볼 수 있다.

       - 배경지식을 좀 더 많이 알 수 있다.

       - 계속 사용함으로써 변화를 따라가기 쉽다.

       - 오픈소스 학습이 업무지식에 도움이 된다.

       - 관심 없는 프로젝트보다는 길게 참여할 가능성이 높다.

     

     오픈소스를 고를 때 Check Point

       - 나에게 충분히 익숙한 언어로 구현되어있는가?

          (Kafka를 선택했다면 Scala/Java, Kubernates를 선택했다면 GO)

       - 기발 지식을 충분히 이해하고 있는가?

          (Linux라면 운영체제 지식, Spark라면 분산처리 지식)

       - 커뮤니티는 활발한가?

     

    오픈소스를 통한 세속적인 장점

     오픈소스를 공부하다 보면 업무에 필요한 툴에 대한 이해도가 높아진다. 

     혹은 취업이나 이직을 할 때 내가 이 부분을 이해하고 있다는 근거가 되어준다.

     

    좋은 오픈소스 컨트리뷰션 플로우

     업무로 특정 솔루션 사용 -> 사용 중에 버그나 기능 필요 -> 버그 수정/기능 구현 -> 업스트림에 반영

     

    강대명 님은 주니어 개발자들에게 주는 조언과 함께 세션은 마쳤다. 주니어 시기에는 성장에 대한 갈증이 많고, 성장을 잘하지 못하는 것에 대한 고통이 있을 테지만 여유를 가지고 성장하는 것이 좋다는 조언을 해주셨다. 앞으로 최소 30~60년은 더 개발할 텐데, 1~2년 늦는다고 급할 것이 없다고 한다.

     

     

    Q&A

    Q. 리모트 근무를 시작하는 팁이 있다면?
    A. 오픈소스 경험이 도움이 된다. 그전에, 내가 리모트 군무에 맞는 사람인지 고민해보는 것이 필요하다. 리모트 근무를 하게 되면 기술적인 토론을 할 수 없음에 대한 외로움이 있다.
    Q. 오픈소스의 규모가 너무 커서 겁먹는 경우가 있다. 오픈소스를 어떻게 파악하면 좋을지?
    A, 처음 봤는데 다 이해될 수는 없다. 배경지식을 추가로 공부하고, 사용하면서 불편한 부분에 집중을 하면 좋을 것 같다.

     

     

     

     


    절망 드리븐 성장: 함께 일하고 싶은 개발자가 되기까지

    이소영 뱅크샐러드

     뱅크샐러드의 이소영 님은 2018년에 웹 공부를 처음 시작했고, 2019년도에 입사한 1년 차 개발자라고 한다 구글링 하다가 이소영 님의 발표 슬라이드를 몇 번 본 적이 있는데 이렇게 연차가 적은 분인 줄은 몰랐다. 나랑 비슷한 연차인데.. 정말 대단하신 것 같다. 멋짐 뿜뿜!!

     이소영 님은 '절망 드리븐 성장', 절망이 주도하는 성장을 겪으면서 함께 일하고 싶은 개발자가 되기까지의 과정을 공유해주셨다.

     

    웹 공부 시작!

     이소영 님은 웹 공부를 시작하고, 어려워 보이는 스펙을 구현하면서 무엇이든 짤 수 있을 것 같은 자신감이 생겼다고 한다.

     그러나 2달 후, 다른 사람과 협업을 시작하면서 첫 번째 절망에 빠졌다.

     코드에 규칙이 없었기 때문에 어떤 기준으로 만들어졌는지 기억이 나지 않고, 다른 사람에게 코드를 설명할 수 없었던 것이다.

    첫 번째 절망 : 화면 구현에 심취해서 협업이 불가능한 코드를 만들었다.

     이소영 님은 첫 번째 절망을 통해, 모든 코드에는 이유가 있어야 한다는 것을 배웠다.

     

    진짜 뛰어들어보니..

     이소영 님은 뱅크샐러드에서 인턴생활을 시작하게 된다. 실전에 뛰어들어보니, 배워야 할 것들이 너무 많았다. 

     Clean Architecture, DI, Rx.js, TypeScript, git flow....

     하지만 아는 것은 없었고, 내 길이 아닌가라는 고민에 빠졌다고 한다.

    두 번째 절망 : 도저히 이해할 수 없어서 한 줄도 못 짜겠다...

     이소영 님은 스스로 작전회의를 해보았다. "이해했다"라는 것은 무엇일까? "이해했다"라는 것의 정의를 세우는 것부터 시작했다.

     이해라는 것은, 정리하는 것이다. 정리란, 남에게 설명할 수 있는 정도.

     이소영 님은 가상의 인턴사원, "뱅그래"를 만들었다. 인턴사원이 아무것도 모르는 상태로 들어왔다고 가정하고, 그를 위한 자료를 작성했다. 회사의 Git Setting, 기존 구조 (Clean Architecture), 만났던 오류 등등...

     정리해서 공유하니, 좋은 피드백도 많이 받을 수 있었다고 한다.

     

    개발자란? 성장이란?

     다시, 성장에 대한 고민이 시작되었다.

    세 번째 절망 : 고여있지 않기 위해서 나는 어떻게 해야 할까?

     이소영 님은 "성장은 떠먹여 주지 않는다"라고 생각한다고 한다. 

     업무를 하는 것이 곧 성장을 뜻하지는 않는다. 

     반복적인 업무나, 하드코딩이나, 버그 등을 흘려보내거나 Copy & Paste 하는 것은 그 단계에 머무르는 것이라고 한다.

     업무가 곧 성장이 되려면, 반복적인 업무를 자동화할 수 있는 방법을 생각해보고, 더 나은 패턴을 생각해보고 그것을 팀 내에 공유하여 '모두의 성장'으로 이끌어나가야 한다고 한다.

     우리 팀이 쓰는 구조나 기술 스택에 당연한 것은 없다. 항상 더 나은 것을 고민해봐야 한다. 일례로 이소영 님은 팀 내에서 Clean Architecture를 사용했는데, 그 구조가 만능이라고 생각하지 않고 더 나은 구조를 만들었다고 한다.

     이소영 님은 이 내용과 함께 Simple Software라는 책을 추천해주셨다.

      https://book.naver.com/bookdb/book_detail.nhn?bid=15653089

     

    심플 소프트웨어

    100년 뒤에도 유용할 소프트웨어 설계 원칙 & 프로그래머의 바른 길!Google의 코드 건강(Code Health), 즉 코드의 가독성, 안정성, 단순성, 유지보수성은 어떻게 개선되어 왔을까? 오픈소스 버그질라(Bugwilla)는 어떻게 침체기를 벗어나 다운로드 수를 10배 이상 늘렸을까? 그 중심에는 이 책의 저자 맥스-카넷 알렉산더가 있다. Google의 기술 책임자로서, 버그질라 프로젝트의 수석 아키텍트로서 활동하면서 얻은 통찰과 깨달음을 이 한

    book.naver.com

     이소영 님은 회사 생활을 하던 중, 동료 개발자의 '함수형 유틸'에 대한 발표를 듣게 되었다. 

     엄청난 발표 내용에 감탄하고, "좋은 코드"가 무엇일까 고민을 다시 하게 되었다고 한다.

     

     이소영 님께 선배 개발자분께서 좋은 코드에 대한 이야기를 해주셨다고 한다.

     "좋은 코드는 각 페이지를 이루는 코드가 책처럼 읽혀야 합니다.

      다음 페이지로 넘어갈 때, 다음 장을 읽는 것처럼 흐름대로 읽혀야 합니다."

     

    네 번째 절망 : CORE(깔끔한 코드를 짜는 능력)은 어떻게 높일 수 있을까?

     이소영 님은 CORE능력을 높인다는 추상적인 목표에서, 좀 더 구체적인 목표로 발전시켰다.

      1. 내 PR은 내가 다시 보자.

      2. 코드 리뷰를 열심히 하자. 동료의 코드는 배울 점이 많다.

     

     

     이렇게 이소영 님의 네 가지 절망이 끝났다. 마지막으로 이소영 님은 '내가 하는것과 하지 않는것'을 이야기해주셨다.

     

    내가 하는 것

      1. 기록 또 기록

        이소영님의 Github

        이소영님의 블로그

      2. 공유

        발표를 하기 위해 준비하는 과정에서 성장할 수 있다고 한다. 

        내가 아는 무엇인가를 배출하기 위해 조금 더 들여다보게 되고, 그러는 과정에서 놓친 부분도 찾게 된다고 한다.

        발표에 대한 좋은 글

     

    내가 하지 않는 것

      - TDD

         Test Driven Development가 아닌 Twitter Driven Development를 뜻한다.

         Twitter 등 SNS에는 하루에도 몇 개씩 새로운 기술에 대한 이야기가 쏟아진다. 왠지 다 해내야 할 것 같은 기분이 들지만, 꾸준히 소화하기는 어렵다. 그러므로 이소영님은 지금 다루는 기술에 집중하고, 새로운 기술에는 약간의 관심만 두기로 했다. 신기술이 충분히 검증된 뒤에 도입해도 늦지 않는다고 생각한다고 한다. 지식의 홍수에서 오는 초조함은 곧 불안감이 되고, 불안감은 곧 무력감이 되었다. 이는 잘 되던 일도 안되게 한다.

     

     이소영님은 성장에 대한 기준을 이야기하며 세션을 마무리했다.

     언제 한 단계 성장했다고 말할 수 있을까? 

     실패했다면, 그 실패가 반복되지 않을 때. 좋은 것이 무엇인가에 대한 질문의 나의 기준이 많아질 때 이소영 님은 성장했다고 느낀다고 한다.

     

     

    Q&A

    Q. 코드 리뷰에 단점이 있다고 생각한다. (리더가 원하는 방식으로 따라간다던가 하는 단점).
        팀 내에서 어떤 코드리뷰 방식을 사용하는가?
    A. 아직까지 코드 리뷰의 단점을 느껴보지는 못했다. 다만, 서로 바쁘다보니 코드리뷰 자체가 잘 이뤄지지 않는 문제점이 있었다. 
        Pull Reminder 등으로 매일매일 코드 리뷰를 해야 한다는 알림을 받는 방식을 사용하기도 했다.
        가장 중요한 것은, 팀 내에서 코드 리뷰를 하나의 업무로 인식해야 한다.
    Q. 연차가 적은데, 발표를 시작하게 된 계기/기회는?
    A. GDG 라이트닝 토크 등 작은 자리에서 작은 것을 공유하겠다는 마음으로 시작했다. 그렇게 시작했던 발표를 한 단계 한 단계 더 많이 하게 되었다.

     

    댓글

Designed by Tistory.