신입 백엔드개발자 한달 생활기

얼마 전 스타트업에 백엔드개발자로 취업하게 됐다. 거의 한 달이 되어가는 시점에서 있었던 일과 바뀌고 싶은 점, 백엔드개발자를 준비하는 분들에게 어떤 걸 준비하면 좋을지 적어보려고한다.

새로 배우는 언어, 프레임워크를 사용해하는 상황에 어려운점도 많았지만 조금씩 적응되고 있다.

지금도 매우 부족한 상태지만 한달간의 생활기를 적어보려 한다.

업무

주 단위 릴리즈로 다음 주에 진행할 feature나 변경사항들을 수립하여 진행한다. 그래서 1주차에 개발한 부분을 2주 차에 배포하는 형식으로 진행되어 반복된다.

난 업무 방식/도메인이 부족해서 리더분이 일정추산을 해주시고, 가벼운 티켓들을 하나씩 처리하고 있다. 예를 들어 가벼운 유지보수(파라미터 추가, 템플릿 변경 등)와 비즈니스 변경사항에 필요한 개발을 하고 있다.

---

질문

처음 들어가면 궁금한 게 많았다. 1부터 100까지 다 궁금한데, 분명 위키에 있음에도 불구하고 세부적인 부분이 궁금한점이 많았다. 왜냐 실무에서는 어떤 식으로 일하는지도 잘 모르고, 팀의 스타일이 어떤지 모르니까.

예를 들어 git 브랜치전략은 어떤식인지? 어디서 feature 브랜치를 따야 하는지? 데이터베이스 주소가 어딘지? 머지는 어느 시점에 하는지? 이런식으로 많이 물어봤던 것 같다.

온라인이라서 질문을 계속드리기 미안했다. 온라인으로 소통을하다보니 사수님과의 DM 내용은 거의 아래와 같았다.

1. OO님 이거 ~~이렇게 하려는데, ~~이렇게 시도했는데, 잘 안되서 어떻게 하면 좋을까요?
2. ~~이렇게하시면 됩니다.
3. 감사합니다

이 채팅의 반복이었다ㅋㅋ 사수님께 굉장히 감사하지만, 너무 미안해서 질문드리기가 어려웠다. 또 굉장히 바쁘시다. 그래서 질문 하기 전에 다 찾아보고, 모든 케이스를 해본 후 조사한 뒤에 질문하려고 노력했다.

그래서 질문할 때 몇 가지 준비하여 질문했다.

1. 내가 왜 질문을 하는지
2. 어떤 시도를 했는지, 어디까지 알아봤는지
3. 가능하면 생각까지 함께

왜 질문을 하는지

우아한테크코스에서 모 크루가 알려준 내용이다. 질문할 때, 왜 이 질문을 하는지 이야기해주면 좋다는 내용이었다.

만약 A문제를 해결하려다, A를 해결하기 위해 B라는 작업이 필요하여 생각되어, B에 작업을 착수했다. 그런데 B에서 이슈가 생겼다. 그럼 B에 대해 질문 할 것이다.
근데 A를 해결하기 위해 B라는 작업이 필요하여 생각되어 이 생각부터 잘못된 방향일 수 잇다.

예를 들어서 A라는 메서드를 테스트 하려고 하는데, 테스트가 어려우면 Mocking을 하면 된다고 들어서 mock 프레임워크인 mockito를 사용했다. 그런데 mockito를 사용하다 보니 이슈가 있어서 질문한다.

질문을 받은사람은 'mockito ~~이런 부분 이슈 어떻게 해결하나요?'의 답변만 해줄 것이다. 해당상황에서 모킹을 하는 게 올바른 길인지는 모르는 거다. 오히려 테스트하기 쉬운환경을 만드는 게 더 빠른 길이 아니었을까 싶다.

이래서 '왜 질문하는지'도 같이 첨언하면 더 좋은 답변을 받을 수 있을 것 같다.

어떤 시도를 했는지, 어디까지 알아봤는지

질문하기의 예의라고 생각했다. 질문을 받게 되면 그분에게 인트럽트가 걸리는 점을 생각했다.

질문하기 전에 충분히 고민해본 점을 보여드리려고 했다. 슬랙에 찾아보고, WIKI에서 찾아보고, Github 커밋내역 추적도 해보고 관련 지식을 얻어갔다. 거기서도 안 보이면 질문을 했다. 너무 당연하게 필요한 건 바로 물어보는 게 좋은 것 같다. (데이터베이스 비밀번호라던지..)

가능하면 생각까지 함께

---

실수

너무 많은 실수를 했다. 데이터를 잘못 건드려서 다른 팀에서 담당하는 데이터 불일치로 이슈를 만들었다. 또 단순 컬럼을 추가해야 하는 경우여서 컬럼을 추가했는데, 이미 있는 컬럼이었다.

