2021년을 돌아보고 2022년을 목표를 다짐 하면서 작성한 회고록입니다.
지난 1년의 시간동안 경험 했던일을 정리하면서 작성해보았습니다.
최대한 타임라인대로 작성하였으나, 조금 차이가 날수도 있습니다.
2019년 회고 / 2020년 계획
2020년 회고 / 2021년 계획
에 이은 세번째 회고입니다.
1. 2021년 상반기
1.1 이직
작년 회고를 작성할때 쯤에 서류를 넣은 곳이 한군데 있었다. 그게 지금의 회사 이기도 한데,
어차피 일정이 2021년에 끝날것같지 않고, 합격을 한 상태도 아니므로 2021회고에는 따로 언급하지는 않았다.
연초부터 매우 바빴는데, 서류가 통과하고 나서 바로 코딩 테스트 일정이 잡혀있었다.
코딩 테스트는 합격하였고, 그 다음 1차 면접을 보게 되었다.
퇴근하고나서 계속 공부를 한상태로 면접 준비는 따로 하지는 않았다.
다만 기존에 알고있는 내용을 복기하는 정도로만 정리를 하였다.
면접은 화상 면접으로 진행되었는데, 매우 기억에 남는다. 무려 7명에 달하는 분들이 면접관으로 들어오셨다.
긴장되거나 떨릴 겨를도 없이 질문 하나하나에 답변 하다 보니 정해진 시간이 모두 지나가 버렸다.
입사를 하고나서 보니 면접에 들어오신 분들 모두가 팀장직급을 가지신 분들이었다.
그리고 2차 면접까지 꽤나 오랜 시간이 걸렸다. 그쯤 확진자수가 급증해서 그랬다.
이게 정말 내입장에서는 힘들었다. 합격한 상태도 아니고 마지막 관문이므로 빨리 결과를 보고 싶었는데,
하루마다 늘어가는 코로나 확진자 때문에 일정이 계속 밀렸다.
그렇게 벌써 2월이 다되었고, 결국 임원진 면접은 대면 면접으로 진행되었다.
임원진 면접은 인성 면접이었고, 질문에 성실하게 대답하고 무덤덤하게 집으로 왔다.
떨어지던 합격하던 하고있는 일을 해야했고, 그렇게 한 일주일 동안 매우 바쁘게 지냈었다.
그러다가 문자 메시지와 메일로 최종면접 결과가 날라왔다. 결과는 최종 합격이었다.
1.2 퇴사와 입사, 끝 그리고 시작
퇴사전에 했던일은 다음과 같다. 하던 업무의 마무리와 인수인계 문서 작성 그리고 바로 부검메일 작성이다.
하던 업무 마무리와 인수인계 문서는 당연히 해야하는 일이었다.
팀장님께서는 인수인계 문서만 잘좀 써달라고 하셨고, 거기에는 장비 관리와 같은 내용도 있어야했다.
인수인계 문서를 쓰려고 기존에 입사자들이 쓰고갔던 인수인계 문서들을 봤는데
형식도 제각각 담고 있는 내용도 제각각이었다.
나는 가는길 마저도 뭔가를 남기고 가고 싶은 마음에 아무도 하지 않았던 제대로된 인수인계 문서를 작성했다.
기존에 인수인계 문서들은 고작 한두 페이지였고, 목차도 순서도 없이 정말 엉망진창이었다.
신규 입사자가 해당 문서를 받았을때 매우 당황할 정도의 내용이었다.
내가 처음왔을때 받았던 인수인계가 왜그렇게 허술하였는지 알 수 있었다.
나는 누군가가 나와 같은 입장이 된다면, 내가 겪은 고민을 겪지 않았으면 좋겠으면 하는 마음이었다.
우선 내가 크게 중점적으로 작성했던 부분은 내가 하고 있는 업무에 대한 이해와 업무 방법들이다.
그리고 개발 환경, 소스코드 구조, 그리고 마지막으로 내가 미처 진행하지 못한 일들에 대한 내용이었다.
인수인계 문서를 작성하면서, 체계적인 문서화의 중요성을 남아있는 사람들에게 전하고 싶었고,
내가 진행하지 못하고 떠나는 일에는 비효율적이고 개선의 필요성이 있다고 생각하는 부분들이 있었다.
나의 게획들에 대한 가이드, 누군가 혹시라도 나와 같은 생각을 한다면 실마리를 잡을수 있게 작성을 하였다.
하지만 내가 하지 못했던 일들에 대해서는 부검메일에 쓰는게 좋다고 생각하여 부검메일에 내용을 작성했다.
내가 회사를 다니면서 하고자 했던 일들은 대략 다음과 같다.
- 이슈 처리의 효율화를 위한 Jira 도입
- 노션, 컨플루언스를 통한 체계적인 문서화 체계 구축
- 테스트 코드 추가 및 시니리오 기반의 테스트 환경 구축
- 레거시 코드의 리팩토링 (레거시 코드의 모던 c++으로의 전환)
- 코드 리뷰 시스템 강화
- svn 에서 git으로의 전환
이중 Jira 도입과 git의 전환, 그리고 문서화 툴 도입을 위해서는 팀원들을 모아놓고 발표까지 했었다.
개발자 테스트 시나리오화 계획은 러닝 메이트와 몇날 몇일 야근까지 해가면서 테스트 스텝을 만들어놨었다.
하지만 이직을 하게 되면서 끝내 개선을 하지 못하고 퇴사하게 되어서 미련이 조금은 남는다.
게다가 위의 내용은 부검 메일에 담기에는 상당히 많은 양의 내용이었다.
그래서 위의 상세 계획을 조금씩 구체화 하여 남아있는 러닝 메이트에게 문서로 정리하여 전달하였다.
2021년 3월 까지 전 회사에서 근무하고 4월 5일 부터 현재의 회사로 출근하게 되었다.
새로운 회사에 입사하기까지 약 5일간의 시간동안은 푹 쉬려고 했는데, 기대 반 설레임 반으로 쉬지도 못하였다.
또한 쉬는 기간동안에는 퇴사하는 회사에서 배운것과 다니면서 있었던 일들을 정리하였다.
1년이 좀 넘는 시간동안 정말 많은 일들이 있었고, 추억도 많이 쌓았던 것 같은데 조금은 아쉬운 마음도 들었다.
또한 새롭게 출근할 회사에 가서 무엇을 해야할지, 요즘에는 어떤 기술이 뜨고있는지 등을 돌아보는 기간이 되었다.
나는 첫번째 직장에 다니기전에 인턴을 이미 다른 회사에서 해봤기 때문에 별다른 느낌이 없을거라고 생각했다.
하지만 새로운 팀원들과 새로운 프로젝트를 생각하면 설레는 마음을 감출수가 없었다.
이직을 하면서 많은 것이 달라지긴 했지만 새로운 환경에 적응해나가는것에 크게 어려움이 없었던것 같다.
전회사에서 쌓아왔던 것들은 버리고 새로운 환경에서 새로 시작한다는 것은 두려운 일인지도 모른다.
하지만 다르게 생각해보면 새로운 사람들을 만나고, 새로운 프로젝트를 맡게 된다는 것은 기쁜일이 아닐까
1.3 Unix
작년 회고에도 등장한 유닉스에 대한 이야기를 좀 해보려고 한다.
유닉스에 대한 포스트를 계속 작성 하고는 있지만, 여기에도 짧게나마 언급을 해보려고 한다.
아래는 구글링을 하다가 다운로드 받은 사진이다. 2021년을 기준으로 잔인할 정도로 현실을 잘 반영하였다.
사진처럼 유닉스는 더이상 쓰이지 않는데에 반해, 리눅스는 임베디드에서 정말 많이 사용된다.
물론 현재 대부분의 운영체제의 뿌리가 유닉스에 있음을 보면, 상당히 안타까운 현실이 아닐수 없다.
퇴사하기전에, 그니까 2021년 초에 새로운 유닉스를 맞이했다.
정확히는 장비가 온게 아니고, os가 설치된 HDD가 왔고 유닉스 장비에 장착했다.
왜 HDD만 구매를 했냐면 윈도우로 따지면 부팅 드라이브를 다르게 해서 사용하는것처럼
설치된 두개의 하드에 각각의 os가 설치되어있고, 부팅시에 디스크를 바꿔서 부팅하여 사용한다.
왜 이렇게 써야하냐면 장비를 구하기가 하늘의 별따기이기 때문이다.
장비 업체를 수소문해도 이미 오래전에 단종된 cpu를 구할수가 없고, 그에 맞는 보드 역시 마찬가지였다.
그래서 중고 장터 까지 뒤져가면서 장비를 구하려고 했으나 중고로 구매하는 경우 A/S를 받을수 없으며
육안으로 보이지 않는 내부 부품들이 언제까지 버텨줄지도 모르기 떄문에 중고 구매는 진행이 안된것으로 알고있다.
그러다가 겨우 발품발아 찾은 업체측에서 보유중인 os가 설치된 HDD가 있다고 하여 구매를 할 수 있었다.
서버 장비의 경우 굳이 gui를 통해 접근을 할 필요가 없다.
그래서 서버 장비를 렉에 여러대를 꽂아두고 모니터와 키보드, 마우스를 옮겨가며 꽂아서 사용한다.
보통 노트북이나 pc는 썬더볼트나 hdmi가 달려있는데, 서버 장비의 경우에는 보통 rgb포트가 달려있다.
근데 만일 hdmi는 커녕 rgb포트가 없는 경우에는 어떻게 서버 콘솔로 접근을 할수있을까?
정답은 시리얼 포트이다. 이름도 생소한 시리얼 포트…
putty에 있는 접속 방식중에 시리얼 포트 연결이라는게 있는데 이걸 처음 써봤다.
시리얼 포트를 pc에 한개의 pc에 연결한뒤, 연결된 pc에서 장비로 시리얼 접속을 하면된다.
HDD를 변경해서 부팅을 하는 경우 이과정을 진행해야 했고, 그때마다 서버실에는 노트북을 들고가야 했다.
그리고 생각나는 것은 유닉스의 패키지 매니저에 대한 내용이다.
리눅스를 사용하면 apt나 yum과 같은 패키지 매니저를 사용할것이다.
유닉스에도 패키지 매니저가 있냐? 물론 있긴 있다.
문제는 의존성 라이브러리 설치를 해주지 않고 단순히 소프트웨어 설치만 하는 역할을 한다.
리눅스와 유닉스에서 git을 설치한다고 생각해보자
리눅스에서는 yum -y install git으로 쉽게 git을 설치할 수 있다.
유닉스는 어떻게 해야할까?
- Unix 제조사 홈페이지에서 설치하고자 os에 맞는 패키지를 찾는다 (아키첵쳐 및 os버전 확인)
- 설치하고자 하는 패키지가 의존하고 있는 패키지를 찾아 다운로드 받아준다.
- 패키지 매니저를 통해 의존 패키지를 설치해주면 된다.
만일 설치할 패키지가 다른 100개의 패키지를 의존하고있다면 어떻게 해야할까?
그렇다. 최악의 경우에는 1번 부터 3번의 과정을 100번 수행해야 한다.
hp-ux는 depot 이라는 패키지 시스템을 사용하고, swinstall 이라는 패키지 설치 툴을 이용한다.
위의 사진이 바로 swinstall 이다. 자세히 보면 알겠지만, gui툴이 아니라 cli로 구현된 gui형태이다.
cli 터미널 화경에 gui가 있을리가 없다. 흡사 BIOS 설정을 보는것 같기도 하다.
사용할때마다 느끼는건데 이걸 구현한 사람들 역시 정말 대단한 것 같다.
gui이긴 하나 보기랑은 다르게 마우스로 사용은 불가능하고 키보드 입력만으로 작동하는데,
문제는 설치할 패키지 경로를 직접 입력해주어야하는데, 이게 복사/붙여 넣기가 안된다.
즉, 설치하고자 하는 패키지의 full-path를 전부다 직접 입력해주어야 한다.
hp-ux에 git을 설치하려면 무려 40개에 달하는 패키지를 전부 설치해야 했다.
유닉스에 대해서 안좋은 이야기만 하는것같은데, 조금은 다른 얘기를 해보자면
유닉스를 얘기하면서 c언어를 빼놓을 수가 없다. 유닉스가 c언어로 작성된 운영체제이기 때문이다.
c언어는 2021년을 기준으로 딱 50년된 프로그래밍 언어이다.
현재는 추상화된 언어들이 많이 나왔지만 유닉스가 개발되던 당시에는 어셈블리어를 사용 하던 시절이었다.
그때 만들어진 언어인 c언어가 50년이지난 지금 까지도 쓰인다는 것은 놀라운 사실이다.
특히나 어플리케이션 레벨이 아닌, row 레벨에서의 c언어 대체제는 존재하지 않는다.
리눅스 커널의 경우 지금까지도 c언어로 개발되고 있다.
유닉스에대해 혹시라도 알고싶다면 다음 책을 꼭 읽어보기를 추천한다.
유닉스의 탄생 - 세상을 바꾼 운영체제를 만든 천재들의 숨은 이야기
꼭 유닉스에 관심이 있지않아도 컴퓨터를 좋아하는 사람이라면 매우 흥미롭게 읽을수 있을 거라고 생각한다.
그리고 작성중인 유닉스 회고록은 언젠가는 완성해 포스팅 하려고 한다.
1.4 키보드
나는 그냥 회사에서 주는 멤브레인 키보드를 사용했다.
그전까지의 나는 고가의 키보드는 사치품 정도로 생각을 했던것같다.
LED가 반짝 반짝 거리고 타건감이 좋은 기계식 키보가 정말 필요한가 라는 생각을 했다.
인턴 시절에 회사에서는 개발자들에게는 고급 키보드를 주었는데, 아마 받았어도 잘 사용을 안했을 것 같다.
직장에서도 기계식 키보드를 사용하는 팀원이 몇이었는데 몇번 타건해보아도 도저히 뭐가 좋은지 몰랐었다.
그러다가 작년에 친했던 차장님의 추천으로 구입한 기계식 키보드로 키보드에 눈을 떳다.
고가의 키보드의 장점을 말씀해주셨었는데 특히 손가락 건강에 대해서 말씀 해주셨을때 넘어가고 말았다.
개발을 오래하고 싶고, 잘하고 싶으니 기계식 키보드를 구입해보라는 것이었다.
차장님은 포커배열이라고 하는 기존 키보드이 60%의 배열만 있는 키보드를 추천해주셨다.
나는 바로 키보드를 샀고 걱정과는 다르게 방향키와 f1 라인 키가 없는 키보드에 어떻게 적응하나 해는데,
산지 몇시간만에 집중해서 사용하니 손쉽게 적응하였다.
작년 회고에 해피해킹 키보드 구입을 고민하고 있다고 했는데, 앤프로를 산이유가 바로 위의 내용이다.
올해는 이직을 하면서 그동안에 수고했던 자신에게 보상을 주기위해 큰마음을 먹고 해피해킹을 구입했다.
그리고 리눅스 환경에서 vi로 프로그래밍을 할것이므로 개발자에게 편하다고 하는 해피해킹을 골랐다.
퇴직금과 연차를 사용하지 않고 받은 돈이 좀 생겨서 그돈으로 해피해킹을 구입했다.
키보드 하나에 무려 40만원이 넘기 때문에 정말 고민을 많이 하다가 결국 주문을 했다.
위의 사진과 같이 처음 보게되면 저건 무엇인가하는 생각이 들것이다. 나도 그랬다.
방향키도 없고, 숫자패드도 없고, f1 라인도 없다. 정말 있을것만 있는 듯한 느낌이 든다.
실제로도 키보드가 작기 때문에 풀배열을 쓰다가 넘어오면 책상의 여유 공간이 생긴다.
나도 특이한 키의 배열이 걱정이되었는데, 이미 포커 배열로 넘어왔기 때문에 생각보다 쉽게 적응 하였다.
아무래도 포커 배열과는 다른점(ctrl키, backspace키, fn키)이 많아 하루정도 걸렸던 것으로 기억한다.
이제 방향키가 따로 없는 것은 큰 문제가 되지 않을 정도로, 특이한 배열의 키보드에 적응을 해버렸다.
처음 해피해킹을 타건 했을때를 정말 잊을수가 없었다. 도각도각 초콜릿 부러뜨리는 느낌이 너무 좋았다.
키감이 너무 좋아서 처음 받고나서 신나서 코딩을 했었다. 그뒤로 앤프로2는 거의 쓰지않고 있다.
그런데 회사에서는 윈도우를 쓰다보니 해피해킹을 쓰고, 집에는 맥을 써야해서 매직 키보드를 쓰는데,
출근, 퇴근 하고 한동안은 오타가 많이 발생했다.
그것도 그럴것이 하루 절반 넘게 해피해킹을 쓰다가 퇴근후에 다른 배열을 쓰려고하니 헷갈리고
해피해킹에 적응할때쯤 퇴근후 매직키보드를 쓰다보니 출근, 퇴근 하고 나서는 오타가 좀 많았던 것이다.
그래서 나는 조금 번거로워도 키보드를 들고 다니는 것을 선택하였다. 하지만 이것도 문제가 있었다.
서로다른 os에서 사용하기 위해 출근, 퇴근 하고나서 딥스위치를 매번 바꿔주어야 하는것이다.
하루 두번 딥스위치를 변경하는것도 일이라서, 결국 해피해킹 한대를 더 구입하였다.
키보드에 돈을 쓰는게 사치처럼 느껴질 수도 있다고 생각한다.
하지만 하루종일 개발 업무를 하면서 몸에 직접 닿는게 의자, 모니터, 키보드, 마우스 정도 밖에 없다.
키보드가 좋고 모니터가 좋다고 꼭 개발을 잘하는것은 아니다. 사실 아무런 관계가 없다.
하지만 개발할때 주변의 좋은 환경 조성을 통해 조금이라도 더 집중하고 효율을 낼 수 있다면,
그게 얼마가 되었던 반드시 투자해야 한다고 생각한다.
1.5 OS 만들기 프로젝트
2021년에 가장 잘했다고 생각하는 일중 하나는 OS 만들기 프로젝트를 마무리한 일이라고 할 수 있다.
학생때부터 정말 보고 싶었던 책이었는데, 입사하고 얼마뒤에 보니 옆 팀원 분의 책상위에 이책이 있었다.
보고싶다고 말씀드렸는데 책을 내게 주셨다. 두권으로 구성되어있으며 무려 3천 페이지에 달하는 책이다.
입사하고 일정 기간 동안은 ojt 및 팀내 적응기간을 가졌다. 업무를 시작하기 시작할때쯤 이책을 펼쳤다.
그때가 아마 5월이었던 걸로 기억하는데, 책을 전부 읽고나니 12월이 되어있었다.
책은 엄청나게 방대한 내용을 담고있다. os를 다루는 책이다보니 당연하다고 생각한다.
부트로더, 어셈블리어, c언어, 자료구조, 파일 시스템, 인터럽트 핸들링, 프로세스 스케쥴링, gui 시스템
정말 돈을 주고 사도 아깝지 않을 만큼의 방대한 양을 다루고 있다. 다만 그만큼 상당한 지식을 필요로 한다.
이책을 보면서 공룡책이라고 부르는 OS 책과 컴퓨터 구조론의 책을 같이 보면서 프로젝트를 진행 했다.
난 학교에서 운영체제 수업을 정말 좋아하고 열심히 들었는데, 그때 열심히 들은걸 정말 감사하게 생각한다.
위에서 언급했지만 2021년 하반기에는 바쁘기도 했지만, 이책을 보느라 거의 모든 시간을 보냈다.
게다가 코로나가 다시 유행하면서 재택근무가 계속되었고, 정말 몇일 동안 집밖에 나가지도 않고 공부를 했다.
프로젝트를 진행하다가 막히는 구간이나 소스가 이해되지 않으면 정말 머리채를 움켜쥐어가며 진행을 하였다.
다본뒤에는 조금 휴식기를 가진 뒤에 리눅스 커널 소스 분석을 시작 하려고 했는데, 엄두가 나질 않는다.
이책을 읽은 이유 중에는 커널 소스를 분석에 도움을 얻고, os에 대한 지식을 다지려는 것도 있었다.
2022년에는 시간이 좀 남는다면, 커널 소스 분석에 도전을 해보려고 하는데 잘되었으면 좋겠다.
이 프로젝트의 저장소는 64비트 멀티코어 OS 만들기 레포지토리 여기 이다.
README 파일에는 책읽기전 참고하면 좋은 내용들과 간단한 후기를 올려놓았다.
혹시라도 관심이 있다면, 읽어보기를 바란다.
2. 2021년 하반기
2.1 사내 깃-깃플로우 발표
입사하고 가장 먼저 하고 싶었던 일은 바로 svn에서 git으로의 전환과 gtest를 이용한 단위 테스트다.
우선 gtest를 꼭 도입하고자 했던 이유는 회사의 제품 코드에는 테스트 코드가 거의 전무하다 시피했다.
그래서 꼭 테스트 코드를 제품 코드에 반영하고 싶었다.
svn에서 git으로의 전환은 전 회사에서 미처 마무리 하지 못한 숙제와도 같아서 꼭 해보고 싶었다.
우선 시작에 앞서 왜 전회사에서 전환을 실패 했는지에 대한 분석을 하고 전환 준비를 진행하였다.
여러가지 이유가 있지만, 나의 준비가 부족함을 탓했다. 그래서 나는 더 많이 준비를 했다.
발표를 준비하는 두달 동안 깃 레포지토리만 몇백개를 생성하였고 테스트 하였던것 같다.
깃 관련 책도 두권을 읽었고, 강의도 들었다. 수십개의 블로그를 보면서 준비를 했다.
나는 깃을 좋아한다. 대학생 시절부터 깃을 사용했고, 깃 플로우를 통해서 프로젝트를 관리해왔다.
하지만 내가 잘알고 사용하는것으로는 부족했다.
우선 깃으로의 전환을 위해서는 깃을 아예 모르는 사람을 설득하고, 이해를 시켜야 했다.
그런데 남을 이해 시키려면 나혼자만 알고있는것보다 더 많은 것을 알아야 했다.
기존에 사용중인 svn만을 사용하던 사람들에게 git의 러닝 커브는 좀 있는 편이라고 들었다.
git으로의 마이그레이션은 나의 제안이었으므로 팀원들의 학습까지 맡았다.
그래서 나는 처음 git을 사용하는 사람의 마음가짐으로 공부를 시작하고 발표자료를 준비했다.
정말 git을 하나도 모르는 사람이 보더라도 이해가 가능하도록 발표자료를 준비헀다.
대상은 팀원 전체였고, 거의 20명에 달하는 사람들이 내 발표에 들어오게 되었다.
긴장이 많이 되기도 하고, 준비한 내용을 충분히 전달하지 못할까봐 두렵기도 했다.
그리고 질문이 나올수있다고 생각하는 리스트를 미리 만들어서 답변을 달아 예행 연습을 하기도 헀고,
팀내에 몇명을 대상으로 발표 연습을 진행 하기도 했다.
발표는 무사히 마무리 되었고, 칭찬도 많이 받았다.
앞으로도 종종 이런 발표를 진행해줬으면 좋겠다는 소리도 들어서 꽤나 뿌듯했다.
그래서 발표이후에 git으로 전환을 성공했냐 하면…
웃기게도 git을 사용하는 파트로 이동하게되어 git을 사용하고 있다.
하지만 팀내에 신규 입사한 분들의 경우 git에 익숙하지 않은 분들도 있어서
그분들에게 조금이나마 도움을 주고있다.
굳이 잘 사용중인 svn을 놔두고 git으로 가야하냐는 질문에 대한 나의 대답은 다음과 같다.
git으로 가지 않아도 됩니다. 다만 git이 svn 보다 더 개선되었다고 생각할 뿐입니다.
만일 git의 단점들이 개선된 새로운 툴이 나왔다면 저는 그 툴을 도입하자고 할 것 입니다.
문제를 인지하고도 그대로 두는것은 문제를 인지하지 못하는 것보다 더 위험한 태도라고 생각한다.
익숙함에 속아 소중한것을 놓치지 말라는 말이있습니다. 불편함에도 익숙해지지 말아야합니다.
내가 만드는 제품에 있어서 불편하고 개선의 여지가 있다면 과감없이 개선해나가는 개발자고 되고싶다.
2.2 업무 변경 (Golang와 Docker)
무더운 여름쯤에 나는 업무롤 변경을 제안 받았다.
제안받은 프로젝트는 신규 프로젝트 였고 내가 이제까지 사용하던 c++을 사용하지 않는 팀이었다.
게다가 잘모르는 MSA 구조의 프로젝트여서 나를 더욱 고민에 빠지게 만들었다.
선택에 앞서 나는 우선적으로 내게 제안이 온까닭을 먼저 생각했다.
나의 장점은 새로운 기술을 빠르게 습득하고, 프로젝트를 진행해나가는 것이라고 생각한다.
그러한 장점을 잘 살릴수 있는 기회라고 생각했다. 그래서 나는 제안을 수락하였다.
업무 환경 역시 c++와 온프레미스 환경에서 벗어나 Golang과 MSA 환경으로 업무롤 변경을 하게되었다.
업무가 변경하게 되면서 자바와 golang의 두가지 경우의 수를 제안 받았는데, 나는 go를 선택헀다.
선택한 이유는 자바는 이전에도 조금 접해본 경험이 있지만, go는 한번도 경험해본적이 없는 언어였다.
대학생때부터 새로운 언어를 공부하는 것을 좋아했고, 투입까지 시간이 좀 남아서 바로 공부에 돌입했다.
우선은 go의 기본적이 문법에 대해서 공부를 했고, 그후 http 프레임워크인 gin 에 대해서 공부했다.
거기에 도커까지 공부를 해야했다. 운영 환경은 도커와 k8s를 이용하는 환경이었다.
도커는 이전에도 깔아보고 이것저것 설치해본 경험이있어서 기초는 잡혀진 상태였다.
그래서 바로 실행에 옮겨야 할때라고 생각해 바로 토이 프로젝트를 진행했다.
여기서 하나의 버릇을 들이게 되는데 바로 새로운 언어를 공부하는 방법이다.
기존에는 문법부터 뗴고 기본적인 사용방법까지 모두 숙지하고 프로젝트를 진행하는 스타일이었다.
이제까지 내가 주력으로 쓰던 언어인 c++를 바로 이렇게 공부하고 사용했다.
그런데 go는 상대적으로 c++에 학습할 시간이 부족했다. 간단한 프로젝트를 만들면서 공부를하게 되었다.
이전에는 문법과 같은 기본기 없이 업무를 진행하거나 무언가를 구현한다고 하면,
당장의 결과물은 나올지 몰라도, 나중에 가서 발생하는 문제들을 해결하는데 도움이 안된다고 생각했다.
간단한 프로젝트를 통해 업무가 가능할 정도로 공부를 하고 업무에 투입한뒤 나의 생각은 180도 바뀌었다.
어차피 프로젝트를 진행하면서 문제는 발생하기 마련이다.
문제가 두렵다고 준비를 오래한다고 한들 준비한 범위내에서 문제가 발생할 확률은 매우 적다.
그렇기 때문에 준비를 길게 하기보다는 직접 부딪혀가면 문제를 해결해 나가는 방법을 선택한 것이다.
그리고 파트 변경을 하면서 정말 개발이 재밌다고 다시 한번 느꼈다.
그리고 다시한번 개발자로써 나의 장점을 알 수 있었다.
난 새로운 트렌드에 맞는 기술을 빠르게 습득해서 제품을 개선해 나가는데에 장점을 가지고 있다.
난 시간이 지나고 그런 개발자가 되고 싶고, 그게 내가 잘할수 있는 것이라고 생각 했다.
파트를 변경하면서 선택한 go와 Docker는 요즘 나의 최대 관심사중 하나가 되었다.
2.3 두번의 면접
2021년에는 총 두번의 면접을 보았다. 이직을 한지 얼마되지도 않았는데 왜 면접을 보았냐면,
이직을 하고 싶은 마음 반, 그리고 다른 회사의 개발자와 소통을 해보고 싶은 마음 반이었다.
내가 생각할때 개발자가 조심해야할 것중에 하나가 바로 협소한 시야이다.
처음에는 폭넓은 시야로 세상을 바라 보고 살지만, 시간이 지나면 지날수록 시야가 좁아진다.
세상을 바라봄에 있어 내가 이전에 보고 배운것에 한해서 생각을 하고 행동하게 된다.
그래서 전혀 다른 회사의 개발자와 대화를 자주 나누어야 한다고 생각한다.
서로 다른 업무를 하더라도 그렇게 진행하는 이유와 방법을 배워야 할 필요가 있다고 생각하기 때문이다.
꼭 이직을 위해서만이 아니라 소통을 하고 환기를 하기 위한 창구로 면접을 이용하는 것이다.
첫번째 회사의 면접은 꽤나 길게 진행되었다. 거의 2시간에 달하는 동안 두명의 면접관과 얘기를 나누었다.
여기는 내가 대학생때부터 정말 가고 싶었던 곳이고, 그때는 서류를 몇번이고 넣어도 탈락하였었는데
이번에는 서류 합격후 면접을 볼 수 있었다. 프로젝트도 내가 하고 싶어하는 프로젝트였고 마음에 들었다.
두시간에 달하는 시간동안 정말 많은 얘기를 나누었던 것 같은데,
조금 놀랬던건 블로그에 쓴 나의 글을 정말 자세히 읽고 질문을 던지셨던 부분이었다.
나조차도 오래되서 조금 희미해진 것들에 대해서 정말 처음부터 끝까지 다 보고 질문을 주셨다.
나는 면접관의 태도부터 신경을 많이 쓰는데, 이유는 바로 그 태도가 입사후 나를 대할 태도이기 때문이다.
1차 면접 즉, 실무진 면접은 보통 입사후 내가 일하게될 사람들과 대화를 나누게 된다.
면접에서 부터 태도가 좋지 않다면, 그건 입사하고 나서 일을 할때도 동일한 태도 일 수 있다는 것이다.
그런 점에서 지원자에대해서 정말 면밀하게 검토했다는 생각이 들었다.
두번째 회사는 모두가 가고 싶어하는 그런 회사였다. 흔히들 말하는 연봉 높고 좋은 회사였다.
좋은 회사여서 가고 싶었던것은 아니고 정말 하고 싶은 대용량 트래픽이 발생하는 서비스를 하는 회사였다.
지금 보면 어떻게 면접까지 가게되었는지도 의문이 든다.
면접은 두분과 함께 보게되었고, 시간은 그리 길지 않았지만 꽤나 많은 질문을 받았다.
그중에는 정말 가변운 질문도 있었고, 깊이 생각해봐야 하는 깊이가 있는 질문도 있었다.
이때 면접에서는 몇몇 질문에 대해서는 대답을 제대로 하지 못했다.
특히나 답이 정해지지 않은, 그러나 문제를 해결하려는 방법을 보려고 했다는 문제는 난이도가 상당했다.
꼬리에 꼬리를 무는 질문을 통해서 답변하지 못할때까지 깊게 질문이 이어졌다.
결국 답변을 하다가 하다가 막혀서 대답을 못하였다. 그리고 탈락하였다.
아쉽지만 그래도 내가 무엇을 놓치고 있었는지에 대해 알수있는 좋은 계기가 되었다.
올초에 이직을 하기도 했고, 두번의 면접을 통해서 부족함 점을 느낄 수 있었던 계기가 되었던것 같다.
2022년에는 조금 더 부지런히 노력하는 한해가 되어야 겠다.
2.4 세미나
2.4.2 C++ Korea 8회 세미나
작년 7월 세미나에 이어 8회도 코로나로 인해 온라인으로 진행되었다.
세미나에서 재밌게 보았던 세션은 POCO 라이브러리를 이용해서 채팅 서버를 만드는 세션이었다.
POCO 관련 라이브러리 책을 도서관에서 지나가다가 보았는데, 자세히 읽어보지는 않았다.
Boost, Ace 등의 쟁쟁한 라이브러리가 많이 있어 굳이 POCO를 써야할 이유가 없었기 때문이다.
특히나 Boost는 이미 다수가 모던 c++에 포함되었기 때문에 배워두면 좋은 라이브러리였다.
그래서 나는 Ace, POCO 보다는 Boost를 선택하였다. 그래도 나중에 사용할지 모르니
POCO 라이브러리의 사용법과 POCO를 사용하여 서버를 구현하는 방법을 재밌게 보았다.
2.4.2 C++ Korea 9회 세미나
9회 세미나는 세션이 두개 밖에 없었다. 약 6개월만에 열린 세미나라서 그랬던 것 같다.
여기서 재밌게 본 세션은 유지보수가 편한 게임서버 만들기 세션이었다.
코드 수준의 내용인 비트로 쪼개서 쓰지 말아야 한다는 내용과 데이터 타입에 대한 이야기 부터
패킷 직렬화와 관련된 proto buf, 데이터 베이스 키 관련 내용 그리고 게임내 데이터 관리,
게임내 시간 데이터 동기화와 같은 내용까지 약 30분동안 정말 많은 내용을 다루고 있다.
발표자가 현업에서 느낀 풍부한 경험을 자세하게 설명해주셔서 재밌게 세미나를 들었다.
2.4.2 우아한 테크 콘서트
이번년도 우아콘에는 내가 좋아하는 개발자 분들이 나오지 않았다.
게다가 내가 모르는 내용이 많아 몇개 골라서 시청하였으나, 아쉽게도 기억이 나질 않는다.
다만, 1대1 커리어상담 행사가 있었는데, 재빠르게 접수를 하였다.
상담은 30분 정도 진행이 되었고, 포트폴리오 첨부를 하였기에 포트폴리오를 기준으로 상담을 해주셨다.
상담사 분께서는 친절하게 포트폴리오의 피드백을 주셨고, 상담이 끝나자마자 포트폴리오를 수정했다.
이렇게 지인이 아닌 다른 사람의 의견을 적극적으로 들어볼 수 있는 행사에는 무조건 참여하는 편이다.
나의 부족한점을 보다 객관적으로 알 수 있고, 다른 사람의 의견을 들음으로써 안목을 넓힐수 있기 떄문이다.
2.4 의사소통
매년 노력을 하려고 하나 잘 못하고 있는것 중에 하나는 바로 의사소통을 위한 노력이다.
개발자로써 살아가면서 항상 주의하는 것이 소통이다. 그럼 원활한 소통이라는건 무엇일까?
내가 전달하고자 하는 바를 잘 전달하는것, 그리고 상대방이 원하는 바를 이해하는 것이라고 생각한다.
하지만 이게 사람마다 표현이 다르고, 주어진 환경이 다르다 보니 서로 다른 시각으로 서로를 바라본다.
그렇다 보니 비슷한 상황에 있는데도 소통이 잘 안통하는 경우도 존재하며,
반대로 전혀다른 상황에 놓여 있는데도 소통이 잘되는 경우가 존재한다.
더군다나 협업을 해야하는 상황에서 소통이 문제가 발생하는 경우 더욱이 큰 문제가 된다.
소통으로 인해 일처리에 어려움이 되는 경험을 종종 한다.
소통이 잘안되어 의도하는 바가 잘못 전달되어서 일이 틀어지기도 하고,
의도를 잘못 알아들어서 쉽게 해결 가능한 문제가 반나절이 걸리기도 한다.
이러한 일을 겪다보니 나름대로의 노하우가 생겼다.
첫번째는 대화 내용이 잘 이해가 되지 않는 경우, 고민 해본뒤 정중하게 질문을 던진다.
질문 자체가 이해가 안되는 경우에는 질문의도가 무엇인지 물어보고 내가 이해한 바를 확인한다.
대화의 흐름과 아예 상관없는 질문이 아니고서는 성실하게 답변해주지 않은 개발자는 없었다.
대화에 있어 상대방의 표현을 그대로 흘려보내지 말고 적극적 자세로 임하는게 중요한 것 같다.
두번째는 대화 내용을 메모하거나 발표와 회의 같은 경우 양해를 구하고 녹화를 하는것이다.
말의 특성상 한번 뱉고나서 따로 기록을 해두지 않으면 휘발되어 사라진다.
따라서 대화중에 중요한 내용은 메모를 해두는 습관을 가지는게 좋다.
그리고 재택근무가 많아지며 온라인 회의를 진행하는데, 양해를 구하고 녹화를 한다.
주로 회의록을 남기는 편이지만, 한시라도 놓치면 안되는 경우 녹화본과 함께 회의록을 검토한다.
세번째는 비개발직군과 대화할때 사용하는 방법이다.
비개발직군과의 대화시에는 마치 어린아이에게 전달하듯이 이야기를 풀어나가는 편이다.
이게 상대방이 기술적인 지식이 없기떄문이 절대 아니며, 자세 하고 쉬운 단어를 선택하는 것이다.
생각해보자 개발자끼리의 기술적인 설명이 부족해도 지식과 경험으로 이해를 하고 넘어가는게 가능하다.
그러나 비개발 직군과의 대화는 조금 다르다. 정확하게 전달하지 않으면 오해가 생기기도 한다.
그리고 대화상대의 직군이 어떠한 일을 하는지를 명확하게 파악하고 필요로 하는 정보를 확실히 전달한다.
기획자와의 미팅이 잡혀있는데, 미팅의 목적이 기능 수정을 범위를 설정하기 위해 미팅을 잡았는지?
아니면 기능 추가를 위해 현재 기능을 검토하는 미팅인지? 를 우선적으로 파악한다.
그리고 내가 전달하고자 하는 정보를 우선적으로 전달한다. 이는 직군이 다르기 때문에 그렇다.
직군이 다르면 서로가 바라보는 시선의 차이가 있다. 정보를 전달하고 의견 차이를 좁혀나가는 것이다.
2.5 모던 C++과 Boost 라이브러리
회사에서는 c++을 사용하는데, boost를 사용하는 코드가 일부 포함되어있다.
boost를 사용하는 코드는 객체 지향 구조를 성싱하게 따르고 있으며, 템플릿을 사용한 코드가 많다.
반면에 boost를 쓰지 않는 코드는 확장자를 제외하면 c라고 해도 믿을 정도로 c언어 코드와 유사하다.
클래스를 비롯해서, stl과 템플릿을 사용한 코드가 거의 없다. vector며 상속 구조가 하나도 없다.
나는 객체지향 설계와 stl을 적극적으로 사용하며, 템플릿을 사용한 제네릭 프로그래밍을 지향한다.
그래서 시간이 남는 경우에는 주로 boost를 쓰는 코드를 관심을 가지고 보는 편이다.
신기한것은 코드가 작성된지 시간이 조금 흐른 상태 인데, 쉽게 읽을 수가 있다.
바로 boost를 사용한 코드가 현재 표준에 포함되어 namespace만 std로 바꾸면 되기 때문이다.
boost에는 c++표준 위원들이 다수 포진했었는데, 그로인해 c++에 적용될 코드들이 boost에 있었다.
그래서 과거에는 c++ 개발자들중에 진보적인 개발자들은 boost를 사용하는것을 매우 좋아했다고 한다.
boost의 주요 기능들의 다수가 표준으로 포함되어서 요즘에는 boost를 사용하는 것이 큰 의미는 없다.
다만 c++로 고성능 서버를 만들때 윈도우는 iocp를 리눅스는 epoll을 사용하는데,
양쪽 플랫폼에서 모두 돌아가는 코드를 작성하려면 boost의 asio를 많이 사용하곤 한다.
한동안은 boost 코드와 모던 c++의 코드를 비교하면서 분석하였는데, 이 작업이 매우 재미가 있었다.
현재는 사용하는 컴파일러의 버전이 낮아 부스트를 사용해서 개발을 해야하지만,
기회가 되어 리팩토링을 진행해야 한다면, c스타일의 c++ 코드를 모던 c++로 리팩토링 하고 싶다.
모던 c++에 대한 학습을 꾸준히 하고 있는데, 어서 빨리 리팩토링의 기회가 왔으면 좋겠다.
3. 2022년 계획
3.1 2021년을 돌아보며
올해에는 개발자로 살면서 참 의미 깊은 해가 되지 않을까 하는 한해였다.
이직을 하기도 헀고, 업무 변경이 있기도 했다. 작년보다 회고록에 쓸내용이 많아지기도 했다.
한해동안 회고에는 담지 못한 많은 일들이 있었는데, 모두 좋은 경험이 되었던것 같다.
3.1 2022년 계획
2021년에는 포스팅을 거의 하지 못했다. 포스팅하려다가 중간에 멈춘 글이 거의 10개에 달한다.
그리고 인프런에서 강의를 꽤나 구매하였는데, 구매만 하고 공부를 하지 못하고 있다.
게다가 책도 꽤나 많이 구입을 하였는데, 역시 구매만하고 읽지 못한 책이 여럿있다.
2022년에는 시간이 나는 데로 틈틈히 구매해두었던 강의들을 듣고 책도 읽어야겠다.