첫 회고

계속 주니어이고 싶다는 우스갯소리를 종종 했는데, 어느덧 경력이 4~5년 정도 쌓였더라 (실력은 부족한데 경력만 쌓여가는 느낌이..ㅠㅠ)

돌이켜보니 2013년 즈음부터 개발을 시작했었고 2015년에 개발자(병특)로 첫 발을 내딛었다.

아직도 많이 부족하지만, 최근 지인분들과 대화하면서 예전엔 의미 없다고 생각했던 경험들이 돌이켜보니 그 경험들 덕분에 추상적으로 바라볼 수 있다거나, 어떤 부분을 맡더라도 해낼 수 있다는 자신감, 팀원을 배려할 수 있는 작업들이 보인다거나 하는 것들 생겨서 그래도 조금은 성장했다고 느꼈다.

 

사실 개발이 처음부터 즐거웠던 것은 아니다. (그래서 방황도 참 많이 했다)

그냥 좋은 동료이고 싶은 마음이 공부하는 이유였다. (당시에는 더 공부하거나 더 일한다고 돈을 더 주던 시절도 아니었고...)

병역특례로 개발을 시작하긴 했어도, 복학 후 다른 분야에도 발을 담궜고(공기업), 그 길을 평생 걸어갈까 고민도 했었다.

하지만 최근에는 개발이 꽤 재미있게 느껴진다. (오히려 재미있는 것이 너무 많아서 이게 문제일 정도. 아마 예전보다 개발의 매력들을 조금 더 잘 느끼기 때문이 아닐까 싶다)

 

일전에는 작업의 세부 사항만이 보였지만, 어느 순간부터 다음 단계와 전체 흐름이 보이기 시작했다. 덕분에 작업을 추상화할 수 있게 되었고, 직장을 옮겨도 유사한 지점을 발견하거나, 다른 방식의 장단점을 비교하면서 문제를 파악하는 등의 과정이 조금씩 가능해졌다.

결국 이러한 과정을 통해 일로만 느껴지기보다는 문제 해결로 느껴지기 시작하더라(돌이켜보니 이 시기부터 즐거웠던 것 같다)

심지어는 하루에 12시간 이상씩 주 7일을 일해도 괴롭다거나 하진 않았다(물론 몸은 괴로워했지만)

 

이런 시기(개발이 즐겁게 느껴지는)가 어릴때부터 찾아온 멋진분들도 정말 많지만, 안타깝게도 나는 재능이 없던 쪽에 속했다.

가장 처음 개발을 시작했을 때 개발은 단순히 제품을 만들기 위한 수단이었다.
당시 eclipse + java 로 (TMI. 당시에는 android studio 도 나오기 전이었기에 eclipse 밖에 선택지가 없었다) 조악한 안드로이드 어플리케이션을 만들었는데 심사위원분들께서 좋게 봐주셔서 장관상을 받을 수 있었고 덕분에 병역특례를 거쳐 지금까지 이어져오지 않았을까 싶다.

이후 병특시절까지 개발이 재밌기보단 어렵기만 했다. (그 시절 열심히 했던 건 재밌어서가 아니라, 좋은 동료이고 싶은 이유밖에 없었다)

다만, 병특 도중에 만난 지인분 덕분에 개발을 바라보는 시야가 완전히 바뀌게 되었다.

조금 넓어진 그 시야 덕분에, 나는 정말 개구리만도 못하지 않을까? 싶은 생각이 들었고, 정말 열심히 했던 것 같다.

퇴근하고 항상 서점에 들르거나, 집에 가서 공부하고, 다른 언어들에도 관심을 가지기 시작했다(당시에는 python)

지금은 의미가 없어졌지만, 당시엔 python dependency manager를 어떤 걸 쓸지(pyenv, pip, poetry 등 하나씩 써보며 즐거웠던 기억이..ㅎㅎ) 고민한다거나 flask, django 등을 써보면서(병특땐 spring 만 써봤으니) 시야도 조금 넓어지고 모든 게 새로웠기에 시간이 빨리 지나갔던 것 같다.

 

병역특례가 끝나고 학교에 복학했더니 새로 부임하신 교수님이 계셨고, 다행히 날 좋게 봐주셨어서 (학부연구생으로) 프로젝트마다 불러주셨다.

예를 들면 뉴스 댓글을 크롤링해서 감성 분석을 해야 하는 상황이었는데 기반 시스템이 당연히 하나도 없었다.

