안녕하세요. 인포그랩에서 프론트엔드 엔지니어로 일하고 있는 Fabbro입니다. 저는 컴퓨터공학을 전공하지 않은 비전공자 출신 엔지니어인데요. 인포그랩에 입사한 지 1년 6개월이 조금 넘었습니다.
이 글은 DevOps 전문 기업인 인포그랩에서 비전공자 출신인 엔지니어가 회사 입사 후 경험한 일과 엔지니어의 삶에 적응하는 과정을 사계절 테마로 나눠 다뤘습니다. 문과 감성을 담은 엔지니어의 글임을 고려하며 읽어주시면 좋겠습니다.
1장 봄
개발자가 되기로 결심한 사연
제가 개발자가 되기로 마음먹은 데에는 전 직장의 업무가 큰 영향을 줬습니다. 제 업무는 상담사의 실적 데이터를 엑셀로 관리하면서 그 데이터를 시각화하고 이를 토대로 상담사에게 실적을 압박하는 관리 업무였습니다. 문제는 전 직장이 굉장히 오래된 회사로 전형적인 수직 구조를 띄고 있었다는 건데요. 술 강요, 수직적 업무 체계는 탈출 욕구를 키우는 데 큰 역할을 했죠.
전 술을 강요하지 않는 직업을 찾다가 개발자를 발견했습니다. 엑셀을 다루는 업무가 재미있었지만 제 업무는 ‘잘해야 본전’이었는데요. 이와 달리 개발자는 무언가를 만들어 내는 일을 하면서 동료에게서 인정받는 건 물론, 스스로 자신의 성과를 대외적으로 자랑까지 할 수 있더라고요. 제게는 이런 점이 너무 충격적이고 매력적으로 다가왔습니다. 이에 당장 개발 공부를 시작했습니다.
겨울인 줄 알았는데 봄이었다
개발 공부를 시작하고 얼마 되지 않아 ‘엑셀 함수를 다루는 일이 개발자와 비슷하다’고 생각했던 저 자신이 미워졌습니다. 엑셀 함수를 실행하는 환경(개발 환경)을 만드는 것부터 어렵더군요. 그렇지만 끊임없이 문제가 발생하더라도 그걸 해결했을 때 오는 강력한 희열에 중독되어 개발에 재미가 붙기 시작했습니다. 그렇게 1년이 흐르고 저는 국비학원도 수료하고, 정보처리기사 자격증도 따고, 개인 프로젝트도 수행해 마치 개발자가 된 것 같았습니다.
그러나 머지않아 ‘현실이 겨울처럼 냉혹하다’는 걸 깨달았죠. 개발자로 취업하는 과정은 녹록지 않았습니다. 그러나 포기할 수 없었습니다. 여전히 개발자라는 직업은 제게 마법사처럼 환상적이고 멋있는 직업이었거든요. 그래서 저는 “나 를 알아봐 주는 기업은 정말 좋은 기업일 거야! 그래서 좋은 기업을 만날 때까지 시간이 조금 더 걸리는 거야!”라고 자기최면을 걸었죠. 그러던 어느 날 드디어 제게도 ‘인포그랩’이라는 봄이 찾아왔습니다.
나, 마법사가 아니라 트롤이었네?
인포그랩에 입성한 날, 맥북과 32인치 델 모니터가 세팅된 제자리를 보고 저는 “와 진짜 마법사(개발자)가 된 것인가?”라고 생각했습니다. 처음 사용해 봐서 불편하지만 ‘감성 충만’한 맥북과 화면을 반반씩 나눠도 여유가 넘치는 축구장 크기의 모니터 덕분에 너무 행복하였습니다. 맥북 사용 꿀팁 전수, 회사 규칙 교육, 실무에서 사용하는 프레임워크를 활용한 사이드 프로젝트 수행 등 약 3주간의 온보딩 교육이 끝나고 저는 드디어 실무에 투입되었습니다.
처음 2주 동안은 별 사고 없이 작은 단위의 업무를 조금씩 해결해 나갔습니다. 그러던 어느 날 결국 사고가 터지고 말았죠. 해당 프로젝트는 ssh 원격으로 같은 워크플레이스에서 작업을 수행했습니다. 그러던 중 제가 작업한 코드가 마음에 들지 않아 작업한 코드를 discard 했는데요. 그런데 제 코드가 아니었습니다.(제정신이 아니었습니다!😵💫) 동료분이 작성한 코드를 날려버린 게 아니겠습니까? (지금 생각해도 손이 떨리네요.👋)
너무 놀라서 당황하다가 일이 더 커지기 전에 동료분에게 알렸습니다. 다행히 그분은 “중요한 부분은 아니었어요. 그래도 다음부터는 주의해 주세요”라고 따뜻하게 말씀해 주셨습니다.(정말 안 중요했던 건지는 지금도 몰라요.🥹) 그래도 이 경험으로 코드의 소중함과 형상 관리의 중요성을 뼈저리게 느꼈습니다.
2장 여름
남모를 문화 지체 현상
인포그랩이 추구하는 업무 스타일은 “Get Shit Done!” 일단 부딪혀서 빠르게 실행하는 것입니다(회사에 출근하면 이 문장이 적힌 액자가 눈에 띕니다). 이에 맞춰 개발도 애자일 방법론에 따라 2~3주 간격으로 스프린트를 두고 진행합니다. 스프린트 회의에서는 그동안의 진행 상황을 공유하고 피드백을 주고받습니다. 또 요구사항을 다시 정리하여 프로덕트가 조금씩 원하는 방향으로 나아가도록 조정합니다. 본격적으로 개발할 때는 어제 수행한 작업과 오늘 할 일을 공유하는 스크럼 회의를 매일 진행합니다. 이 회의에서 스프린트 기간에 발생할 수 있는 문제를 파악하고 해결하며 일정을 조절합니다.
회사에서는 동료와 평소 피드백을 자주 주고받고, 누구든 원하는 업무를 자발적으로 시작할 수 있으며, 동료에게 언제든지 도움을 요청할 수 있었습니다. 정기적으로 업무를 회고하기도 하고요. 저는 인포그랩이 좋은 문화로 가득 차 있다고 생각했어요. 과거 정보처리기사 자격증을 공부할 때도 ‘폭포수(워터폴) 방법론보다 애자일 방법론의 장점이 눈에 더 들어왔는데요. 인포그랩에서는 애자일 방법론에 따라 업무를 진행하기에 제 선호에 부합했습니다.
그러나 머리로는 ‘애자일 방법론이 좋다’고 이해하지만 실제 이를 수행하고, 내면화하는 일은 녹록지 않았습니다. 저는 이전 직장에서 수직적인 위계 구조에 절여져 있었는데요. 그렇다 보니 미리 준비하지 않고 부딪치기, 자발적으로 참여하기, 피드백 주고받기, 회고하기가 너무 낯설고 어렵더군요. 이에 저는 남몰래 문화 지체 현상을 겪기도 했습니다.
비비디 바비디 부(소원아, 이뤄져라)
인포그랩에서는 업무를 추진할 때 생각대로 다 합니다. 생각을 입 밖에 내는 순간 업무가 생성되고 참여자를 포획(모집)하죠. 제가 ‘포획’이라는 단어를 선택한 이유는 요즘 유행하는 밈 중 하나인 “너 내 동료가 돼라"를 넘어 hp(체력)가 100%인 포켓몬에게 몬스터 볼을 던지듯 순식간에 업무가 생성되고 급작스럽게 팀원을 모집하기 때문입니다. 더 놀라운 점은 대부분의 팀원은 기분 좋게 잡힙니다. 다들 일에 열정과 호기심이 많아서 그런 듯합니다.
이런 문화는 제가 소속된 프로덕트 팀에서도 느낄 수 있어요. 엔지니어는 새로운 기술에 관심이 많잖아요? 그래서 새로 배운 기술을 실무에 사용해 보고 싶은 욕구도 풍부합니다. 일반 기업에서는 새로운 기술을 실무에 바로 적용하기가 어려운데요. 제가 속한 프로덕트 팀은 “사용하고 싶은 기술을 실무에 활용해 보라”고 권장합니다. 단, 이 기술을 실무에 적용해야 할 이유를 제시해 팀을 설득한 이후에 말이죠. 이러한 문화 덕분에 저는 다양한 기술 스택을 실무에 활용할 수 있었습니다. 다음은 제가 조사하고 제안하여 실무에 사용한 기술입니다.
- React-Query: 이 기술을 사용할 때 서버 상태 관리가 필요했습니다. React-Query는 npm trends에서 제가 후보에 올린 기술 중 1등이었던 기술이고요. 이는 Jotai와 호환됩니다.
- Jotai: 이 기술을 사용할 때 전역 상태 관리가 필요했습니다. 저는 상태 관리를 많은 곳에서 사용하지 않고, 최대한 간단하게 사용하고 싶어서 이 기술을 선택했습니다. 이 기술은 ‘러닝 커브가 낮다’는 장점도 있었습니다.
- TailwindCSS: 이 기술은 npm trends 1등은 아니었는데요. 저는 TailwindCSS 인기가 수직으로 상승한 그래프를 보고 호기심이 생겼습니다. 사용감이 무척 좋았고요. 저는 daisyUI의 디자인을 여기에 적용했습니다.
굳은살
저는 위와 같은 성장통을 거치며 업무에 적응했습니다. 입사 초반에는 ‘작은 기능 하나를 구현하라’는 지시만 받아도 벌벌 떨었습니다. 그랬던 제가 부딪치고 깨지면서 개발 역량에 굳은살이 붙기 시작했는데요. 이 굳은살은 제 성장의 징표처럼 느껴졌습니다.
제게 굳은살을 만들어준 기억을 하나 뽑으라면 ‘최적화 경험’을 선택하고 싶은데요. 웹 성능 최적화를 위해 코드 스플릿팅, 이미지 최적화(크기, 확장자), 불필요한 CSS와 JS 제거, 압축을 위한 Vite & NGINX 설정 등을 진행했습니다. 그 결과, 렌더링에 사용하는 파일 크기를 1/4로 줄이고, 퍼포먼스 점수도 42점에서 84점까지 올렸죠.
물론 완벽하거나 대단한 결과물이 아니라고 생각하실 수도 있습니다. 그러나 저에게는 굉장히 어렵고, 소중하고, 기쁜 경험이었습니다. 이런 경험을 할 수 있었던 건 경력과 상관없이 모든 인원에게 기회를 주고 응원해 주는 회사 문화 덕분이라고 생각합니다. 그래서 저는 주니어 개발자지만 다양한 경험을 할 수 있었죠.
이 밖에 제가 수행한 업무를 더 설명하자면 SEO 최적화, JS 프로젝트→타입스크립트 전환, 라이브러리 버전업 등이 있습니다. 저는 위 경험과 더불어 다양한 내•외부 프로젝트에 참여해 뜨겁게 성장할 수 있었습니다.
3장 가을
내 이야기 같던 더닝 크루거 효과
여러분, ‘더닝 크루거 효과’를 아시나요?
“인지 편향의 하나로, 능력이 없는 사람이 과잉 자신감과 우월감으로 자신의 실력을 실제보다 높게 평가하는 반면, 능력이 있는 사람은 오히려 자신의 실력을 과소평가하여 열등감을 가지는 효과”
갑자기 더닝 크루거 효과를 언급한 이유는 이게 마치 제 이야기 같아서인데요. 저는 제 굳은살을 보며 “마법을 완벽히 구사하는 마법사(개발자)가 다 됐구나!”라는 착각에 빠져있었습니다. 우매함의 봉우리에서 떨어지기 전까지는 말이죠.
업무를 수행할 때 제 부족함을 여러 번 마주했는데요. 그때마다 전 우매함의 봉우리에서 떨어졌습니다. 봉우리에서 떨어지고 정신을 차려보니 ‘모르는 게 너무 많았다’는 걸 비로소 깨달았어요. 그러나 다시 올라가기가 겁이 났습니다. “나 다시 잘 올라갈 수 있을까? 지금까지 한 게 프론트엔드 엔지니어로서 최선이었을까? 물경력이 된 건 아닐까? 나는 바보가 아닐까?”라는 걱정이 머리에 가득 찼거든요.
개발 여정의 등대 ‘프로덕트 팀’
그러나 전 슬럼프에 빠지지 않도록 신발 끈을 고쳐 매고 전의를 다시 다졌습니다. 프로덕트 팀의 리더이자 빛인 팀장님 덕분이었는데요. 팀장님은 팀원과 팀의 성장에 끊임없이 관심을 기울였고, 팀원이 가을걷이할 성과를 잘 거두고, 추운 겨울을 이겨낼 수 있도록 훈련을 시켜주었습니다. 그중 하나가 바로 ‘데일리스’ 활동인데요. 데일리스는 일종의 팀 미팅입니다. 이는 현재 일주일에 3번 진행되고 있는데요. 데일리스는 두 파트로 이뤄졌습니다. 첫번째 파트는 기술 세션으로, 자신이 공유하고 싶은 정보나 기술을 활용하면서 좋았던 경험을 이야기합니다.
두 번째 파트는 코드 리뷰인데요. 이때 팀원이 작업한 코드 가운데 자랑하고 싶은 점이나 피드백 받고 싶은 점을 공유하고요. 디자인, 해결 방법, 아이디어 등을 주제로 다양한 의견을 나누죠. 지금의 팀 문화는 굉장히 만족스럽고요. 데일리스는 제가 성장하는 데 도움이 되고 있습니다.
물론 우리 팀도 처음부터 완벽한 팀 문화를 형성했던 건 아닌데요. 처음 데일리스를 진행할 때는 업무 내용부터 사소한 일까지 다 공유해서 너무 긴 시간을 사용했습니다. 또 코드 리뷰가 어색해 이 시간이 업무 보고 시간처럼 운영되기도 했죠. 이러한 시행착오를 거친 결과, 이제는 데일리스의 구성도 개선됐고 운영도 원활합니다.
이밖에 프로덕트 팀에서는 2~3주마다 ‘토이 프로젝트 자랑하기’라는 사내 동아리 활동도 진행하는데요. 이는 각자 진행하고 싶은 토이 프로젝트를 수행한 다음, 함께 모여서 ‘무슨 일을 했는지’ 뽐내는 시간입니다. 이 활동도 처음에는 스터디 형식으로 시작했는데요. 팀원의 흥미를 유발하도록 토이 프로젝트를 진행하는 방향으로 바뀌었습니다.
“처음부터 완벽한 건 없다. 시행착오는 필연적이다.” - 프로덕트 팀 -
프로덕트 팀은 위와 같은 마인드로 계속해서 팀 문화를 발전시키고 있고요. 팀 덕분에 저는 ‘도약하기 위해 다시 제대로 뛰어보자’는 마음을 다질 수 있었습니다.
좋은 동료
인포그랩에는 정말 대단한 동료들이 많습니다! 앞서 제가 마법사 타령을 그렇게 했는데요. 회사에는 정말 다양한 히어로가 많답니다. 하루 만에 80장의 문서를 만들어 내는 마법사, 회사의 모든 일을 분신술을 쓴 것처럼 처리하는 손오공, 사람의 마음을 훔치는 구미호, 입력하면 반드시 해내는 인간지능 로봇, 못생긴 글을 넣으면 예쁜 글로 바꿔주는 연금술사 등 정말 대단한 동료들이 너무 많아서 다 적을 수가 없네요!
회사에서 이러한 동료들과 같이 있으면 보는 것만으로도 성장할 수 있었습니다. 아울러 동료끼리 서로 피드백을 아끼지 않는데요. 이는 직원들이 무한 성장하는 데 도움이 되죠. 한편으로는 이렇게 대단한 동료들과 어깨를 나란히 하려면 “정말 더 많이 노력해야겠구나”라고 자극도 많이 받습니다.
종장 겨울
다시 겨울
인포그랩은 다양한 시도로 구성원의 성장을 도모합니다. 그중 하나가 유닛 활동인데요. 유닛은 포지션별로 구분된 기존 팀과 달리 회사 프로젝트(서비스)별로 팀을 구성합니다. PO(Product Owner)는 프로젝트를 이끌면서 시야를 넓히고 역량을 키울 수 있고요. 팀원은 프로젝트에 주인의식을 갖고 몰입하며 업무를 수행할 수 있습니다. 이 유닛 활동도 시행착오를 겪으면서 발전하고 있죠.
저는 인포그랩의 파이프라인 에디터인 ‘Plumber’ 관련 유닛에서 PO 역할을 맡았는데요. PO는 팀의 의사소통을 조율하고, 좋은 의사결정을 내리도록 중심을 잘 잡아야 합니다. 아울러 팀이 잘 나아가도록 넓고 깊게 보는 안목과 지식도 필요한데요. 저는 PO를 경험하면서 프로덕트를 보는 시야가 넓어졌습니다. 그러나 제 짧은 개발 경력이 벽처럼 느껴질 때도 있었죠. 그래도 유닛과 PO 활동에서 배운 점이 많아 엔지니어로서 더 성숙해질 수 있었습니다.
1년 6개월 동안 좋은 일도 있었고, 아쉬운 일도 있었는데요. 실력 있는 엔지니어로 성장하는 과정에서 ‘커리어의 겨울’은 매년 찾아올 수 있다고 생각합니다. 앞으로 이러한 겨울을 더 성숙하고 지혜롭게 이겨내는 엔지니어가 되고 싶습니다.
외전
프론트엔드 엔지니어로 1년 6개월여 시간을 보내면서 다양한 피드백을 받았는데요. 이 가운데 기억에 남는 피드백과 제 생각을 공유하고자 합니다.
기억에 남는 피드백은?
“항상 프로의 자세로 임하세요.”
- 주니어라고 해도 늘 프로처럼 생각하고 태도를 갖춰야 합니다.
- 이를 위해 업무를 볼 때 최대한 장난기를 빼고 진중하게 임하려고 노력합니다.
“주인 의식을 갖고 조금 더 적극적으로 나서주세요.”
- 누군가가 업무를 지정해 주고, 직책이 있어야 주인인 건 아닙니다.
- 참여했으면 누구나 주인입니다.
“힘든 점이 있으면 공유하세요.”
- 수행하기 힘든 업무를 받았을 때 힘들어도 참고 이겨내야 하는 줄 알았습니다.
- 힘들다고 말하지 않으면 아무도 모르더군요.
“의견은 항상 장단점 모두 생각하세요.”
- 장점만, 단점만 있는 기술이나 방법은 없습니다.
- 항상 이면을 생각하고 고려할 줄 알아야 합니다. 그래야 실수를 줄일 수 있더군요.
마법으로 딱 하나만 잘할 수 있다면?
“고도로 발달한 기술은 마법과 구분할 수 없다.” - 아서 C.클라크 -
만약 제가 마법으로 한가지 능력만 업그레이드할 수 있다면 전 의사소통 능력을 향상하고 싶습니다. 의사소통을 잘해야 불필요한 작업을 줄일 수 있으니까요. 원활한 의사소통 능력은 마법 못지않게 신비하고 놀라운 결과를 끌어냅니다. 저처럼 의사소통을 잘하는 방법을 늘 고민하는 주니어 엔지니어를 위한 팁을 공유해보겠습니다.
- 의사소통은 한 번에 이루어질 수 없습니다.
- 반드시 되물어보고 확인하는 습관을 들이세요.
- 멀리 떨어진 사람과 원격으로 잘 소통하려면 두 배의 노력이 더 필요합니다. 의사소통에 실패했다면 준비가 덜 된 건 아닌지 확인해 볼 필요가 있습니다.
비전공자 출신인 주니어 엔지니어에게
다들 매일 성장통을 겪으면서 힘든 시간과 보람찬 시간을 번갈아 마주하고 계시는지요? 끊임없이 성장하려고 노력하되 자기 자신을 너무 탓하지는 말았으면 합니다. 지금 힘든 시간을 보내는 분이 있다면 너무 위축되지 말고 어깨를 활짝 펴세요. 원래 해뜨기 전이 가장 어둡고요. 어둠이 지나면 항상 빛이 오니까요. 겨울이 지나면 당연히 봄이 다가옵니다. 모두 파이팅이고요. 제게도 많은 응원 부탁드립니다. 감사합니다.
인포그랩은 GitLab 및 DevOps에 대한 맞춤 기술 지원을 제공합니다. GitLab(Omnibus/Cloud Native Hybrid) 구축 관련한 지원이 필요하시면 문의하기 로 연락 주십시오.