입사 후 4개월, 나 자신 돌아보기 (feat. 신입개발자)

안녕하세요! 드림어스컴퍼니 이용권&정산개발팀에서 이용권 파트를 담당하고 있는 Derrick입니다. 👦

저에게 첫 회사인 드림어스컴퍼니에 입사한 지 4개월 정도 지났는데요. 짧은 기간이지만, 개발자로서 회사에 다니며 많은 것을 깨달았습니다. 그 중 일부분을 공유합니다!

1. 일정 산정은 경험의 산물! 일정 산정 시 업무를 세분화하자

이용권&정산개발팀에서는 업무를 할당받고 직접 개발 일정을 산정합니다. 제가 일정을 산정할 당시 "이 정도 일정이면 괜찮겠지?" 생각하고 뭉뚱그려 일정을 산정한 적이 있었는데요. 물론 버퍼 기간을 아예 고려하지 않았던 건 아니었어요.

나름 메인 업무에서 추가 이슈가 생길 것도 고려해 버퍼 기간까지 생각했으나, 예상하지 못한 게 있었습니다.

메인 업무를 하다가 VoC가 들어왔고, VoC와 메인 업무 둘 다 생각했던 것보다 어려워서 기한 내에 메인 업무를 완료하지 못했습니다. 결국에는 해당 메인 업무의 일정 산정을 다시하게 되었죠.

위와 같은 경험을 하고 조언을 받았습니다. '일정 산정은 경험의 산물'이라고. 처음에는 원래 일정 산정하기가 어렵다며 괜찮다고 이야기해주셨습니다. 또한 일정 산정의 오차가 적을수록 프로 개발자라고 말씀해주셨습니다.

이 말을 듣고 어떻게 하면 일정 산정의 오차를 줄일 수 있을까 생각했습니다. 그리고 다음과 같은 결론에 도달했습니다.

'일정을 산정할 때 업무를 최대한 세분화하자'입니다.

예를 들어, 어떤 업무를 받았을 때 그 업무를 완전히 해결하기까지 여러 부분으로 나눌 수 있습니다. 도메인 파악, 기존 코드 파악, 기술에 대한 이해도, 여러 배포 환경, 각종 예외 처리, 설계, 개발, 문서화, 테스트, 중간 VoC 처리, 그 외 추가 이슈가 있고 이외에도 외부와 커뮤니케이션, QA 대응, 환경 구성 등이 있겠죠.

이처럼 업무를 최대한 분할하고 각각 일정을 산정합니다. 특히 외부와 커뮤니케이션하는 부분은 예측이 쉽지 않기 때문에 추가로 일정을 산정하는 것이 도움이 될 수 있습니다. 어떤 Task가 3일이 넘어간다면 해당 Task를 더 나눕니다. 이런 식으로 업무를 세분화한다면 우선순위에 따라 어떤 일을 할지 구체적으로 알 수 있으며, Task마다 3일이 넘어가지 않아 각 Task가 루즈하지 않습니다.

"신입이 개발 일정을 산정하면 그 산정한 값에 * 3을 하라"는 말이 있습니다. 그만큼 저를 포함한 대부분의 신입은 일정을 산정하기 힘들다는 의미겠지요. 앞으로 일정을 산정할 때는 업무를 최대한 세분화하고 업무가 완료됐을 때 초기 일정 산정 대비 걸린 시간을 비교해보며 오차를 줄여나가려고 합니다.

2. 문서화를 잘하자

혼자 개발을 진행하거나 간단한 팀 프로젝트를 할 때는 개인이 많은 부분을 담당하기 때문에 기록의 의미가 덜 중요하게 여겨집니다. 개발한 것의 도메인을 가장 잘 알고 있는 사람이 본인이고 팀 프로젝트를 하더라도 보통은 그 규모가 크지 않기 때문이죠.

하지만 회사 프로젝트는 규모가 상당합니다. 누군가 퇴사해도 프로젝트는 꾸준히 돌아가야 하며, 유지보수 또한 잘 되어야하죠.

이런 면에서 문서화는 제 생각보다 더 중요했습니다. 일회용으로 쓰고 버려질 코드가 아니라면 내가 개발한 것은 언젠가 쓰이게 됩니다. 이때 문서화가 되어있지 않으면 그 구조를 이해하기 쉽지 않습니다. 더군다나 새로운 기능을 추가할 경우 그 기능만 문서화하면 되지만, 기존에 있던 구조를 바꾼다면 문서화할 내용은 더 많아집니다.

문서화라는 것이 사소한 부분 같지만 신입 입장에서는 해당 도메인의 히스토리를 알 수 있어서 그 도메인을 이해하는 데 큰 도움이 됐었습니다. (특히 이해를 돕기 위한 그림 or 스크린 샷이 있고, 없고 차이가 컸습니다!)

문서화의 좋은 예시(보안상 블러처리). 그림과 함께 자세히 설명해주셔서 어떤 이슈인지 금방 알 수 있었다.

