부트캠프

개발을 전혀 모르던 상태에서 부트캠프에 들어갔다.

3개월 만에 커리어 전환이 된다고 했다.
실제로 3개월 만에 취업했다.
지금도 비전공이면서 개발자 되고 싶다는 주위 사람들에게 부트캠프를 추천한다.

하지만 부트캠프를 나오면 뭔가 대단한 개발자가 될 거라는 생각은 하지 않았다.
인생에 페스트 트랙은 없다고 믿는다.
세상 그 어떤 분야도 3개월 배우고 쌉고수가 될 순 없다.

부트캠프를 통해 개발자 트랙의 궤도에 겨우겨우 첫 진입을 할 수 있을 뿐이다.
결국 자기 하기 나름.

늦게 비전공자로 새로운 분야에 입문했다는 것이 내가 기억해야 할 냉정한 현실이었고,
그에 맞는 대가를 치러야 한다고 생각했다.
바닥에서 3~4년은 열심히 구르자고 다짐하며 부트캠프에 들어갔다.

40명가량의 동기 중 가장 잘하는 사람이 되는 건 어렵겠지만,
가장 열심히는 할 수 있겠다고 생각했고, 딱 한 가지 결심을 했다.

"문 열고 들어가고, 문 닫고 나오자"

결심을 지키기 위해 부트캠프 근처 고시원을 잡고 아침 7시쯤 출근해서 12~1시쯤에 퇴근하는 생활을 했다. (못 지킨 날도 있다 당근.)

인턴 시작

2개월 동안 열심히 배웠고, 3개월 차에 중고명품 플랫폼에서 인턴을 시작했다.
사수를 통해 많이 배울 것을 기대하고 갔는데 사수는커녕 개발팀이 없던 회사였다.
외부 솔루션 업체를 통해 운영하던 서비스를 탈피하여 자체 서비스를 (제로 베이스에서) 만들어야 하는 상황.
당연히 한 달 동안 저걸 다 할 순 없었고,
한 달 치의 적정 분량을 정해 결국 뭔가를 개발해내긴 했다.
인턴이 끝나갈 때쯤 같이 인턴 한 프론트엔드 1명, 백엔드 2명(나 포함) 전원이 입사 제의를 받았다.

3개월 차 주니어들이 모여서 사수 없이 뭔가를 만들어 낼 수 있을까? 이게 내 커리어에 도움이 될까?

당시 가장 심각하게 하던 고민이었다.
심지어 저 고민은 입사 후 반년 넘게 지속했었다.
힘들 때마다 "과연 좋은 선택이었는가" 질문이 내 마음속에 불쑥 찾아들었다.

여하튼 입사를 결정한 이유는 다음과 같았다.

• 사수는 없지만, 마음이 잘 맞는, 막혔을 때 머리를 맞대고 고민할 동기들이 있었다.
  좋은 회사 가도 못된 사람과 같이 일하면 지옥일 텐데, 적어도 여기는 그렇진 않음이 보장돼있었다.
• 기존 레거시가 없고, 서비스 기획, 설계, 개발, 배포, 운영까지 다 해야 하는 상황인데, 이게 나름 귀한 경험일 것 같았다. (실제로도 그랬다)
• 지금 실력으로는 어차피 좋은 곳에 입사 못 한다(는 현실적인 자각).
• 좋은 사수가 있는 곳에 갈 수 있다는 보장이 없다.
• 빨리 취업하고 싶다.

입사

많은 우여곡절이 있었다. 정말 많은 삽질을 했다.
출퇴근 길에 인강을 놓지 않았고, 주말도 거르지 않고 공부 또 공부했다.
개발도 어렵지만, 백 끝백엔드 개발자로 제일 부담됐던 것은 배포와 운영이었다.
EC2, RDS 하나 띄어본 게 고작이었는데, 배포와 운영까지 할 생각을 하니 아찔했다.
긴 기간을 잡고 나는 AWS, 다른 백 백엔드 동기는 docker를 각자 공부했다

