나예진

1년차 삐약이

피드백 절대 환영합니다 :D

신청 계기?

배권한 멘토님과 평소에 멘토링을 진행할 때 굉장히 많은 점을 배웠고, 여러 도움이 되는 조언을 많이 받아왔었다. 그런데 이번에 서초에서 오프라인으로 멘토링을 진행한다고 하셔서 바로 신청했다.

멘토링을 신청한 주제는 주로 협업과 프로젝트에 대한 내용들이었다. 내가 집현전이라는 곳에서 활동을 하며 느꼈던 점들이나 궁금한 점들 등을 멘토님께 여쭤보고 싶었다. 그 외의 내용은 앞의 타임에 계시던 분의 멘토링 내용을 듣게 되었는데, 그 중 나도 참고할 만한 좋은 얘기들이 많아서 같이 블로깅을 하였다.

주제

협업

협업에 있어서 갈등이란?

갈등은 협업을 방해하는 모든 요소이다.

협업이 잘 이루어지지 않는다

이유

  • 서로 이야기를 하지 않는다.
  • 일을 했는데, 티내지 않는다.

해결 방법

  • 디스코드 등의 수단으로 연락을 한다.
  • 짧게라도 일정을 잡아서 만난다. 일정을 박아두고 일단 만나는 것이 중요하다 (ex. google calendar로 일정 공유).

협업을 할 때 회사에서 바라는 사람

  • 자신의 일만 잘 처리하는 사람
  • 자신의 일 뿐만 아니라 다른 사람의 일도 봐줄 수 있는 사람
  • 일을 잘 정리하는 사람

이 세 유형의 사람이 전부 필요하다고 한다.

화법의 완급 조절

나의 경우, 말을 조심하면 너무 빙 둘러서 말하게 되고, 그렇다고 직설적으로 꽂아버리면 가끔 주변에서 놀랄 정도의 직구를 던져버린다. 일종의 팩폭러 포지션일 때가 있다. 그래서인지 종종 “이걸 이렇게 티를 냈는데 못 알아 듣는다고?” 싶거나 “아 너무 세게 말했나” 싶은 상황이 종종 있었다. 그래서 이 부분에 대해 어떤 식으로 해야 개선할 수 있을지를 여쭤봤는데, 경험이 중요하다고 답해주셨다. 그리고 그 경험을 쌓을 수 있는 곳이 42 서울이라고 하셨다.

추가적으로 ‘비폭력 대화’ 라는 책을 추천해주셨는데, 나중에 이 책을 읽고 블로깅하도록 하겠다.

CS 공부

CS 공부의 방향성

  • 문제를 터뜨리고, 해결하면서 배우기! => 문제가 발생했을 때, 어떻게 할 것인지를 생각
    ex) 채팅 서버를 공부한다 했을 때, 만 명의 사용자를 동시 접속 시켰을 때 “왜 터지는가”에 초점을 두기
  • trouble shooting의 경우에도 과정을 보기
  • 문제와 연관된 형식으로 CS를 공부할 것

어떤 경우에 어떤 문제가 발생할지 잘 알게 되는 방법

  • 클론 코딩
  • 본인만의 문제 풀기

시간 관리

시간이 모자란 이유

  • 낭비되는 시간이 많다
  • 포기하지 못하는 일이 있다

시간 관리 방법

  • 뽀모도로 타이머(어플 말고 물리적인) 활용하기
  • 제한 시간 걸어두기: 시간 내로 일을 못 마칠 경우, 답을 보기
  • Time Tracker 활용하기
  • 캘린더에 일정을 작성해두고 그 내용을 지키기

나의 경우, 30분마다 한 번씩 강제로 물을 마시러 간다든가 하면서 뽀모도로 타이머처럼 물 마시는 시간을 갖고 있다. 42서울 클러스터는 물을 마시는 공간이 따로 있기 때문에 물을 마시려면 컴퓨터 자리에서 반드시 벗어나야 하기 때문에, 잠깐 물 마시러 가는 김에 생각을 환기하기도 한다.

