이직 3개월차 회고
인간은 적응의 동물
이직 초반에 어렵다 여겨졌던 아키택쳐와 RxKotlin, Git과 배포, 여러 협업 툴들이 이제 익숙해지고 있다.
기술적인 부분에서 못따라가면 어쩌지 하는 걱정은 괜한 조바심이었고, 도메인지식은 금방 습득한다고 생각했던 과거는 건방진 생각이었다는 것을 느낀 3개월이었다.
생각보다 디테일한 상황들을 고려한 도메인 로직들은 History를 들을 때마다 만들어진 이유에 대해 납득할 수 있었고, 회사에서 운영하는 여러 앱(Vroong Agent, Vroong Friends, Vroong Pos, Vroong Rider, Vroong Manager)이 가진 디테일한 로직과 차이(데이터 갱신주기, 모듈 구성, DI, 아키텍처 등등 다르게 구성되어있음)들을 알아가고 있는 단계이다.
어떤 기능의 추가나 유지보수 또는 개선을 위해 들어오는 요구사항에 대해 분석하고 적용하는 과정은 퍼포먼스가 조금씩 나오기 시작했다. 회의에 들어가기 전, 필요한 정보를 수집하고 변경점 전반을 미리 분석해 최대한 나의 약점(백지수준의 History)을 보완하며 업무에 임하고 있다.(노력은 당연... 잘해야할텐데...)
슬금슬금 적응하며 어떤 업무를 어떻게 했는지 회고해보자.
잘못된 점과 실수는 회고를 통해 반복하지 않도록 하자.
또한 개선점을 찾아, 앞으로 어떤걸 녹일 수 있을지 계획을 세워보고 의식적으로 커리어를 쌓아가고자 한다.
1. 업무 정리
모바일팀은 함께 모든 도메인을 관리하는 방식으로 업무를 진행하고, 모두가 서로의 코드를 리뷰하며 서비스를 발전시키고 있다. 모든 서비스를 같이 바라보기 때문에 모두가 적당한 이해도를 가지고 있고, 소스 수준을 맞춰갈 수 있었다.
- 이슈 대응
: 실사용자가 시스템 사용중 생기는 이슈 처리 - 리팩토링
: Legacy 구조로 되어있는 프로젝트를 최근 프로젝트의 구조로 변경하여 관리 용이성을 목적으로 리팩토링을 진행함 - 신규 기능 구현
: 비즈니스상 or 사용자 요구사항에 맞는 신규 기능 구현 - 기존 기능 스펙 변경
: 기존에 사용했던 외부 api를 더 이상 제공받을 수 없어 사용하고 있던 스펙을 변경하게 됨 - 형상관리 + 배포
: 팀에서 사용하는 브랜치 전략과 배포 자동화 툴(현재 bamboo)을 사용하여 배포하고 그 과정을 프로세스에 맞춰 전달
대표적으로 5가지 업무를 수행하며 더 관리가 편하고 이슈가 생기지 않는 구조를 만들기 위해 모두가 함께 고민하며 서비스를 발전시켜나가고 있다.
2. 시행착오
Legacy프로젝트를 기준으로 기존 기능 스펙 변경 업무 중에 단위테스트부터 도입하면, 데이터 처리 부분은 안드로이드 애플리케이션 프로세스를 진입하지 않고 확인이 가능 -> 개발 속도를 개선할 수 있을 것이라 판단하여 유닛테스트 모듈을 만들었다.
결과: 실패...
안드로이드 context와 객체간 의존성이 크게 걸려있어 당장 테스트를 할 수 있는 부분이 제한적이었다. 의존성을 걷어내는 상황이 현재 일정에 맞지 않다고 판단하여 방향을 다시 돌려 업무를 최우선으로 처리했다.
원하는 요구 스펙에 맞는 결과물을 일정내에 처리할 수 있었지만, 테스트를 위한 고민에 꽤 많은 비용을 소모했다.
사실 어떤 업무든 고민을 통해 개선하는 과정은 필요하고 감당할 수 있는 실패는 성장의 자양분이라 생각한다. 그러나 이번 소요는 도입을 하기 전에 먼저 소스를 분석하고 판단했으면 어땠을까하는 아쉬움이 있다. 테스트 도입을 최근에 만든 프로젝트에 시도해보면서 적용했으면 더 좋은 효과를 기대할 수 있지 않았을까한다.
이 과정을 다른 팀원들과 함께 전체적으로 개선하면 좋겠지만 현실적으로 팀에 주어진 과제가 먼저 완료되어야 할 것이라 생각된다. 다만, 내가 적용해서 개선된 점을 객관적인 수치로 보여주고 이를 전파하여 모바일팀의 전체적인 생산성 향상에 기여하는 것을 기대한다.
3. 성장 경험
1) 잘못된 설계 확인 및 개선
: 예전 소스들을 보면 처음 생각했던 설계와 다른 방향으로 서비스가 진행되면서 기존의 설계가 개발과 유지보수에 방해가 되는 경우가 생길 수 있다. 그리고 잘못된 설계라는 것을 감지했을 때도, 지금 당장은 그 설계를 따라가면 본인이 맡은 업무를 가장 빠르게 쳐낼 수 있다... 그러나.. 이 설계를 기준으로 계속해서 서비스가 확장되면 확장되는만큼 계속해서 필요없는 인터페이스와 관리포인트들이 늘어날 것이 뻔히 보인다.
이 때, 개발자의 역량에 따라 업무를 처리하는 방향이 많이 달라질 것 같다.(문제가 있는지 발견도 못하고 기능 구현에 급급하면 실력 향상에 더~욱 신경쓰자...)(나도 실력 향상에 신경쓰자)
일정 내에 개선된 설계를 소스 전체에 적용하는 것이 가장 좋은 방법이겠지만 현실적으로 불가능하다면 어떻게 해결해야할까?
기존 설계 그대로 빠르게 일을 쳐내고 쉴 수도 있고, 과도한 일정을 잡거나 일정을 지연시키고, 모든 코드를 리팩토링할 수도 있다.
나는 일정내에 해결할 수 있는 수준이 어느정도인지 파악하고, 관리포인트를 최소화할 수 있는 방향으로 코드를 개선하는 방법을 선택했다.
-> 개선 사항을 찾아 어떻게 개선했는지 기록.
개발자는 코드만 짜는 사람이 아니라 현재 비즈니스를 풀어나가기 위해 가진 리소스가 어느정도인지 파악하여, 어떻게 활용하여 어떤 해결방안을 낼 것인지, 개선할 수 있는 것은 어떤게 있는지를 끊임없이 고민하는 역할이라 생각한다.
2) 서비스 회사에서 필요한 능력에 대해 다시 생각함(기술적 역량 + 커뮤니케이션 역량)
: 회사에서 개발을 하며 기술적인 부분에서 많이 성장했음을 느꼈지만, 실제로 업무에서 의사소통 능력에 따라 내 퍼포먼스 차이가 많이 날 수 있음을 많이 느꼈다. 개발자는 어떤 요구사항에 따라 구현해주는 것이 전부가 아니다.
(1) 구현하는 목적에 대해 정확하게 인지하는 것(해결하려는 문제가 뭔지 이해)
(2) 어떤 예외상황들이 생길 수 있는지 예측하는 것
(3) 어떤 리소스가 필요한지(UX리소스가 필요한지, 서버팀과 함께 작업해야하는지)
(4) 어떻게 처리할 것이고 그 때 사용성은 어떠한지, 또 개선할 수 있는 방법은 무엇이 있는지
등등에 대해 고민하여 우리의 서비스가 개선되어 사용자가 더 만족하며 서비스를 이용할 수 있도록 개발하는 역할을 해줬을 때 더 원활하게 서비스가 제공되고 의도한 결과를 더 잘 만들어 낼 수 있었다. 개발 능력은 기본적으로 중요하게 생각하지만, 이런 Soft Skill 또한 업무 퍼포먼스에 큰 영향을 준다.
-> 초반 개발 프로세스 이해도가 부족하여 ux팀 협업이 필요한 부분인지 정확하게 알지 못하여 업무를 두 번 했던 상황
등을 겪으며 Soft Skill의 중요성을 몸으로 체감했다.
익숙하지 않아 생긴 몇 번의 실수들을 동료들이 이해해주고 노력을 통해 극복할 수 있었고, 지금은 개발업무 시작 전 문제 인식과 리소스 파악의 중요성에 대해 더 많이 느껴 같은 실수를 반복하지 않고 있다.
스스로 느끼고 변화하는 것만큼 빠르게 변하는 건 없지만, 실수를 하는 상황은 유쾌하지 않다. 다른 사람들에게 유쾌하지 않은 상황을 피하게 하려면 개발프로세스 확립과 문서화를 통해 버벅거리는 상황을 피하도록 준비를 해두자.
4. 마무리
회고를 목표로 매일매일 업무를 개인적으로 관리하고, 관리한 업무를 다시 읽어보면서 내가 어떤 생각을 했고 어떻게 적용했는지 작성해보는 이 과정이 성장을 필요로 하는 나에게 좋은 영양분이 되는 것 같다.
1) 일과 시작 전, 하루의 업무를 미리 작성하기 때문에 업무중에 특별한 이벤트가 생겨 집중이 흔들려도 방향을 잃지 않아 퍼포먼스가 나름 일정하게 나온다.
2) 정말 많은 일을 했던 시간보다 과거에 무엇을 했는지 명확하게 기억에 남는다.
3) 일상적인 업무 처리가 아니라 의식적인 업무처리로 내가 무엇을 하고 있고 더 좋은 방향에 대해 계속해서 고민한다.(걷기만 많이 한다고 모델이 될 수 없다. 걷는 연습을 해야지!)
이러한 장점들이 있어 회고를 계속해서 작성하고, 또 뿌듯해하고 있다. 앞으로도 의식적인 개발을 바탕으로 업그레이드하는 내 모습을 상상하며 천천히, 꾸준히 성장해가야겠다.