스토리가 많아 일일이 적기엔 너무 길고
결론만 얘기하면 입사일 기점으로 약 3~4개월, 6~7개월 두 시점에 각각 앱을 론칭했다.
3개월 차엔 판매 대행 서비스, 그 후엔 쇼핑몰을 론칭했다.
내가 한 일들을 대략 적어보면 다음과 같다.

• 판매 대행 신청 앱, 쇼핑 앱 개발.
• 기존에 사용하던 구글폼과 쇼핑몰 솔루션 업체를 벗어나 자체 서비스를 개발하는 프로젝트 초기 단계에 합류
• 서비스 설계, 개발, 운영에 주도적으로 참여.
• DB 모델링
• 기존에 사용하던 쇼핑몰 솔루션 data migration 작업
• 회원가입, 로그인 시스템 구현
• 카카오 알림톡, SMS 발송 , 슬랙 메시지 자동화 구현(celery를 이용한 비동기 작업)
• celery-beat를 이용한 cron job 구현.
• 포인트 시스템(포인트 적립, 사용, 소멸) 구현.
• bootpay를 통한 pg사 결제 모듈 연동, 결제 검증, 취소 구현.
• django admin 커스텀을 통한 판매 대행, 쇼핑몰 어드민 페이지 구현.
• 어드민 기능: 회원 관리, 상품 관리, 상품 상태 변경, 상품 사진 업로드,
  쇼핑몰 메인 페이지에 띄울 팝업 설정 기능, 카카오 알림톡 발송, 결제 취소, 주문 상태 변경 등.
• 쇼핑몰 기능 관련 API 개발(상품 리스트, 상품 상세, 필터, 정렬 등)
• selenium을 활용하여 타 사이트 상품 모니터링 시스템 구현.
• 리뷰 시스템 개발(CRUD)
• CloudFront, Lambda@Edeg를 통한 On-Demand 이미지 리사이징 기능 구현
• AWS 서비스를 활용한 배포(ELB, EC2, ASG, RDS, Route53, S3,
  Elastic Beanstalk, API Gateway, Lambda, Code Pipeline, Cloudwatch, WAF)

느낀 점

1. 일정 관리의 어려움

거의 매주 대표님 + PO + 개발자 3명이 스프린트 회의를 했는데, 제일 곤란했던 질문은 이런 식이었다.
"A 기능 언제까지 개발되나요?"
"이번 스프린트 기간을 언제 까지로 하면 될까요?"

솔직히 저런 질문을 들을 때마다 든 생각은 이거였다.
"제가 그걸 할 수 있을까요?"
"할 수 있는지 먼저 물어보는 게 예의 아닌가요"

할 수 있다는 확신이 없는 상황에서
기한을 말해야 하고, 사수도, 개발 팀장도 없으니 쉴드 쳐줄 사람도 없고, 정말 정말 난감하고 어려웠다.

개발자로 돈은 받고 있으니 뭐라도 말은 해야 하고. 진땀을 많이 뺐다.

나중에 가서 일정 조율 방법을 나름 터득했는데, 대략 이런 식이다.
1) 정확한 기간은 아직 잘은 모르겠고, 해보면서 각을 재봐야 할 것 같다.
2) 일단은 기간을 ~ 정도로 잡고, 중간중간에 특이사항이 생길 때마다 계속 공유를 드리며 유동적으로 일정을 정하겠다.

대략적인 기간을 잡아 놓고 짧은 미팅과 공유를 통해 일정을 유동적으로 조절하는 방법.
나중엔 이 방법으로 일정 조절이 좀 더 매끄러워졌으니, 나름 이 부분에서도 성장했다고 말할 수 있을 것 같다.

2. 배포, 운영의 어려움