서버 세팅에부터 웹 서버, 크롤러 심지어는 프론트까지(그래서 당시 gogs, gitlab 등 다양한 private git server를 직접 설치하고 운영하고, ubuntu 에 서버를 구축하는 등의 모든 작업을 직접해야만 했다)
크롤러의 경우, selenium 방식으로 크롤링하니 성능이 너무 안 나와, 네트워크 패킷을 까보면서 어디로 호출하는지, 어떤 파라미터가 있는지 등을 다 뒤져보고 크롤링하고, 심지어는 그것도 모자라 docker + docker-compose로 학교 컴퓨터 실의 모든 서버에 docker-compose를 세팅해 두었고 결국 1억 개 이상의 데이터를 크롤링할 수 있었다. (처음엔 설치형으로 하다가 너무 힘들어서 docker, docker-compose로 넘어갔는데, 지금과는 달리 docker 한글자료도 거의 없고, 잔 버그도 많아서 삽질을 많이 했었다ㅠㅠ) 

 

뿐만 아니라, 요즘처럼 개발 붐이 일어난 시기는 아니어서 아이디어는 넘치지만, 제품화 된 경우가 적어서 제품을 쏟아내듯 만들 수 있었다. 

뭘 하더라도 다 새로운 제품이 될 수 있었기에, 병특 때 주로 사용하던 java + spring 대신, 엄청난 생산성을 가진 python flask + docker compose 가 내 애착 스택이었고, (제품으로 성공하지 못하더라도) 즐겁게 만들었다.

(+ 이 당시까지만 하더라도 docker swarm과 경쟁하던 kubernetes 가 defacto 까지는 아니었기에, docker에 관심 있던 대학생들에게 메일로 GCP 크레딧을 제공하면서 kubernetes 강의와 실습을 무료로 제공해 주었다. Google에 다시 한번 감사를...ㅎㅎ)

다만, 단점도 명확했다. 해당 지역만 타겟으로 한 제품들은 결국 유저수가 너무 빈약했기에 오래 지속될 수가 없었다.

그러던 와중 개인적인 이유로 (공기업 인턴 등) 개발과 조금 멀어지게 되다가

예전에 병특을 같이 했던 지인분의 조언으로 인해 다시 개발을 시작하게 되었다. (뭔가 상당히 많이 생략되었지만 너무 TMI 라...ㅎㅎ)

 

이후, CSAPP 를 읽으며 lab을 실습하고, http 완벽 가이드, OS, 알고리즘 공부 등 복습을 하다가,

DDIA, Database Internals, Programming Kubnertes (이 책은 open container korea 분들과 같이 스터디했는데, 혼자였다면 아직도 읽지 못했을 것 같다) 등의 책들을 읽으며 관심 분야를 정하려고 노력했다.

그 과정에서 CKA 도 취득하고, 토이프로젝트도 1년 정도 운영했다.

혼자서 공부하다 보니 스터디, 팀원을 찾기가 얼마나 힘들지 알고 있기에 취준생 분들께 도움이 되었으면 하는 마음에 스터디/프로젝트 팀원을 매칭시켜 주는 프로젝트를 진행했는데, 동시 접속자 1k를 찍어보기도 하고, 악성 유저 때문에 rate limit을 걸기도 하고, 실시간 트래픽을 받으며 재밌는 경험들을 많이 했었던 기억이 난다.

 

그러다가 다시 취직을 하게 되고 또 이직도 하게 되고...

사실 취직, 이직은 아직도 그저 운이 좋았다고 생각한다.

예를 들면, 그냥 DB 에 관심이 많았을 뿐인데 DB 관련된 질문이 나온다거나(LSM 관련된 질문 등) 심지어 JDBC 내부가 어떻게 되어있냐는 질문에 대해 (java 를 전부 까먹었기에) python 으로 빗대서 설명했는데 감사하게도 면접관분께서 DB 를 좋아하셔서 예쁘게 봐주셨다.

이후 회사에서는 다양한 경험을 했던 것 같다. webflux, osgi 에서부터 netty, mysql, mariadb, ELK, grafana, eks, vault 등... 때론 heap dump 떠서 분석하기도 하고... (최근엔 Observability 제품을 만들고 있고, Cluster Stroage 팀에서 분산 저장소, OLAP, 인덱스 등과 같은 다양한 경험을 하고 있다)

사실 몇 년 전까지는 개발 역량에 대한 고민이 많았지만,

최근에는 기술적으로는 모니터링과 데이터베이스 그리고 한편으론 소프트 스킬에 대한 내용들을 주로 고민하고 있다.

 