사실 이렇게 이야기해도 각자 일정도 있고 다른 업무도 있는 만큼 자신이 개발한 기능 하나하나 모두 문서화를 하는 건 어려운 일이죠. 그래도 추후에 입사를 하시는 분이 내가 작성한 문서를 보고 빠르게 적응할 수 있다면 그만큼 기쁜 일은 또 어디 있을까 싶습니다. 이렇게 문서 작성에 힘을 기울이다 보면 나의 가치가 더 높아지지 않을까요? 😁

3. 내게 주어진 업무부터 잘하자

저는 드림어스컴퍼니에 입사하자마자 개발하고 싶은 마음이 굴뚝같았습니다. 모든 팀원을 만났던 입사 첫날부터 빨리 개발해보고 싶다고 이야기할 정도로요.

그러나,

막상 레거시 코드를 만나니 어디서부터 어떻게 개발해야 할 지 하나도 감이 잡히지 않았습니다..😥

그 와중에 잘하고 싶은 욕심은 커서 회사 내부 스터디뿐만 아니라 다른 외부 스터디까지 2개를 동시에 참여했습니다. 그러다 보니 회사 일, 회사 내부 스터디, 외부 스터디 등 해야 할 일이 너무나 많았습니다.

물론 회사 일을 최우선순위로 두고 진행하긴 했지만 다른 스터디도 놓치기 싫었습니다.

(지금 생각해보면 그만큼 욕심이 많았던 것 같아요.)

결국 두 마리 토끼를 잡으려다 다 놓친 격이 되어버렸고, 어느 하나 제 마음에 들 만큼 결과물이 나오지 않았습니다. 회사 일과는 별개로 제가 벌여놓은 일로 스트레스만 쌓여갔죠.

야심차게 시작했던 DDD Study. 그래도 DDD를 잘 모르겠다ㅠ

게다가 외부 스터디를 참여하면서 새로운 인사이트를 배우는 건 좋았지만 사용해볼 기회가 없어 자연스럽게 잊히기 쉬웠습니다.

회사에 처음 들어오는 신입이라면 회사의 도메인 혹은 구조를 이해하는데 집중하고 이슈를 처리하는 것을 최우선순위로 삼는 게 좋다고 생각합니다. 만약 외부 스터디를 한다면 현재 쓰고 있는 기술에 대한 스터디를 하는 것이 베스트일 것 같습니다.

4. 개발 문화를 직접 만드는 사람이 되자

저는 다른 회사 면접을 볼 때 항상 이런 질문을 했었습니다.

"코드리뷰 문화는 활성화되어있나요?"

"테스트 코드가 많이 작성되어 있나요?"

회사의 개발 문화가 이미 정착되어있는지에 대해 집착하듯이 질문했죠.

그런데 입사 후, 일을 하다 보니 문득 그런 생각이 떠올랐습니다. 내가 원하는 개발 문화를 너무 바라기만 했던 것은 아닌지 말이죠.

"만약 회사에 그런 문화가 없다면 내가 직접 건의하고 만들어보면 안되나?" 라는 생각이 들었습니다.

감사하게도 드림어스는 CTO와 이런 이야기를 자유롭게 할 수 있는 분위기가 형성되어있어요. 업무 진행 상황을 함께 확인하는 Weekly 문화도 있고, 영어 닉네임을 쓰다 보니 리더와도 편하게 의사소통을 할 수 있죠.

실제로 최근에 외부에서 스터디를 하다가 Feature Freeze라는 문화를 알게 되었는데요. Feature Freeze는 일정 기간 동안에는 새로운 기능을 추가하지 않고 소스코드를 리팩토링한다거나 소스코드를 살펴보는 등 프로그램의 안정성을 높이는 것을 말합니다.

생각보다 괜찮은 작업이라 생각이 들었고 Tech 팀에도 적용하면 좋을 것 같아 CTO에게 우리도 Feature Freeze라는 문화를 적용해보자고 직접 말씀을 드렸습니다. 그 결과, 제 의견이 반영되어 올해 말에 Feature Freeze 작업이 예정되어있습니다. 😀

회사에 이미 정착되어있는 개발 문화를 바라기보다 적극적으로 회사의 기존 문화를 개선하고 더 나은 방향으로 이끌어 나갈 수 있는 태도야말로 더 나은 개발자가 되는 길이 아닐까요?

'내가 경험하고 싶은 회사 문화는 내가 직접 만들어간다'는 마인드로 적극적으로 이야기하고 팀원들과

함께 고민해본다면 그만큼 회사의 성장에 도움이 되리라 생각합니다.

지금까지 제가 드림어스컴퍼니에서 신입개발자로 4개월을 지내보며 느꼈던 점들을 적어보았는데요.

아래 내용들로 요약할 수 있을 것 같습니다.

• 일정 산정 시 업무를 세분화 하자

• 문서화를 잘하자

• 내게 주어진 업무부터 잘하자

• 개발 문화를 직접 만들어보자

위 내용들은 이미 많은 분들이 알고 계시거나 당연한 이야기일 수도 있겠지만, 입사 4개월차 신입 개발자인 저에게는 이런 부분들이 앞으로 잘- 성장할 수 있는 밑바탕이 되었다고 생각합니다. 🙂

긴 글 읽어주셔서 감사합니다!