회고

[회고] 19살, 첫 회사에서 배운 것들

user-anonymous 2023. 1. 4. 23:53
728x90

19살, 신입 개발자였던 내가 겪은 ‘현실’ 그리고 성장

나는 19살이 되는 해에, 선생님의 추천을 받아 약 180명 규모의 IT 중소기업에 면접을 보게 됐고, 9월부터 3개월간의 현장실습 과정을 거쳐 정규직으로 입사하게 됐다. 이후 약 3년간 회사에 몸담으며 다양한 경험을 했다. 2년은 사내 시스템을 개발했고, 1년은 B2C 플랫폼을 맡아 일했다.

"환영합니다"는 없었다

입사 첫날, 내가 상상했던 회사의 모습은 ‘웰컴키트’가 책상 위에 올려져 있고, 사수가 배정되어 업무를 하나하나 알려주는 구조였다. 하지만 현실은 딱 달랐다. 테이프로 칭칭 감긴 컴퓨터 박스와 오래된 본체가 덩그러니 책상 위에 놓여 있었다. 나와 함께 입사한 동기에게도 어떤 가이드도 주어지지 않았다. 그래도 나는 열정이 가득한 신입이었다. 선배들에게 하나씩 물어가며 적응했고, 그 과정에서 정말 많은 실수를 하며 배웠다.

첫 번째 실수, 그리고 습관

입사 초, 내가 처음으로 저지른 큰 실수는 WHERE절 없이 전체를 UPDATE 해버린 일이었다. 개발 서버였지만, 정말 식은땀이 줄줄 났다. 다행히 선배에게 도움을 요청했고, 그때 DB 덤프라는 걸 처음 알게 됐다. 이후로는 어떤 작업을 하든 무조건 덤프를 떠두는 습관이 생겼다. 실수는 분명 힘들고 창피했지만, 되돌아보면 그때 배운 것들이 훨씬 오래 기억에 남는다.

 

"휴가 신청 시스템을 만들어봐" 끝.

회사 1년 차가 될 무렵, 대학과 병행하던 시기였다. 상사가 내게 업무를 하나 줬다.

"사내 직원들이 휴가를 신청할 수 있도록 시스템을 만들어봐. 관리자 페이지도 포함해서."

그게 끝이었다. 기술 스택? 배포 환경? 전혀 언급이 없었다. 단지 나와 선임 한 명이 해당 프로젝트를 맡았고, 우린 프론트는 리액트, 백엔드는 자바 + JPA, API는 MSA 구조로 Netflix Zuul + Eureka를 사용하기로 했다.

리액트의 ㄹ도 몰랐던 내가, 개발을 맡게 됐다.

그런데, 시작한 지 2주 만에 그 선임이 타 부서로 발령이 나버렸다.

 

1인 프로젝트의 시작

입사한 지 3개월 된 신입이 사내 휴가 신청 시스템 전체를 1인 프로젝트로 맡게 된 것이다. 나는 리액트를 구글링하고, 자바와 JPA도 구글링해서 학습하며 프론트와 백을 동시에 진행했다. 당연히 쉽지 않았다.

 

나를 괴롭힌 현실들:

  1. 함께 고민해줄 개발자가 없었다.
    리액트를 할 줄 아는 사람이 나밖에 없었다. 막혔을 때 물어볼 곳이 없었다.
  2. 업무 협업의 어려움
    휴가 정책, 신청 프로세스를 파악하려면 다른 부서와 직접 논의해야 했다. 그 소통 과정 자체가 또 하나의 장벽이었다.
  3. 일정 조율과 진행 상황 보고
    상사에게 일정과 현황을 보고해야 했지만, 나조차도 전체 흐름을 장악하기 어려웠다.
  4. 프론트 배포..? 그게 뭐지?
    서버 배포 경험도, 프론트 호스팅 지식도 전무했다. 결국 하나하나 부딪히며 배웠다.
  5. 간헐적인 API 실패와 타임아웃 에러
    APIGateway에서 생기는 타임아웃 이슈는 해결 방법을 찾기 전까지 매일 나를 괴롭혔다.

 

매일 새벽에 눈을 떴다

이런 환경 속에서 자연스럽게 새벽에 눈이 떠졌다. 잠든 사이에도 계속 머릿속은 서버, 에러, 배포 실패 메시지로 가득했다. 누군가 나 대신 해주는 사람은 없었고, 내가 다 해결해야 했다.

 

취업하고 나서..현재 상황을 고등학교 담임쌤께 찡얼거렸더니,, 값진 뼈 때리는 팩트를 보내주셨다.
🙆


 

A가 안 되면 B, 그래도 안 되면 Z까지

개발을 하다 보면 ‘구글링’이 전부인 것처럼 느껴질 때가 있다. 나도 그랬다. A로 안 되면 B, 그래도 안 되면 C... Z까지 다 해봤다. 만약 그래도 안 되면 결국 스택오버플로우에 직접 질문을 남기기도 했다. 이런 과정을 겪으며 느꼈다.
개발자는 인내심과 끈기의 생물이구나.

 

