쪼렙 개발자가 스타트업에서 1년 8개월 동안 배운 9가지

10 min readMar 8, 2020

밑도 끝도 없이 배운 점을 얘기하면 너무 맥락이 없다고 생각한다. 처음 만난 사람에게 아무런 언급도 없이 말을 놔버리는 느낌이다. 그래서 어떻게 들어갔는지, 담당했던 업무, 회사에 한 기여를 간략하게 언급하고 배운 점을 나열해보려고 한다.

어떻게 들어갔나?

대학교 같은 학회 선배랑 학회 프로젝트를 같이 했다. 근데 그 선배가 스타트업(포자랩스)의 공동 창업자 중 한 명이셨다. 내가 괜찮아 보이셨는지 딥러닝 개발자 인턴을 제안하셔서 입사하게 됐다.

담당 업무 요약

2018.06 ~ 2019.03: 딥러닝 개발자 (모델 성능 개선 & 데이터 수집 & 전처리)
2019.04 ~ 2020.02: 백엔드 & 데브 옵스 개발자 (자동화 & 데이터 저장 및 관리 & CMS 개발 & 전처리)
자세한 거는 로켓 펀치에 있다!

회사에 한 기여

CTO님의 작별 인사.

나는 당신이 얼마나 훌륭한 사람인지 알고 있고, 우리를 떠나서도 빠르게 성장할 것을 알고 있다. …(중략)…당신이라는 사람이 세상에 더 많은 가치를 전하기를 원한다.

회사 다니는 동안의 github contributions. 2020년에는 TIL이 좀 섞여있기는 하다.

slack message 개수. 1등 해서도 뿌듯하지만 Owner님들을 이겨서 뭔가 뿌듯하다. 나가기 한달 전에도 1등을 했다 😎

notion에서 개인이 할 일을 issue로 만들어 관리했다. 총 close한 개수와 나가기 전 캘린더. 나가기 전까지 열일하고 갔다. 물론 close에 완료 못 한 거도 조금 포함돼 있다.

어떤 점을 배웠나

1. 여러가지 해야할 일이 있을 때,우선 순위를 정해야된다.

회사에서 일을 하기 전에는 기껏해야 과제 혹은 일회성 학회 프로젝트가 개발의 전부였다. 깊게 생각할 필요 없이 이미 할 것은 정해져있고 그냥 하면 됐다.
하지만 회사의 구성원 중 한명으로서 일을 해보니 내가 어떤 일을 먼저 끝내는지에 따라, 서비스를 할 수 있냐 없냐가 결정되기도 하고 팀원이 특정 태스크를 몇 초만에 끝내냐가 아니냐가 결정되기도 했다.
내가 하고 싶은 걸 먼저 하는 게 아니라, 팀원과 소통하면서 어떤 걸 먼저 해야 가장 효율적이고 효과적인지를 계속 찾아가야 한다고 느꼈다. 비록 결정을 내린 후에 뒤집어져서 다시 결정해야 되는 상황이 있어도 어쩔 수 없다.

2. 누군가에게 질문을 할 때 어떤 방식이 효과적인지를 고민한다.

1년을 넘게 다녔을 때 조차도 이 부분이 부족했다. 그래서 뭔가 궁금한 게 있을 때 슬랙에서 상대방을 태그하고 “~님 이게 뭔가요?” 라는 답이없는 방식으로 물어봤었다. (지금 생각해도 답이 없다.) 당연히 질문을 받은 상대방은 ??? 상태여서 질문에 대해서 다시 설명을 해야 했다. 그래서 다음과 같이 질문을 해보니 위와 같은 상황이 줄어들었던 것 같다. (질문한 것에 대한 이해도가 서로 달라 결국은 구술로 얘기했던 상황도 종종 있었다.)
“제가 이런 걸 하고 있는데”라고 처음에는 자신이 어떤 걸 하고 있었는지 맥락을 얘기해야 한다. 아무 맥락없이 물어보면 상대방이 질문에 대한 이해도가 떨어져 엉뚱한 대답을 들을 확률이 커진다.
이후 질문에서는 단순 질문과 해결법에 대한 질문으로 종류가 나눠지는 것 같다. 단순 질문을 할 때는 이게 구글링으로 해결될 수 있는지 혹은 깃허브 한 번 보면 해결될 수 있는지 다시 한 번 생각해봐야한다.
단순 질문은 “이런 부분이 궁금해서 이런 방식으로 찾아봤는데 잘 안 나오더라고요. ”라고 얘기하는 게 좋다. 일단 상대방한테 뭔가 찾아봤다는 언급을 해주면 상대방이 나를 핑프라고 생각해 짜증이 날 확률도 줄고 이 사람이 정말 모르구나를 파악할 수 있기 때문이다.
해결법에 대한 질문은 “(이런 방식으로 해봤는데도 ) 이런 부분이 잘 안되더라고요. 어떻게 해결해야 될까요?”라고 하면 되는 것 같다. 정말 모르겠으면 그냥 어떻게 해야되냐고 물어보는 게 좋다. 하지만 뭔가 시도를 해봤으면 내가 무슨 시도를 해봤는지 알려줘야 상대방한테서 내가 한 것과 똑같은 대답을 들을 확률을 줄일 수 있다. 똑같은 대답을 들으면 상대방한테서 답을 작성한 시간을 뺏은 거라고 생각한다…