일은 누구나 다 할 수 있다. (개인적으로 정말 누구나 다 할 수 있다고 믿는다)

단, 우리에게는 주어진 자원(대부분은 시간) 안에서 적당한 퀄리티의 코드로 문제를 해결해야 하는 제약이 있다.

나는 이 부분이 정말로 중요하다고 믿는데, 퀄리티와 기한 모두 챙길 수 있어야 좋은 팀원이라 믿기 때문이다.

사실 기술적인 역량을 높이기 위한 노력들이 위 문제를 대부분 해결해 준다고 생각한다.

다만, 소프트스킬에 대한 역량은 절대로 저절로 성장하는게 아니더라. (중요성 또한 절대 낮지 않고)

다 생각나진 않지만, 그래도 중간에 느꼈던 점들이나 고민들을 몇가지 나눠보려고 한다.

 

1. 서비스 -> 솔루션 업체로의 전환

감사하게도 대기업(서비스), 중소기업(솔루션) 모두를 경험할 수 있었다.

솔루션이라서 옮긴 것은 아니고 회사가 만드는 제품, 추구하는 가치에 관심이 갔기에 이직을 결정했다.

다만, 머릿속으로 회사 규모마다 작업 방식이 달라야 한다는 건 짐작했지만, 그게 구체적으로 어떻게 달라져야 하는지 몰랐다.

(지금 회사의 제품 복잡도가 상당히 높은 편인데, 코드 복잡도 + 제품 및 시장에 대한 이해가 좀 더 되어야 하는 느낌이었다)

대기업은 이미 거의 대부분의 시스템이 구축되어있었고, 자동화되어 있는 것들이 많았다. 스크립트도 많고, 제품을 편하게 찍어내 듯 만들 수 있는 환경이었다. 뿐만 아니라 요구사항이 명확하고, 규격화되어 내려온다.

반대로 스타트업은 요구사항을 내가 구체화시켜야 할 경우도 있고, 변경될 경우도 많다.

이렇게 보면 스타트업이 나쁘게만 보일 수 있다. 다만, 관점에 따라 기여할 부분이 많아진다고 해석될 수도 있다. (물론 풍부한 신뢰 자산이 뒷받침 되어야 하겠지만...) (이 부분 때문에 주변 지인분들께 고민상담도 참 많이 했었는데, 이 자리를 빌어 감사함을 전하고 싶다)

당연히 작업 방식도 달라진다. (다만, 이 주제는 회사마다도 다를 수 있어서 적합한 방식이 필요할 것 같다.)

+ 개발방법론에 따라 달라질 수도 있음

현재 회사에서는 Shape Up이라는 개발 방법론을 도입했는데 (개인적으로는) 잘 동작한다면 매력적인 선택지라 생각한다.

https://basecamp.com/shapeup

Shape Up: Stop Running in Circles and Ship Work that Matters

 

2. bottom up 작업 상황 공유

만약 내가 열심히 작업을 했더라도, 그게 공유가 되지 않으면 의미가 많이 퇴색된다.

문제는 알아서 체크되고 있지않을 경우가 많고, 결국 bottom up 방식으로 상황을 전파하는 것도 나름 괜찮은 전략이더라.

물론, 너무 자주 전파하는 것은 노이즈로 느껴지기에 문제겠지만, "적절한" 방법으로 본인의 작업에 대한 공유는 중요하다.

+ 애매한 부분은 중간에 한번씩 더 체크하는 것도 좋은 방법.

(이것도 앞서 말한 것처럼 대기업엔 의미 없는 말일 수 있다. 스타트업의 경우에는 스펙이 애매하거나 혹은 변경이 발생하는 경우가 잦은데, 그런 부분들은 알아서 딱! 잘한다는 마음가짐보다는 체크를 한번 더 하는 게 삽질을 훨씬 줄여줄 수 있다.)

Patrick Winston 교수님께서 남겨주신 정말 좋은 강의가 있는데, 아직 못 보신 분들은 꼭 한번 보는 것을 추천한다.

https://youtu.be/Unzc731iCUY

 

3. 회의 내용 로깅

완벽해 보이는 팀원일지라도, 완벽한 사람은 없다.

예전에 했던 말과 지금 했던 말이 다른 경우는 꽤 자주 접하게 된다. (심지어 의도하지 않았더라도)

대기업의 경우 업무가 정돈되어 내려오기에 빈도가 적지만, 스타트업의 경우에는 빈도가 높아진다.(요구사항이 바뀌는 등의 이벤트도 빈번하기에 더더욱 발생하기 쉽다)