5개월의 혼자 프로젝트, 그리고 발표

당시 나는 약 5개월간 회사의 휴가 신청 시스템을 혼자 개발하게 됐다. 덕분에 상사에게 혼나기도 했고, 사장님 앞에서 직접 진행 상황을 발표하기도 했다. (물론 PPT도 내가 만들었다.)

디자인은... 말 안 해도 알지 않나.
정말 범접할 수 없는 영역이다. 그래도 그렇게 뚝딱뚝딱 만들고 나니, 설령 내가 짠 코드가 스파게티일지라도, 껍데기는 돌아갔고. 그 껍데기는 사내 직원들에게 실제로 배포되었다. 회사에서 사용하는 첫 버전의 휴가 시스템이 그렇게 만들어졌다.

 

그 와중에…디자인은 참말로 어려웠다..(범접할 수 없음)

 

프로젝트를 통해 배운 것들

  1. 사용자 UI/UX를 무조건 고려하자
    다음 액션을 사용자가 예측할 수 있도록 구성하는 것이 핵심이다.
  2. 내 상황을 숨기지 말자
    “막혔어요”라고 말할 수 있어야 해결도 빠르다.
  3. 내가 만든 서비스로 누군가가 편해졌다는 사실은 뿌듯하다
  4. ‘이해했다’고 착각하지 말자
    5분 뒤의 나는 지금의 나와 다르다. 확실히 정리하고 넘어가자.

 

버그 폭탄, 그리고 다시 새벽

오픈과 동시에 날아온 수많은 버그 제보들. 다이렉트 메일, 자리 방문, 상사에게 넘어간 이슈들…

프로젝트를 혼자서 만들었기 때문에 디버깅과 버그 픽스도 전부 내 몫이었다.

내가 짠 코드인데도 디버깅할 땐 “왜 이런 짓을 한 거지?” 싶을 때가 많았다.

그렇게 약 2개월 동안 해당 서비스가 안정화될 수 있도록 모든 걸 쏟아부었다.

그 시간 동안 깨달은 것은 단 하나.

“껍데기만 돌아가면 안 된다. 유지보수가 가능해야 한다.”

 

그래서 나는 노력했다

  1. 문서화
    핵심 로직은 꼭 기록으로 남겼다. (예: 휴가 산정 로직, 월차 부여 스케줄러 등)
  2. 변수명 짓기
    이름은 그 변수의 성격을 담아야 한다.
  3. Swagger로 API 명세서 작성
    나중에 설명 안 해도 될 정도로 깔끔하게 정리했다.
  4. 커밋 메시지에 혼을 담자
    미래의 내가 이해할 수 있도록.

 

그리고 버전 2의 탄생

그 후, 나는 해당 시스템에 직원 근태 관리 기능까지 추가했다. 피그마를 직접 사용해서 UI 설계를 하고, 개선된 버전 2를 배포할 수 있었다. 디자인? 여전히 어렵다. 하지만 전보다는 낫다. 적어도 더는 검정 배경 + 파란 글씨는 아니다.

 

22살, 새로운 부서에서의 시작

새해가 밝자 다른 부서의 팀장님이 “그 친구 데려오자” 해서 부서를 이동하게 됐다.
이전에는 1인 개발이 많았다면, 여기서는 협업이 전부였다.

  • 팀원들과 역할을 분담하고,
  • 기획자, 디자이너, 인프라팀과 커뮤니케이션하고,
  • 일정 맞추고, 릴리즈 준비하고…

진짜 회사에서의 개발은 이때부터라고 느꼈다.

 

기억에 남는 순간들

  • 내가 만든 코드에 문제가 생겨 핫픽스 배포를 했던 날
  • “내일까지 프로젝트 끝내주세요”라는 말에, 새벽 4시에 퇴근했던 날
  • 현장 설치에 따라가서 실제로 서비스가 설치되는 걸 처음 본 날
  • 선임 개발자가 나에게 기술적인 질문을 하고, 내가 대답해줬던 뿌듯한 날

 

3년의 시간, 그리고 지금

함께했던 동료들이 하나둘 퇴사하면서, 슬픔과 동시에 업무 부담도 따라왔다.

하지만 그 과정 속에서 나는 진짜 실력과 마주할 수 있었다.

23살인 지금도 나는 부족하다. 같은 실수를 반복한 적도 있고, 앞으로도 고칠 것, 배울 것은 끝도 없다.

하지만 분명한 건 하나다.

이 길을 걷는 동안 나를 도와준 사람들, 함께한 동료들, 그리고 날 믿어준 상사들에게 진심으로 감사하다.

앞으로도 그렇게 살아가고 싶다!

 

728x90
반응형