[ WIL ] 6-5 지난 날들의 요약, 프로덕트 개발과 일정 그리고 코드품질, 상반기 회고 OKRs를 돌이켜보며, 내가 생각하는 스타트업과 최소한의 아키텍처

이번 6월, 새롭게 이사하게된 FRONT1. 벌써 집보다 더 편해진 듯하다.

 

벌써 6월의 마지막 주말이다. 매번 회고 글을 작성할 때면 드는 생각이 시간이 정말 빠르다. 빠르게 지나가는 시간을 잘 보내기 위해 회고글도 사실 꾸준히 작성해고 있었는데, 완성을 다 해내지 못했다. 그래서 임시저장 상태로 남아있는 글이 4개나 존재한다..

 

매주 금요일 저녁 초안을 작성하고, 일요일날 마무리를 하는데, 지난 3주동안에는 일요일날 모두 일에 전념하여 글을 완성하지 못했다.  임시저장된 글을 과연 내가 완성할 수 없을 듯하여, 해당 내용은 삭제하고, 지금이라도 간략하게 요약, 정리를 해두어야겠다.

 

정리는 시간의 흐름은 아니다. 내가 생각나는 순으로, 또 내가 정리하고 싶은 순서일 뿐임을 미리 이야기한다.

 

• 프로덕트 개발과 일정 그리고 코드 품질
• 상반기 회고 OKRs 를 돌이켜보며
• 내가 생각하는 스타트업과 최소한의 아키텍처

 

---

프로덕트 개발과 일정 그리고 코드 품질

 

우리 팀이 운영하는 "큐리어스"

 

 

지난 6월은 우리 팀 자체가 정신이 하나도 없는 한달이었다. 사무실 이사에서부터, 굵직한 개발 건들( 5월달부터 시작한 메인 프로덕트(이하 어울림)의 개선 작업)을 큰 축이외에 잔가지의 다양하고 많은 업무가 존재했다. 

1. 어울림 등록 개선에 대비한 결제 프로세스 개선 작업: 트랜잭션, 슬랙 연동 등 + 수 많은 핫픽스 건
2. 어울림 등록 프로세스 개선 작업: 프론트엔드(퍼블리싱, JS 작업, 백엔드 연동) 백엔드(API 스펙 설정, 로직 개발, 트랜잭션, 예외처리), QA

 

이번 진행한 작업들에 대하여, "기술적인 성장을 이뤄냈는가?" 에 대한 솔직하게 나는 아니라 생각한다. "내가 가진 지식을 활용" 했을 뿐, "새로운 기술을 익히거나", "기존 기술의 숙련도가 증가" 했다는 생각은 들지 않는다.

 

다만, 이번 경험을 통해  "앞으로 현 회사(미션드리븐)에서의 나의 역할과 책임" 에 대해서는 분명히 알 수 있었다. 

 

나의 역할과 책임

나는 개발자이다. 조금 더 구체적으로 이야기를 한다면, 나는 서버 개발을 하는 것으로 현 회사 입사를 했다. 입사 3개월차에 접어 들며 내가 생각(기대)한 역할과 책임에 대한 변화를 정리해보면 다음과 같다.

• 입사 이전: 서버 개발자로서, 백엔드 API 를 개발하고, 현재(입사 당시)의 서버의 안정성과 유지보수성을 증진시키기 위한 다양한 업무를 진행한다.
• 현재: 풀 스택 개발자로서, 짧고 빠른 개발주기, 다양하고 많은 비즈니스 액션을 지원 할 수 있도록 하는 업무를 진행한다.

어찌보면, 현재 파악한 나의 역할과 책임이 입사 이전, 내재되어 있었을지도 모른다. 그러나 같이 일하는 동료 개발자분과 이야기를 해본 결과, "입사 이전 생각이 맞으나, 상황을 고려할 때, 현재 파악한 역할과 책임을 조금 더 요구하게 되는 상황" 이라고 한다.

 

이와 관련하여, 나는 많은 생각을 하게 되었다.

 

나에게 기대하는 역할과 책임은 이러한데(현재에 정리한 내용) 나는 그런 사람인가? 그렇지 않다면 그렇게 될 수 있을까?

 

나에게 기대하는 역할과 책임이 달라졌다는 것을 알게되었을 때, 나는 불안했다. 사전에 협의된 내용을 넘어선 내용이었고, 이를 당장 내가 해낼 수 있는 사람인가? 에 대하여 스스로 질문하였을 때, 나는 확신을 하지 못했기 때문이다.

 

