2019 돛을 올리며 (2018 회고록)

시작하며

개발자라는 직함을 사용한지도 4년이라는 시간이 흘렀다. 공공기관 교통물류분야 시스템구축(SI)사업을 전문으로 하는 기업에서 주로 운영관리 업무를 해오다 지인의 추천을 받아 2018년 3월 말 모빌리티서비스 기업으로 자리를 옮기게 되었다. 이전회사와 교통이라는 공통분모를 제외하곤 내가 그동안 해오던 업무의 원천이 달라지게 됐는데 그 정도가 4년차 경력을 다시 정의할 수준에 이르렀던 것이다.

 

아무렴 기술의 비중보다 고객사 현업의 배경을 잘 이해하는 비중이 업무성과의 앞선 척도가 되고 그것을 근거로 다행(?)스럽게 매년 연봉은 상승했지만 개발자라는 직함의 이면에는 이미 나도 모르게 '회사원' 또는 '공무원'과 같은 업무방식에 서서히 체화되어가고 있다는 것을 느끼게 될 때 즈음, 내 본연의 '직업정체성'에 대해 고민하기 시작했다.

 

작년 하반기부터 본격적으로 이직에 도전하였고 많은 시행착오와 우여곡절 끝에 올 3월 이 회사에 합류하게 됐다. 이 회고는 지난 한해 그러니까 2018년에 대한 회고록이라기보단 지난 4년이라는 SI환경에서의 개발경력의 마침표와 함께 시작된 내 개발생애 2막의 시작을 정리해 보는 시간 정도로 소개할 수 있을 것이다.

 

[얼마 전 교토에서 구입한 해피해킹 프로페셔널2 키보드.]

 

지나온 것들

이전직장에서 지난 4년간 수행해온 주요프로젝트와 기술스택과 담당업무는 다음과 같다. 

 

정부부처 물류신고관리시스템 운영 유지보수

- 기술스택 : 전자정부프레임워크 2.0, Tibero5.2 Enterprise, jQuery2.20

- 담당업무

1. 실적신고기능 및 운행차량 이력관리기능 프로세스설계 및 기능구현

2. 지자체공무원대상 시도별 이용자 실적신고 현황정보제공 기능구현

3. CBD산출물작성 및 이력관리

4. 시스템 보안취약점 관리(인증 / 세션관리)

5. 이용자대상 시스템관련민원처리지원

6. 지자체공무원 및 화물운송사업자 대상 전국 시스템순회 교육진행

  

공공기관 교통데이터 품질 시각화 시범시스템 구축

- 기술스택 : Spring3.0, PostGreSQL9.1, jQuery2.20, D3.js

- 담담업무

1. 지역별 본부 간 교통량을 관계형 다이어그램으로 정보 시각화 서비스구현

2. 구간별 VDS 교통품질 데이터를 히트맵형태의 정보 시각화 서비스구현

 

도서산간지역 대중교통 탄력운행 버스기사용 모바일앱 개발

- 기술스택 : SPRING 4.0, Visual Studio Code, jQueryMobile2.0, Cordova(Phonegap),6.0, Google Cloud Messaging API2.4, Open Layers 3.0, signature capture0.9

- 담담업무

1. 하이브리드앱기반 안드로이드 버스기사용 모바일APP 개발

 

 

 

형상관리도구는 SVN을 사용했고 그마저도 협업시 파일단위의 작업에 대한 수렴(커밋)용도로만 활용되다보니 코드리뷰나 버전관리따위는 애초부터 고려대상이 될 수 없었다. 요즘 대두화 되고 있는 Devops에 대한 정의에 반대로 뒀을 때의 상황으로 보면 될까? 배포직전 서비스검증은 '코드기반'이 될 수 없고 배포의 과정마저도 windows탐색기(발음조심)에서 해당 workspace폴더 하위로 일일이 찾아들어가 자신이 수정했던 .class파일들을 하나하나 마우스로 복사하여 붙여넣는 식이었다. 

 

물론 간혹 .class파일과 동일한 이름의 .java파일을 구분하지 못해 발생하는 실수는 1년차(당시의 내가 자주 저질렀던)개발자에게서 흔히 볼 수 있는 경우이다. 그렇게 취합한 소스파일을 FTP를 통하여 일일히 원격 컨텍스트에 대조하며 덮어씌우고 난 뒤 ssh로 deploy경로로 직접접근하여 WAS의 재기동 또한 오직 사람(human)의 공수로 수행한다.

 

