내가 왜 1년차 개발자?

나도 이제 주니어?

나는 25년 8월부터 실습생으로 출근을 시작해서 이제 곧 있으면 1년을 채우고 있는 개발자이다. 시간이 너무 빠르게 지나가서 내가 왜 벌써 1년차 개발자인지 실감도 안난다.

보통 1년~3년차를 주니어로 친다는 말을 많이 들었기에 이제 나도 주니어 개발자구나 하는 생각과 함께

내가 왜 주니어 개발자인거지? 난 할 줄 아는거 뭣도 없는데;

라는 생각도 같이 든다.

그래서 곧 1년차 개발자가 되는 기념비(?)적인 날을 기념하여 그동안 회사에서 경험하고 배운 것들을 나름 정리해 보는 글을 적어보려고 한다.

입사

25년 8월에 나는 정식으로 입사하게 되면서 실습생으로써 시작하게 되었다.

처음 맡은 업무는 홈페이지 제작이었는데, 백엔드로 들어왔지만 놀랍게도 프론트 개발을 하고 있는 나를 발견할 수 있었다.

당연히 마지막으로 제작한 웹페이지는 1학년 때 HTML 배울 때 수행평가로 제출한 웹이 마지막 이었기에 구조도 모르고 문법도 모르는 상태로 지피티에게 "해줘" 하면서 개발했다.

여담으로는 그 뒤에 입사한 프론트 동기가 코드를 보고 속으로 욕을 한 바가지를 했다고 한다.
미안하다

그 뒤에는 메인 프로덕트의 디비 구조 설계를 하고, 기본적인 인프라 구축에 들어갔다.

익숙한 AWS가 아니라 잘 만져보지 못했던 GCP로 하려니 좀 많이 어지러웠지만 사람은 구르면서 배우는 것처럼 일주일 정도 만지다 보니 살만해 졌다.

GCP를 처음 다루면서 가장 힘들었던 점은 용어가 다르다는 것이다. AWS에서 쓰는 서비스 용어가 GCP에서는 다르기 때문에 서로 매칭 시키는 것이 힘들었다.

협업

언어

규모가 작은 회사였기에 크게 개발자끼리 협업할 일은 없었다. 애초에 백엔드는 나 혼자였고 다른 분야도 각자 1명씩 있었기 때문에 개발자 끼리는 크게 협업에 있어서 문제가 없었다.

다만 문제는 비개발 직군의 분들과 협업할 때 나타났다.

학교에서는 어딜가나 전부 개발자이거나 관련 지식이 있는 사람들하고 협업을 하다 보니 자연스럽게 써온 단어들이 비개발자에게는 너무나 어려운 전문 용어였던 것이다.

예를 들어서 아래와 같은 경우다.

수정사항이 다른 곳에도 바로 반영되게 해주세요 -> 그거 하려면 SSE 통신이나 폴링으로 해야합니다
-> 그게 뭔데요?

다른 개발자라면 아 SSE~ 하면서 알아들었겠지만 관련 지식이 없다면 당연히 모른다는 이 당연한 사실을 나는 망각하고 있었다.

그래서 항상 비개발 직군과 협업하거나 소통할 때에는 아래처럼 풀어서 설명하는 것을 습관 들이게 되었다.

SSE 통신을 통해 데이터를 전달해야 하기에 현재 아키텍쳐에서는 힘듭니다.
-> 실시간으로 서버가 웹으로 데이터를 보내줘야 하는 구조라서 현재 구조에서는 변경 사항이 많아서 힘듭니다.

설득

동시에 "왜 이 기능이 당장 구현이 어려운지" 그리고 "왜 지금 구조에서는 불가능한지" 등 개발적인 지식을 기획팀으로 전달하기 위해 설득을 위한 설득을 해야했다.

전문 용어를 풀어서 말하니 말이 길어지고, 반대로 전문 용어를 섞어서 쉽게 설명하니 이해를 못하는 이 무한 악순환에 갇힌 것이다.

