비전공자 개발자로 살아남기 (만 3년차 회고)

안녕하세요. 프롭테크 스타트업에서 백엔드 개발자로 일하고 있는 만 3년차 개발자 정정일입니다.

비전공자로 개발을 시작해볼까 고민하는 분들을 떠올리며, 제가 어떻게 여기까지 왔는지 시간순으로 정리해봤습니다. 화려한 성공담은 아닙니다. 간절함과 운을 반쯤 섞어 그럭저럭 살아남은 기록에 가깝습니다.

시작

2018 · 영업으로 사회에 나오다

제 부모님은 한 가지 확고한 가치관이 있으셨습니다.

“고등학교를 졸업하면 3,000만원을 줄 테니 독립해라. 대학을 가든, 취업을 하든, 창업을 하든 하고 싶은 걸 해라.”

뚜렷한 꿈이 없던 저는 지금 대학에 가면 돈과 시간이 아깝겠다고 생각했습니다. 그래서 졸업하자마자 군대에 다녀왔고, 제대 후 바로 영업에 뛰어들었습니다. 그 때가 스물한 살이었습니다.

영업은 약 5년을 했습니다. 그런데 영업은 실적이 매달 0으로 리셋되는 구조가 저를 계속 괴롭혔습니다. 한 달을 잘 채워도 다음 달이면 처음부터 다시 시작이었고, 쌓아온 게 사라지는 느낌이 들 때마다 “내가 발전하고 있는 게 맞나” 싶었습니다.

느낀 점 — 저는 제가 성장할 수 있는 꾸준히 쌓여가는 일을 하고 싶었던 것 같습니다.

2022.07 · 개발자가 되기로 하다

어느날 친동생이 국비지원으로 개발을 준비한다는 이야기를 듣고 처음 이 직업을 들여다보게 됐습니다. “개발자는 평생 공부해야 한다"는 말이, 매달 리셋되던 일을 하던 저에게는 단점이 아니라 매력으로 다가왔습니다. 며칠 고민하다 일을 그만두고 국비 학원에 등록했습니다. 이 때가 스물다섯이었습니다.

학원은 하루 8시간, 주 5일, 6개월 과정이었습니다. 같은 교육이어도 수강하는 모습은 사람마다 갈렸습니다. 무료라 “일단 들어보자"는 분이 많았는데, 저는 생활비를 스스로 책임지던 터라 “이게 내가 무언가를 온전히 공부할 수 있는 마지막 기회다"라는 마음이 컸습니다. 제 반 20명 중 개발자가 된 사람은 서너 명이었습니다.

공부는 단순하게 했습니다. 강의로 개념을 익히고 → 작은 개인 프로젝트로 직접 만들어 보고 → 이해하게 되는 식이었습니다. 거기에 주 2~3회 스터디를 더했습니다. 강의만 보면 머리로만 아는 느낌이라, 한 번은 손으로 만들어 봐야 비로소 체득된다고 느꼈습니다.

느낀 점 — 사실 개발이 아니더라도 무언가를 할 때 간절히 원하면, 그만큼 더 빨리 배울 수 있는 것 같습니다.

첫 회사

2023.03 · 첫 취업

수료 전부터 지원했지만 현실은 학원 홍보와 달랐습니다. 서류에서 숱하게 떨어졌고, 자신감이 가장 바닥이던 시기였습니다. 그래도 이력서와 포트폴리오를 다듬으며 면접을 보다 보니, 경험과 열정을 봐주는 스타트업들이 있었습니다. 지원을 시작한지 약 2~3개월 만에 반에서 가장 먼저 취업했습니다.

합격한 회사의 면접은 CTO 한 분, 개발팀장 두 분과 1시간가량 진행됐습니다. 처음에는 인적성 위주였는데 중반부터 기술 질문이 이어졌고, 꼬리질문이 깊어지면서 어느 순간 제가 답을 못 하는 지점이 왔습니다. 그때 CTO님이 “이렇게 질문과 답이 오가는 건 좋은 신호다. 그만큼 더 듣고 싶은 이야기가 많다는 뜻이다"라고 하셨습니다. 면접이 끝나고 나서도 그 말이 계속 생각났습니다.

