Start-Up Start-Developer (회고)

박우영·2024년 1월 28일
0

history

목록 보기
1/1

Overview

2023.11.06 입사 후 Repository 생성 ~ CBT 까지 경험하며 느낀점 입니다.

모종의 이유 컨벤션 레벨의 코드리뷰만 받으며 Crechat Service 의 기능을 혼자 구현하게 되었습니다.

입사하고 1달뒤 프리베타? 그것도 혼자서? (2023-11-16)

12월 15일 알파테스트, 12월 18일 Pre-Beta 테스트가 잡혀있었고 체육대회, 온보딩 등 인사 일정과

매일 진행하는 1~2시간의 회의가 일정에 잡혀있어 A to Z 까지 진행하며 서비스를 배포하기엔 시간이 부족 했고, 저는 일정을 맞추기 위해 다음과 같이 우선순위를 선정 하였습니다.

Java가 주 언어긴 하지만 Kotlin은 처음사용하는 언어다 보니 기능을 구현하며 언어를 학습해야만 했습니다.

처음 접하는 언어, 낯선 환경에서 하는 개발이기 때문에 흔히 말하는 clean code 와 test code 를 포기하였습니다. 그 이유는

  • 1인 개발이기때문에 본인이 flow 를 이해하고 있다면 side effact 를 최소화 할 수 있다.
  • ktlin 와 detekt 로 최소한의 Convention이 잡혀있고, Coding Convention 이 확립되지 않았다.
  • 사내 테스트에서 Pre-Beta 간의 주말이 있어 refactoring이 가능하다.
  • 이미 정해져있는 일정안에 맞추는것이 더 중요하다.
  • 개발을 하는중에도 요구사항은 변경된다.

아직 완전한 시스템이 갖춰지지 않았고 이를 만들어 나가는 시점에서 코드 품질을 낮추더라도 기능 구현에 우선순위를 두고 개발하기로 결정하였습니다.

Pre-Beta 끝 그리고 기술부채 (2023-12-29)

Pre-Beta를 마치고 저의 기술부채는 다음과 같습니다.

이는 시간이 없다는 면죄부라고 생각하지않고 스스로의 피드백, 임시 조치를 회고 하며 더 좋은 서비스를 개발하기 위해 어떤것들이 필요했는지 말씀드리고자 합니다.

  • 배포전략 미구축
    • 사용자 feedback을 받고 개선/추가 된 사항을 배포하기 위해선 현재 이용하고 있는 사용자가 있는지 확인하고 배포를 해야 하며, docker 가 재시작 되는 시간동안 사용자가 이용하지 못함
  • 클린 아키텍처 미준수
    • 서비스의 요구사항에 따라, 문제점을 개선하기 위해 여러가지 MySQL, Redis, DynamoDB, 외부 API 연동 과 같이 해당되는 OutPort 가 바뀌고 비즈니스 로직이 바뀔때마다 Side effact를 고려 하는 공수가 더 크게 발생함
  • 낮은 테스트커버리지
    • 요구사항이 변경, bug fix로 인해 코드 수정이 이뤄지면 낮은 테스트 커버리지로 인해 Side effact가 발생 하는 경우도 있었음, TDD 가 물론 좋은 개발방법론 이긴하나 숙련도가 낮고 익숙하게 사용하기 위해선 개발 기간이 너무 짧아 개발 후 테스트 커버리지를 높이고자 함
  • 낮은 확장성 과 무결성 결여
    1. 대화 내역과 채팅방에 관련된 내용을 Local Cache 에 저장
      1. 채팅 중 서버가 재배포 이뤄진다면 사용자는 대화기록을 확인하지 못함
    2. 실시간 채팅을 위한 WebScoket Connection 관리를 Local 에서 실시
      1. Scale-out 됐을 시 실제 매칭이 가능한 작업자가 있음에도 사용자는 대기해야 함
  • 동시성 문제
    • 채팅을 마치고 채팅방목록을 불러오지만 최근 채팅내역이 채팅방에 Update 가 이루어지기 전에 이루어짐
  • 강한 결합의 시스템 아키텍처
    • 인증을 담당하는 서버가 다른 서비스에 dependent 하게 이루어져 있다보니 서비스의 수정이 생길때마다 인증서버 또한 update가 이루어져야 함

CBT (2024-01-15)

기능 구현이면 기능구현이지 CBT 대응기라고 한 이유는

  • CBT 전용 Spec
  • Pre-beta 직후 실제 Production 환경과 동일하게 해달라는 요구사항
  • Pre-beta 의 기술부채를 갚아 나가는 과정과 병렬적으로 이루어져야함

모든 기술부채를 해결하기엔 리소스가 너무나 부족했고, CBT 요구사항에 맞추는걸 우선순위에 두고 같이 해결할 수 있는것은 클린아키텍처 를 적용하며 각 Layer 간 의존성을 줄이는 것 이었습니다.

비즈니스와 엔지니어링의 Trade off

Input Port 와 OutPut Port 즉 API, DB, 비즈니스 로직이 모두 변경이 되어야 하는 작업량이 적지 않은상황에서 Pre-beta, CBT 를 경험해보니 Best Practice 를 추구하며 높은 코드 퀄리티를 추구하는 것도 중요하지만 코드의 가치를 창출하기 위해선 외부 IP 등 비즈니스 적으로 많은 관계들이 있기때문에 높은 코드 퀄리티 보단 빠른 기능 구현이 더 가치 있다고 생각하였습니다.

CBT 까지의 회고

기획팀의 요구사항에 맞게 모든 기능이 구현이 CBT 까지 성공적으로 마쳤지만 많은 기술 부채를 가지게 되었고 부채들을 갚아나가며 발생할 수 있는 human error 를 어떻게 최소화 할수 있을지 현재는 막막하지만 Enterprise 급 Production 의 코드에 모든 기여를 할 수 있다는 값진 경험을 할 수 있었습니다.

profile
박우영
:)

0개의 댓글