2019 회고 <실수에 관하여>

서론

시간이 흐른다고 미래가 되는 건 아니다. 최근 <백종원의 골목식당>이란 프로그램을 보면 과거엔 파리만 날리다 어렵사리 백종원의 솔루션을 전수받아 문전성시를 이룬 가게들의 최근 근황을 방영해주고 있는데 몇몇 가게를 제외하곤 대개 그 시점을 기준으로 서비스나 품질이 그 이전의 과거로 회귀해 버렸다.

저기 나오고 있는 사장님들은 그때 백종원이 가고난 뒤 무슨 풍파를 맞았길래 저래 과거의 모습으로 다시 퇴행해 버린 걸까?

 

중소 SI기업에서 4년 그리고 2018년 3월 지금의 회사에 합류한 시점을 기준으로 전과 후 그리고 지금까지. 내가 하고 있는 본업에 대해 퇴행이 아닌 앞으로 조금씩 전진해 나아가고 있다고 생각하는 건 내 삶에 있어 분명한 긍정적 기류이다.

 

어느덧 2년이란 시간이 지나간 이 시점, 지금 이 회사에서 사내 백오피스 개발을 담당해오며 올 한 해를 되돌아보고 짤막하게나마 회고해보는 시간을 가져보고자 한다. 일연목연한 구성은 거둬두고  한 해 동안 내 삶의 변화를 이루었거나 성장해온 것들이라 생각되는 몇 개의 키워드에 대해서 자유롭게 서술했다. 2018년도에 이은 두 번째 회고다.

Blog.

지금의 이 공간은 작년도 첫 번째 회고록(2019 돛을 올리며)과 함께 태동했다. 첫 발걸음을 떼긴 했으나 연초에 다졌던 목표에 비해 활동은 매우 미미했다. 총 8개의 기술 블로그와 1개의 서평을 작성했는데 지금 읽어보면  좀 더 세밀하게 다듬어져야 하는 구성이나 문장들이 눈에 훤하다.

SpringBoot
[SubModule] 1. SubModule 혹은 MultiModule?
[SubModule] 2. 프로젝트 생성
[SubModule] 3. 멀티 모듈생성
[SubModule] 4. 프로퍼티 설정하기
[spring boot batch] 1. 간단한 대용량 배치처리, 스프링부트배치
[spring boot batch] 2. 미납회원 배치처리 구현
[spring boot batch] 3. 배치실행의 모든기록. 메타테이블
[spring boot batch] 4. 배치실행의 영역. Scope

IntelliJ
[Intellij] cannot find symbol 에러 해결하기

휘갈기는 글
새로운 규칙

 

상반기에 프로젝트를 진행해 온 것들을 스스로 정리하는 차원에서 기술블로그를 작성을 했고 최대한 내 눈높이에서 문체를 이어가려다 보니 보는 시각에 따라 다소 구구절절한 표현들이 가미됐다. 자주 방문하는 블로그(기억보단 기록을) 벤치마킹해가며 나름대로의 정리한 내용들을 녹아내려하였으나 아직까진 콘텐츠의 순도가 옅다.

 

새해에는 기술 블로그를 정기적인 계획을 세워서 성장시켜 갈 예정이다. 아직 모든 게 어설프긴 해도 현업에서 직접 구현했거나 기존의 것을 개선한 것들에 대해 차곡히 글과 그림으로 정리해 가는 습관을 다져가면 갈수록 뇌리에 좀 더 깊숙이 자리하게 된다는 걸 조금씩 체감하게 된다.

 

블로그를 쓴다는 건 내가 수행해왔던 경험을 토대로 복기을 해 갈 수 있는 그 나름에 쉼표가 되고 그것에 대해 스스로 반문해가며 답을 정리해 가는 나름의 소통의 활로가 되어준다. 지금은 미약하고 허술한 이 블로그가 내년 한 해엔 지금보다 더욱 성숙되고 건강하게 가꾸어지게 되길 소망하다.

 