3. 코드를 짤 때 전제, debug할 케이스, (TODO)를 쓰는 게 좋다.

전제는 코드를 짤 때 어떤 상황인지 파악하는 것이다. input이 있다면 input이 뭐고 어떤 기술 스택을 쓰고 안 쓸 건지 등등이다. 복잡도와도 밀접하게 연결된다. 이거는 고려 안하고 딱 이렇게만 해야지를 정하는 것이다. 전제를 파악하고 짜도 나중에 뒤집는 경우가 종종 있었는데 무작정 코드부터 짠다면 뒤집을 확률이 매우 커진다.
사실 debug할 케이스는 TDD를 한다면 필요없다! 하지만 TDD로 개발하지 않다보니 익숙하지 않아 잘 못했다… 나름의 차선책이다. debug할 케이스를 적고 체크박스로 체크해 놓으면 PR하기 전에 정말 제대로 테스트 했는지 다시 점검해 볼 수 있고 다음날에 이어서 개발을 할 때 어디까지 디버깅이 됐는지 점검해 볼 수 있다. 다시 말하지만 TDD나 unittest가 훨씬 더 좋다… 살짝 일회용 방법이다…
TODO는 안 쓸 때도 꽤 많았던 거 같다. 그냥 전제만 보고 바로 코드를 짰기 때문이다. 하지만 코드 수준을 넘어 AWS에 뭘 해야 한다든지 누구에게 알려줘야 한다든지 한다면 TODO로 기록하는 게 까먹지 않고 좋다.

4. 처음부터 복잡하게 설계하지 말고 간단하게 시작하자.

회사를 그만둘때까지도 잘 못하던 거였다. 초중반에는 이게 잘 안 되서 기껏 이렇게 저렇게 복잡하게 설계해서 구현했는데 아예 쓰이지 않는다든가 뒤집어야 되는 경우가 있었다. 한 마디로 그 시간은 날린 거다…
최종적으로 구현해야하는 게 10이면 처음부터 10으로 잡고 설계하지 말고 한 2~3 정도만 고려하고 구현을 하는 게 더 유연한 구조라고 느꼈다. 특히 스타트업에서는 갑자기 하려던 것이 휙휙 바뀌기 때문에 이런 특성이 더 두드러졌던 것 같다. 간단하게 빠르게 빠르게 구현해보고 아니다 싶으면 엎는 거고 좀 더 develop 해야 한다면 그때부터 추가하면 되는 것이다.
이걸 효과적으로 하려면 복잡도와 필요성에 따라 단계를 잘 나눠야 한다. 꼭 필요한 거만 일단 구현하고 구현 되면 편한거는 뒤로 미루는 것이다. 예를 들어 서버에서 딥러닝 모델로 인퍼를 해야된다면, 처음에는 체크포인트나 필요한 데이터를 수동으로 넣어주다가 나중에 리모트에서 자동으로 다운로드 받도록 만든다.

5. 실수를 했다면 반드시 왜 났는지를 찾아내 앞으로 다시 나지 않는 법을 생각해낸다.

들어간 지 얼마 안 됐을 때는 작든 크든 실수를 하면 거의 무조건 ‘난 왜 이렇게 멍청하지… 적성이 아닌가…’ 이러고 하루종일 시무룩해 있던 거 같다. 이런 식으로 실수에 매몰돼버리면 나아지는 게 하나도 없다.
물론 이런 절망적인 감정은 들 수 밖에 없다. 하지만 잠시 시간을 갖고 머리를 식혀 얼른 날려버려야 한다. 그리고 어떤 지점에서 어떻게 났는지를 꼼꼼하게 살펴봐야 한다. 단순히 여기서 그치는 게 아니라, 앞으로 어떻게 하면 예방할 수 있는지 생각하고 그 방법대로 실천해야한다.
구체적인 예시는 다음과 같다. 내가 딥러닝 모델 학습을 위한 trainer class를 구현했었는데 keep prob을 무조건 1로 사용하는 치명적인 실수를 했다. (딥러닝 안 한 지 오래 돼서 까먹었다는 변명을 꼭 하고 싶다.) 심지어 다른 분이 발견했었다. 어떻게 이런 실수를 할 수 있을까 하고 충격에 빠져 야근을 하지 않고 정시에 퇴근을 했다. 하지만 집에 가면서 ‘아 이게 중요한 게 아니라 앞으로 이런 실수가 안 나도록 해야겠다!’ 라는 생각이 들었다. 그래서 slack으로 다른 분께 train을 할 때 사용하는 max keep prob을 여쭤봐서 assertion을 추가하고 자신이 사용한 하이퍼 파라미터가 로그로 출력되게 만들자고 제안을 드렸었다.