배포, 운영, 모니터링 쉽지 않았다.
Elastic Beanstalk을 쓰는데,
초반에는 뭘 잘 몰라서 코드 배포할 때 약 1분 정도 downtime이 발생했다.
이것 때문에 스트레스받아 죽을 뻔했다.
내 클릭 한 번으로 서비스 샷다가 내려가다니.
차 몰다가 교통사고 낸 마음이 이런 마음일까.

에러는 나는데 어디서 나는지를 몰랐다.
에러 모니터링 구축해야 되는지도 몰랐고,
뒤늦게 필요성을 느껴 cloudwatch, sentry 등을 도입해서 사용했다.

CICD, 에러 로그 등 서비스 운영에 필수적인 것들이 준비된 채로 런칭을 했어야 했는데,
저런 걸 해야 한다는 것 자체를 몰랐다.
그래서 일이 터지고 나서야 필요에 의해 필수적인 것들을 덧붙였다.
결과적으로는 필수적인 것들을 다 구축했지만,
여기에 오기까지 많은 실패들이 있었다.
그래도 그런 실패들이 필요성을 느끼게 해 줬고, 필요한 것들은 구축했으니, 일단 됐다 치자.

3. make it work, make it right, make it fast.

extreme programming 창시자 Kent Beck이 한 말이다.
한국말로 하면,

일단 돌아가게 해라.
그다음엔 버그 수정하고,
마지막으로 더 효율적으로, 빨리 돌아가는 코드를 만들어라.

나의 지난 1년을 make it work를 배운 해로 정의할 수 있을 것 같다.
초기 스타트업 특성상 "빨리"가 제일 중요했다.
대표님에게 코드 퀄리티나 효율은 중요하지 않다.
우리 팀도 make it work에 집중했다.
사실 그럴 수밖에 없던 것이 make it work만으로도 진땀을 빼는 주니어들이 뭉쳤기 때문.
make it right이나 make it fast는 우리가 볼 수 있는 시야에 있지도 않았다.

아직도 갈길이 한참 먼 주니어지만 이제야 make it right, make it fast에 대한 사고를 하기 시작했다. 내가 만든 코드지만 리펙토링 할 엄두가 안 나는, 그런 머쓱한 상황을 경험하면서 코드 퀄리티의 중요성을 느끼고 있다.

처음엔 "내가 이 기능을 구현할 수 있을까?"에 대한 자기 확신이 없었는데,
이제는 "어떻게든 하면 굴러는 간다"는 확신은 있다.
make it right, make it fast의 세계를 향해 나아가자.

4. 나중에 고치면 cost가 더 크다.

일단 굴러가게만 해놓은 상태로 배포하고, 나중 가서 고치려 하면 cost가 훨씬 더 큰 경우가 많더라.
특히 DB 스키마 바꿔야 하는 상황은 정말 스트레스ful.
아무리 머리를 굴려봐도 무중단 배포가 불가능해 보이는 상황도 생긴다.
처음부터 완벽히 만드는 건 당연히 어렵고 기획이 다 안 나와서 불가능할 때도 많다.
내 기준 best는 기획이 완벽하게 짜여있고, 기획에 맞는 큰 밑그림을 먼저 그리고 개발을 시작하는 것.
하지만 이 또한 이상적인 말이다. 개발하다가 개발자가 기획의 허점을 발견해 기획이 바뀌는 경우도 많더라.

5. 필요가 스승이다.

최근 들어 가장 꽂혀있는 문구다.
필요에 의한 공부가 가장 잘된다.
사수 없는 척박한 환경에서 시작했지만, 덕분에 많은 성장을 한 것 같다.
필요에 의한 공부를 엄청나게 했다.
덕분에 AWS 공부도 열심히 했고 SAA자격증도 땄다.
똥줄 탈 때가 가장 성장할 수 있는 때다.
앞으로도 똥줄 타는 상황을 피하지 않고 온 몸으로 받아내야겠다.

6. 주니어라면 팀에서 가장 뒤떨어진 이가 돼라.

여우의 머리가 되기보다는 사자의 꼬리가 되어라! (-Tractate Avot)