하지만 조금 더 생각해볼 때, 나는 이런 "도전이 있어야 성장하고, 결국 해낼 수 있을 것" 이라는 생각에 도달하게 되었다.(이하 결심) 이 결심 후, 나는 이젠 이것을 해내기 위해선 어떻게 해야하지? 하는 생각으로 진화하게 되었다.

 

"결심" 에 도달하는 과정에서,  "과거, 팀에 합류하기 이전 내가 기대한(?) 챌린지가 이것이 아닐까?" 하는 생각도 들었다.

 

 

이후, 나의 역할을 다하기 위해서, 그리고 그 이상을 해내기 위해서는 어떻게 해야할까? 에 대한 고민을 하게 되었다.

 

현재 스스로 인지한 나의 문제점은,  시간(일정) 관리가 잘 되어지지 않는 다는 것이다. 조금 더 구체적으로 이야기를 한다면, 수 많은 작업목록에 대하여, 특정 작업 A가 얼마나 걸릴지 예측하고, 실제 그 기간안에 업무를 끝내는 것이 힘들었다.

 

모든 만인 직장인의 고민이자 풀어내야할 숙제일텐데, 내가 생각하기에 현재 나의 가장 큰 문제점은 시간 관리라고 생각하게 되었다. 그리고 나는 이를 해결하기 위해 짧지만 많은 고민을 하였고, 가장 쉬운 방법이면서 효과적인 방법을 정리하고 시도해 보았다.

• 뽀모도로 타이머를 통한 정해진 시간에 특정 업무를 마무리하기
• 업무를 이전보다 더 세분화하여 트래킹 및 기록하기
• 업무를 진행하면서, 도움을 적극적으로 요청하기

 

뽀모도로 타이머 사용기

집에서공부할 때, 내 책상의 모습. 업무 할 때에도 모습은 동일하다.

 

 

 당장 타이머를 사서 사용하기에는 시간이 없었고, 다행히도 아이패드 앱이 존재하여, 바로 적용해 볼 수 있었다. 뽀모도로 타이머 액션의 효과는 만족스러운 부분(P), 아쉬운 부분(C)이 존재했고, 이에 대한 나의 회고는 만족이라고 이야기 할 수 있다.

• P: 정해진 시간 내에 끝낼 업무를 정리하면서, 업무를 좀 더 세분화 할 수 있었다.
• P:정해진 시간을 준수하기 위해 나는 좀 더 스스로 동기부여 및 업무에 집중할 수 있었다.
• C:업무에 대한 시간 할당이 실패 할 경우, 이후 일정이 무너지는 경우가 빈번히 발생했다.(끊임없는 디버깅으로 인한 다른 업무 진행 불가)
• C:작업단위(45분)에 대한 시간 관리는 되었으나, 전체(약 10시간)에 대한 시간 추척은 이뤄지지 않았다.(시간을 효율적으로 사용했는가? 에대한 답을 얻을 수 없었다.)

 

 

뽀모도로 타이머를 통해 시간을 관리하는 것 뿐만아니라, 업무를 좀 더 세분화 할 수 있었다. 그리고 업무를 세분화하면서 나는 내가 현재 모르는 부분을 사전에 식별할 수 있었다. 궁극적으로 나는 스스로  더 고민할 시간을 확보할 수 있었고, 모르는 부분을 분명히 하여, 도움을 요청할 수 있었다.

 

그리고 더 나아가, 앞으로의 숙제도 파악할 수 있었다.

• 추상적인 표현 줄이기.(이것, 저것 사용 줄이기)
• 고민할 시간 또한 제한하기
• 협업에서 필요한 부분에 대해 좀더 깊이 생각해보기

 

그러나 앞으로의 숙제 말고도 다른 굉장히 중요한 문제에 직면하게 되었다. 그것은 "코드 품질과 개발 일정 사이에서의 트레이드 오프" 였다.

 

코드 품질과 개발 일정 사이의 트레이드 오프

레거시 코드 하면 이런 무서운 이미지가 보인다.. 레거시 코드는 무시무시한 놈인게 분명하다.

 