[context폴더에 이런 파일들이 남아있다면 내가 그러했던것이 분명해..]

 

주로 공공기관으로부터 용역을 수주하기에 프로젝트의 기술스택(전자정부프레임워크 준수)에 대한 제한은 존재하나 그렇다고 구현레벨까지 간섭하는 수준은 아니다. 정부 또는 주요공공기관 웹서비스의 경우 Spring Framework기반의 전자정부프레임워크(이하 eGov)을 통해 구축된다. 일부의 경우 SK C&C, LGCNS와 같은 과거 SI 대기업으로부터 납품되는 자체프레임워크기반의 레거시(SKCC..)도 아직 존재한다. 

 

eGov는 기존의 스프링프레임워크기반에 게시판, 로그인인증과 같은 공통컴포넌트이 추가적으로 끼워넣어져 있는 형태로 제공된다. 관련 컴포넌트에 대한 상세한 한글메뉴얼도 해당홈페이지에서 다운로드를 받아 사용할 수 있기 때문에 프레임워크에 대한 사전이해없이도 제공되는 메뉴얼에 따라 그대로 따라하기만 하면 게시판과 로그인인증기능이 손쉽게 구현이 가능하다.

 

다만 이러한 컴포넌트가 기본적으로 끼워 나오는데에 생겨나는 비용이 상당한데 그중 가장 치명적인것이 바로 최적화 이슈이다. 그건 마치 익스플로어의 액티브X의 존재와 견줄 만큼 eGov에서 제공하는 자체 컴포넌트를 사용하지 않는다 할지라도 이로인한 자원소모가 상당히 크다. 뿐만 아니라 기본제공하는 컴포넌트에 의존적인 개발이 진행되다보면 추가적인 요구스펙에 따른 커스터마이징에 대한 이슈가 발생되는 경우 컴포넌트는 그것대로 놔두고 동일한 기능이 중복해서 재구현해야하는 최악의 사례도 적잖게 발생한다. 

 

결국 eGov는 공공기관납품수준의 프로젝트들에 '쉬운개발을 위한 프레임워크'를 표방하지만 결국 그건 '쉬운 프레임워크에 의한 어려운개발'로  귀결되는 결과를 낳게된다.

 

[공공SI프로젝트에서 사용되는 전자정부프레임워크]

 

기본적으로 햄버거세트구성이 햄버거 + 감튀 + 콜라조합이듯 eGov + tibero(국산DBMS) + jQuery조합은 공공기관 시스템구축 프로젝트에서 자주 볼 수 있는 조합이다. 특히 공공SI프로젝트를 주로 수행하는 중소기업에 종사하는 개발자들은 회사안에서 자신에게 투입되는 프로젝트가 그 무엇이든 그 프로젝트에 구현된 기술에 대한 러닝커브 매우 적거나 아예 존재하지 않는다. 그러다보니 회사내부에서도 어느정도 기술스택를 숙지한 2년차와 5~6년차 개발수준의 변별력 또한 아주 적거나 더 암담하다면 아예 존재하지 않을지도 모른다. 대개의 경우 이러한 태생구조를 가진 개발환경에서 3년정도 근무를 하다 이직을 결심하게 되는 사례가 흔한데 대부분은 그러한 이유에서다.

 

 

퇴사직전 흥미있게 진행했던 프로젝트가 도서산간지역 대중교통 탄력운행 버스기사용 모바일앱 개발이었다. 모바일앱 개발경험이 전무한상태 admin페이지로부터 push가 연동되는 앱을 개발했어야 했는데 약 1개월간 공수로 네이티브기반으로 구현을 하기엔 분명한 역량의 한계가 존재했다. 

 

그 대안으로 하이브리드앱 프레임워크인 phonegap을 활용하게 되었는데 HTML과 CSS만으로도 꽤나 그럴듯한 앱플랫폼구현이 가능했다.(그것도 멀티플랫폼으로 말이다.) 구현하려는 모바일앱에 대한 기능적인 요구사항이 단순했던지라 사실 꼭 역량의 부재라는 이유가 아니라도 phonegap과 같은 하이브리드앱 도구에 대한 존재의 이유에 대해서 알게 된 의미있는 경험이었다.

 

 

 

이 프로젝트를 진행하면서 직면하게 된 몇가지 이슈와 당시 도출방안은 다음과 같다.

 

 