2023 · 처음으로 크게 데인 날

첫 회사는 20~30명 규모의 핀테크 스타트업이었습니다. 배울 게 많아 즐거운 나날들이었고, 인정을 받고 싶어 팀장님께 일을 더 달라고 요청드리기도 했습니다.

솔직히 말씀드려서 일 자체는 제게 어렵지 않았습니다. 흔히 이야기하는 java, spring, json, rest api, db, ci/cd 정도를 다룰 줄 알면 충분히 해낼 수 있는 일이었습니다. 도메인 지식의 부족함은 있었지만, 그건 시간이 지나면 해결되는 문제였습니다. 선배 개발자분들께서 심심치 않게 농담반 진담반으로 “에이스가 들어왔네"라고 해주시면 그때마다 인정받는 것 같아 정말 기분이 좋았습니다.

그러다 수습기간이 끝날때쯤 한번 크게 사고를 치게 됐습니다. 개발서버 테스트 데이터에 실제 고객 데이터가 섞인 걸 확인하지 못하고 약 600분에게 테스트 메일을 보냈고, 운영팀에 CS로 사용자 분들께서 불편을 겪으셨다는 연락이 들어왔습니다.

CS를 받던 운영팀이 개발팀으로 “혹시 이런 메일 보낸 적 있냐"고 확인하러 왔을 때, 등골이 서늘하고 온몸에 식은땀이 났습니다. 그때는 정말 벌벌 떨었습니다. 내가 회사에 큰 피해를 줬구나 싶었고, 한동안은 실행 버튼을 누를 때마다 손이 멈칫했습니다.

느낀 점 — 사고는 거창한 데서 나지 않고 늘 확인 한 번 건너뛴 자리에서 났습니다. 그 전까지 저는 인정을 받고싶은 마음에 빠르게, 많이 처리하는 데만 정신이 팔려 있었습니다.

회사를 나온 지금도 사고를 수습해주신 운영팀의 대리님과 가끔 술 한잔 하며 이때 이야기를 나누곤 하는데, 그땐 정말 제가 미우셨다고… 그때마다 저는 정말 고생하셨다고 항상 감사한 마음뿐이라고 말씀드리곤 합니다. ㅎㅎ

이후 맡는 일이 점점 늘었습니다. 입사 1년이 안 됐을 때 부사수가 생겨 후배를 가르치게 됐고, 정산과 백오피스를 맡으며 서버와 DB 권한 전체를 받게 되기도 했습니다. 새 요구사항을 개발하고 사고를 수습하기를 반복하다 보니, 어느 순간 “내가 이 일을 할 줄 알게 됐구나” 싶었습니다.

2023.12 · DevOps를 떠안다

이때 제 개발 인생에서 중요한 전환점이 된 사건이 발생하게 됩니다.

2023.12월 유일한 회사의 DevOps 담당자께서 더 좋은 조건으로 스카우트되어 이직하면서, 회사 서버를 온전히 아는 사람이 사라질 상황이 됐습니다. 후임을 뽑아 한 달간 인수인계를 하려 했지만 회사 사정상 채용이 어려웠고, 결국 “그럼 문서라도 남기고 가겠다"로 정리됐습니다.

그런데 개발자인 제 입장에서는 여간 불안한 게 아니었습니다. 당시 회사 서버 구성을 모두 알고있던건 DevOps분께서 유일하다고 해도 과언이 아니었고, DevOps분께서 이직을 하시게 되면 회사 서버에 문제가 생겼을 때 대응할 수 있는 사람이 아무도 없는 상황이 오게 되는 거였죠.

