[웨비나] ‘스타트업 개발자, 회사와 함께 성장하기 by 이종립’ 정리 및 후기

트위터에서만 보던 그 종립님..?!!

정리

(+ 중간부터 참여해서 앞부분이 잘렸다.. 흑흑)

코드 리뷰

• [질문] 비슷한 사람들끼리의 코드리뷰도 괜찮은가?
  • 수준은 중요하지 않다!
  • 목표는 대화와 분위기, 더 나은 코드를 위한 것!!
  • 옆에 있는 동료와 잘 지내야 나중에 서로 도움을 주며 팀을 만들어 갈 수 있다.

BDD 테스트 코드

• 리팩토링을 확신할 수 없다 → 테스트 작성
• 테스트 코드 스타일 : 가독성 있는 BDD 스타일을 좋아함
• 주니어 개발자나 경험이 없는 분들은 굉장히 어려워 한다. 시작을 모르기 때문에..
  • 어떤 주제로 해야 할지 모름
  • 스타일을 제한하기 때문에 고민을 적게 하고 표준적인 테스트를 반복적으로 만들 수 있다는 장점이 있다.
  • 테스트하고자 하는 메소드를 describe로 삼는다.
    • 해당 메소드가 어떤 환경에서 작동하는가 → 컨텍스트
  • 계층형으로 짜면 빠진 컨텍스트를 쉽게 찾아볼 수 있다.
• 테스트와 리팩토링 중 무엇을 먼저 하는가?
  • 테스트를 먼저 작성 → 모두 통과하도록 함 → 리팩토링 후 테스트 돌렸을 때 실패하면 실패하는 부분만 고치면 됨.
  • 즉, 테스트가 리팩토링의 기준이 됨
  • ⭐ 많은 양의 질 좋은 테스트 코드를 짜는 것이 우선이다!

매주 세미나

• 보통 주 1회 진행
• 동료들과 함께 하고 싶었던 것, 공부할만한 자료가 없었던 것들 → 같이 보는 시간
• 암호화, 테스트 짜는 법, JVM 구조, 다음 프로젝트에 할 것, Vim 사용법 등등
• 코드 리뷰의 첫번째 목표였던 서로 친근하게 물어보고 공유하는 분위기가 생김.

기술 블로그 만들기

• 사실상 바쁘기 때문에 기술 블로그가 원활하지 않았음.
• 만약 개발 블로그를 다시 만든다면 이렇게 할거다~ 했던 것을 마컬의 기술 블로그로 올림
• 좋은 사내 문서, 장애 보고서나 외부에 공개할만한 자신만의 지식을 가진 분들을 찾아감
• 회사마다 특징이 있음.
  • 뛰어난 인재가 있다를 어필
  • 우형은 개발자들이 달력에 이름쓰고 날짜가 되면 기술 블로그를 발행하는 정책이 있었음.
    • 외부에서 어떻게 보는지보단 회사 내 개발자들이 성장하는 것에 주안점을 둠
  • 컬리에서는 목차를 도입하고 싶었음.
    • 목차만 봐도 글의 전체가 보이게, 세 줄 요약처럼 보였음 좋겠다는 방식으로 함.
    • 목차를 보면 글을 읽으면서 어디쯤 있는지 알 수 있고, 목차만 봐도 글의 요지를 파악할 수 있어서 좋다.
    • 읽을때 가독성이 좋음.

히스토리 문서를 열심히 작성하자

• 스타트업 다니면서 고민
  • 히스토리를 아는 사람이 없다!
• 새로 만드는 프로젝트에서는 히스토리를 열심히 만드는 것을 해야겠다고 다짐
  • 배포까지의 체크리스트에 날짜를 부여함
    • 위로 갈수록 미래, 아래로 갈수록 과거인 형식으로 작성
    • 히스토리이기때문에 체크해도 지우지않고 남긴다.
    • 오늘날짜를 기준으로 밑으로 보면 해온 기록이 됨
    • 위로 보면 해야할 리스트가 됨
    • 링크를 함께 남김
    • 함께 보면 좋은 문서들도 제일 밑에 링크 모음을 만들어서 한번에 볼 수 있도록 함
    • 장애와 관련된 문서도 체크리스트에 추가함.
