3월 22일부로, 라인웍스의 데이터 엔지니어 팀원으로써의 여정을 마치게 되었다.
더 힘든 길일 수도 있지만, 다른 좋은 기회가 나에게 왔다 생각하고 새로운 도전을 해보려고 한다.
라인웍스는 나에게 정말 좋은 회사였고, 단순히 나의 욕심으로 라인웍스를 떠나게 되었다. 1년간 라인웍스를 다니면서 정말 많은 것들을 배웠는데, 새롭게 내가 배우고 느낀 점들을 이 글에 써보려고 한다. (너무 많아서 다 못 쓸 수도 있음…)
📍 모든 사람의 시간은 소중하다.
나의 시간도 중요하지만, 내가 대화를 요청한 사람의 시간도 소중하다. 내가 부탁하거나 질문하는 입장이라면 최대한 상대방이 이해하기 쉽도록 내 시간을 사용해야 한다는 것을 배웠다. 나는 보통 서두에 어떤 내용에 대한 질문인지 부탁인지에 대한 내용을 작성하고, 그 뒤로 간단한 챕터를 나눠 작성한다. (ex. [문제상황][에러 메시지] [해결하기 위해 시도한 방법]…) 이를 통해 상대방이 나의 질문이나 부탁의 요점을 이해하는 시간이 줄어들었다고 생각한다.
📍 회의를 한 후에는 결정된 내용이 있어야 한다.
모든 사람의 시간은 소중하고, 스타트 업일수록 참여하는 회의가 많아질 수 있다. 어떠한 회의를 진행했다면, 결정된 내용이 나와야 한다. 결정된 내용이 없다면 무엇을 위해 한 시간 동안 회의를 했는가? 회의를 할 때는 결국 무엇에 대한 회의인지를 명확히 해야 하고, 어떤 것을 결정할 건지 들어가기 전 미리 생각을 해놔야 한다. 회의를 통해 결정을 했다면 행동해야 한다.
📍 궁금한 회의가 있다면 요청해서 들어가 보자.
초반에 라인웍스의 데이터 엔지니어는 어떤 일을 하는지 명확히 인지하지 못했을 때가 있었다. 연차가 오래되신 DE 팀원분들은 항상 회의가 많으셨는데, 어떤 회의를 하는지 궁금해서 회의에 참여해도 되냐고 요청을 했고, "당연하죠"라고 답을 주셨다. 회의에 들어가서 "라인웍스는 이러이러한 일들을 하고 있구나", "라인웍스 데이터 엔지니어 그룹은 이러이러한 일들을 하는구나"라는 것을 조금 더 쉽게 알게 된 것 같고, 내가 해야 할 일을 명확히 알게 되었다. 입사 초반에 많은 회의를 들어가 보는 건 나에게는 좋은 경험이었다.
📍 거절은 나쁜 게 아니다.
상대방이 나에게 요청했을 때 거절할 용기도 있어야 한다는 것을 배웠다. 요청이나 부탁이 들어왔을 때 내가 요청이나 부탁을 들어줄 수 있는 시간이 있는지 스스로 판단해야 한다. 만약 어렵다고 판단되면 최대한 공손하게 부탁을 거절해야 하는 용기가 있어야 한다. 그렇지 않으면 내 스스로 너무 힘들어진다는 것을 느꼈다. 거절을 하기 위해서는 현재 나의 업무량은 어떤지, 일의 우선순위는 어떤지 스스로 알아야 한다는 전제가 깔려있다.
📍 무겁고 딱딱하게 느껴졌던 코드 리뷰가 이제는 좋아졌다.
코드 리뷰는 피드백만 주는 것이 아니라는 걸 배웠다. 라인웍스에서는 누구에게나 코드 리뷰를 요청할 수 있다. 코드 리뷰에서는 사소하더라도 궁금한 내용이 있다면 질문할 수 있는 것이고, 새롭게 알게 된 코드, 기술이라면 따봉을 날려 칭찬을 해줄 수도 있다. 코드 리뷰는 단지 내가 잘못한 것은 없는지 확인받기 위한 행동이 아니라는 뜻이다. 또한 만약에 피드백을 받았다고 해도 그 피드백은 나에 대한 이야기가 아닌 그 일에 대한 이야기라는 것을 배웠다. 무겁고 딱딱하게 생각했던 코드 리뷰가 이제는 무겁게 느껴지지 않는다:)
📍 생각만 하지 말고 직접 코드로 작성해 봐라.
어떠한 기능을 개발할 때 코드로 작성해 보지 않고 "방금 생각한 로직보다 더 좋은 로직이 있을 거야" 또는 "잘 돌아가겠지"라고 생각'만'한 뒤에 계속해서 다른 로직을 생각하려 했다. 하지만 여기서 나에게 중요한 것은 우선 그 코드를 직접 작성해 봐야 했었다. 그다음 수정을 해도 되기 때문이다. 실제로 생각한 코드를 작성함으로써 내가 생각지도 못한 에러 발생 가능성을 찾을 수 있었고, 나중에 큰 오류를 발생하는 상황을 줄일 수 있었다. 이것을 느낀 후로 생각한 코드를 직접 작성해 보고, 다른 생각을 하는 방법으로 바뀌었다. (무작정 코딩을 시작한다는 뜻이 아님)
📍 단위 테스트 코드를 작성한다.
테스트를 진행할 때 큰 로직만 테스트하는 코드를 작성했다. 그러다 잘못된 값, 에러가 나면 어디서 발생하는지 에러 메시지를 보고 찾은 후, 에러 발생한 부분의 코드를 수정하고 나머지 주석 처리한 후 다시 테스트하는 행동을 반복했다. 이렇게 되니 나중에 테스트를 진행할 때 최소한의 기능을 테스트하는 것이 어렵다는 것을 느꼈고, 최대한 작은 단위로 테스트를 하면 좋다는 것을 느꼈다. 어디서 에러가 나는지, 어느 부분에서 잘못된 값이 추출되는지 쉽게 알 수 있기 때문이다.
📍 코드를 작성할 때 최대한 작게 만들려고 한다.
함수, 클래스 등을 만들 때 '어떻게'가 아닌 '무엇을' 하는 함수인지, 클래스인지를 명확하게 보여주기 위해 최대한 작게 작성하려 한다. 또한 하나의 함수는 하나의 기능만 수행하도록 최대한 작게 작성한다. 이렇게 작성하게 되면 코드를 봤을 때 훨씬 이해하기가 쉽다는 것을 느꼈고, 테스트를 할 때 작게 작게 테스트할 수 있었다. 이러한 부분은 회사 내 스터디, 클린 코드, 리팩터링 책을 통해 배우게 되었다.
📍 내가 원하는 것은 무엇인지, 어떤 일을 하고 싶은지에 대한 생각을 꾸준히 해야 한다.
라인웍스는 1 on 1을 통해 어떠한 일을 하고 있는지, 진행 속도는 어느 정도인지, 일은 적성에 잘 맞는지, 힘든 일은 없는지, 회사에 요구하고 싶은 것은 없는지 등을 이야기하는 시간이 존재한다. 계속해서 이러한 시간이 있다 보니, 나는 이 시간을 나에 대해 생각하는 시간이라고 생각했다. 현재 나의 업무량은 어떤지, 나의 상태는 어떤지, 내가 하고 싶은 것은 무엇인지, 어떤 일을 하고 싶은지에 대한 생각을 꾸준히 할 수 있게 만들어주는 시간을 주어서 좋았다. 1 on 1 시간이 아니더라도 스스로 나에 대해 생각하는 시간은 있어야 한다는 것을 알게 됐다.
📍 나에게는 정말 좋은 회사였다.
글을 쓰다 보니 1년간 다니면서 회사에 불평 하나 없었던 이유는 위에 작성한 내용들과 좋은 회사 위치, 좋은 팀원들, 워라벨 보장, 좋은 근무 환경 등을 모두 경험할 수 있었던 회사였기 때문 아닐까? 나중에 내 인생을 돌아 봤을 때 너무 좋은 추억으로 남을 회사가 될 것 같다.