issue 1. 모바일앱에 사용된 페이지뷰는 대략 6개정도로 SPA(Single Page Application)방식으로 설계를 하였는데 나중엔 이러한 설계에 대한 경험과 이해부족 때문인지 점차 기형적인 형태의 코드로 변모해갔다.

페이지뷰 성격상 상황에 따라 내용이 동적으로 변하는 경우 즉, 이벤트가 발생될 때에 대한 처리를 어떻게 해야하는지에 대한 스터디가 전무한 상태이다보니 서버사이드렌더링에 대한 방법이나 예제를 찾지 못했다. 그리하여 생각해냈던게 서버에서 json으로 데이터를 받아오면 jQuery를 append를활용하여 html코드를 한땀한땀 그려내는 수고를 거쳐 페이지를 렌더링시키는 상당히 장인(?)스러운 방안이었다. 코드는 코드대로 너저분해지면서 사실상 구조화 자체가 불가능에 가까운 수준의 더러운 코드가 되어가고 있었다.

issue 2. 주기적(약 10초)적으로 실시간클라이언트(앱)의 위치정보(GPS)를 서버에 전달해야는 기능구현에 많은 어려움이 있었다.

휴대폰의 GPS에서 수집된 정보를 서버에 주기적으로 전달하는 기능을 만들어야 했다. 네이티브가 아닌 phonegap에서 위치정보를 수집하는 것에서 수집된 정보를 서버에 전달하는 과정까지는 달리 지원해주는 별도의 적절한 플러그인을 찾지 못했다.

기꺼해봐야 html5표준 javascript API를 통해서 위치정보를 가져오는 수준의 플러그인으로 1회성 위치정보를 취득하는데에는 별 무리가 없지만 약 10초내외의 주기적인 위치정보를 가져오는데에는 일정주기가 지난 이후엔 캐싱된 동일위치값을 계속 반환한다거나 아예 fail로 떨어지는 경우가 빈번했다.

기능적인 이슈와는 별개로 클라이언트(모바일앱)에서 수집되는 위치정보 또한 해당 모바일앱의 통신망의 기지국의 상태나 통신음영지역에 대한 변수도 고려하지 못했다. 궁극적으로 이 프로젝트에서 구현하려 했던 당초 요구스펙의 기준으로, 모바일앱이 거치된 차량들의 이동위치를 실시간으로 서버에서 받아 지도화면에 실시간 모니터할 수 있는 수준의 서비스는 결국 충족시키지 못한 채 마무리지었다.

 

$(function() {
        $(document).on('deviceready', function() { /** 장치 초기화와 함께 위치정보 취득 시작 */
        // 위치정보객체 참조 변수
        var id = navigator.geolocation.watchPosition(
            function(position) { },
            function(err) { },
            {
                maximumAge: 3000, // 갱신주기(1/1000초 단위)
                timeout: 30000, // 타임아웃(1/1000초 단위)
                enableHighAccuracy: true // 높은 정확도 사용
            }
        ); // end watchPosition
 
        
        $(window).unload(function() {  
            if (id !== undefined && id !== null) {
            	// 위치정보 취득을 중단.
            	navigator.geolocation.clearWatch(geo_id);
        	}
        });
    });
});

[해당 function을 10초간격의 inteval을 주었을 때 maximumAge와 timeout의 설정옵션은 정상적으로 반영되지 않았다.]

 

 

변화한 것들.

앞서 진행되었던 '도서산간지역 대중교통 탄력운행 버스기사용 모바일앱 고도화사업'이 착수가 이뤄질 시점에 두 곳의 기업으로부터 오퍼레터를 받게되었고 한달간의 인수인계끝에 3월 말 모빌리티플랫폼 선두기업인 SOCAR에 합류하게 되었다. 이곳에서 내가 약 9개월동안 업무를 수행해오면서 이전의 환경과 비교하여 다르게 느껴왔던 것들을 크게 3가지 꼭지로 나누어 정리해 볼 수 있었다.

 

1. 사용언어의 변화 Java -> PHP + node.js

앞서 말해왔듯 4년이라는 시간동안 거의 고정되어온 공공SI 기술스택(전자정부프레임워크, 티베로, jQuery)에 변화를 맞딱드리게 되었다.

 

기존Java를 주로 사용해왔던 터라 PHP언어에 적응기가 필요했지만 일부 문법적 특성을 제외하고는 오히려 Java보다 더 간결한 덕에 러닝커브가 높진 않았다. 타입기반언어가 아닌 점과 인터프리터방식을 채택하는 스크립트언어이다보니 별도의 컴파일과정은 없이 코드에 대한 빠른실행이 가능하다는 점은 과거에 매번 build의 과정이 필요했던 Java환경보다 상당히 편리하게 다가왔다.

 

