들어가며
이 글에서는 비전공자로서 사수도 팀원도 없이 혼자서 백엔드를 맡아서 해왔던 저의 생각과 느낀 점들을 1년 2개월이 된 지금 시점에서 정리하며, 어쩌면 같은 길을 걷고 있을 혹은 걸을 예정인 사람들에게 하고 싶은 말을 전달하려 합니다.
지난 1년간의 여정
저는 앞서 말한 것처럼 비전공자였으며, 완전히 다른 직무에서 일하다가 개발자로의 직무 전환을 선택했습니다.
운이 좋게도 첫 커리어를 시작한 지 1년 정도 된 스타트업에서 일할 수 있게 되었습니다. 제가 합류했을 때는 MVP(Minimum Viable Product)를 리뉴얼하던 상황이었습니다.
기존 백엔드는 JavaScript & Express로 이루어져 있었고, 제가 가진 기술 스택은 Java & Spring이었습니다.
이 말은 즉, 기존 백엔드를 새로운 기술 스택으로 마이그레이션 해야 할 뿐만 아니라, 새로운 사람이 더 올 때까지 혼자서 모든 것을 맡아야 한다는 것을 의미했습니다.
어디선가 '스타트업은 업무의 경계가 없고 혼자 여러 업무를 해야 한다'는 비슷한 말을 들어보신 적이 있으실 겁니다.
저도 그 말을 피해갈 수 없었고 백엔드 서버, 데이터베이스, 인프라 등 필요한 것이면 가리지 않고 다 맡아서 해왔습니다. (행사에 참여해 기업 부스 운영까지도..)
이 말을 다르게 생각해보면 이 경험은 당신이 대체하기 어려운 혹은 불가능한 인력으로서의 역량을 키울 수 있는 기회가 될 것입니다.
저는 이 경험을 통해 프로덕트 수준에서 데이터베이스를 관리하며 slow query에 대한 개선, 대용량 데이터 처리 등을 해보았고 인프라를 구축하며 부족했던 네트워크나 운영체제에 대한 지식을 습득할 수 있었습니다.
이렇게 제 1년이 지나갔습니다.
이게 맞는 방법인지 모르겠어요
이 소제목은 아마 제가 1년 동안 가장 많이 한 말일 정도로, 신생아 수준의 개발자였던 저에겐 모든 게 다 처음이었고 낯설었습니다.
결과적으론 정상적으로 작동하지만, 제가 작성한 코드가 마음에 들지 않았습니다.
기능들이 많아질 때마다 분명 제가 작성한 코드임에도 불구하고, 스파게티 코드가 되어가고 있었습니다.
기본적인 MVC 패턴에만 맞춰서 개발하고 있었고, 내 코드가 정말 객체지향적인지, 그리고 아키텍처를 맞게 설계한 건지에 대해선 항상 의문을 갖고 있었습니다.
코드 리뷰를 해줄 수 있는 사수나 팀원이 없었던 저는 아래와 같은 방법들을 통해 이러한 의문을 해소해왔습니다.
여러 사람들을 통해 의견을 참고하기
검색을 통해 다른 사람들의 글을 자주 접하는 사람들은 글의 퀄리티가 천차만별이며, 간혹 잘못된 정보가 포함되어 있음을 알고 있을 것입니다.
하지만, 개발에서는 은탄환과 같은 정답이 존재하지 않기 때문에 개발자마다 자신만의 방식이 있다는 것을 인지해야 합니다.
따라서, 저는 글뿐만 아니라 깃허브의 여러 레포지토리와 컨퍼런스를 참고하여 가능한 많은 양의 정보를 습득하려 노력했습니다.
이렇게 얻은 정보를 바탕으로 제 생각과 비교하며, 은탄환에 조금이라도 가까워지기 위해 노력하고 있습니다.
관련 서적을 읽고 자가진단 해보기
제 코드가 객체지향적인지에 대한 의문이 들었을 때, "객체지향의 사실과 오해"라는 책을 읽었습니다.
또한, 아키텍처를 잘 설계하고 있는지에 대한 의문이 들었을 때는 "클린 아키텍처"라는 책을 읽었습니다.
업무 중 마주치는 문제들과 관련된 서적을 읽으면서 내용을 더 빠르게 이해할 수 있었고, 해당 내용을 적용해 나의 코드베이스를 다듬을 수 있었습니다.
숨고나 지인을 통해 리뷰 받기
다른 개발자분이 "OO만원짜리 코드 리뷰를 받아서 나중에 연봉이 더 높아진다면 오히려 이득이다"라고 말씀해 주셨던 게 굉장히 인상적이었습니다.
그러던 중 우연히 좋은 기회로 짧게 인프라 진단을 받게 되었고, 1시간 만에 평소에 문제라고 생각했던 부분들을 시원하게 짚어주셨습니다.
그 이후 시간을 내어 건네주신 키워드를 통해 인프라 개선을 하며 공부할 수 있는 계기가 되었던 적이 있었습니다.
스터디 활용하기
약 8개월동안 오렌지플래닛에서 운영하는 개모임(개발자 모임)에 참여하며 다양한 주제로 의견 공유하는 시간을 통해서도 많은 인사이트를 얻을 수 있었습니다.
저와 같이 혼자서 외로운 싸움을 하고 계신 분들에게 절대 혼자가 아니고 이미 개발자 커뮤니티에 속해있다는 말씀을 해드리고 싶습니다.
테스트 코드.. 그거 꼭 만들어야하나요?
얼마 전 오렌지플래닛 전주센터에서 주최한 스타트업 간담회에 스피커로 참여해 TDD(Test Driven Development)에 대한 얘기를 한 적이 있었습니다.
갑론을박이 있을만한 주제긴하지만 간략히 내용을 설명하자면 TDD든 NOT TDD든 상관없다는 어디까지나 저의 의견을 발표했었습니다.
테스트 코드를 작성하는 동안 소요되는 리소스를 무시할 수 없고 비즈니스 로직 변경에 취약하기도 합니다.
그래서 빠르게 변화하는 스타트업에서는 조금 안 어울릴 수 있지만 변화하기 때문에 오히려 테스트 코드가 필요하다고 생각합니다.
저는 약 1000여개의 테스트 케이스를 만들었지만 TDD를 지켜서 만들진 않았습니다.
빠른 기능 개발을 위해 기능을 먼저 만들고 나중에 시간이 나는 대로 테스트 코드를 작성하였고 기능이 변경된다면 작성 해놓은 테스트 코드를 과감히 버리고 새로 작성하였습니다.
테스트 코드를 작성하고 나서 얻은 점은 크게 2가지였습니다.
내 코드에 대한 자신감
테스트 코드는 항상 기능이 원하는대로 작동하도록 보장하기 때문에 테스트만 통과한다면 내 코드가 잘 작동할거라는 믿음이 생겼고 CI/CD 파이프라인에 테스트 과정을 추가함으로써 배포에 대한 두려움이 사라졌습니다.
사이드 이펙트 예방
혼자서 할 수록 점점 늘어나는 기능들과 복잡해지는 코드에 스스로가 놓치는 부분이 생길 수 있지만 테스트 코드를 작성해두면 여러 이유로 발생할 수 있는 사이드 이펙트를 미리 발견하고 수정할 수 있습니다.
이러한 이유들 때문에 빠른 변화에 오히려 테스트 코드가 필요하다고 생각하고 아직 테스트 코드를 작성해보지 않았다면 열심히 작성한 테스트 코드가 통과하는 짜릿함을 맛보셨으면 좋겠습니다.
AI, 너 내 동료가 돼라
요즘 ChatGPT나 Copilot X 같은 AI 기술이 빠르게 발전하고 있으며 이미 많은 분들이 사용하고 있습니다.
2023 Stackoverflow Developer Survey에서는 AI 도구에 대한 개발자들의 의견을 알 수 있었습니다.
전체 응답자 중 70%가 개발 프로세스에서 AI 도구를 사용 중이거나 사용할 계획이 있다고 답했습니다.
그리고 AI 도구의 이점으로는 생산성 향상 32.81%, 학습 속도 향상 25.17%, 효율성 향상 24.96% 등을 응답했습니다.
저는 초반에는 AI 도구에 대한 두려움을 느꼈지만, ChatGPT를 제 동료로 삼기로 생각을 바꿨습니다.
업무를 하면서 모르는 것이나 더 효율적인 방법을 ChatGPT와 대화하며 찾고, 공부할 때에도 ChatGPT와 대화를 통해 Drill-down 방식으로 세부적으로 학습하였습니다.
여러 명이 할 일을 한 명이 할 수 있게끔 도와주고 축적된 데이터를 빠르게 찾을 수 있다는 AI 기술의 장점을 잘 활용한다면 주니어 개발자 혼자서도 +@년차 정도의 훌륭한 성과를 낼 수 있을 것입니다.
마무리하며
개발자는 평생 공부해야 하는 직업이라고 합니다. 그렇기 때문에 더욱 공부에 친해지려고 노력하고 항상 원리나 근본을 이해하려고 Top-down 방식의 학습법보다 Bottom-up 방식의 학습법을 고집했습니다.
처음에는 방대한 데이터에 압도당하는 기분이 들었지만, 앞에 놓인 계단을 하나씩 오르는 생각과 "안 되는 건 없다"는 마인드셋을 갖고 있었기 때문에 헤쳐나갈 수 있었던 것 같습니다.
성장하고자 하는 의지를 갖고 스타트업에서 다양한 경험을 해보는 것으로 더 멋진 주니어 개발자로 성장할 수 있지 않을까 생각합니다.