그렇기에 작업뿐만 아니라, 회의에서도 정리를 하고 그때마다 공유를 하는 습관이 도움이 되더라.

(물론 이것을 무기로 상대를 압박하고 공격하라는 뜻은 절대 아님. 독성말투는 그 어떤 상황에서도 좋지 않다.)

공격하려고 하는 것이 아니라 신뢰 자산을 쌓기 위해 기록은 중요하다고 생각한다.

 

4. 모든 코드는 부채다.

정말 모든 코드는 부채다. 한 달만 지나도 레거시로 느껴지고, 문제를 해결하려고 내가 새로운 문제를 만들지 않았나 싶은 때도 있었다.

예전에 내가 조금의 성능을 더 높여보자고 애쓰고 있을때, 팀원분께서 해주신 "적은 코드를 선호한다"는 말씀이 이제야 어렴풋이 와닿고 있다. 결국 지금 문제를 해결한다고 생각해서 추가된 코드가, 복잡도를 높이고 부채가 되는 경우가 있었기에, 코드를 작성하기 전에 한 번씩 더 고민해 보게 되더라.

그래서인지 최근 들어 이 문장이 묘하게 좋다.
"성능이나 비용보다 간결함"

 

+ 이 글도 꼭 한번 읽어보길 바란다.

20 things ive learned in my 20 years as a software-engineer

20 Things I've Learned in my 20 Years as a Software Engineer

 

5. 다양한 분야(언어)에 대한 관심

IT 분야에는 DevOps, BE, FE, Data Engineer 등 여러 직군이 존재하는데, 이 모든 걸 다 잘할 순 없지만, 다른 분야에 대한 경험이 도움이 된 경우가 많았던 것 같다.

라떼는~ 같은 느낌이 있어서 조심스럽지만, 개발을 일찍 시작하신 분들은 BE, 서버관리, FE 등 한 번씩은 다 해보신 경우가 많다.(그땐 시스템 복잡도가 훨씬 낮았다) 내 경우에도 토이프로젝트를 많이 해오다 보니 (잘하지는 못하지만) 시야도 넓어지고, 조금 더 크게 볼 수 있었던 것 같다.

지금은 java를 주로 사용하지만 다른 언어가 회사에서도 도움이 된 경우가 꽤 많았는데,

예를 들면, 이제껏 비효율적으로 작업해 온 부분들을 python 자동화 스크립트를 만들어서 공유했을 때(comparison checker, auto inserter 등등) 비록 한번 쓰고 다시 안 쓰일 것 같은 스크립트일지라도, 파이썬의 생산성이 높기에 15~30 분 내외로 자동화가 가능했고 (사람이 작업하는 것에 비해) 실수를 무조건적으로 방지할 수 있기에 아직도 파이썬을 비롯한 스크립트 언어로 자동화하는 것이 좋다고 생각한다. 특히 많은 양의 작업일수록 더더욱.

뿐만 아니라 다른 분야에 관심을 가지던 것이 다른 팀원을 배려할 수 있게 된 경우도 많았다.

 

6. 생산성 높이기

팀에 도움이 되고 싶다는 마음에 사소한 부분에까지 너무 과도한 에너지를 쓰는 경우가 종종 있다.

다만, 생산성을 높이려면 중요한 지점에 더 많은 고민과 좋은 코드에 대한 노력을 쏟아야 한다고 생각한다. (시간은 한정적이기 때문)

아이러니하게도 입사 초기에는 어떤 부분이 중요하고 어떤 부분이 사소한지 모르니 더 힘 빼기 쉬우니, 결국 초기엔 더 많은 커뮤니케이션이 필요하다.

https://en.wikipedia.org/wiki/Amdahl%27s_law

Amdahl's law - Wikipedia

 

7. 기술로 모든 문제를 해결할 수는 없다

기술로 모든 문제를 해결할 수는 없다는걸 느꼈다. 특히 제품의 복잡도가 높을수록 스스로 해결하는데 한계가 생겼고, 여러 사람이 얽혀 있는 문제는 정치적으로 해결하거나 덮어두고 미루는 선택지 밖에 없었다.

+ 나 혼자 문제를 고민하는 것을 넘어서 큰 그림에서 볼 수 있어야하고 앞서말한것처럼 정치적으로 해결되어야 하는 문제도 있더라.

 

8. 조급함을 버리자(Feat. 회복탄력성)

