회고 1/ 입사 1주년, 어디까지 왔나

개발자로 직무 전환 후 취업까지 1년이 걸렸다. 2개월의 직업 탐색 및 기초 학습, 6개월의 교육(국비지원), 그리고 4개월의 그룹 스터디 끝에 22년 10월 백엔드 개발자로 취업했다. 취업 후 1년이 지났고, 다시 이력서를 수정하며, 새로운 회사에 지원하고 있다. 여전히 서류 통과는 쉽지 않고, 이번주에도 서류 탈락을 경험했다. 변화가 필요하다고 판단했다. 회고를 통해 지난 1년을 점검하고, 목표를 수정해야겠다.

지난 1년

입사 초기부터 노션에 업무일지를 적어두어 시기마다 맡았던 업무를 구체적으로 알 수 있었다.

1. 입사 초기 (22.10 ~ 22.12)

입사 첫 주는 개발 환경 설정 및 업무 파악을 위한 시간이었다. 윈도우 복구 드라이브 만들기, 프린터 설정, 공유기 설정, Git, Mantis, NAS 계정 신청, 팀 업무 숙지, 운영 중인 서비스 소스코드 빌드 및 테스트베드에 배포, SSL 인증서 테스트, PC에 각종 프로그램 설치, MariaDB, VPN 계정 신청 등 정신없이 지나갔다. 셋탑박스 미들웨어를 제조하는 회사로 방송 관련 업무 숙지가 관건이었다. 쏟아지는 방송 용어에 필기하기 바빴다. 틈나는대로 회사 문서들을 뒤적이며 용어를 숙지했다. 첫 업무는 서버 이전 설치를 지원이었다. 고객사의 온프레미스 환경 서버 이전을 지원하는 업무였다. 라운드로빈이 적용된 서버 2대 중 1대를 스탑시키고 정상동작 하는지 확인, 스탑시킨 서버를 먼저 이전한 후 서비스 재가동, 설정 IP 변경, DB 백업, 클러스터링 설정, 모니터링 서버 설정 등의 업무였다.

개발을 리눅스로 시작했는데, 업무용으로 윈도우가 필요했다. 윈도우에 익숙해지는데 소소하게(사실 많이) 시간이 필요했지만, 다른 OS도 경험해볼 수 있어 오히려 좋았다. 나의 모든 경험이 앞으로 개발자로 살아가는데 다 필요할거라고 생각해서 어떠한 경험이든 긍정적으로 받아들이고 있다.

2. 프로젝트 1단계 (22.11 ~ 23.01)

기획 및 초기설정까지 진행 된 프로젝트에 투입되었다. 셋탑박스를 원격으로 제어하고 펌웨어 업그레이드 시스템을 관리하는 웹 사이트를 개발하는 프로젝트였다. 프로젝트 투입 인원은 백엔드 개발자이자 PM인 사수, 나, 셋탑 클라이언트 개발자 1명, 그리고 외주사 프론트 개발자 1명, 총 4명이었다. 초기 기획자는 퇴사한 상태이고, 프론트는 외주에 맡겨졌다. 잘 모름에도 좋지 못한 상황같았다. 초기에 프로젝트에서 맡은 업무는 개발된 코드 분석, 기능 숙지, 에러코드 정리, API 테스트, 프론트 정합 후 개발 테스트, 프론트 외주 관리 등을 맡았다. 쉽게 말해, 정식 개발 빼고 모든 잡무를 맡았다. 그 중 프론트 외주 관리는 참 곤혹스러웠는데 원인은 아래와 같다.

1. 스프린트 일정을 지키지 않는다. (개발 일정동안 연락없이 늦은 날이 10 중에 9.5이다.)
2. 추가 기능 구현 시 사이트 이펙트가 정말 많다. (추가 기능이 구현되거나 이슈 수정 시, 무조건 통합테스트를 했다. 심지어 혼자 진행했다.) 어제 멀쩡했던 A 기능이, B 기능을 추가하자 먹통이 되는 상황이 잦다보니, 어제는 됐는데, 오늘은 왜 안돼요? 이 말을 사수한테 정말 많이 들었다.
3. 태스크 정리 및 연동 가이드 등의 문서 작업이 늘었다. (마음대로 태스크를 줄여서 개발하여, 태스크 리스트를 작성해 전달했다.) 그 때문에 매주 온라인 미팅을 통해 개발 가이드를 했고, 잦은 가이드로 결국 스토리보드 + 유즈케이스 + 연동 가이드 이 모든 것이 혼합된 ppt 가 탄생하기도 했다.