코드의 직관성이 높기 때문에 그저 의식의 흐름에 따라 읽기가 가능하지만 또 한편으로는 이러한 직관성이 객체지향적이기보단 절자지향적인 성격이 더 짙게 느껴지는 경우가 많았다. 물론 이러한 점은 언어가 가지는 한계로 치부하기보단 그 언어를 통해 구현하는 개발자의 역량에 좌우되는 것이기도 하지만 기존 Java에서 봐오던 다양한 디자인패턴구조를 함수를 중심으로 설계된 PHP언어 환경에서 동일하게 잡아가기가 다소 애매해 보일 때도 있었다.

 

2. 개발환경의 변화 Local -> Cloud

서두에 쓴것처럼 이곳에 입사한 후 가장 컷던 컬쳐쇼크가 바로 Cloud 환경이다. 확장자가 주로 .class, .hwp, .doc, .xls 된 것들을 주로 다뤄왔던 터라 이곳에서 꽤 다양한 '신조어'를 듣게 되었다.

 

- 구닥으로 공유해주세요.

- 슬랙채널에 공유했으니 확인부탁드려요.

- 작업완료되는대로 검토해 드릴테니 바로 PR해 주세요.

- AWS EC2인스턴스를 별도로 생성하셔도 돼요.

입사후 지급받은 PC에 가장 처음 한일이 카카오톡을 다운로드받아 설치하는 거였는데 사실 카카오톡은 우리의 업무환경에서 딱히 필요치 않는 도구였다.

 

[구닥이라고요? 아! 혹시 이거 말씀하시는건가요?]

 

슬랙(Slack)을 사용해오면서 좋았던 점은

- 다양한 이모티콘과 마크다운을 사용하여 좀 더 자연스럽고 유연하게 의사전달할 수 있게된 점.

- 이미 보낸 대화의 내용을 수정하거나 삭제할 수 있기 때문에 중간에 잘못전달된 내용이나 표현을 쉽고 빠르게 정정할 수 있다는 점.

- 그때 그때의 히스토리를 쉽게 추적하여 잃어버린 업무내용을 빠르게 복기해 갈 수 있다는 점이다.

- 어쨌든 강력한 마크다운의 위력!

 

SVN에 익숙해져 있던 나에게 github 또한 또 하나의 도전과제였다. 협업시에 commit, revert, merge 오직 이 세개의 단어가 코드관리의 전부였던 것에서 몇가지가 더 늘어났다. commit이라는 의미가 내가 알고 써왔던 그 commit이 아니고 brunch라는 개념 또한 온전히 이해하기까지 꽤나 적잖은 시간이 흘렀다. 입사 둘째날에 AWS환경에 업무개발환경을 구축하게 되었는데 사실 AWS가 아마존이라는 기업에서 만든 Domain이라는 사실말곤 이게 정녕 무엇을 서비스하는 도메인인지 정확히는 알지 못했다.

 

  - 아마존에서 서버도 파는구나.

  - 근데, 다나와나 네이버쇼핑이 더 싸지않나?

이외에도 budyworks, sentry와 같은 자동화도구의 존재의 이유도 입사이후 여러번의 시행착오를 겪으며 존재의 이유를 파악하게 되었으니 어찌보면 새로운 클라우드기반 개발환경을 처음 접하게 된 그때의 내모습은 과거 척박하게 살아온 제 3세계의 사람이 처음 문명화된 도시를 맞이할 때에 엄습해오는 문화충격과 거의 비슷할 것이다.

 

 

3. 기업문화

코드리뷰 부탁드립니다.

입사이후 얼마지나지 않아 처음 투입된 개발업무가 amdin페이지에 일부 검색조건을 추가하는 업무였다. 대략 한시간이면 완료했을 법한 불륨은 결국 10일이 지나서, 그러니까 1주일하고도 3일째 되는 시점에 비로소 배포를 윤허받았다. 처음 개발투입이 되었을때 컨텍스트에서 MVC모델의 Persistance Layer에 해당하는 지점이 당최 보이지가 않았다. 도대체 SQL Mapper는 어디에 숨어있는거야? 여러번 시행착오와 코드컨벤션에 대한 검토수렴에만 일주일이상 소요되었는데 그러한 수렴과정자체는 그간 한번도 겪어보지 못했던 고난의 행군이었다.