다음 DevOps가 언제 채용될지도 모르는 상황에서 서버에 문제라도 생긴다면 저희 서비스에 심각한 장애가 생길 수 있다고 판단했거든요.

그래서 제가 실례를 무릅쓰고 DevOps분을 따로 찾아뵈어

“혹시 실례가 안된다면 제게 회사 인프라에 대해 조금만 알려주실 수 있으실까요..? DevOps가 공백인 기간에 혹시라도 서버에 문제가 생기면 누군가는 해결해야 할 텐데… 번거로우시겠지만 조금만 알려주신다면 제가 부족한 지식으로라도 어떻게든 버텨보겠습니다.”

당시 그런 저를 좋게 봐주셨는지, 그분은 한 달간 멘토링과 인수인계를 해주셨습니다. 덕분에 쿠버네티스, AWS EKS, Jenkins, ArgoCD, ELK를 처음 접했습니다. 한 달로 다 흡수할 수 있는 양이 아니어서, 던져주시는 키워드를 노트에 받아적어 하나하나 찾아보며 공부했습니다. 핀테크 회사라 내외부망이 분리된 환경이라 더 까다로웠습니다.

그렇게 다음 DevOps가 채용되기 전까지 약 7개월을 혼자 인프라를 운영했습니다. 지금 생각하면 꽤나 호기로운 자세가 아니었나 싶습니다.

그 7개월 사이에 어떻게든 막아낸 장애도 몇 번 있었고, 제가 도저히 해결하지 못해 이직하신 그분께 사적으로 연락드려 SOS를 청한 적도 있었습니다.

그래도 이 시기가 제 개발 인생에서 가장 많이 배운 때 중 하나인 것 같습니다. 돌아보면 저에게는 정말 큰 행운이었던 것 같습니다. 많은 회사의 개발자분들께서는 인프라를 접근할 수 있는 권한 자체가 없으신 경우가 많거든요.

느낀 점 — 이 때 부터는 개발자이면서도 인프라를 다룰 수 있는 능력이 제게 큰 무기가 된 것 같습니다. 좀 더 넓은 시야에서 서비스를 바라볼 수 있게 됐고, 개발자와 DevOps의 입장을 모두 이해할 수 있게 됐습니다.

2024.01 · 인수합병, 그리고 버티기

회사가 어렵다는 소문이 돌았고, 10명이던 개발팀이 4명으로 줄었습니다. 사수와 팀장님도 떠나 제가 정산팀에서 가장 오래된 사람이 됐습니다. 얼마 뒤 회사는 동종업계 다른 회사에 인수합병됐고, 줄어든 인원만큼 일은 더 늘었습니다. 1년 차에 한 회사의 정산과 서버를 혼자 맡는 상황이, 지금 생각해도 쉽지 않았습니다.

2024.03 · 연봉협상

인수한 회사에서 “연봉을 많이 올려줄 테니 남아달라"는 말을 믿고 기다렸지만, 인상폭은 기대에 한참 못 미쳤습니다.

제 개인적으로는 정산, 백오피스, 신규 기능 개발, 인프라 운영까지 맡아서 하고 있었기 때문에 그만큼의 가치를 인정받고 싶었으나 반영되지 않았다는 점이 많이 아쉬웠습니다.

사측에서는 ‘연봉인상’과 ‘신규 DevOps 채용’중 신규 DevOps 채용을 선택할테니 채용될때까지만 기다려 달라고 했습니다.

2024.07 · DevOps 인수인계

신입 DevOps분께서 입사하셨고, 제가 7개월간 운영하던 인프라를 인수인계했습니다. 그동안 제가 혼자서 운영하며 겪었던 시행착오와 장애 대응 경험을 공유했습니다. 다행히도 DevOps분께서 빠르게 적응하시고, 이후로는 안정적으로 인프라를 운영할 수 있었습니다.

2025.01 · 이직을 결심하다

그렇게 다시금 연봉협상 시기가 다가오게 됐습니다.