당연히 개발 관련 업무를 하는 분들이 아니기에 모르는 것이 당연하고 그걸 이해하지만 마음 한 켠에는 "아니 이걸 왜 이해 못해?" 하는 생각이 드는 것도 사실이었다.

이 짓을 반복하다 보니 설득을 하기 위해서는 그냥 직관적으로 비유를 하는 것이 좋다는 것을 깨달았다.

지금 비동기로 가는 요청에서 요청 시점을 서버에서 하나하나 추적하는 것이 불가능합니다.
-> 현재 구조를 비유하자면 메일을 날리기만 하지 거기에 대한 답변이 언제 오고 언제 보냈는지 까지 관찰하지 않는 구조라서 그걸 알 수가 없습니다.

예시를 들자면 약간 위와 같은 형식으로 말하고는 했다. (예시일 뿐이지 실제로 저런 대화가 오간건 아니다)

문서화

평소라면 죽어도 안할 문서화를 회사에 오면서 정말 많이 했다. API 문서같은 기본적인 문서부터 시퀀스 다이어그램, ERD, 아키텍쳐 등등 이미지로 그리거나 글로 쓰는 등 다양한 문서화를 했다.

원래는 코드에 주석도 잘 안치고 혼자서 개발해 왔으나 점점 프로덕트에 기능이 추가되고 업데이트가 되면서 내가 짠 코드를 내가 못 알아보겠는 대참사가 발생해서 주석을 계속 달면서 개발하는 습관을 들이고 있는 중이다.

클로드 코드

클로드 코드 그는 신이야, 나는 숭배해야만 해

회사에서 클로드 코드를 지원해 주어서 살면서 처음으로 클로드 코드를 써봤다. 딱 처음 써보면서 든 생각은 "개발자 왜 필요하냐 ㅋㅋ" 이었다.

진짜 프롬포팅만 해놓으면 거기에 맞춰서 컨벤션 지키고 알아서 구조 분석하고 원하는 기능 짜주고. 에러 분석해서 관련 코드 수정해 주고, 친절하게 관련 레퍼런스도 찾아주는 등...

거기에 MCP 서버들 붙이면 활용도가 무궁무진해진다. 속된 말로 정말 개발을 "딸깍" 하면서 하게 되었다.

솔직히 취업을 하기 전에는 비용 때문에 쓰지 못하다 보니 "AI가 좋아봤자 얼마나 좋다고, 그냥 내가 개발하고 말지" 하는 생각이 많았다.

근데 클로드 코드를 쓰다보니 도대체 왜 사람들이 바이브 코딩이 유행이라고 하는지 알 것 같다. 정말 이제는 누구나 개발할 줄 몰라도 개발을 할 수 있고 원하는 앱이나 웹을 만들 수 있다.

당연히 개발자가 바이브 코딩으로 짠 코드가 비전공자가 아무것도 모르고 그냥 "딸깍" 한 코드보다는 좋을 것이다. 아무래도 보는 눈이 다르다 보니 퀄리티의 차이는 존재하겠지만 요지는 예전에는 코딩을 할 줄 알아야 개발을 했다면 지금은 몰라도 일단 구현은 할 수 있다는 점이다.

이렇듯 AI가 발전하면서 개발자 입지가 줄어드냐 늘어나냐 하는 논쟁을 계속 보고 듣는다. 나는 솔직히 모르겠다는 생각이 많이 든다. AI가 얼마나 더 발전할지, 그리고 그에 따라서 역설적으로 개발자의 수요가 폭증할지 반대로 줄어들지는 이제는 예측이 안간다.

확실하게 말할 수 있는건 개발자의 수요가 늘어나든 줄어들든 이제는 AI에게 잡아 먹히지 않는 개발자가 되는 것이 더 중요해 보인다. AI를 도구로 얼마나 효율적으로 쓰냐가 개발자의 중요한 능력치 중 하나가 된 느낌이다.

결제를 만들라고요?

백엔드 개발자가 나 혼자이다 보니 신입 개발자 이지만 결제 기능을 처음으로 개발해 보게 되었다. 구글과 애플의 인앱결제 + 토스 웹결제 이렇게 총 3개의 결제 기능을 개발하게 되었다.