- 아니 잘 돌아가는데 뭐가 문제야?

- 왜 내가 코딩하지않은 (의존성)코드도 수정을 해야돼?

- 변수선언이야 내 맴이지.

 한동안 코드리뷰에 대해 체질화해가는데 여러모로 성장통을 겪었다. 리뷰어들의 깐깐한 코멘트 하나하나가 과거 내가 과거 저 리뷰어에게 오해를 불러일으키거나 잘못한 점이 있었는가? 스스로에 대해 반성의 시간을 가져보기도 하고 한번은 리뷰를 수렴하는데에 하도 지치다보니 개선을 제안하는 몇몇개의 커맨트를 정중히 거부하기도 했다. 몇달이 지나 이젠 제법 코드의 구조를 깊이있게 곱씹어 가며 개발업무를 진행갈수 있게 되었을 즈음에 문득 맥을 끊는 아주 저질스런 코드와 조우하게 되었는데 블레임에 당당히 내 이름 석자가 들어간 걸로 본 순간 얼굴낮이 따스해지기 시작했다.

 

코드리뷰라는 과정을 단순히 내 코드의 과연 몇점짜리 코드인가를 평가받는 자리로만 보게되면 그 문화를 받아들이기 많은 어려움이 생기게 된다. 왜냐하면 코드리뷰는 궁극적으로 코드에 대한 '평가의 장'이 아니라 '토론의 장'으로 바라봐야 하는 것이 옳고 코드에 대한 O,X만을 따지는 것이 아니라 그보다 더 나은 방법을 모색하고 제안하는 자리로 받아들여 더 좋은 환경(시스템)을 지향해 가는 것이 그 자체의 궁긍적인 목적이기 때문이다. 코드리뷰문화 자체에서 가져다주는 유익함은 어느 스승의 가르침보다 실질적이고 순도가 높다고 생각한다.

 

지금은 이러한 성장통 덕분인지 코드리뷰에 대한 시각도 당시이 비해 좀더 건강해지고 코딩을 할 때에 빠른 구현보다는  조금 더 구조적인 접근을 통해 우아한 구현을 하고자 하는 고민을 자연스럽게 하게 된다.

 

각자 알아서 잘 합시다.

근무시간은 09:30~18:30기준으로 별도의 출퇴근관리는 하지 않고 알아서 오고 가는 편이다. 업무시간에 대한 어떠한 간섭이 없기 때문에 야근부담 또한 존재하지 않았다. 업무할당 및 진행상황공유를 매주 2회 팀원들과 함께모여 30분간 소통하는 자리를 갖는다. 이 자리에서 신규업무를 부여받거나 진행중인 업무중에 이슈가 발생했을 때에 해결방안을 함께 모색한다. 팀장과 팀원 모두 서로에 대한 나름의 존중과 신뢰가 밑바탕이 되어 소통을 이뤄가기 때문에 각각의 업무에 대한 측정치를 추산하기위한 별도의 노력의 비용이 굳이 요구되진 않는다.

 

모두가 자신의 일에 대해 제하거나 보탬없이 양껏 할당을 하고 각자의 위치에서 스스로가 주도적으로 추진해 나아가는 업무문화가 제법 탄탄히 잘 정착되어 온 것으로 보인다. 연차에 대해서 본인이 직접 상신과 결재를 하는 시스템으로 연차사용에 대한 가부는 전적으로 본인의 판단하에 결정되고 남은 팀원들에게 굳이 '내가 이래서 연차를 꼭 써여한다'는 설득의 과정은 필요없이 그저 통보만 하는 식이다. 물론 각 본부마다 문화의 차이가 다소 있을 수 있지만 현재 내가 소속된 본부와 부서에서는 이러한 자율과 책임이 각자 스스로에게 무한하게 담보된다.

 

그래서인지 부서내 구성원 다수가 이러한 신뢰를 자기 자신으로 인해 깨지 않기 위해 스스로에 대한 경각과 노력이 자연스럽게 작동되고 운영되어 가고 있다. 개인적으로는 이런 건강하게 정착된 환경가운데 두번째 성장을 이어갈 수 있는 것에 감사하게 생각하고 있다.

 

 

성장한 것들

1.contribution

적절한 지표는 아니지만 올해 3월말에 회사입사 이후 커밋한 내역이다. 내년에는 개인계정을 지표를 가져올 예정이다. 

 

 