주변을 당신보다 뛰어낸 개발자들로 채워라.
당신이 가장 뒤떨어진 멤버가 되며, 그 안에서 더 성장할 여지가 있는 팀을 찾아라.

프로그래머의 길 멘토에게 묻다에 나오는 내용으로,

이직을 결심하게 한 문구다.

프레임워크를 다루는 기술은 udemy를 통해 배울 수 있지만,
뛰어난 개발자들이 어떻게 일하는지,
어떻게 문제를 정의하는지,
어떻게 문제를 풀어가는지,
어떻게 공부하는지 등은 그 무리 안에 있지 않고는 배우기가 어렵다.

이런 생각 끝에 이직을 결심했고 21년 6월 말부터 새로운 회사로 출근한다.

7. 사수에 대한 막연한 환상을 버릴 것.

첫 회사에서 사수 없이 일하다 보니 사수에 대한 막연한 환상과 갈망이 엄청 컸다.
우연히 페이스북에서 Baekjun Lim님이 쓴 아래의 글을 보고 그런 환상을 내려놓았다.
결국은 내가 제일 중요하다.
의존하려는 마음을 버리고 두 발로 우뚝 서자.

한국에 와서 보니 소프트웨어 개발자 중 선배를 갈구하는 사람이 많아. 엄청. 내 눈엔 그래.
막히는 일이 있거나 기술적 의사 결정을 내려야 할 때, 응 그건 이렇게 하면 되는 거임, 멋지게 조언을 해주는 사람이 있으면 얼마나 좋을까. 요거거든.
꿈깨셔. 그런 선배는 없어.
혹시 마음에 쏙 드는 선배와 일하고 있다면 복권당첨 수준의 예외적 경우. 어쨌든 복권에 당첨되는 사람은 있으니까.
길이 막히면 너님이 뚫는 거고, 결정이 필요하면 너님이 내리는 거야. 결과에 대한 책임은 온전히 너님의 몫이고.
그러기엔 너님이 너무 어리고 연약한 주니어님? 셧업. 세상 모두가 마찬가지야. 다들 막힌 길을 뚫어 처음 가는 길을 만들고, 확신없이 판단을 내려. 너님만 그러는 게 아냐.
뼛속까지 주체적이고 독립적인 프로페셔널들이 모여 협력해야 강한 팀이 되는 거지. 선배, 후배, 멘토, 멘티... 이런 거 연연하는 사람은...
그러니 선배나 좋은 팀을 갈구하지 마셔. 어떻게 내 두 발로 서서 걸을 것인가, 를 고민해야지. 너님이 그렇게 걷기 시작하면, 너님이 있는 곳이 좋은 팀이 되는 거야.
좋은 팀은... 찾아 들어가는 게 아니라, 너님이 만드는 거라고. 🙂

8. 뿌듯함

"척박한 환경에서 열심히 삽질한 것 같고 나름 잘 해낸 것 같다.
주변에서 도와주면 잘 성장할 것 같다"

면접에서 들은 피드백이었는데, 큰 위로를 받았다.
약 1년 간 막막함, 좌절감 속에서 묵묵히 삽질한 그 시간들을 누군가가 알아봐 줬다는 것 자체가 너무 감사했다. 너무 고마워서 면접에서 떨어져도 좋았다. (다행히 붙었다.)

9. 동료의 소중함

사수는 없었지만 좋은 동기들이 있어서 해낼 수 있었다.
고만고만한 놈들끼리 모였지만 서로 머리를 맞대며 고민할 때 문제가 해결됨을 여러 번 경험했다.
내가 처한 문제를 말로 설명하는 것 자체로 해답을 얻은 경우도 정말 많다.
소통하기 어려운 사수보다 차라리 말 잘 통하는 동기가 더 낫지 싶다.

난 문제를 말로 풀어가는 걸 좋아한다.
앞으로도 치열하게 토론하고 페어 프로그래밍할 수 있는 동료를 계속 만나고 싶다.