2021-06-04(Fri)

Facts (사실, 객관)

김수보 멘토님과 이민석 학장님, 폴라베어님과 각각 수다했고, 스파르타 42 회의에 참여하여 이호준 멘토님 얘기를 들었다.

코드숨 5주차 과제의 javadoc을 1차적으로 작성했다.

Feelings (느낌, 주관)

출근하고나면 99%의 확률로 회사일 외에 시간을 쏟지 못할 것 같다. 그 전에 감사한 분들과 수다하는 것을 목표로 했다. 취업을 축하해주시며 여러 꿀팁을 주셔서 감사했다. 감사한 일이 많은데, 나도 받은 선한 영향력들을 나눌 수 있는 사람이 되고 싶다.

선배 개발자 분들과 수다하다보면 시간이 너무 훅훅 간다. 나만 그런가 왤케 라떼이야기도 재밌는지ㅎㅎ 수보 멘토님의 ORM의 기원에 대한 얘기나 소프트웨어의 일정 수준의 오류는 생기기 마련이라는 미국 논문 얘기, 학장님의 리얼 대환장이었던 고대 시절 IT 환경 이야기와 교육관에 대한 이야기, 호준 멘토님의 동남아 인프라에 대한 이야기와 현업 프로세스 이야기 등등 꿀잼이었다. 오늘 하루 밖에 시간을 못 낸게 억울할 정도. 특히 수보 멘토님에게 유머에 대한 얘기를 들을 때는, 아 우리가 정말 문제를 푸는 역할을 해낸다는 것이 느껴졌다. 개발자로서 문제를 풀려면 기술은 기본이고, 소프트 스킬도 정말이지 필수다.

욕심 같아서는 다른 멘토님, 동료분들과도 수다하고 싶었는데 못 해서 쬐끔 아쉬웠다. 다음에 또 다른 기회를 내봐야겠다.

코드숨 5주차 과제에 시간을 쏟지 못 했다. 저녁 약속도 다음으로 미루고 학습해봤지만, javadoc만 간신히 작성했다. 생성자 어노테이션 연구에 시간을 너무 쓴 걸까. 종립님의 성의에 답하지 못한 것 같아서 마음이 무겁다. 흠...

Findings (배운 점)

신입 백엔드 개발자에게의 꿀팁

1. 백엔드 개발자라면 급하게 판단을 하지 말자.

   • 특히 DB 업데이트 칠 때, 한번 더 생각하고, update 반영 갯수가 의도한대로 반영되었는지 꼭 체크해보자.

2. 나 자신을 믿지 말자.

   • 인간인 이상 실수를 할 수 밖에 없다. 나 자신을 믿지 말고 한번 더 검증하자. 가령 rm -rf 를 확 누르지말고, mv로 지울 파일 옮기거나 이름 바꿔도 문제 안 생기는지 체크한 다음에 지우는 식으로.

3. 요구 공학을 어떻게 준비하냐고? 현업에서 배워야 한다.

   • 그래도 대략 설명을 해보자면, Tech를 모르고 도메인 지식을 아는 팀원이 문제를 해결해달라고 할 것이다. 이걸 Tech를 아는 개발자가 풀어내야 한다.

     1) 일단 무슨 말을 하는지 이해하자. 2) 이제 인터뷰 스킬을 발휘해서 정확히 뭘 원하는지 끄집어내자. 이 때 만들 수 있다없다 여부를 말하진 말고, 이런거 해결하고 싶구나? 하며 찬찬히 탐색해보자. 3) 일단락 되었다면, 만들면서 짧은 주기로 문제를 해결할 수 있는지 체크해보자. 기본적으로 만드는게 핵심이 아니라, 원하는 목적을 이루게 하는 것이 포인트다. 이걸 엣지가 산다고도 표현한다.

4. 요청이 들어오면, 마침표를 확인해보자.

   • 무슨 말이냐면, 그냥 해달라는 것 받지 말고, 일정을 파악하자. 어디서 시작된 일이고 어디까지 해줘야하는지 확인해보자.

5. 들은 것을 구글 닥스에 적어서 관리하는 것을 추천한다. 막 적어도 검색기능이 강력하다.

6. 실무를 접하고, 이동 시간 등을 쪼개서 CS 책을 보는걸 추천한다. 알았던 개념도 새롭게 다가올 것이다. 좀 더 지나면 논문도 봐야할 수 있다.

7. 회사는 일을 하는 곳이다. 내가 뭘 남기는지, 내가 왜 월급을 받는지를 계속 인지하고 있자.

8. 유머도 중요하다. 개발자는 기본적으로 '긴장감'이 높아지는 환경에 놓이거나, 이미 '긴장감'이 높은 환경에 던져지기 마련이다. 이럴 때 두 가지 측면에서 유머가 필요하다. 1) 적절하게 긴장감을 풀어주면 풀릴 문제가 많다. 2) 개발자 스스로의 프레셔를 이겨내는데 도움이 된다. 요는 문제를 푸는데 소프트 스킬도 적극 사용하자!

9. 혹시라도 잘난척하지 말자.

10. 이슈를 막 정신없이 쳐내지 말고, 내가 추정한 것과 실제와의 간극을 좁히는 훈련을 계속하자.

    • 예를 들자면, 아래 과정을 반복하는 것.

      1. 문제, 해결시간 추정

      2. 실제 문제, 해결 시간을 측정

      3. 비교

11. 본인 코드도 리뷰하자. 한번쯤 소스코드를 출력해서 리딩해보는 걸 추천한다. 바로 키보드가 있으면 바로 손이 나가기 쉬운데, 그러지말고 읽는 것을 연습해보자. 그리고 사소한 것까지 설명해보자.

12. 자기 자신을 잘 챙기자.

Affimation (자기 선언)

나는 피상적인 문제에 매몰되지 않고 문제를 정확히 파악하는 개발자다.