2. Dev-ops 교육 진행

11월 17일부터 FAST-CAMPUS에서 주최하는 Dev-OPS 구축 BOOTCAMP 3기 교육을 수강중에 있다.

해당 강좌에 대한 간추린 커리큘럼은 다음과 같다.

 

1. 서버 인프라 이해

2. 배포방법과 툴 이해

3. CI/CD 모니터링 환경 구축

4. 실제업무환경 도입

 

현재 종반을 넘어가는 시점에 리뷰를 하자면 실제 튜토리얼형태의 실습과 이론강의를 병행해 가기 때문에 관련배경에 대한 이해가 없어도 충분히 따라갈 수 있도록 강의가 진행되고 있다. 강사분 또한 열정적이면서도 현장에서의 경험을 들어 수강생에게 최대한 재미있게 설명해 주신다.

 

해당교육과정이 이수되는 시점에 궁극적인 목표로 실제업무환경에서 설계부터 운영구축까지 경험해온 내용들을 회고하고 직접 배포,운영, 모니터 환경을 구축해본 다음 이 블로그를 통해 해당내용대한 정리와 리뷰를 진행할 예정이다.

 

 

3. 사이드 프로젝트 개발

입사과제 포트폴리오로 사이드프로젝트로 우리회사가 소유한 서비스운행 차량 별 데이터사용량에 대한 분포도를 시각화하여 표현해내는 대쉬보드개발을 진행했다. 해당 서비스에 대한 로직을 간단히 소개하자면 다음과 같다.

 

1. 서비스등록 과 로그인

2. 매월 통신사로부터 발행되는 차량별 데이터청구서파일(xls)를 업로드

3. 업로드된 파일의 각 레코드를 파싱처리하여 json객체타입으로 묶어 mongo DB에 저장

4. 저장된 레코드를 json객체로 불러와 데이터양 구간별(100M)로 사용량을 산출한뒤 데이터시각화 라이브러리를 통해 클라이언트 뷰에 표현

 

구현의 방식과 설계는 자유였던지라 무작정 node.js와 mongoDB를 활용할 작정이었다. 이유야 단순했다. 스크립트기반에 서버사이드언어인 node.js는 스터디목적이 가장 컸고 mongoDB를 선정한 경우 역시 아직 구체적인 요구명세가 갖추지 않는 프로토타입기반의 빠른개발을 고려했기때문에 향후 모델구조의 변경이 잦을 수 있다는 가정하에 확장과 변경이 유연한 비정형 데이터구조로 설계비용을 단축시킬수 있을 것이라는 기대가 있어서였다.

 

지금 생각해 봤을 때도 그때의 선택이 틀리진 않았다고 생각하지만 아쉽게도 아직까지 node.js와 mongo.db가 가지고 있는 강점을 체감해 보진 못했다. 특히나 node.js로 서비스를 구현하면서 가장 크게 불편을 느꼈던 것이 바로 디버깅이었다. 단순히 버그을 추적하는 도구의 부재였다기보단 node.js로 서비스구조를 설계함에 있어 모듈단위로 잘게잘게 쪼개갈수록 에러를 추적해 나아가는 과정이  그만큼 배가되기 때문에 어떤설계가 과연 유지보수를 고려한 설계인지 고민이 필요할 때가 많았다.

 

나와같이 머리나쁜 엔지니어를 기준으로 유지보수하기 가장 편한 구조는 콜백과 프로토타입을 최소화하고 하나의 파일에 어지간한 config를 몽땅 넣어 버리는 것이다. 그렇다면 node.js로 채택하여 서비스를 구현할 이유도 굳이 없긴 하겠지만 말이다. 비지니스 로직을 구현하는 비용보다 서비스 컨텍스트구조를 설계하는 비용이 점점 커지면서 node.js에 대한 회의가 물밑듯 물려왔다.

 

자바스크립트공부를 더 열심히 공부해야겠구나. ㅠ

나에게 Node.js는 아직까지는 정말 잘 알고 써야 약이 되는(그렇지 않으면 병이 되는) 녀석으로 보인다. 모델지향은 어떻게 하고, 디플로이는 어떻게 하고 또 디버깅은 어떻게 하는지 모범사례를 차근차근 살펴 볼 필요가 있었다.

 