사측에서 회사가 어려워져 올해에는 “연봉협상할지 언제 할지 확답을 줄 수 없다"는 말을 했습니다. 면담에서 “할 수 있으면 할 수 있다, 없으면 없다 확실히 말씀해 달라"고 여러 번 청했지만 끝내 답은 같았습니다.

느낀 점 — 막연한 기대를 붙잡는 것보다, 확답이 없으면 움직이는 게 맞다고 판단했습니다.

2025년 2월 지금의 회사에 합격했고, 한 달 인수인계를 마치고 3월에 이직을 하게 됐습니다.

퇴사 의사를 밝히고 나서 여러차례 면담이 오가기도 했습니다. 회사 상황이 어려워 금전적인 부분의 협상은 어렵지만 원한다면 재택근무와 같은 방법으로 근무하는 등의 편의를 제공할 수 있다 라는 말씀을 여러차례 해주셨지만,

이미 마음이 떠난 상태이기도 했고 면접본 회사에서 1000만원 이상 처우가 올라가는 제안을 받았던 상황이기도 했기 때문에, 회사에서 해주시는 편의 제공 제안은 솔직히 크게 와닿지는 않았습니다.

그 회사는 결국 2025년 8월, 연봉협상 없이 개발팀 전체에 권고사직이 내려지며 모두 떠났다고 합니다.

두번째 회사

2025.03 · 이직

새 회사는 아파트·오피스텔과 같은 집을 사고팔려는 분들과 공인중개사를 연결하는 프롭테크 플랫폼이었습니다. pre-A 단계, 15명 남짓, 백엔드는 CTO와 저 둘뿐이었습니다.

합류한 팀은 마침 레거시 모놀리식을 MSA로 옮기는 중이었습니다. 그래서 첫인상은 “할 게 많겠다"였습니다. 16개로 쪼개진 레포, 규모에 비해 과한 MSA, 아직 IDC에 남아 있는 모놀리식 서비스, 제대로 된 모니터링 시스템의 부재, 그리고 단일 인스턴스에 몰려 있던 서비스들.

꽤나 많은 기술부채를 보유하고 있었기 때문에 오히려 흥미로웠습니다.

2025.04 · 처음은 문서화부터 MSA까지

처음 입사해서 가장 먼저한 일은 문서화였습니다. 제가 입사한 시점에 회사에는 온보딩 문서가 없어, 제가 궁금한 부분들을 직접 CTO님께 여쭤보며 문서화했습니다. 시스템 아키텍처를 그려보며 서비스 구조와 흐름을 이해할 수 있었습니다.

회사의 첫 기여가 문서화였다는 점에서 CTO분께서는 감사하기도 하며 미안하기도 하다고 말씀해주셨습니다. 이후 온보딩문서는 회사 내부 Confluence에 정리됐고, 이후 입사하는 개발자분들은 온보딩 문서를 참고할 수 있도록 구성해뒀습니다.

그 이후 레거시 서비스를 MSA로 전환하는 과정에 참여했고, 핵심 도메인인 ‘아파트’를 MSA로 분리하려다 한 번 크게 고민하게 되는 일이 생기기도 했습니다. 아파트와 매칭이 같은 테이블을 공유하며 깊게 얽혀 있어서, 하나만 떼어낼 수가 없었습니다.

느낀 점 — 이 때 사이드 프로젝트로만 구성해본 MSA를 실제 서비스 환경에서 운영하고 개발하려하니 MSA의 장단점이 더 선명하게 보였습니다. 개인적인 판단으로 저희 회사 서비스는 MSA는 과하다고 판단해 차후(2026년 1월) MSA 서비스들을 모듈러 모놀리식으로 합쳤습니다.

2025.06 · 쿠버네티스와 모니터링