흔히 개발 일정에 맞추다보면, 자연스럽게 기술 부채가 생기고, 코드의 품질이 저하된 "레거시 코드" 를 맞이하게 된다. 하지만 레거시 코드에 대한 정의는 조금 다양한 듯하다. 그리하여 개인적으로 레거시 코드에 대하여 스스로 정의 했는데,  "레거시 코드란 수정하기 두려운 코드"라고 정의 했다.

 

그리고 나는 가능하다면 레거시 코드를 최대한 줄이고자 하는 것(살아있는 코드)이 개발의 목표라고 생각하며 개발을 해왔다. 그러나 매우 짧은 개발주기와 이와 상반되는 수 많은 개발 업무에서 나는 이러한 목표를 상당 부분 많이 놓치게 되었다.

 

이와 관련하여 함께 일하는 동료 개발자분과 이야기를 할 때면, "보이스카우트 정신" 으로 "레거시 코드는 발견할 때 마다 리팩터링을 진행합니다!" 라고 비장하게 이야기를 했으나, 레거시 코드를 건드는 일 자체가 현실적으로 굉장히 어려운 일이라는 사실을 알게되었다.(테스트 코드가 없다면 더욱 더)

 

 

리팩터링 조차 어려운 코드를 작성한다면?

 

나는 이 부분이 가장 힘들었다. "빠른 개발을 한다 하고 있는데, 과연 이것을 빠른 개발이라고 할 수 있을까?" , "현재 잘못된개발을 하고 있는 것은 아닌가?" 하는 생각이 굉장히 많이 들었다. 

 

실제 불과 작성한지 2주도 안된 코드를 다시 수정해야할 때, 진짜 억장이 무너질 뻔했다. 불과 2주밖에 안된 코드가 레거시가 되어있다니, 내 자신에게 화도 많이나고, 개발자로서 자책도 많이 하게 되었다.

 

그러나 고난은 여기서 끝나지 않았다. 더 힘들게 한 것은 현재 "매우 촉박한 일정 속에서 코드를 개선할 수 없다는 것 + 앞으로도 이러한 결과물이 예측된다는 것" 이었다. 이 악순환을 끊을 해결책을 고민해보았는데, 가장 현실적인 방법은 "기획자와 조율하는 방법" 이 최선인듯하다.

 

현재의 문제의 원인도 생각해보면, 기획이 점점 커지면서 처음 산정한 일정보다 더 많은 시간이 필요하게 되었고, 리소스가 더 많이 사용되었으며, 너무나도 짧은 일정 탓에 현재의 코드와 문제가 발생한 것으로 파악된다. 솔직하게는 이에 대하여 깊은 고민을 하진 못했지만, "기획자와 조율하는 방법" 이 가장 최선의 방법이 될 듯하다.

 

 

기획에 대한 공부를 하기 위해 출퇴근 길 독서를 진행하고 있다. 현재 읽고 있는 책의 제목은 "서비스 기획의 기술" 이다.

그리하여 어덯게하면 기획자와 효율적인 소통을 할 수 있을까? 에 대한 고민에서 시작으로, 기획자와 개발자 모두 프로덕트를 만들어간다는 공통점을 갖고 있기에 프로덕트 기획에 대한 공부(독서)를 하기 시작했다. 

 

이미지는 책의 일부분인데, 책은 굉장히 많은 생각을 하게 하는 부분들이 많았다. 이와 관련하여 책의 내용도 정리를 해야겠다.

 

 

---

상반기 회고 OKRs 를 돌이켜보며

 

상반기 회고에 대한 내용은 사실 5월 마지막 주 5-5 WIL에서 작성 중인 내용이다. 그러나 내가 5-5 내용을 완성하지 못하면서 해당 내용을 정리하지 못했다..비록 완성하지는 못했지만, 해당 내용을 잊고 가기엔 너무 아쉽기에, 2분기 회고 겸 상반기 회고를 진행해본다.

 

올해 초 작성한 OKRs

 

나는 올해 초, 에이블랩스에서 OKR이라는 것을 처음 알게되었고, 이것이 나에게 굉장히 도움이 될 수 있을 것이라는 생각이 들었다. 

• 구체적인 목표를 세움으로서, 긴 시간의 여정에서도 목표를 잃지 않고 북극성으로 활용 할 수 있다.
• 목표를 세우고 해냄으로써 스스로 성취감과 만족감을 얻을 수 있다.
• 결과물을 남김으로서, 내 자신에게 유용하게 활용할 수 있다.