그래도 한가지 느꼈던 강점으로는 분명 서버사이드언어임에도 불구하고 전혀 서버사이드답지않게(=빠르게) 작동한다는 것이다. 그동안 업무영역에서 주 사용언어가 PHP기반인 점을 감안하지 않고 과거 (Java기반의 컴파일언어로 된)Framework에서 개발을 진행할때 코드 수정 - Build - Run을 거치기까지의 소요시간과 비교해 볼때 이건 결코 현실적이지 않은 속도인건 분명하다. 스크립트언어에 대한 기본적인 이해가 기본 밑바탕이 깔려있고 마이크로서비스운영하거나 간단한 프로토타입서비스를 개발한다고 했을 때 node.js만큼 제격인 서버사이드도 아마 없을 것이다.

 

 

경험들

1. 원티드 인터뷰

지인채용플랫폼인 wanted에서 지인추천을 받아 이직을 하게 되었다. wanted에서 지인추천을 받아 채용에 성공하면 추천한 사람과 추천을 통해 입사한 사람 모두에게 일정이상의 보상금이 주어진다. 입사이후 3개월이 지난 시점에 보상금이 지급되는데 이때 인터뷰 제안을 받게되어 인터뷰를 하게 되었다. 올 해 뜻밖에 이직과 뜻밖에 보상금 그리고 뜻밖에 미디어노출까지 경험하게 된 셈이다.

나에게 라이프워크는 '목적'이다

 

2. DEVIEW2018 참가

사실 이러한 개발컨퍼런스 자리가 익숙치 않았다. 애초 먼저 관심을 가지고 신청을 하여 참가한 것이 아니고 먼저 기회를 얻은 동료의 권유로 대신 참석을 할 수 있게 된 사례인지라. 그래서인지 이곳에서 어떠한 지식적 유희를 얻어갈 준비도 갖출 채비도 없이, 마치 올림픽대회에 참가한 변방의 대표선수마냥 그저 ‘참가에 의의’를 두고 향했던 자리이기에 어마어마한 티켓팅 경쟁끝에 그 자리에 기회를 얻지 못한 다른 개발자들로 하여금 조금은 부끄럽기도 했다. 이번 컨퍼런스에서 준비한 콘텐츠를 모두 소화할 역량은 못되었으나 최대한 즐기고 얻어가고자 마음이었다.

 

행사를 주최한 네이버에서 나온 연사들의 프레젠테이션능력은 기대이상으로 뛰어났다. 하루종일 모니터만 보면서 일할 시간에 이런발표준비는 어떻게 다 했을까? 

한가지 아쉬웠던 점으로 각 세션당 발표시간이 45분이었는데 사실 45분이라는 시간은 과연 누구를 배려한 시간 배분이었는지 조금 애매했다. 더욱이 발표의 말미에 갈수록 발표자의 진행이 다급해진다거나 중간설명이 불가피하게 생략되는 경우도 존재했고 나아가 Q&A까지 생략되는 사태까지 오니 이것은 시간배분을 잘 활용하지 못한 발표자의 문제라기보단 처음부터 불가항력적인 발표시간을 선정한 주최측의 운영미스라 보여진다.

 

그럼에도 국내 IT를 주도하는 기업에서 개발자를 대상으로 이러한 컨퍼런스를 매 해 준비하고 주최한다는 것은 상당히 고무적이라 느꼈다. 더불어 이러한 소통의 장이 앞으로도 더 많아져서 개발자들이 개발을 더욱 더 즐기고 소통해가는 활로가 더 촘촘하고 끈끈해 졌으면 좋겠다. 듣는 청중들도, 청중들의 호응을 통해 발전하는 연사 모두에게 말이다.

 

 

올해 목표들

2019년도에 새운 목표들을 몇가지 세웠다.  국내 모 조사에서 따르면 한해의 목표를 세우고 한해가 거의 지났을 때 그 목표를 온전히 이룬 경우가 대개 약 11%정도된다고 한다. 대개 89%에 속하는 대상자들에게 실패사례의 원인으로 가장 많이 지목한 것은 연초계획이 너무 원대했기 때문이다. 그렇기에 올해 목표선정은 내가 역량 이상의 개인적인 욕심이나 부담을 모두 내려놓고 실현가능하는 범위내에서만 또렷히 설정하고자 했다.

 

1. 토이프로젝트 진행

개인 웹서비스를 만들어 볼 예정이다.

서비스 주제 : 

사용자가 주로 다니는 산책경로를 기록/관리하고 관련데이터를 기반으로 여러개의 위치기반서비스를 구현(아직은 매우 추상적)

 