결제 기능은 특히 실제로 돈이 오가는 매우 민감한 로직이라는 생각이 들어서 공식 문서들을 참고하고 또 참고하면서 개발했다.

근데 IAP는 일반적인 PG사 결제와 다르게 웹훅 기반으로 IAP 결제 서버가 자체적으로 스케쥴링 및 결제를 하면 서버는 그냥 알림만 받아서 상태값들을 수정하고 변경하는 역할만 수행하는 구조였다.

여기서 1차 멘붕이 왔다. 내가 기존에 공부했던 PG사 결제 구조와는 완전히 다른 형태였기에 이건 또 뭐야? 하면서 문서를 다시 뒤져보기 시작했다.

심지어 최초 결제 시 이뤄지는 로직도 구글과 애플은 달랐다. 진짜 이때 스트레스를 제일 많이 받았던 것 같다.

클로드 코드와 여러 문서들의 힘을 빌려서 다행히 "구현"에는 성공했다. 그러나 앞으로 운영을 하면서 어떤 문제가 닥쳐올지 모르기에 지금도 매일 기도 중이다 "제발 에러 없어라.."

기능 추가..그리고 또 수정...

분명 기능명세서 있는 기능은 다 했는데 갑자기 기능이 추가되고, 또 있던 기능이 수정되고... 이거를 한 10번은 반복한거 같다. 아직 1차 기능도 개발 안됐는데 갑자기 2차 기능을 예고하면서 설계 다시 또 엎고...
제발 그만해..

어쩌겠는가, 돈 벌려면 하라는대로 해야지.

그렇게 나는 야근을 하면서 DB와 로직을 갈았다. 그나마 다행히도 중간 중간에 정말 이건 아니다 싶은 사항들은 반려하다 보니 조금은(?) 여유롭게 개발할 수 있었다.

스타트업의 한계

스타트업을 처음에 가고 싶어했던 이유 중 하나는 "내가 직접 처음부터 개발할 수 있어서" 그리고 무엇보다 "재밌을거 같아서" 였다. 근데 문제는 우선 일은 재밌을 수 없고, 처음부터 개발한다는 것은 생각보다 많이 고통스럽다 라는 것을 몰랐던 것이다.

메인 프로덕트는 매번 기획이 수정되거나 기능이 추가되고 기능명세서는 부실했다. 인프라는 구축된 것이 아무것도 없어서 클라우드 인프라는 아예 처음부터 새롭게 구축해야 했다.

무엇보다 내가 구축하는 거 = 회사의 초기 인프라, 즉 토대가 된다는 압박감이 정말 힘들었다.

포트폴리오

입사한지 어느덧 1년이 다 되어 가다 보니 나름 한 것들이 많아지면서 슬슬 포트폴리오를 정리해 봐야겠다 싶었다.

작년 5월부터 사실상 방치 상태였던 신입 포폴을 치우고 영광스러운 경력 첫 줄이 추가된 포트폴리오를 다시 쓰기 시작했다.

안에 채워넣을 내용 자체는 사실 10번 넘게 내용을 갈아엎었던 경험 때문에 이제는 크게 어렵지 않았다. 오히려 내용의 질 자체는 전보다 상승한 느낌이다.

그러나 항상 나를 가로막은건 이 디자인이다. 아무리 포폴이 내용이 더 중요하다고 해도 사람은 기본적으로 깔끔하고 예쁜 포폴에 더 눈이 가기 마련이다.

그걸 모르지 않기에 더더욱 여기저기 돌아다니면서 디자인을 갈고 또 갈면서 작업했다.

그러면서 느낀 점은

왜 신입을 안뽑고 경력을 뽑으려는지 알겠다

당장 신입과 나의 포폴을 비교해 봤을 때 내가 만든 모든 프로젝트와 거기에 따른 트러블 슈팅들은 결국 "어떤 A라는 상황을 가정하여 이러한 대처를 했다" 이거나 아주 소규모의 이슈를 조금 과장해서 표현하는 일종에 부풀리기 식으로 과대포장하는게 전부였다.