• 매일 근무일지를 작성함
  • 날짜 기준으로 쌓음.
  • 슬랙 → 스크린샷 찍고 어떻게 처리했는지 적어가면서 작업함
  • 나중에 시간이 지나서 참고로 링크를 드릴때도 좋음
  • 퇴근하기 전에 정리함
    • 대여섯개만 남기고 삭제
    • 목차를 작성해서 중요할수로 위에 올림.
    • 제목: 날짜 + 목차 첫번째 항목의 이름
      • 동료가 어떤 작업을 했을때 바로 드릴 수 있음
      • 인사평가시 일년 동안 무슨 일을 했는지 훑어만 봐도 알 수 있어 도움이 됨

재택 근무

• 개발에 대한 철학에 가장 큰 영향을 준 사건 → 짝 프로그래밍
• 최선혁님과 프로젝트를 진행하게 됨. 도메인 지식이 없고 일정이 촉박한 상황이었음. 원격으로 CODE WITH ME, 구글 MEET으로 공유하면서 작업.
• 재택 근무시 가장 어려운 점 → 집중력이 순식간에 낮아짐..!!
  • 짝 프로그래밍을 하면 함께 일하게 되어 딴짓을 할 수 없음.
  • 일을 많이 하게 됨.
  • 서로의 아는 점을 공유할 수 있음
  • 코딩하다 모르는 점이 생기면 구글링을 하는데 짝 코딩을 하면 숨길 수 없게 됨. → 마음을 터놓고 서로 모르는 점을 인정하게 되고, 바보처럼 보이지 않을까 싶은 걱정을 내려놓고 서로 신뢰하며 함께 해결책을 찾아볼 수 있게 됨.

좋은 동료와 일하고 싶다면

• 좋은 친구를 만나려고 기다리면 어렵다. 하지만 내가 먼저 그런 종류의 친구가 되면 좋은 친구가 생긴다.
• 좋은 동료를 만나는 것도 마찬가지이다. 내가 먼저 동료들에게 양보하고, 칭찬하고, 배운 것을 공유하고, 힘들어하는 동료를 돕는 동료가 된다면 한두명이라도 좋은 동료가 되어 줄 것이다.
• 동료를 진심으로 축하하고 아낌없이 나눠주자

---

질문

1. 공부를 할 수 없는 과업 시간에는? 시간을 효율적으로 쓰기 위한 전략?

• 항상 시간이 부족하다고 생각함. 따라서 평소에 하는 것의 가짓수를 줄이는 게 중요하다
• 휴식의 종류, 공부의 종류도 줄이는 것
  • 코딩 테스트 문제를 풀지 않음. 이직할때에는 모르지만 당장 필요 없으므로
• 회사일과 관련된 공부를 하는 것이 중요함 → 업무의 연장선이기에 동료에게 도움을 받을수도 있다
  • 회사일과 관련된 공부가 우선 순위에 제일 높다
  • 기록을 남기는 것이 중요
• 하루에 하나라도 제대로 하자

1-1. 도움이 되는 정보와 안되는 정보를 어떻게 구분?

• 회사와 관련된 정보가 도움이 되는 정보이고, 아닌 것이
• 찾으려고 해서 찾은 정보는 우선 순위에서 높다. 하지만 트위터나 페이스북에 올라와서 본 정보는 우선순위가 낮다.

1-2. 개인 프로젝트를 어떻게 해야할지, 하는게 좋을지

• 많은 사람들에게 프로젝트의 종류가 꼭 깃허브에 올리고 코딩을 해야한다는 강박이 있는 듯 하다.
• 개인 프로젝트가 꼭 코딩일 필요 X. 일주일동안 책을 읽고 책 내용을 정리하는 리포트를 만드는 것도 프로젝트가 될 수 있다.
• 하루에 한가지라도, 일주일에 한 가지 주제라도 제대로 한다면 좋은 프로젝트가 될 수 있다.
• 집중해서 공부한 경험은 스스로를 돌아보기에도 좋은 경험이다.
• 너무 많은 지식을 얇게 알아서 고민에 빠진다. 한두가지라도 회사에서 쓰는 기능을 제대로 안다면 좋음

1-3. 잘하고 있는지를 어떻게 판단할까