기술스택 : 

Back-end : SpringBoot2.0 + Java + mariaDB를 활용한 REST API 서버구현

front-end : Nuxt.js(Vue.js)

 

2. 블로그 운영

- DEV-OPS 환경구축과정 포스팅

현재 교육중인 내용을 복기하고 그것들을 온전히 내것으로 기록하기 위해, 관련 교육내용을 커리큘럼에 맞게 재정리하여 곧 포스팅할 예정이다.

 

- 스프링부트2.0 + 코틀린 트러블 슈팅 가이드 포스팅

올해 새로운 stack(PHP + CodeIgniter)을 적응해 나아가는데 낭비가 발생되었던 것들중에 하나가 관련스택의 지식의 부재로 막히는 부분에 대해 건건이 찾아 해소해 가야하는 과정이 빈번했다. 

 

문제는 그러한 해소과정을 따로 기록하거나 필요할 때 꺼내보는 공간이 없다보니 향후 동일한 이슈가 발생될 때에도 그런 삽질의 과정을 매번 거쳐야 했는데 시간낭비는 둘째이고 결국 내 것으로 체득되지 않고 계속해서 그때의 상황을 넘어간다는 것이 가장 큰 문제였다. 이러한 오답노트의 구실을 하는 창구를 이제 블로그를 통해 활용해가고자 한다. 

 

올해 업무영역의 기술스택이 PHP에서 스프링부트2.0 + 코틀린으로 한번 더 변경될 예정이다. 이외 토이 프로젝트진행도 변행해가면서 발생되는 다양한 트러블이슈 사례들을 일연목록하게 정리하고 추후에 유용하게 활용할 수 있는 트러블가이드를 때마다 정리해 나아가려고 한다.

 

3. 독서

특정 서적을 선정하여 기계적인 완주를 목표로 독서를 하는 습관이 아니다.다만 내 업무영역에 있어 꼭 구비해야할 해야할 아래의 서적 두권만큼 올해 필수완주를 목표로 선정했다.

- Clean Code 클린 코드 애자일 소프트웨어 장인 정신 - 로버트 C. 마틴 저

- 처음 배우는 스프링 부트 2 - 김영재 저

 

2019 돛을 올리며.

과거에 적을 두었던 곳이 N사던(=K사), 은행권이던, 혹은 SI이던.. 어떤 배경안에서 무슨 일을 어디서 하더라도 업무의 본질은 크게 다르지 않을 것이라 생각한다. 

 

내가 그토록 벗어나고자 했던 척박한 SI환경에서의 운용유지보수경력은 적잖은 내 개발자의 삶을 이어온 과거이자, 지금의 내가 만들어진 데에 지대한 영향을 미친 곳임을 인정한다. 변화 이전의 모습이 모두 부정이고 변화 이후의 모습이 반드시 긍정은 아니다. 그래서 나는 현재 어떤 일을 하건 일의 기술적 내용보다 그 일에 접근하는 태도를 배우고 쌓아나가는 것이 중요하다고 생각한다. 

 

일하는 방식의 틀을 잘 잡아 놓으려 노력하다보면 그 안에 어떤 내용물의 일을 적용시켜도 조금만 익숙해지면 일을 잘해낼 수 있는 저력이 되어준다.  다시말해 과거의 그 어떤 일에 대한 경험도 허비되거나 쓸모없는 것은 없다고 생각한다.

 

'열심히 하는 것과 잘하는 것'

최근 주변에서 자주 듣는 조언이 '열심히 하는 것'과 '잘하는 것'을 구분짓는 것이다. 이런 고상스러운 조언이 약간의 일리가 있을 순 있어도 전적인 동의는 해줄 수 없다.

 

언제부턴가 '열심히'라는 단어가 이리도 홀대받고 '잘한다는 것'에 인과를 두지 않을 정도로 우스운 존재가 되어버렸단 말인가?

우월감이나 열등감을 느끼는 대신 나는 이런 점은 부족하지만 그래도 이런 점은 나의 강점이야라는 것을 말하고 뚜벅뚜벅 담대히 지금의 위치에서 개발자의 삶을 걸어나아가고자 한다. 내가 목표로 하는 일에 노력하는 사람은 적어도 노력하지 않는 사람에 비해 그 나름의 보상이 주어진다. 현실주의자인 나는 감나무에서 때되면 열매가 떨어지리라 생각하지 않는다.

 

올해에도 그저 그렇게 걸어가고자 한다.