아무리 잘난 개발자라고 하더라도, 처음부터 모든 맥락을 알 수도 없고, 특히 복잡도 높은 시스템의 경우 더더욱 시간이 소요된다.

특히 퍼포먼스를 증명하기 위해 조급함을 가지게 된다면 번아웃의 지름길이 될 수도...

이때, 아무래도 내 가장 큰 장점인 높은 회복탄력성이 도움이 되었다.

번아웃에 한번도 빠지지 않는다는것은 힘들기에 빠지더라도 빨리 빠져나올 수 있도록 규칙적인 생활습관, 유연한 사고, 든든한 지인들이 중요한것 같다. (우리가 시스템 디자인하는것과 비슷한 부분을 발견할 수 있다. 아예 튼튼한 시스템을 설계하려고 노력하되, 장애를 복구도 늘 염두해 두듯이)

그 힘든시절을 나도 잘 알고 있기에, 일부러 나도 힘들어보이시는 지인분들께 뜬금없이 칭찬섞인 연락 혹은 밥먹자고 연락하기도 하고...

(번아웃을 겪고 있는 사람들 중 대다수는 본인이 번아웃임을 인지하지 못한 상태인 경우도 많다)

 

9. 체력

비교적 최근까지 일을 핑계로 운동을 전혀 안 하고 있었다.

다만, 어느 순간부터 체력이 부족한 것과 더불어 몸도 좀 이상해지더라. (특히 체력이 심하게 부족할 땐 예민해지게 되고..) 

그래서 어떤 스포츠를 할까 물색하던 중 달리기를 선택했다(선택의 이유는 아래와 같다)

1. 시간에 구애받지 않음 (일에 지장 받게 되어 그만두는 경우가 꽤 있었는데, 달리기는 이 점에서도 너무 좋았다)

2. 혼자 할 수 있음 (경험적으로 혼자 할 수 있는 스포츠여야 오래 지속할 수 있더라)

처음엔 1.5km 달리고도 심장이 터질 것 같았지만, 이젠 3km 정도는 잘 달릴 수 있고 컨디션이 좋다면 4.6km 까지 가능해졌다.

10km를 달리게 되면 그제서야 달리기를 시작한 것이라고 농담식으로 주변에서 얘기하던데, 내년까지 10km를 목표로 하고 있다.

 

 

폭풍 같은 시기였기에, 모든 게 다 생각나진 않지만 대략적으로 이러한 부분들을 느꼈고,

최근 고민은 기술적으로 너무 공부할 게 많아서 좀 벅차다는 생각이 든다.

(그와중에 DevOps 관련된 지식들은 희미해져가고 있고, DB, Observability 는 공부할게 엄청나게 많은데 그 문맥 속에서 결정을 내려야 하다보니... 내 스스로가 미울때도...ㅠㅠ)

그래도 포기하진 않고 묵묵히 걸어나가고 있다.. (불평을 들어주신 지인분들께 늘 감사를..헤헤) 지금 스터디 중인 Observability Engineering 은 아주 재밌게 읽고 있고, Longhorn을 발표하기로 해서 이것도 조금 살펴볼 예정.

 

마치며

서두에 언급한 것처럼, 나는 처음부터 개발이 재밌진 않았고, 그저 좋은 동료이고 싶었다.

고민도 많았고 방황도 길었다. 어느 쪽 하나 놓기 싫은 욕심이 시간만 뺏어갔고 동시에 전문성을 잃어가고 있었다.

결국 선택을 해야할 시기가 찾아왔고, 개발을 선택했다.

선택과 집중을 했더니 마음이 한결 편했다. 개발이 너무 즐거운 시기가 찾아왔고, 하루 종일 공부만 하더라도 힘들지 않았다.

다만, 어느 순간부터 (특히 요즘 들어) 아무것도 모른다는 자괴감에 빠지기도 한다.

(언젠가 이 글을 읽고 아래 사진과 같은 글을 쓰기도 하고..)

저 글을 읽으며 예전엔 어떤 생각을 가졌는지 기록을 해두었더라면 재밌었을 텐데...라는 생각이 들었고,

'이제라도 회고를 한번 작성해 보자!'는 생각에 한번 남겨본다.

 

+ 조심스러운 부분들을 조금씩 걷어내고 나니 밋밋한 글이 된것만 같은 느낌이 든다.

그렇다고 기술적인 부분을 집어넣자니 글이 너무 길어질것 같고...

(다른 포스팅에서) 어떤 기술로 어떤 고민을 했는지도 조금씩 풀어봐야겠다.