부끄럽지만 그래도 1명의 방문자의 존재만으로도 감사하다.

 

신규 프로젝트 구축

사내 백오피스 시스템 개발환경은 PHP 언어기반 Codeigniter2.0 framework(이하 CI)로 유지관리되어오고 있다. CI에 대해 간단히 소개를 하자면 스프링 프레임워크의 그것과 비슷하나 CI에서는 부모 클래스인 CI_Controller를 상속받아 모든 URL네임단위로 컨트롤러 클래스명과 맵핑되어 처리를 전담시킨다. 다시말해 index.php를 제외한 서브메인페이지(https://mainurl/suburl)는 Contorller Class명이다.

 

 

역사와 전통을 자랑하는 PHP 빠르고 유연하다.

 

 

빠르고 유연한 PHP와 CI의 단순한 형태의 프레임워크가 그동안 우리 서비스의 중추인 백오피스 시스템을 굳건히 유지관리를 해온 터, 지금은 새로운 기술스택(Kotlin+SpringBoot2.0)을 기반으로 도메인 서비스 단위별 MSA를 새롭게 구축해 가고 있는 시기에 도래해 있다. 그래서인지 우리 부서 팀원 누구든 지금은 어느 때보다 주체적이면서 유감없이 무한하게 도전해 볼 수 있는 충만한 모멘텀이 자리하고 있다.

 

Null Safe한 언어  Kotlin. 이리로 가고 있다.

 

 

올 한 해 다음의 2개의 신규 프로젝트 TF로 조인했다.

상반기(4월~8월) : SpringBootBatch를 활용한 고객 미수금액 자동결제 배치 프로세스 구현

하반기(10월~12월) : Netflix zuul GateWay를 활용한 Notification 마이크로 서비스 구축

운이 좋게도 상반기와 하반기 각기 다른 도메인 영역의 서비스 구축에 참여했다.  상반기 때 진행했던 SpringBootBatch를 활용한 고객 미수금액 자동결제 배치 프로세스 구현업무는 새로운 언어(Kotlin)에 대한 장벽이 존재했다. 지금에 와서 Kotlin언어에 대한 간략한 특징을 소개하자면

• Null safe의 특징을 통해서 자주 발생하는 NullException을 예방할 수 있다.
• 기본적으로 객체지향 언어이지만, 람다 표현식과 같은 함수형 프로그래밍의 컨셉을 가지고 있다.
• JVM 위에서 작동되는 언어다.
• 자바에서 코틀린 사용 가능하고 코틀린에서 자바 사용을 가능하다.
• getter , setter가 존재하지 않음.(하지만 자체적으로 비슷한 기능을 지원함)
• (기본적으로) null값을 지원하지 않음.
• 클래스 범위 선언 안 해도 자동으로 전역변수가 된다 고로 private가 없다.
• 1 개의 primary constructor
• N 개의 secondary constructor
• secondary constructor에서는 primary constructor 호출해야 한다.

아직 Java만큼이나 성숙도가 길지 않았음에도 불구하고 Java와의 언어 호환이 뛰어난 덕분에 언어의 접근성이 생각보다 어렵지 않다. Kotlin언어로 표현하기 난해하고 답답한 지경에 오게 되면 줄곧 Java로 프로토타입 형태로 빠르게 작성한 뒤 마치 구글 번역을 돌리듯 Kotlin언어로 convert하면 제법 그럴듯하게 변환하여 주기에 이러한 패턴의 학습을 통해 언어의 친밀도를 높여갔다.

 

최근 여타의 서비스들이 Monoithic 아키텍처에서 MSA 형태로 변화해가는 추세 속에 그 왜 MSA로 가야 하는지에 대한 정확한 컨셉을 이해해 가는데는 직접 빠르게 한번 구현해 보는 것만큼 좋은 방법도 없다. 하반기에는 legacy형태로 존재해 있는 Notification성격(SMS 문자 카카오 알림톡발송, 이메일발송)의 서비스들을 공통 도메인영역으로 묶어 각 MSA형태로 구축을 하는 프로젝트를 진행했다. 이 프로젝트에 대한 도입의 필요성은 다음과 같았다.

1. 프록시 서버처럼 동작하는 모든 클라이언트 요청에 대한 EndPoint를 통합하는 서버를 만든다.

2. 도메인을 분리하면 서비스별로 서버가 많이 생길 것이고, 서비스별로 URL이 또한 많이 생길 것이다. 그렇다면, 기능별로 URL을 관리할 수 있도록 한다.

3. 동일한 기능을 하는 LegacyServer의 URL과 신규 서버 URL을 나누어 서비스할 수 있다.

4. 클라이언트 요청 시, 각 리소스에 대한 인증 요구 사항을 서비스 단위별로 쉽게 설정이 가능하도록 한다.

5. 장애발생시 클라이언트에 예외상황 응답을 유연하게 핸들링할 수 있다.

이러한 요구사항을 충족시키기 위해 각 도메인 서비스(SMS, 카카오알림톡, 메일)애플리케이션 서버를 먼저 구현하고 각 서버를 하나로 통합하여 관리할 수 있는 별도의 프록시 모듈 애플리케이션을 필요로 했다. 왜냐하면 이들 모두가(sms발송, 카카오알림톡발송, 메일발송)은 빈번한 요청과 함께 갑작스런 트래픽 과부하나 다양한 형태(예상하지 못한 형태)의 요청 등. 예측하기 어려운 운영이슈를 곳곳에 잠재하고 있는 서비스들이기 때문이다.

 

NetflixZuulProject는 이러한 MSA에서의 문제점을 충분히 고려하여 설계된 최적의 오픈소스 컴포넌트였다. 여타의 비슷한 오픈소스들이 있었지만 각기 서비스의 성격이나 상황이 다르거나 달라지더라도 우리가 필요한 것만을 선택해서 간편하게 구현이 가능한 것들 중에 결론적으로 이만한 게 없었다.

NetflixZuulProject에서 기본적으로 제공하는 ZuulFilter를 통해, 서비스 요청이 들어오면 PRE Filter를 실행하고, ROUTING Filter에 의해 원하는 서버로 요청을 보낸다. 원하는 서버에서 응답이 오면 POST Filter를 실행(run)시키도록 정의하는 형태로 그 요구조건을 매우 간단하게 쉬운 방법으로 충족시켜갈 수 있었다.

 

Zuul Filter 기본구성도 (출저 : https://medium.com/netflix-techblog/announcing-zuul-edge-service-in-the-cloud-ab3af5be08ee)

 

 

2개의 신규 프로젝트 개발 업무를 수행하면서 느낀 소회로 한마디로 그 모든 시간이 마치 나에겐 놀이터와 같았다. 아무런 기반지식이 준비되어 있지 않은 상태(원래 무식하면 용감하다)에서 다양한 사례와 튜토리얼을 여기저기 탐독하면서 사내 코어 서비스를 내손으로 빚어가는 과정 하나하나가 흥미롭고 보람됐다. 사실 회사의 업무영역에서 이만큼에 극강의 자유도를 갖고 리드미컬하게 서비스 개발을 진행하는 게 그리 흔치만은 않은 기회이지 않은가. 그러고 보면 난 올해 참 운이 좋은 사람이다.

 

Mac

2018년 3월 회사 입사 당시 개발장비로 맥을 쓸 것인지? 윈도우를 쓸 것인지? 선택을 해야하는 기로에서 윈도우를 선택한 것이 화근이었다. 당시엔 Mac 환경을 한 번도 접해보지 못했던 상황인지라 지례 겁을 먹고 윈도우가 설치된 PC를 달라고 한걸, 알고 보니 우리 부서에서 윈도우피시(그것도 랩탑이 아닌 배불뚝이 데스크탑)를 기어이 선택해서 사용하는 개발자는 나 말곤 찾아볼 수 없었다. 그렇게 작년 한해를 반짝이는 사과 마크들 속에 홀로 윈도우즈가 설치된 배불뚝이 데스크탑PC로 개발업무를 고군분투했다.

 

과거 디아블로2에서 파티구성원 모두가 날렵한 소서리스인데 나만 하필 뭣도 모르고 힘이 쎌거같아서 선택한 뚱뚱한 대머리 바바리안 캐릭으로 푸른 초원 위를 방방 뛰어다니며 보스 사냥하러 가는 심정이었다.

 

우리회사는 기본적으로 맥북프로15(혹은 13) 최고급형사양을 제공한다.

굳이 이걸 원한다면..

 

굳이 맥 VS 윈도우 중 무엇이 더 우위라는 걸 논하려는 건 차치하고 업무와는 별개로 개인적으론 맥 특유의 둥글둥글한 UI와 부드러운 화면 간 전환되는 애니메이션이 마냥 부러웠다. 옆에 동료 맥북 화면에 나오는 Item 2의 커맨드 라인을 보다가 다시 바바리안같이 생긴 내 컴퓨터의 Putty클라이언트를 켜진 화면으로 돌아오면 어디 머나먼 시간여행을 다녀온 듯한 기분이 들었다. 그리고 올해 그렇게 바바리안을 거두어내고 비로소 Mac을 영접했다. 

 

 

Mac iTerm2

Windwos Putty

 

 

윈도우즈에서 Mac으로 개발환경이 전환되면서 여러 면에서 업무효율이 증대되었다. 좀처럼 나만 좀 다르게 해야 했던 특정 개발환경 구성을 통일된 도큐먼트를 통해 진행해 갈 수 있고 OSX의 패키지 매니저인 brew를 통해 패키지 관리를 쉽고 빠르게 할 수 있게되었다. 동일한 컨테이너임에도 Kernel System Call 호환성에러가 발생했던 사례도 더이상 우려할 필요가 없어졌다. 작게보면 그저 장비가 교체되었다 할수 있겠지만 좀 더 멀리서 보자면 개 개발업무 전반에 걸친 모든 환경이 전환되었다고 할 수 있을 만큼 올 한 해 획기적이고도 행복한 변화이다. 다시 한번 말하지만 윈도우즈가 나쁘게 다는 게 결코 아니다.

 

PM

하반기 10월에 신규 프로젝트 프로젝트 관리자를 맡게 되었다. 보편적으로 그려지는 혹은 그간 내 경력 커리어에서 봐왔던 PM은 대개가 그랬다. 도메인 영역 유지관리업무에 A-Z까지 차근히 다져진지라 이젠 제법 툭하면 척척 답을 제시할 줄 알고  내면에 카리스마로 팀 동료들의 사기를 잘 이끌어가거나 필요에 따라 분위기를 집중력 있게 장악해 갈 수 있는 그런 사람. 그게 나일리는 만무했다.

 

내향적인 성격상 팀 내에서도 말 수가 적고 업무의 능률 또한 전체로 보아 그리 탁월한 편도 아니다. 최종적으로 내 의사결정이 수반된 합의이긴 해도 당시 그 후보로 내가 염두되었는진 솔직히 지금도 궁금하긴 하다.

영화 암살의 염석진대장 : 도메인MSA가 총 3개지요~

앞서 이미 설명한 바, 기존 백오피스 내부 Legacy로 파편화되어 있는 Notification성격의 서비스들(SMS, KAKAO알림톡, 메일)들을 MSA구조로 한데 묶고 모든 클라이언트 요청에 대한 end point를 통합할 수 있는 gateway 애플리케이션서버를 구축하였다. 서비스 성격상 발생빈도가 잦고 특정 시점의 트래픽이 과다하게 칠 수 있다는 점을 고려하여 Google StackDriver Trace 플랫폼을 도입하여 서비스 요청에 대한 이동경로를 추적할 수 있게 하고 타임라인을 통해 전체 트래픽 혹은 샘플 된 결과를 실시간으로 측정이 가능하게 했다.

 

측정가능해야하는 서비스를 측정가능하도록 GCP StackDriver Trace를 적용했다.

 

(이 프로젝트에 대한 자세한 소개는 다루진 않고 차후 정리를 하여 소개할 예정이오니 관심 있으신 분께서는 기다려주시면 감사하겠습니다.)

 

당연히 그렇듯 생애 첫 프로젝트 관리자 업무는 정신없고 바빴다. 엉뚱하다고 하면 엉뚱하지만 결과적으로 그리 되었으니  그런 까닭에 뭐가 뭔지 모르는 사이에 올 하반기는 후다닥 지나가버렸다. 이 쪽문으로 들어와서 그대로 저쪽 문으로 나가버렸다.

 

나를 제외한 다른 2명의 동료를 섬기어 가는 것은 혼자 업무를 수행해 가는 것과 다른 차원의 한계와 어려움이 존재했다. 가만히 서서 뭔가를 곰곰이 생각할만한 시간적 여유가 점차 없어지다 보니 때론 과정이 겉돌게 되는 시행착오를 겪거나 동료들 사이에 소통에 대한 문제도 발생했다. 그래도 어쩔 순 없었다. 피아노 연주회에서 건반을 잘못 칠대마다 "아이쿠 죄송합니다. 틀렸네요." 하고 처음부터 연주를 다시 시작할 수도 없는 노릇이니.. 때론 업무적, 감정적 오해나 갈등은 그저 그대로 가슴 어딘가에 묻어가기도 하고 당초 계획과 다른 형태나 방안에 대해서도 그것이 타당하다면 빠르게 수용하고 타협해 가는 것이 당시 내 판단으로는 최선의 선택이었다.

 

관리자의 직책을 맡는다는 건 어디 하나 숨을 데가 없다는 것이다. 뭐가 잘 안되거나 이슈가 발생하면 그 앞엔 항상 든든한(?) 관리주체가 서있었고 그의 판단에 따라 문제를 해결하거나 제시한 대안에 따라가기만 하면 된다. 그러나 그 든든해야 할 관리 주제가 전혀 든든하지 않다고 생각되는 나 자신이 돼버리면 얘기는 달라진다. 잔잔하게 넘실대는 물결조차 거대한 파도가 덮쳐오는 것 같고 분명 좌회전을 했는데 동체는 자꾸 우회전한다.

 

암초다!!!!!

오른쪽으로 돌려!!!

오른쪽!!!!! 이 개새끼야!!!!!!!

 

시스템 설계부터 구축 그리고 기존 레거시에서 서빙되고 있는 서비스들을 새롭게 설계된 시스템으로 이관하는 과정까지 장장 3개월이라는 시간을 소요했다. 주어진 양만이라도 무조건 책임지자는 마음으로 한 걸음 한 걸음 물속을 걷는 것 같이 조심조심 나아가 우린 결국 조금 늦어졌어도 좌초되거나 표류되지 않고 온전히 종착점에 도착했다. 고난의 항해를 함께 해준 팀원들에게 감사를 표한다.

 

소통

말이 많은 편이 아니다. 언제부터인진 잘 모르겠지만 주변으로부터 원래 그렇게 말을 안 하는 편이냐는 질문을 유독 많이 받았던 한 해였다. 적어도 가까인 친구들에겐 곧잘 조잘되던 아주 어렸을 적을 빼면 담을 수 없는 말은 차라리 적을수록 좋은 게 미덕으로 여겨오면서 자연스례 체화된 것도 없지 않다.

 

서른 나이가 접어들면서 대개 서너 명이 모여 함께 즐거이 담소를 나눌만한 주제의 공통분모를 찾기란 쉽지가 않을뿐더러 지금껏 거처가 협업의 파트너들 중에 유난히 말이 많은 사람에게만 매번 크게 데어왔던 지라 스스로에게도 극도로 기피하는 유형에 대해 타석지석으로 삼기 위한 습성을 내재해온 탓이다.

 

딱히 그러한 사연을 들지 않더래도 개발자의 업무적 역할에서 좀처럼 말을 할 기회가 그리 많지는 않았다. 같은 언어이긴 해도 보통은 컴퓨터가 이해할 수 있는 언어로 컴퓨터와 대화를 하고 업무형상을 관리해간다.  삶의 도처에 내 성대에 힘이 들어갈 일이 좀처럼 없다 보니 정작 목소리가 필요한 순간 비로소 목소리가 잘 나오지 않게 된 것에 대해  조금 실감 있게 받아들이게 된 것도 최근이었다. 협업의 과정 중에 기술 문의를 받고 내가 알고 있는 지식을 알기 쉽게 설명을 해야 하거나 협의과정에 있어 설득이 필요한 순간에 정작 내가 전달하고자 하는 내용이 좀처럼 잘 표현되지가 않았다.

 

말을 하면서 머릿속에서는 그려지는 구문의 조합이 순간적으로 흐트려지거나 어색한 단어의 선택으로 말하고 있다는 사실을 한참 동안 모르고 지내오다 최근 주도적으로 협업을 해야 하는 순간에서야 차츰 깨닫게 됐다.

 

문서로 기록을 남기는 과정은 초고를 기준으로 몇 번의 수정을 거쳐 상대에게 전달이 되지만 즉흥적인 말의 표현은 그러한 버퍼링이 허용되지 않는다. 불펜에서 한 개의 공도 던지지 않은 채 벤치에 엉덩이 말에 손 넣고 구경하다가 바로 마운드로 나와 공을 던지는 투수라면 그때에 내 상황에 대해 조금은 이해되지 않을까?

소통하는 능력, 이것도 좀처럼 의식적인 훈련이 필요하다. 이미 경직될 때로 경직된 근육상태에서 어떠한 스트레칭 없이 순간적인 무리를 가할대 오는 경련처럼 평소 말을 잘하지 않다고 말로 표현해야 하는 순간이 닥쳐올 때 발생되는 이질적인 충격은 생각보다 적지 않다.

 

내년에는 의식적인 소통을 해 나아가고자 한다. 주변 동료들과도 원만한 대화를 조금씩 참여하는 습관을 가져가는 것부터 시작해서 팀 내 스터디에서 정기적인 발표 기회를 가지면서 이러한 내 중증이 되어버린(?) 약점을 조금씩 회복해가고자 한다.

 

2019 실수에 관하여

옛날 미국 서부의 술집은 대부분 전속 피아노 연주자들을 두어 밝고 티 없이 맑은 춤곡을 연주하게 했다. '피아니스트를 쏘지 말아 주세요. 그도 열심히 연주하고 있습니다.'라는 메모가 피아노에 붙어있었다고 하는데 왜인고 하니 실제로 피아노 연주가 영 시원찮으면 술을 마시는 총잡이들이 사정없이 피아니스트 향해 마구 총질을 해댔기 때문이다. 매일 전쟁터와 같은  공포 속에 건반을 치던 그때의 피아니스트들의 숭고했던 소명의식은 지금에 와서도 충분히 경의를 표할만하다.

백오피스 개발업무을 하면서 기존의 레거시를 거두고 미래 유지관리가 용이해질 수 있도록 더 우아하고 간결한 프로세스로 늘 고민하는 태도는 늘 유지하려 노력한다. 그리하여 중요한 부분을 기꺼이 완성하고 비교적 평이한 부분으로 들어서면 집중력이 확 풀리면서 하찮은 실수를 저지를 대가 종종 있다.

 

코드 리뷰 PR을 올리기직전 내 두눈으로 분명 diff를 몇번이나 대조해보지만, '이런데서 틀렸을 리가 없어'라는 선입견이 있다보니 몇번씩 검토를 하면서도 그 버그를 찾아내지 못한다. 리뷰과정까지 갈 것가지도 없이 그렇게 코드리뷰PR을 올리고 퇴근 이후 이부자리에 들어가 불을 끄고 멍하니 잠을 청하려던 참 '아차 그게 잘못했다.'라는 생각이 불쏙 내미는 찰나 뇌 한구석에 일부의 정신 세포는 이미 잠이 달아내고 말똥거린 상태가 된다.

내가 별로라는 걸 인지하는 사람은 더 나은 사람이 되기 위해 무엇을 해야 하는지 고민할 수 있다고 생각한다. 그런 면에선 난 아직 많이 별로인 사람이다. 필요 이상 자책은 필요 없을지라도 책임을 다해야 할 일에서 아직까지 자기 확신이 강한 편이라 어떤 문제가 발생하면 그 출발점은 내부가 아닌 외부에서부터 머저 찾아가려는 습성을 아직 버리지 못하고 있다.

 

현업에서 내가 잘 모르는 기술적 문의에 대한 변명으로 '허허 제가 사실 그동안 SI개발만 해온 터라 이런 건 잘 모릅니다'라고 상황을 무마하려 했던 적도 있었는데 이건 지금 생각해봐도 참 황당하고도 창피한 기억이다. 내가 과거 일해 온 환경이 어떤지간에 그건 그거대로, 굳이 내 경력연차 대비 지식의 한계치까지 내가 몸담았던 본적에 얹혀 책임을 회피하는 건 얼마나 비겁하고 옹졸한 처세인가? 그런 기억들이 가끔 주마등처럼 스쳐지 날 땐 나도 모르게 얼굴 낮에 살짝 미열이 올라온다.

올해는 더 나은 사람이 되기 위해 '내가 별로'라는 것을 인지하게 된 것만으로도 그 나름에 의미가 있다. 새해엔 지금보다 좋은 사람이 되고 싶다. 개발자로써 개발을 더 잘하는 사람보다 먼저 좋은사람이 되고 싶다. 우리 서비스를 이용하는 고객들이 더 좋아할 수 있는 서비스를 제공하는 개발자 중 한 사람으로, 팀 동료들에게 힘이 되어 줄 수 있는 좋은 한사람으로, 어딘가에 존재해 있을(잠시 눈물좀..)내 배우자에게 행복하게 해 줄수 있는 좋은 한사람으로 그렇게 나아지고 싶다.

 

언제쯤 그럴 수 있을까. 매일 침대에 누워 하루일을 뒤돌아 보면서 '그땐 좀 내가 그랬지만 그래도 그건 내가 잘했다.'는 생각을 더 많이 할 수 있을까? 올해에 기록된 그런 실수의 기록은 내년에 더 나은 사람이 될 수 있는 자양분으로 될 수 있게끔 이렇게나마 허술한 회고의 기록으로 잊기 전 먼저 남겨놓는다.

 

부록. 2019년 즐겨 본 유튜브

1. 우리 업계에선 그가 백종원, 백기선 유튜브 https://www.youtube.com/user/whiteship2000

백기선

2. 안경잡이 개발자, 나동빈 https://www.youtube.com/channel/UChflhu32f5EUHlY7_SetNWw

동빈나

3. 1인 개발자의 목소리를 들을 수 있어서 좋아요. 사윤 TV https://www.youtube.com/channel/UCNKmQkO1zhCwsIqqrh7pSAg

사윤TV

4. 제가 예배드리는 교회입니다. 새문안교회 https://www.youtube.com/channel/UCM1lj8Gqmiw_aqTKqYNXcSQ

새문안교회