이때 회사 서비스는 단일 인스턴스로 구성돼 있었습니다. 그러나 서비스가 늘면서 메모리 부족으로 죽거나, 한 서비스가 CPU를 독점해 옆 서비스까지 느려지는 일이 잦았습니다. 기존에 회사는 개발 서버조차 없어 테스트를 운영 환경에서 해오고 있었습니다. (이때 꽤나 충격을 받았습니다. 개발 환경은 당연하다고 생각했어서) 6월부터 쿠버네티스(GKE)로 옮기면서 Eureka·게이트웨이를 걷어내고, ArgoCD로 GitOps를 구성했습니다.

그리고 가장 신경 쓴 건 모니터링이었습니다. 그전까지는 시스템 장애를 개발팀에서 먼저 인지할 수 없는 상태였습니다. 모니터링 환경이 CloudWatch만으로는 부족하다 판단해, Loki·Grafana·Tempo·Prometheus로 직접 모니터링 스택을 만들었습니다.

덕분에 장애 감지가 수 시간에서 수 분으로 줄었습니다. 실제로 네이밍이 컨벤션이 지켜지지 않아 발생하고 있던 예외 같은 문제를, 찾게 되기도 했습니다.

2025.06 · 투자가 무산되다

면접 때 “시리즈 A에 투자가 거의 확정났다"는 이야기를 듣고 입사했는데, 입사 3개월이 채 안 돼 그 투자가 어그러졌다는 말을 듣게 됐습니다.

이때 꽤나 충격이 컸습니다. 저는 “거의 확정났다"를 “투자가 확정됐다"로 오해했었고, 그 투자금으로 회사가 안정화될 거라 생각했기 때문입니다. 계약서에 사인했더라도 돈 들어오기 전까진 모른다는 걸 이 이후에야 깨닫게 됐습니다. (나중에 알았지만 계약서에 사인한 상태도 아니었습니다. 하하…)

느낀 점 — “투자가 거의 확정났다” != “투자를 받았다” 이 말을 꼭 기억하시길 바랍니다.

월급이 밀리지 않는한 1년을 채우자라는 마음으로 다니게 됐습니다.

2025.08 · 혼자가 되다

투자 무산의 여파는 사람으로 돌아왔습니다. 8월부터 10월까지 CTO 분을 시작으로 동료들이 연달아 회사를 떠났고, 어쩌다 보니 입사 반년도 안 돼 MAU 2만 규모 플랫폼의 백엔드와 서버를 혼자 책임지게 됐습니다.

처음에 CTO의 퇴사가 결정났을때 CEO분께서는 어느정도 불안감을 내포한 상태로 “신규 채용은 어려운 상황인데 백엔드 혼자서 서비스 운영과 개발을 다 할 수 있겠냐"라는 질문을 하셨습니다.

새 환경에 대한 설렘이 가시기도 전이라 솔직히 막막했습니다. 그렇지만 5개월의 기간동안 시스템에 대한 파악은 어느정도 되어 있어 “가능은 하다"는 게 제 결론이었습니다.

제가 “쉽지 않겠지만 불가능하지는 않다"라고 답하자, CEO는 “당분간은 현상 유지만을 해도 좋으니 안정적으로 서비스를 유지시켜만 달라"고 요청하셨습니다.

그 뒤로는 한동안 살아남기 위한 시간이었습니다. 다만 신기하게도, 혼자가 되니 손볼 곳이 더 또렷하게 보였습니다.

나 혼자 이 시스템을 다 봐야한다고? 라는 생각에 혼자 관리하려면 이것들부터 해야겠다. 라는 생각이 들었습니다. 그래서 우선순위를 정해, 관리 병목이 되는 부분부터 하나씩 개선하기로 결심했습니다.

2025.09 · 모노레포로 전환

가장 먼저 눈에 걸린 건 코드 중복이었습니다. MSA 환경으로 16개 레포를 관리하다 보니, 공통 Exception 하나를 고치려면 16개 레포에 똑같은 수정을 반복해야 했습니다.