그러나 경력을 쌓으면서 실무에서 한 "실제 상황을 바탕으로 한 나의 고민과 해결책"을 담다 보니 그 퀄리티가 압도적으로 높을 수 밖에 없었다. 그리고 분명 나보다 경력이 높은 분들은 그 정도가 배는 될 것이라고 생각했다.

약간의 번아웃

2학년부터 여러 프로젝트와 동아리를 하고 3학년 때 취준을 하면서 매우 큰 번아웃이 연속으로 찾아 왔을 때 나는 속으로

취업을 하고 나면 분명 이 번아웃은 사라지고 행복할거야

라는 착각을 했다.

처음 한 두달은 좋았다. 괜찮은 직장에, 돈도 잘 들어오고, 자기관리할 시간과 여유도 생기고... 근데 딱 거기까지 였다. 매일 똑같이 빙빙 도는 하루는 생각보다 사람을 빠르게 질리게 하고 지치게 한다는 것을 알게 되었다.

내 방학 돌려주세요

적어도 고등학교에 있을 때는 이럴 때는 나가서 좀 뛰어놀거나, 생각없이 그냥 좀 자고 일어나서 생각을 정리할 수가 있었다. 근데 직장에서 퍼질러 잘 수도 없고, 집에 가면 운동하고 씻고 누우면 10시 11시이다. 대충 폰을 조금 보다 보면 12시이고 잘 시간이다.

번아웃이라고 하기 보다는 그냥 지쳐가는 중인거 같다. 이걸 보는 수년간 더 오래 사회생활을 하신 분들은 "뭐 고작 1년 깔짝 한거 가지고 엄살이냐" 라고 하실 수도 있겠지만...

장난입니다

나는 잘 걸어가는 중일까?

마지막으로, 지쳐가면서도 내가 속으로 가장 많이 고민한 점은 "이대로 가도 괜찮나?" 라는 고민이었다.

사수도 없었으며, 오로지 혼자서 모든걸 담당하고 설계해야 했다. 회사는 좋지만 규모가 작고 이제 시작하는 중소기업이다. 그렇기에 내가 하는 결정이 곧 회사의 기초라는 생각이 가장 큰 부담이었다.

그리고 동시에 매우 많은 고민들이 끊임없이 떠오른다. "군대는? 병특을 준비 해야하나? 대학은?" 이런 고민들이 꼬리에 꼬리를 문다.물론 나의 개발자로써 커리어는 이제 시작이고 앞으로 나아가야 할 길에 비하면 이제서야 출발점에 있다는 것도 잘 안다. 그렇기에 더더욱 많은 고민을 할 수 밖에 없는 것 같다.

아마 언젠가는 이직도 하게 될 것이다. 더 좋은 곳으로 갈 수도 있고, 혹은 비슷한 규모의 회사로 가서 비슷한 환경에 놓이게 될지도 모른다.

그렇기에 나는 그냥 "내가 지금 할 수 있는 것" 그리고 "지금 내가 해야하는 것"들에 집중하기로 했다.

인생에는 정답이 없고, 커리어도 비슷하다고 생각한다. 그렇기에 고민해봤자 답도 안나오는 일은 신경을 끄기로 했다. 그냥 열심히 하다 보면 더 좋은 기회도 오고 그러다 보면 커리어도 천천히 쌓아지겠지 하는 생각이다.

마무리

1년 동안 근무 하면서 이런저런 일도 많았고 힘들기도 했지만 그래도 이정도면 잘 성장해 나가고 있는 것 같기도 하다.

벨로그도 꾸준히 적고 있고, 새해 목표 중 하나인 오픈소스 기여와 운동하기도 조금씩 실천 중이다 보니 요즘은 그래도 "갓생" 을 살고 있는게 아닐까 하는 생각도 한다.

다들 행복한 하루 되기를 바라며 이만 글을 마치겠다.