6. 미팅을 주최한다면 최소 30분은 미팅 노트를 준비하자.

미팅을 주최할 때는 최대한 꼼꼼하게 준비해야 한다. 이렇게 하지 않으면, 미팅에 참여하는 사람이 미팅을 이해하지 못 해 미팅 시간도 길어질 뿐만 아니라 제대로된 결론도 얻기 어렵다.
그리고 미팅 노트를 준비해보니 딱히 미팅이 필요하지 않다고 판단이 든다면 미팅 노트에 작성한 내용을 관련된 사람들에게 공유하고 의견을 얻는 게 낫다는 생각이 들었다.

7. 미팅에서 아젠다, 결론, 이후의 action은 반드시 정한다.

미팅을 어떤 목적(아젠다)으로 하는지 명확하게 정하지 않으면 미팅의 논점이 이리저리 왔다갔다 하게 된다. 그러다보면 회의는 길게 했는데 ‘그래서 결론이 뭐지?’의 상태가 되버리고 그에 따른 action을 정하기도 어렵다. 즉, 무의미한 회의가 될 확률이 크다. 단, 주의할 점은 한 회의에서 너무 많은 목적을 설정하는 것도 좋지 않은 것 같다. 그러면 회의가 길어지고 참여하는 모두가 지쳐버린다.
결론은 이후의 action을 정하기 위해서, 나중에 다시 회의를 참고하기 위해서이다. 결론이 이러이러하니 A는 뭘하고 B는 뭘하자 이렇게 딱딱 정할 수 있게 된다. (결론이 안 나거나 노답이라면 불가능하지만…) 특정 회의에서 어떤 것이 정해졌는지를 알기 위해서 필요할 때 마다 미팅 노트를 보는 건 비효율적이다. 따라서 결론으로 금방 파악할 수 있도록 해야한다.
이후의 action은 회의를 하는 의미가 있게 해준다. 아무리 목적이 명확하고 결론이 잘 났어도 누가 뭘 해야 하는지 모른다면 말짱 도루묵이다. 그리고 각자에게 맡겨 버린다면 다른 사람이 같은 일을 할 수도 있고 아무도 안 하는 일이 있을 수도 있다. 따라서 다 같이 누가 어떤 일을 할 지를 정해야 한다.

8. 될 수 있으면 모든 걸 기록하자.

말 그대로 회사 업무와 관련된 모든 거는 일단 적고 보는 게 좋다. 왜냐면 적어 놓지 않으면 나중에 무조건 다시 여쭤보거나 잊어버리기 때문이다. 또한 여러 사람이 커뮤니케이션 할 때 모두가 접근 가능한 곳에 뭔가 적혀있어야 비효율적인 부분이 감소된다.

9. 기록한 것이 접근하기에 읽기에 편리한지 고민하자.

위의 배운점과 이어지는 내용이다. 아무것도 없는 것보다 물론 뭐라도 있는 게 좋다. 하지만 잘 있으면 더 좋다…! 아무런 생각없이 적힌 기록은 일회성이다. 몇 번 보고 버려진다… 어디에 기록하는 게 가장 적절할 지 문서 구조가 알아보기 쉬운지 살펴봐야 한다.
예를 들면, 두고두고 봐야하는 기록을 slack에다가 해버리면 매번 그게 뭐였더라… 이러면서 찾아봐야 하는 불편함이 있다. 그리고 노션에서 특정 문서에서 한 항목당 기록된 내용이 너무 많다면, 원하는 내용을 찾기가 좀 번거롭다. 그럴 때는 차라리 항목당 문서를 만드는 게 더 좋은 선택이라고 생각한다.

마무으리!

1년 8개월 동안 스타트업을 다니면서 배운 점들을 정리해봤다. ‘뭐 이렇게 당연한 걸 남겨놨지’ 라고 생각할 수도 있다. 하지만 이전에 개발자로서 일을 해본 적이 없는 쪼렙에게는 위에 언급된 내용들이 당연하지 않았다. 그래서 스타트업에 다니지 않았더라면 지금까지도 몰랐을 것이다.

본격적으로 개발자로서 취업을 하기 전에 (아직 졸업도 못 한 대학생 신분이다) 너무 뜻 깊은 경험을 했고 많은 점을 배웠다. 다 읽어주는 사람이 있을 까 생각하지만 다른 사람들에게 이 포스팅이 공유돼 좋은 영향을 끼쳤으면 좋겠다 :)