그래서 관리하기 쉽도록 16개 레포를 하나의 모노레포(멀티모듈)로 합쳤습니다. Git Subtree로 커밋 히스토리를 살린 채 통합했고, 그 결과 빌드 시간이 27분에서 8분으로 줄고 중복 코드 약 5,500줄이 사라졌습니다. (대신 23만 줄짜리 PR이 만들어졌습니다.)

이게 4월부터 작업하던 걸 급하게 8~9월에 몰아서 마무리 짓게 됐습니다.

2025.09 · 증명후에 협상

1달간 혼자서 서비스를 안정적으로 유지하는 모습을 보여드린 뒤, CEO께 면담을 요청해 연봉협상을 진행했습니다. 그 결과 연봉 만족할 만큼 인상된 급여를 11월부터 받기로 협의가 이루어졌습니다.

2025.10 · 안정화에 매달리다

서버를 쿠버네티스로 옮긴 뒤, 배포만 하면 첫 요청이 느려지는 게 눈에 띄었습니다. 평소 100~200ms이던 첫 응답이 배포 직후엔 1.2초까지 치솟아 JVM Cold Start 문제를 해결하거나

MSA 전환 과정에서 한 컬럼을 bigint에서 varchar로 바꿨다가 쿼리가 8배 느려진 일을 해결하거나

CI로 사용중이던 GitHub Actions 무료 한도(월 2,000분)가 리밋을 넘게 생겨 급한 대로 팀원 맥북에 Self-hosted Runner를 붙이기도 하고, Jenkins를 쿠버네티스 위에 올려 필요할 때만 파드를 띄우는 구조로 바꾸기도 하며 서비스 안정화에 집중했습니다.

2025.12 · 정말 MSA가 필요했을까

연말에는 한발 물러나 큰 질문을 마주했습니다. 백엔드 한 명이 13개가 넘는 서비스를 분산환경에서 운영하며 기능 개발까지 한다는 건 병목지점이 너무 많았고, MSA는 회사 규모에 비해 비용도 복잡도도 과하다고 판단했습니다. 그리고 GCP 스타트업 크레딧이 2026년 4월에 끝나기 때문에 비용 절감의 필요성도 있었습니다.

그래서 MSA의 필요성에 대해 진지하게 검토해보기로 했습니다.

이후 MSA를 해보며 느꼈던 내용을 고찰하며 “우리에게 정말 MSA가 필요했나”와 같은 MSA 시리즈 글을 남기기도 했죠.

느낀 점 — 제가 느꼈던 MSA의 장점을 위 글에 자세히 적어뒀지만 제가 느낀 바를 짧게 정리하자면 MSA는 특정한 문제를 풀기위해 복잡성을 감수하는 선택입니다. 그렇지만 문제가 발생하지도 않았음에도 MSA를 선택하는 건, 복잡성을 감수할 이유가 없는 선택이라고 생각합니다. MSA는 문제를 해결하기 위한 수단이지, 목적이 되어서는 안된다 생각합니다.

2026.01 · 모듈러 모놀리식으로 되돌리다

그래서 11개 서비스를 하나의 애플리케이션으로 합쳤습니다. 알림과 배치 서비스만 독립으로 남기고, 모듈 간 호출은 ModuleApi 인터페이스로 추상화했습니다. 그 결과 파드가 26개 이상에서 두세 개로, Compute 비용이 하루 96,505원에서 58,768원(월 약 113만원 절감) 으로 줄어 들게 되고 복잡성도 크게 줄어들게 됐습니다.

기존에는 문제가 발생하면 여러 SQS를 뒤지고 여러 서비스의 로그를 뒤져야 했지만, 이제는 한 서비스에서 모든 로그를 확인할 수 있게 됐습니다. 혼자 하다보니 여러 서비스를 뒤져서 문제를 찾는게 여간 쉽지 않았는데 이제는 한 서비스의 스택트레이스로 추적되니 문제 해결 속도가 훨씬 빨라졌습니다.