실수를 줄일 방법 중 중요한 건 이슈, 에픽을 꼼꼼하게 읽는 거라고 생각됐다. 또 모호한 건 내 기준에서 판단하지 않고, 이슈 보고자분에게 물어보는 게 좋다고 생각한다.

또 이슈 보고자가 'XX 기능 추가해주세요. A에 메서드를 추가하면 될 것 같아요' 만약 이런 식으로 이슈를 받았을 때 참고는 하되 우리의 시스템을 먼저 살펴보고 이슈를 진행해야한다.

물론 이슈보고자분이 힌트를 주셔서 그렇게 A에 메서드를 추가할 수 있다. 하지만 그대로 따라 해서 새로운 이슈나 장애가 발생하면 순전히 내 탓이다. 그러니 문제를 잘 파악하고, 시스템과 잘 비교하여 보고자와 커뮤니케이션을 통해서 풀어나가는 게 좋다고 생각한다.

첫 배포 + 첫 장애 + 첫 롤백 + 첫 핫픽스

첫 배포를 했다. 너무 떨렸다. 코드디플로이가 다 해주지만ㅎㅎㅎ

배포가 끝나는 시점에 로그를 보는데, 500 에러가 산처럼 올라갔다. 큰일 났다 사수님께 바로 말씀드렸지만, 이미 장애 채널에는 알람이 와 있었다.

리더님의 판단은 롤백이었다. 멘붕 그 자체. 로그를 보니 어제 급하게 수정한 내 코드에서 일어났다. 2차 멘붕 루비에서는 메서드에 ?나 !가 들어간다. boolean 리턴을 암시하는 메서드에는 ?가 들어가곤하는데, 메서드에 ?를 안써서 장애가 났다. 3차 멘붕

답 없다. 메신저에서 알람만오면 내 실수때문인가? 라는 생각이 들었다. 불안 그자체

바로 핫픽스를 올리고 재배포했고, 배포가 완료됐을 때 조마조마하는 상태가 떠오른다. 한편 드는 생각은 '내 서비스를 사용하는 사용자에게 불편함을 줘서 미안하다'라는 생각이 든다. 상품을 구매하려는 사용자가 갑자기 500 에러를 맛보다니... 여러 자체 멘붕이 왔다.

어떻게 바뀔 수 있을까

컴파일언어에서는 일어날 수 없는 일이라고 생각한다. IDE에서 체크되고, 컴파일에러를 뱉어서 이미 CI에서 잡혔을 테니까. 정말 자바가 그리운 시점이다.

하지만 우리 시스템은 그렇지 않다. 언어를 바꿀 수 없다. 그럴수록 많은 케이스에 대해 테스트로 충분히 검증해봐야 한다. 또 급한 상황일 수록 더 팀원분들에게 코드리뷰요청을 하는 게 좋겠다는 생각이다. 장애와 팀원 인터럽트를 비교했을 땐 당연히 팀원분을 급하게 호출하는게 장애보다 나으니..

아무튼 그렇다. 실수를 줄일 수 있는 몇 가지 장치를 생각해봤다.

1. 충분한 검증
2. 코드리뷰
3. 테스트코드 작성

이전에 테스트코드를 작성할때는 '시켜서 했다' 맞았던 것 같다. 요즘은 정말 필요하다고 몸으로 느낀다. 요즘 공부의 우선순위는 Ruby, Rails의 테스트프레임워크 학습을 1순위로 두고 있다.

---

미래의 신입 개발자분들에게

스타트업이라서 그런지 개발자가 빠르게 투입된다. 내가 작성하는 코드가 빠르게 프로덕션에 올라갈 수 있고, 더 개발 맛이 난다.

그럴수록 '더 기본기는 튼튼히 준비해오고 와야 하지 않을까?'라는 생각이다.

느낀건 회사에서 사용하는 언어, 프레임워크, Git, Github, 데이터베이스는 정말 기본이라고 생각한다. (난 언어와 프레임워크를 잘 모른 상태로 들어가서 너무 힘들다)

대기업같이 교육이 갖춰졌거나, 파일럿프로젝트가 준비, 여유가 있는 회사들은 바로 투입되지 않으니 부담은 덜 할 것 같다.(물론 교육받는 그들도 굉장히 힘들겠지만)

결론

아무튼..! 정말 바쁘게 한 달이 지났다.

주변사람들에게 실수한 이야기를 말하면 '신입이면 그럴 수 있지'라는 조언을 해준다. 이런 말로 안주하고 싶진 않다. 같은 실수를 반복하지 않으려 노력해야겠다.

오히려 '똥은 신입이 싸고, 치우는 건 팀원이지' 이라는 따끔한 말이 날 더 집중하게 만드는 것 같다.

더 꾸준히 학습하고 적응해서 빨리 팀에게 도움이 되고 싶다.

끗