인상적이고 아찔한 외주 개발자

테스트 중 프론트에서 불필요한 요청이 서버로 보내지는 기능들을 확인했다. 외주 개발자께 ‘이 요청을 여기서 보내신 이유가 있나요?’ 라고 질문했더니 말씀하시길, ‘개발하는데 너무 많이 간섭하면 개발하기 힘들다’였다. 벙찌는 대답이다. 쿼리 결과가 적게는 수천에서 많게는 수십만이 될 수도 있다.(물론 100개로 limit을 걸어뒀다.) 굳이 불필요한 요청을 서버에 보내서 리소스를 낭비하는 것은 옳지 못한 방식이라 생각했다. 추후 코드를 보니, 그저 본인의 개발 편의성을 위해서라고 밖에 생각되지 않았다.

다른 문제도 있었다. 기획이 이미 끝났음에도 고객사의 추가 수정사항이 많았다. 그로 인해 개발 도중 기획이 변경되는 일이 많았다. 기획자가 없으니 UI/UX를 직접 고민할 수 밖에 없었다. UI/UX는 정말이지 지식이 부족해 프로젝트가 산으로 가는 것은 아닌가 걱정이 많았다. 그럼에도 이때, 기획자 롤을 겪었기 때문에 개발 프로세스 전반의 이해도는 높아졌다.

(1월엔 회사에서 맥미니를 지원해주면서, 드디어 맥OS를 사용하게 되었다.)

3. 프로젝트 2단계 (23.02 ~ 23.06)

1단계에서는 백엔드, 프론트엔드 디버깅 후 코드 수정을 하는 정도였다면, 이때부터는 개발에 적극 참여했다. 로그 관리하는 기능을 추가 개발하게 되었는데, 데이터 모델링, RestAPI 개발, 그리고 UI까지 직접 만들었다. 기능을 추가로 설명해보자면, 다음과 같다. 서비스 운영 시 각종 로그가 쌓인다. 로그는 리소스 관리 차원에서 가치가 없거나 보관 기간이 지나면 삭제해야 한다. 로그 관리를 GUI에서 쉽고 간편하게 하기 위해 로그 관리 페이지를 만들었다. 아래 이미지와 같이 DB 접근없이, 테이블 이름, 컬럼, 보관 기간을 설정하면 로그가 보관기간 이후 자동삭제 된다. (사실 ‘DB 접근없이’ 라는 표현이 적절하지는 않다. 테이블이름, 컬럼명을 알아야 한다. 하지만, CLI로 직접 관리하는 것과 비교하면 쉽다는 표현이다.)

해당 기능을 구현하면서 STORED PROCEDURE 와 RANGE PARTITIONING을 처음 사용했다. 파티셔닝을 위해 많은 쿼리가 필요했기 때문에 프로시저를 사용했다. 파티셔닝은 데이터 삭제 시, 일반 DELETE 쿼리보다 DB부담을 줄일 수 있다고 하여 사용했다. (해당 부분은 추후 직접 테스트 해보면 더 좋겠다.) 추가로, MySQL 이벤트를 사용해 새벽 4시마다 프로시저 실행되도록 했다. 정리하자면, 로그 보관 기간을 설정해두면 일별 파티션을 생성하고, 보관 기간이 지난 파티션은 삭제되는 프로세스다.

user manual, frontend development guide 산출물 작업까지 완료하며 프로젝트가 마무리됐다.

3. 프로젝트 고도화 (23.07 ~ 진행 중)

3가지 서비스에 관해 고도화 작업 중이다.

1. EPG 파일 파싱 및 저장, 프로그램 가이드 업데이트에 스프링 스케줄러 적용
2. 개인화 대시보드 및 공유 기능 추가, 렌더링 소스코드 프론트로 이동

3. 로그 파티셔닝 상용 서비스에 적용

빠르게 지나간 1년을 되짚어보니 생각보다 글이 길어졌다. 점검과 목표 설정은 회고 2로 나누어 마무리해야겠다.