느낀 점 — 팀과 서비스의 상황에 맞게 선택하는게 중요하다는 것을 다시금 느꼈습니다.

2026.02 · AI 신규기능 론칭

이 때 쯤은 AI를 서비스에 녹이는 일을 시작했습니다.

회사에는 기존에 고정 RAG 파이프라인으로 된 LLM 기반 서비스가 있었는데,

회사에서 기획한 신규 기능은 “송도역이나 강남역 근처에 30평대 10억 이하 500세대 신축 아파트 추천해줘” 같은 자연어 기반의 매물 추천이 됐으면 좋겠다는 요구사항이 있었습니다.

그래서 LLM이 계획만 세우고 실행은 코드가 맡는 구조로 재설계하면서, ‘AI 매물 추천’ 신규 기능을 론칭하게 됐습니다.

또 전세사기 위험도를 분석해주는 ‘AI 등기 분석’ 기능도 개발해 론칭하게 됐죠.

2026.05 · 신뢰성을 ‘약속’으로

가장 최근 손댄 건 SRE이었습니다. 저 혼자 예외 로그도 확인하다보니 “ERROR!!! 확인 요망” 알림이 울려도 실제로는 멀쩡한 경우가 잦아지자, 어느새 제가 알림을 확인하지 않는 경우들이 발생하게 됐습니다. 또 “지금 배포해도 되나?“를 판단할 객관 기준이 없었습니다.

그래서 5xx 비율을 SLI로 잡고, 99.9%(30일에 약 43분 실패 허용)라는 Error Budget으로 신뢰성을 수치화했습니다. 한 가지 더 배운 건, 200 OK가 늘 정상은 아니라는 것이었습니다. 실거래가 배치가 멈춰 한 달째 옛 데이터를 주는데도 API는 200을 응답하고 있었거든요. 그래서 데이터 신선도까지 검사하는 Synthetic 모니터링도 붙이게 됐습니다.

느낀 점 — 신뢰는 ‘감’이 아니라 ‘약속’이어야 한다는 것.

2026.06 · 회사는 지금

아직 회사는 투자를 받지 못한 상태입니다. 어찌저찌 살아남을지 망할지 모르겠지만, 저는 제 역할을 다하기 위해 노력하고 있습니다.

물론 의욕이 사그라드려 하는 날도 있지만 “이 회사가 망하든 말든 나는 내 역할을 다할거야"라는 생각으로 버티고 있습니다.

지금, 3년차

이제 만으로 3년이 넘었습니다. 4년 전만 해도 System.out.println("Hello World")도 제대로 모르던 사람이, 지금은 백엔드와 인프라를 함께 보고 서비스 안정성을 책임지고 있는 나날을 보내고 있습니다.

돌아보면 비전공자라는 건 시장에서 분명한 약점이라고 생각합니다. 그래서 출발선이 남들보다 뒤에 있다는 걸 인정하고, 부족한 만큼 다른 데서 강점을 만들려 하는게 중요하다고 생각합니다. 강의를 듣고 끝내지 않고 직접 만들어 본 것도, 인프라처럼 비어 있는 자리를 떠안은 것도 부족한걸 알기에 더 열심히 하려는 마음에서 나온 선택이었습니다.

영업하던 시절 가장 견디기 힘들었던 게 매달 0으로 돌아가는 느낌이었는데, 개발은 어제 막힌 것이 오늘의 바탕이 되는 것 같습니다. 여전히 모르는 것투성이지만, 하루하루 쌓아갈 수 있다는 것만으로도 저에게는 감사한 날들이라 생각이 듭니다.

비전공자로 개발을 시작해볼까 고민하시는 분이 이 글을 보셨다면, 이런 사람도 이렇게 개발자로 살아가고 있구나 정도로 읽어주시면 좋겠습니다. 긴 글 읽어주셔서 감사합니다.