안녕하세요. 저는 고초대졸닷컴이라는 생산/기능직을 위한 채용 플랫폼을 서비스하고 있는 디플에이치알에서 백엔드를 맡고 있는 김영찬이라고 합니다. 반갑습니다.
오늘 저는 비전공자였던 제가 어떻게하다 개발자가 됐는지에 대한 커리어 전환 경험담과 약소하게나마 제가 실무를 하면서 겪었던 일들에 대해서 얘기해보려합니다.
우선 목차를 먼저 살펴보면 크게 2가지 주제에 대해 이렇게 나눠봤습니다.
여러분들은 생산/기능직하면 어떤게 떠오르시나요?
그래서 검색을 해봤습니다. 대부분의 사진이 작업복을 입고 안전모를 쓰고 공장에서 일하는 모습들이네요.
저 또한 출근하면 플라이어 들고 실험 촉매 교체하고 컴퓨터 앞에 앉아서 엔진 다이노 조작하고 그리고 또 플라이어 들고 촉매 교체하고 컴퓨터 앞에 앉아있고 또 플라이어 들고..
저는 하다하다 플라이어가 제 손인줄 알았어요.
이걸 매일 반복하니까 이러려고 과탑도 하고 자격증도 5개나 따고 한게 아닌데 싶더라구요?
그래서 퇴사했습니다.
퇴사를 고민하면서 이제 뭘 해야되지 생각하다가 2가지 결론이 나왔어요. 첫 번째는 재미를 느끼는 일을 하자, 두 번째는 노력에 대한 결과가 있는 일을 하자였어요.
저는 중학생 때 비쥬얼베이직을 사용해서 mp3 파일 다운로드, 노래 가사 검색, 노래 재생 등의 기능이 있는 프로그램 등을 만들었던 적이 있는데 이 때의 기억이 너무 인상적이었어서 개발자가 되기로 했습니다.
그래서 다시 백수가 된 저는 개발자라는 직업에 완전히 몰입해보자 생각하고 방향을 찾던 중에 이런 로드맵을 찾았습니다.
익숙한 로드맵일 수도 있는데 이 로드맵의 맨 위에서부터 차근차근 찾아보며 블로그에 정리도 하고 공부했는데 이걸 1년만에 다시 보니까 꽤 많이 해온거 같네요 하하
이거 외에도 인강, 책, 사이버교육, 알고리즘 문제 등을 통해 모른다 싶은건 다 공부했습니다.
이걸 물론 저 혼자만의 의지로 한건 아니었습니다.
퇴사 후 개발자로의 전환을 선언한 고초대졸닷컴 유저였던 저에게 앞서 발표하신 민섭님과 대표님이 회사로 와서 준비하지 않겠냐고 먼저 물어봐주셨고
저는 그렇게 5개월 간의 준비 후 인턴을 거쳐 정직원으로 디플에이치알의 백엔드 개발자가 되었습니다.
백엔드 개발자로서의 8개월동안
멀티모듈로 B2B, 백오피스의 API 서버를 만들었고 기존 B2C 서비스의 익스프레스로 된 API 서버를 스프링으로 마이그레이션 했습니다.
그리고 무중단 CI/CD를 구축하고 EC2로 되어있던 서버를 도커로 말아서 ECS로 올리는 등 어엿한 한 명의 백엔드 개발자가 되기 위해서 열심히 노력해왔고 현재 진행형입니다.
이제 짧은 경력이지만 백엔드 개발자로서 실무를 하며 얻은 노하우에 대해 작게나마 얘기해보려합니다.
먼저 얘기할 주제는 로깅과 모니터링입니다.
저희 서비스에선 총 3가지를 사용하고 있습니다.
첫번째는 어플리케이션에서 500에러가 발생했다면 스프링의 AOP라는 기술을 통해 웹훅에 요청을 보내 슬랙으로 알람이 가게끔 했고
두번째론 저희 서비스가 현재 aws의 여러 서비스를 사용하고 있어서 모든 지표나 로그가 cloudwatch로 수집되고 있고 설정 해놓은 값이 넘어가면 lambda를 통해 슬랙으로 알람이 가게끔 했습니다.
마지막으로 Elastic Search + Logstash + Kibana라는 ELK스택을 직접 구축하고 Elastic APM(application performance management)을 사용해 컴퓨팅리소스, 트랜잭션, jvm 등을 로깅하고 시각화하고 있습니다.
백엔드 개발자는 고가용성의 서버를 만드는 것도 중요하지만 혹시라도 발생할 수 있는 장애에 대한 빠른 트러블 슈팅 또한 중요하다고 생각하기 때문에
이렇게 여러가지 로깅과 모니터링을 만들어놓았습니다.
다음으로 얘기해볼건 BDD와 TDD에 관해서 입니다.
들어보신 분도 계실 것 같은데 BDD와 TDD는 서로 상관관계를 갖고 있습니다.
BDD는 유저 액션에 대한 시나리오를 토대로 코드를 작성하는 것으로써 여기서 코드를 작성하는 과정을 테스트 기반으로 하는 것이 바로 TDD입니다.
이 개발방법론에 관해선 얘기가 많은데 저는 TDD를 지키는게 좋다고 생각하지만 TDD를 할 수 없다면 하지 않아도 상관없다고 생각합니다.
대신 어떤 방식을 선택하든 테스트 케이스는 만드는게 좋다고 생각합니다.
저희 서비스에는 약 1000개의 테스트가 있는데 로직이 수정되면 테스트 코드를 수정해줘야되는 번거로움이 있었지만 테스트 코드 덕분에 사이드 이펙트를 잡은적이 훨씬 많았습니다!
그래서 저는 테스트 코드는 꼭 필요하다고 생각합니다.
제가 준비한 발표는 여기까지고 저를 한 줄로 요약하자면 ‘꾸준히 성장하는 개발자’라고 요약하고 싶었습니다.
마치기 전에 질문 받고 마치도록 하겠습니다.