제한 시간의 경우에도, leet code 문제를 풀 때 난이도가 easy면 30분, medium은 1시간, hard는 2시간 정도로 두고 시간이 지나면 답을 본다. 단, 제한 시간 내에 답을 풀지 못했을 경우, 내가 어떤 시도를 했고 어떤 결과가 나왔는지에 대해 블로깅하는 것은 필수이다.

캘린더에 일정 작성하는 것도 운동을 몇 시에 갈지, 클러스터에 몇 시에 갈지, 회의가 몇 시에 있는지, 마감이 언제까지인지, 사적인 약속을 언제 잡을지 등을 구글 캘린더에 전부 다 박아놨다. 한 주가 끝나고 캘린더를 살펴봤을 때, 빼곡한 일정을 보면 내가 이번 한 주를 알차게 보냈구나 싶은 생각이 들어서 굉장히 뿌듯한 건 덤이다.

Time Tracker로는 여러 가지가 있는데, 멘토님께서는 rescue time을 사용하고 있다고 하셨다. 이것까지는… 휴대폰에도 깔고 노트북에도 깔고 데스크탑에도 깔고 해야할 것 같아서 내가 나중에 정 시간 관리에 힘듦을 느낄 때 하기로 했다.

프로젝트

프로젝트에서 어떤 기술을 쓸 지 결정하는 방법

  • 실무에서 많이 사용하는 기술이 무엇인지 확인한다: 회사 구인 공고에서 어떤 기술을 우대하는지 확인한다.

코드의 리팩터링과 기능 추가가 동시에 진행될 수 있는가?

가능하다. 다른 부분에서 기능 추가가 이루어지는 동시에 리팩터링 하는 방법은 아래와 같다.

  1. E2E 테스트를 작성한다. 이는 유닛 테스트에 비해 테스트에 필요한 시간을 줄일 수 있고, 효율은 증가시킬 수 있다.
  2. 테스트가 확실하게 동작한다면, 해당 부분에 대해 리팩터링을 한다.

저장 프로시저를 쓰지 않는 이유

은행권 등에서 트랜잭션에 대해 100% 확신할 수 있다든가 등의 특수한 상황이 아니라면 사용하지 않는다. 확장성에 대해서도 방해받기 때문이다.

마치며

42 서울에서 가끔 다른 카뎃들과 미래에 대한 고민(?)에 대해 얘기를 나눌 때에도 느꼈던 점이지만, 서로 다른 사람이어도 고민하는 내용에 대해서는 어느정도 비슷한 면이 있다는 것을 느꼈다. 앞 타임 분들이 멘토님께 질문드렸던 내용들의 대부분이 나도 갖고 있던 고민의 내용 중 일부였기 때문이다.
이 부분에서 다른 사람들도 지금 하고 있는 고민에 대해 크게 걱정하거나 하지 않고, 다른 사람들도 같은 고민을 하고 있으며, 그런 고민을 하는 건 당연한 일임을 알았으면 한다. 어찌보면 지금 시니어 개발자 분들도 예전에는 우리와 같은 고민을 한 시절이 있었을지도..?

42서울 본과정에 들어와서 처음으로 받은 오프라인 멘토링이었는데, 다른 분들의 질문을 통해서도 역시나 많은 걸 얻어갈 수 있는 시간이었다. 오히려 다른 카뎃의 질문을 듣고 나도 그 질문에 대해 생각해보는 시간도 있었던 점이 좋았다. 앞으로의 멘토링 진행에 멘토-멘티 1:1 진행도 좋지만, 다른 사람의 고민으로부터 내가 배울 수 있는 점도 있기에 42 서울에서 단체 멘토링도 진행한다면 좋을 것 같다.

댓글남기기

참고