개발을 시작하게 된지 2년 된 지금 시점에서 개발을 시작함으로 생긴 가장 장점이라 생각하는것은 문제점을 찾고 개선을 하기위해 노력하는것이다.
예를 들어 지금 사용하는 아이폰은 현재까지 공휴일을 계산해 알람을 설정해주는 기능이 없다. 그래서 한번은 평일에 있던 공휴일에 알람을 끄고 생활했는데, 공휴일이 끝나고 다시 키는것을 깜빡해 출근에 지각을 할뻔한 적이 있다.
지금은 덕분에 공휴일을 계산해 알람을 키고 끄고 해주는 단축어 기능을 개발해 매일 호출해주며 알람을 신경쓰지 않고 살고있다.
이렇게 해오던 일상적으로/관성적으로 생활하는 것을 `관성의 법칙` 이라고 하던데, 개인적으로 이 말을 굉장히 좋아한다.
나에게 남아있는 관성의 법칙이 있다면 나쁜 관성인지, 나쁘다면 개선을 해서 오늘의 나보다 내일의 내가 더 나아질 수 있다는 느낌을 들게한다. 이 느낌이 굉장히 중독적이다.
특히 현재 회사가 관성적인 일을 강하게 유지하고 있는데, 이 관성들을 깨고자 하는게 작년부터의 목표였다.
남아있던 관성
- 앱 버전 관리를 XML 파일로 관리
- 프로젝트 버전 관리를 파일로 관리
- 유지보수/협업을 고려하지 않고 당장 개발할때 편한 개발 방법으로 개발
이렇게 있었는데 이번달까지 이 관성들을 깨는 활동을 했다.
앱 버전관리 관성 깨기
일단 1 번의 버전 관리는 작년에 완전히 깨는데 성공했다.
회사가 개발하는 앱은 모두 사내망을 사용하여 사내에서만 작동되는데, 이러한 특징때문에 스토어에 업로드 하지 못한다. 그래서 버전 관리는 사내 서버의 각 앱마다 XML 파일을 만들어 두고 이 XML 파일에 최신 버전을 명시해 이용자가 앱을 실행하면 XML 파일을 서버에서 다운받아 현재 설치된 버전과 비교하는 방식을 사용했다.
이 방법의 큰 단점은 앱마다 XML 파일을 따로 관리해야 하고 앱에서 XML 파일을 받고 파싱하는데 코드가 굉장히 복잡하고 불필요하다.
그래서 DB 테이블로 앱과 버전을 업데이트해 api 호출에 응답으로 해당 정보를 내려주면 앱에서 간단히 버전만 비교하도록 개선하자 했고, 성공적으로 개선했던 경험이 있다.
이 내용은 변경하기 그다지 까다롭지 않고 한번 바꾸기만 하면 앞으로 편해진다는 이유로 충분히 설득하기 쉬웠다.
하지만 2, 3번은 관성의 법칙을 제대로 받고있는 내용이기 때문에 자료 준비부터 발표까지 꽤 고민을 많이 하면서 준비했다.
형상관리 관성 깨기
기존 형상관리는 각자 프로젝트 파일을 다운받아 작업(작업한 부분을 주석으로 표시)을 한 후, 파일 자체를 서로 공유해 다른 개발자가 작업한 부분을 내 파일에 붙여넣는 방식을 썼다.
국비학원에서도 SVN 으로 형상관리를 경험한 나로서는 처음부터 납득하기 어려웠지만, 다른 개발자 분들과 협업은 해야하니 어쩔 수 없이 따라갔다.
당연히 개선하고싶은 욕구가 솟아올라 회사 계정으로 Github 레파지토리를 만들어 Git 사용을 해봅시다! 라고 선언했고 관련 자료를 혼자 준비할테니 보고 따라하기만 해달라는 조건으로 준비를 시작했다.
Git 사용 방법과 장단점을 정리해 발표를 했고 일단은 성공적으로 설득해 앞으로 하는 프로젝트는 Git 으로 관리하게끔 추진하고 있다.
아직 확실히 관성을 깼다! 라고는 못하지만 다른 구성원 분들도 깃 사용방법에 대해 연습 하겠다는 의지를 보였다는 것 만으로도 만족스럽다.
개발 습관 관성 깨기
3번 개발 습관에 대한 관성이 나에겐 가장 도전의식을 일으키는 문제였다.
일단 대표님이 대학교 교수, 개발 학원/부스트캠프 온라인 강의 강사, 개발 입문 서적 저자 등등 커리어가 화려하시다. 함께 일해보며 느낀거지만 정말 다방면적으로 뛰어나시고 배울점이 확실히 많았다.
하지만 단점 없는 사람은 없듯이 대표님도 그런 굵은 잔뼈만큼 오랜 관성을 지니고 계셨고, 회사 구성원 분들은 그 관성을 전적으로 신뢰하는 상황이다. (특히 모든 구성원이 대표님의 제자 출신이며 다른 회사 경험이 없다는 이유가 크다 생각한다)
대표적으로 관성이라 느낀 것은 절차지향 코딩에 너무 익숙하단 것이었다. 전혀 객체지향 설계를 조금도 하지 않게 되고, 2번 관성인 형상관리 문제와 함께 큰 불편함을 발생시켰다. (OCP 원칙을 지키지 못해 기능 변경으로 인한 호출부 코드 전체 영향)
물론 절차지향은 무조건 나쁘고 객체지향은 무조건 좋다 는 의견은 아니지만, 유용한 부분에는 분명히 객체지향 설계를 하는것이 효율적이라 생각했고, 이와 관련된 내용 전파를 시도했다.
아직 깨고싶은 관성이 남아있지만 너무 급박한 변화는 피로감을 줄거같고 막내 직원이 이거저거 시도하기엔 사내 분위기도 그렇게 부드럽진 못한 느낌이다.
그리고 이런 방법론적인 관성 외에도 사내 구성원 발전 동기부여, 자체 백엔드 프레임워크 리펙토링 같은 작업에 시도도 하고싶은 마음이다.
일단 사내 스터디를 시작했으니 스터디도 열심히 이끌어보려 한다.
어쨌든 막내의 무모할 수도 있는 시도에 조금의 기회를 준 선배들에게도 너무 감사한 마음이다.