• 관심사가 여러가지로 퍼지지 않게 회사일을 기준으로 일을 줄이자.

2. 조직에서 다른 개발자와 교류할때 관점이 맞지 않아 불편한 것 같음. 어떻게 극복할까

• 맥락을 쌓는게 중요함.
• 동료에게 할때 표면적으로는 거부를 안해도 막상 시작하면 부정적인 반응이 오거나 힘들어 하는 경우가 많다.
• 이런 종류의 활동을 철저히 시작하기보단 함께 식사나 스포츠, 게임 등을 통해 친해지고 서서히 시작하는게 좋다.
• 이런게 자주 쌓인다면 일종의 이직 플래그일 수 있다.

3. 집중력이 떨어질 때 텐션 회복하는 법

• 잠을 잔다.
• 하루나 이틀 정도는 아무것도 안하고 쉬기도 함.
• 성장에 대한 불안감이 있어 책을 읽기도 하고, 뛰거나 산책
• 가급적 새로운 활동을 하기도 함

4. 백엔드 개발자가 혼자밖에 없는데 성장할 수 있을까

• 가능하다고 생각함.
• 혼자인 경우 위키를 만들어 보는 것이 도움이 될 듯.
• 랜덤 버튼과 목차를 달아보기
• 반드시 커뮤니티 활동을 해보는 것을 추천
  • 페이스북 그룹, 특정 그룹의 슬랙 채널, 고민 상담류의 DM 등

5. 취직/이직 준비시 지식 외에 어떤 것이 필요할까

• 관심있는 회사의 영역을 넓히자.
  • 세 군데라면 열 군데 정도로 넓혀서 채용 공고를 수집한다. (30 군데를 추천)
  • 채용 공고를 보면 지원 자격과 우대 조건이 있는데 지원 자격이 중요하다
  • 30군데의 지원 자격을 보면 공통적인 부분이 있다. 이 공통 부분을 준비하면 공부가 많이 된다.
  • 커뮤니케이션, 공부 방법은 기본
  • 면접을 직접 보는 것이 중요
    • 면접을 열 군데 이상 봐야 좋다고 생각함.
    • 지원 자격들이 비슷하면 면접 질문도 비슷함. → 대여섯 군데 면접을 보면 감이 잡힘

6. 문서 꾸준히 관리하는 것이 쉽지 않다. 지속하는 방법?

• 사기템이 있어 가능하다. → 위키
• 게임을 하다보면 수집욕을 자극하는 아이템이 있다. 위키를 만들면서 그런 기분을 느낌
• 책을 읽다가 위키에 적어야 겠다는 생각이 들어서 적고 함
• 내가 회사에서 일하다 모르는 게 생기면 위키에 적어야 겠다는 생각이 듬
• 위키 + 랜덤 + 목차
• 쓰기 싫을땐 제목이나 목차만 올려도 괜찮다.
  • 랜덤 누르다 제목만 있는 글을 발견하면 그때 완성하면 됨

7. 철학이 논리적 사고에 도움이 되는가. 전공이 컴공이 아니라 아쉬운 점이 있는가.

• 논리적 사고에 도움이 되었다. 하지만 개발자에 도움이 되었다고 확신할 수는 없다.
• 사고에 큰 도움을 준 사고는 있음.
  • 칼 포퍼
    • 추측과 논박의 이론
    • 정교한 테스트를 만들고 통과하지 못하면 그 이론은 폐기한다.
    • 예) 천동설 → 지동설
    • 이론에 반박되는 근거가 생기면 이론을 폐기하거나 수정한다.
    • 엄격한 경계값 테스트에는 도움이 됨
• 개발을 잘하기 위해서는 어떤 전공이 무조건 도움이 된다고는 생각하지 않음. 최대한 많은 경험을 회사와 관련된 경험으로 추출하고, 빠르게 공부해서 적용하는게 도움됨.

8. 최종 목표

• 먼 미래는 생각하지 않고 있음.
• 부정적으로 미래를 계획하는 편이라 가족과 노후를 행복하게 보내면 좋겠다고 생각
• 지금까지 도움을 많이 받았기 때문에 도움을 줄 수 있는 분들께 코칭 등으로 도움을 드릴 수 있으면 좋지 않을까 생각