한 친구의 DM으로 시작된 여정

인프런에 관심이 많은 친구 한명이 동욱(향로)님을 뵙고 여러가지 질문을 하고, 인프런 방문을 하고 싶어서 별 기대없이 DM을 날렸던 것이 동욱님께서 답장을 주시면서 관심있는 친구들 3명이 더 모여 총 4명이서 대전에서 서울에 가게 되었습니다.

평소에 유튜브 개발바닥, EO 같은 채널을 관심있게 보는 우리에게는 동욱님은 거의 연예인과 같은 존재였는데요, 그냥 저희가 동욱님과 만나서 얘기를 나누고싶다고 무작정 들이밀었는데, 동욱님께서 너무 흔쾌히 받아주시고 따뜻하게 정말 성실히 대답을 해주신 것이 너무나도 감동적이었습니다.

원래는 한시간 계획되어있던 약속이 얘기를 나누다보니 두시간이 넘게 되어서 근무시간인데 동욱님께 방해가 되지 않았을까 걱정했지만 오히려 저희에게 감사하다고 말씀하시는 동욱님을 보면서 한번 더 감탄을 하지 않을 수 없었습니다.

정말로 실제로 봤을 때는 저희가 맨날 유튜브로 인터넷으로만 보던 분이 눈앞에서 움직이니까 정말 연예인을 본 듯한 느낌이었습니다.

이 여운이 가시기 전에 우리가 나눴던 대화들을 조금 공유해보려고 합니다.

급하게 결성되었고 질문들도 엄청 짜임새있게 된게 아니라 정말 개개인이 궁금했던 것에 대해서 물어본거라 다른 분들에게는 큰 도움이 되지 않을 수 있습니다.
저희는 총 4명으로 구성되었고, 3명은 백엔드를 희망하고있고 1명은 프론트를 희망하고 있습니다.
해당 글은 인터뷰 내용을 기억나는 대로 재구성한 것이라 일부 틀리거나 다른 내용이 들어있을 수 있습니다!

1. 인프런 사내의 일과는 어떻게 진행되나요?

동욱: 일반 팀원들과 다를 수 있는데 보편적으로 말하면 9시부터 10시 30분까지 출근하고, 7.5시간 (+1.5시간: 점심시간)을 일하게 됩니다. 10시에 출근하면 7시에 퇴근합니다.

10시 출근 기준으로 출근하고 같이 업무 오늘 해야할 것의 리스트를 적고 이거는 필수는 아니에요.

그리고 10씨 30분까지 개인일을 하고, 인프런 개발파트에 20명인데 평일 오후 1시에서 2시에는 자유 질문 시간 자리에 앉아서 질문만 받는 시간을 따로 가져요.

2시부터 6시까지는 면접, 회의, 계속 잡혀있어요 아니면 외부 개발자 미팅을 많이 합니다.

중간중간에 백엔드 개발자 코드를 계속 봐주고있고 프론트 리뷰는 아키텍쳐 설계만 참여해요. 상세하게는 참여하지 않습니다.

그리고 인프런에서는 일주일에 하나씩 주제를 하나 가지고 여러가지 개발 방식으로 개발을 해보고 다 같이 모여서 어떤 방식이 더 나은지 비교를 해보는 시간도 가집니다.

예를 들어 대량의 Input을 React 상태로 받는 예시에서는 상태 관리 도구로 MobX, recoil, redux, context API로 각각 따로 개발을 똑같이 해보고 어느것이 성능이 좋은지 얘기를 해본다고 합니다.

매일매일 하루일과는 다릅니다. 개발, 코드 리뷰, 회의, 면접 이렇게 하루가 지나갑니다.

서경: 그러면 정해진 퇴근시간은 딱히 정해져 있진 않은 거네요? 예전에 듣기로 인프런 최대 장점 중 하나가 일할 수 있을 때 언제든지 일할 수 있는 문화라고 들었는데요 (웃음)

동욱: 없어요. 대표님이나 저는 보통 퇴근시간이 정해져 있지 않습니다.

세콤으로 관리를 하고 있어서 자기 출근 찍고 일하고, 퇴근할 때도 그냥 하고 싶을 때 일 합니다. 주말에 개인 공부하고 싶을 때 회사에 와서 공부하는 사람들도 있습니다.

2. 결제/스트리밍/쿠폰/회원 관리 등에서 서드파티 서비스를 사용하나요? 만약 그렇지 않다면 부서 관계 없이 모두 다뤄볼 기회가 있을까요?

동욱: 동영상 재생은 video.js와 player.js를 쓰고있습니다. 다른 경우에도 대부분 오픈소스 같은 것을 사용합니다. DRM 기술로는 PallyCon을 사용합니다.

인프런 사이트 자체는 순수 Vanilla JS로 되어있어서 쓸수있는 라이브러리는 많이 없습니다.

JavaScript의 경우에 사용할 수 있는 라이브러리는 대부분 React나 , TypeScript에 맞춰져 있기 때문에 이 부분은 인프런이 개선해 나갈점입니다.

모든 팀이 파트별로 나뉘어 있지 않습니다. 즉 블로그, 강의 이런 식으로 분야가 나뉘어 있지 않고 전부 개발 팀, 한 팀에 모여있습니다. 현재는 전체적으로 다뤄볼 수 있고 만약에 파트별로 나뉘면 자신의 파트를 6개월에서 1년에 한번씩은 바꾸어서 진행을 할 예정입니다.

3. 신입 개발자에 대한 수습기간이 있는 걸로 아는데, 수습 기간에는 어떤 걸 하게 될까요? 또 어떤 것을 공부 하라고 조언 해주시나요?

동욱: 신입의 교육에 대한건 계속해서 바뀌고 있는 중이며 신입을 어떻게 관리해야 하는지 계속 고민중입니다. 인프런은 Node를 사용하는 회사이지만, 서경님 같이 신입분이라면 JVM언어와 Spring을 공부하는 것을 추천드립니다.

Node 쪽은 컨텐츠가 상당히 부족합니다. 예를 들어 JDBC Internal-타임아웃의 이해 (Naver D2) 이 글이 2011년도 글인데 자바의 경우 이런 자료들이 굉장히 많고, 지금도 계속 생성중입니다. 그러나 Node 입장에서는 이정도 수준의 칼럼 혹은 정보량은 부족할 뿐더러 한글로 된 것은 거의 없다고 봅니다.

관련한 참고 글 : 자바 공화국

이와 같이 커뮤니티적으로 Java와 Node가 많이 차이가 납니다. 또 다른 예시로 김영한님의 강의를 보면, 게시물 만들어 보기와 같은 수준이 아니라, 원리와 과정에 대해 깊숙히 다루면서 핵심 구조를 파악할 수 있게 됩니다. 그러나 Node 진영의 경우 ORM이 약하기도 하고, 자세한 수준의 강의는 거의 없다시피 한 것도 큰 이유입니다.

인프런에서는 새로오신 분들 께 과제를 냈을 때 데이터베이스 관련 설정을 해온 사람이 한명도 없었습니다. 그러나 Java를 사용하던 이전 직장에 있을 때는 여러 timeout을 비롯한 커넥션 설정들을 해오신 분들이 일부 있으셨습니다. 그런 부분에서도 배우는 지식 또한 차이가 날 수 밖에 없다고 느껴졌습니다.

브라우저에게 있어 상대하는 클라이언트는 단 한 명입니다. 그러나 서버가 감당해야 할 요청은 수천이 될 수도 있고 수만이 될 수도 있습니다. 따라서 그러한 걸 고려한 설계를 해야합니다.

같은 예로 redux를 활용한 React 상태관리도 클라이언트 하나를 위한 것입니다. 상태를 변경하는 주체도 클라이언트 한명이죠. 그러나 백엔드의 경우 사용자가 수백, 수만명일 수 있기 때문에 상태 관리를 해선 안됩니다. 통신, 타임아웃, 인코딩 등 설정할 게 많은데 Node가 JavaScript를 사용하기 때문에 프론트엔드와 백엔드에서 같은 방식을 사용하는 것은 좋은 설계라고 할 수 없습니다.

서경: 그렇다면 JavaScript를 활용하면 프론트엔드와 백엔드를 모두 사용할 수 있다는 점이 오히려 약점으로 작용할 수도 있다는 말씀이시군요?

동욱: 맞습니다. 프론트엔드와 백엔드가 수행하는 역할은 다르기 때문에 명확히 구분해야 합니다. react에서는 16.8버전 이후로는 함수형 컴포넌트를 권장합니다. 따라서 class를 사용하지 않는 경우가 많은데, 백엔드에서는 OOP가 굉장히 중요한 요소입니다. 이 외에도 프론트엔드에서는 사용자 인터렉션으로 이루어지기 때문에 json 리터럴로 사용하는 경우가 많은데, 백엔드를 하시는 분들이 프론트에서 처럼 모든 값을 json 리터럴로 다룬다면 좋지 않은 방식일 수 있습니다.

참고: React Hook 개요 (함수형 컴포넌트)

서경님께서 인프런에 희망해서 Node를 공부한다고 하셨지만 당장 떨어지신다면 갈 곳이 없는 것이 사실입니다. 앞서 말했듯이 Java에는 좋은 자료들이 매우 많이 있으므로 자주 참고해보시면 좋습니다. 꼭 Java가 아니더라도 JVM 환경에 대해 공부하는 걸 추천합니다. TypeScript를 공부하셨다면 Kotlin도 접근하기 좋을 수 있습니다

4. 백엔드 신입 개발자에게 요구하는 역량에 대해서

충환: 스프링 관련 영한님 강의를 들으면서 공부하고 있는데 신입에게 어느 정도의 깊이를 요구하는 지를 잘 모르겠습니다.

동욱: 신입 기대치를 생각해서 어느 정도의 실력을 쌓고 신입 공채에 지원하는 것보다는 인턴, 공채 등에 다 지원하면서 그 과정에서 배우는 것이 더 낫습니다. 영한님 강의를 들으신다고 해도 개인 프로젝트를 진행할 때는 이때 배운 내용들이 어느 정도 필요한지 잘 모를 수 있습니다.

실제 개발을 해보면 다양한 요구사항이 있고 여러 상황을 마주치게 됩니다. 실무 개발을 해본 사람은 알겠지만 많은 경험을 쌓아야 할 수 있는 게 많아지기 때문에 스스로 어느 정도는 돼야 어디에 지원한다는 커트라인을 정하게 되면 그 시기가 점점 늦어지므로 항상 지원하며 도전하는 것이 좋습니다.

5. 위의 질문과 연관해서 스프링의 핵심 원리는 이해했는데 코드레벨까지 알아야하나요?

동욱: 코드 레벨까지 알 필요는 없는데 어떤 흐름으로 동작하는지는 확실하게 알아야 합니다. 또한 프레임워크의 핵심 원리를 아는 것도 중요하지만 좋은 코드를 작성하는게 더욱 중요합니다. 개인적으로는 자바지기 박재성님이 운영하시는 넥스트 스텝의 **클린코드를 위한 TDD, 리팩토링 with Java**를 추천합니다. 좋은 코드를 작성하는 법, 테스트 하기 좋은 코드를 짜는 법 등을 배울 수 있고 현업에서 일하고 있는 실무진들의 코드 리뷰를 받을 수 있기 때문입니다. 개인 프로젝트를 진행하는 것보다 리뷰를 받는 코스에 참여하는게 실력을 늘리기에 좋습니다. (+우아한 테크 코스도 추천합니다.)

6. NEXTSTEP에 대해서

충환: 작년에는 이것 저것 하느라 경황이 없어서 지원을 못했습니다. 올해 4월에 모집이 또 있는데 동욱님은 어떻게 생각하세요?

동욱: 우아한테크코스와 넥스트스텝이 코치분들은 같고 리뷰어분들이 다릅니다. 운영진이 같기 때문에 우아한테크코스 운영진의 양질의 교육을 받을 수 있습니다. 몇몇 스타트업 또는 빅테크 기업(카카오페이, 11번가)에서 신입개발자 교육을 넥스트 스텝에 맡겼었다고 할 정도로 좋은 교육임을 알 수 있습니다.

7. 백엔드 공부 방향에 대한 추천

충환: 자바를 더 깊게 공부할지, 객체지향 및 테스트 주도 개발을 공부할지 고민입니다.

동욱: 충환님의 수준을 정확히 몰라서 답변하기 애매합니다. NEXT STEP의 교육 과정이 위에서 설명한 것 처럼 정말 구성이 좋기 때문에 진행하면서 어떤 부분이 본인에게 더 필요한지 생각해서 공부하면 좋을 것 같습니다.

8. 트래킹 관련 경험에 대해서

서경: 인프런 채용 공고에 있는 백엔드 개발자의 주요 업무를 보면 모니터링 + 쿼리 관련 성능 개선이 주 업무가 될 것 같은데, 현재 제가 인턴을 하고 있는 스타트업 회사의 경우에는 고객층 자체가 특정 전문 직업군에 한정되어 있어 트래픽 자체가 많지 않아 부하에 대한 모니터링 및 성능에 큰 투자를 하지는 않고, 기능 추가 위주로 task를 받습니다. 따라서 모니터링/로그를 추적해서 성능을 개선하는 task 자체는 받지 않고 있는데 이런 경우에는 어떻게 tracking 관련 실무 경험을 쌓아볼 수 있을까요?

동욱: 모니터링을 하지는 않더라고 로그관리는 무조건 할 겁니다. 그것이 파일로 관리되든, aws cloudwatch로 되던간에. 실제 테스트, 배포환경은 파일이나 실시간 스트리밍으로 로그를 수집하는 형태, 플랫폼에 던지는 것을 선택해야 실제 발생하는 에러를 확인할 수 있습니다.

try catch문들을 확인하며 예외처리를 하는 코드를 뜯어보는 것도 좋은 방법입니다. 어떤 곳에서 에러가 생기며 그 에러를 어떻게 처리하는지 확인하면서 실력을 키우는 겁니다. 인턴 과정에서 중요한 것은 업무를 경험해볼 수 있다는 게 아니고, 실력이 뛰어난 다른 누군가의 코드를 많이 볼수있는게 좋은 겁니다. 인턴 경험에서 최대한 다른 사람의 코드를 보면서 배우고, 개인 프로젝트에 적용해 본다면 가장 좋을 것입니다.

예전에 합격했던분들 중 스프링 레거시로 개발하시던 분이 있습니다. 그 분이 하셨던 일들 중 인상 깊었던 건 그 분이 프로젝트를 진행하면서 서버비용을 줄이기 위해 어떤 걸 했었는지 부터 시작해서, 오류가 발생하면 알람을 보내기 위해 어떻게 구축했고, 작은 서비스라도 24시간 동안 무중단 배포하기 위해 어떻게 설계 했는지 등 세세한 히스토리를 모두 개인 블로그에 적어놓으셨는데 이러한 점이 좋은 요소가 되었습니다.

결국 서비스는 실 사용자들에게 어떤 가치를 줄수 있느냐가 중요합니다. 어떤 프레임워크나 라이브러리를 쓰는게 중요한 것은 중요한 것이 아닐지 모릅니다. 따라서 아주 작은 서비스라 할지라도 실제 사용자를 받아보며 좋은 서비스를 제공하기 위해 고민하는 것이 중요하며 좋은 경험이 될 것입니다.

9. RDBMS 인덱스 튜닝 / 쿼리 튜닝 관련 질문

충환: RDBMS 실행계획을 통한 인덱스 튜닝/쿼리 튜닝 관련해 공부에 도움 될만한 혹은 되셨던 자료를 추천해주실 수 있으신가요?

동욱: Real MySQL을 추천합니다. 아키텍쳐, 인덱스, 실행계획, 쿼리최적화 부분이 잘 되어 있습니다.

10. 개인적인 공부 방향에 대해서

서경: 제 공부 방향에 대해서도 피드백을 받고 싶은데요, 현재 제 기술 스택을 간략히 말씀드리자면, ts-express, sequelize, java-spring, docker, aws 정도입니다. 여기에 더해 제가 지금 사적으로 따로 하고 있는 프로젝트에서 devops 포지션을 맡게 되어서 k8s + aws에 관해 추가적으로 공부할 계획이고, 이왕이면 시작한 김에 SAA와 CKA까지 따보고 싶습니다. 회사 업무 관련해서는 회사 안에 레거시 코드가 꽤 많은데, 특히 ts 관련해 문제가 있어 보이는 코드들이 많아(ex: 너무 많은 any) ts를 집중적으로 공부하고 있습니다. 또한 ts를 공부하다 보니 OOP관련해서도 공부할 게 많아 OOP도 추가적으로 공부할 계획인데 이 이후에 무엇을 하면 좋을지, 혹은 이 계획에 대해 피드백 해주실 사항이 있으실까요?

동욱: 지금도 이미 너무 많은거같은데요? (웃음) 사람들이 DevOps 직무에 대해 오해하는 게 많습니다. k8s를 하는것도 나쁘지 않지만, 특정 기술에 매몰되는건 좋지 않습니다. 실무에서는 k8s 없이 배포환경을 구축하는 경우도 많습니다. Docker가 대세이긴 하지만, 여전히 Docker 없이 EC2에 직접 배포를 하고 실행하는 환경도 실무에서는 쉽게 볼 수 있습니다. 현재 상황에서 가장 효율적으로 구축할 수 있는 배포환경이 어떤 것인지가 중요합니다.

AWS 자격증을 따는 건 괜찮습니다. 다만 탈락률이 꽤 되고 돈이 많이 든다는 것은 감안해야 합니다.

서경님이 백엔드를 지향한다고 말씀하셨기 때문에 우선순위는 좋은 백엔드 개발자되는것이 우선순위입니다. OOP, 계층형 아키텍쳐 구축, 좋은 테스트코드, ORM 등의 역량이 우선시 될 것입니다.

타입스크립트 같은 경우에도 TS eslint, prettier를 활용해 여러 값을 계속 넣어 보면서 강제화 하면서 경험을 쌓을 수 있을 겁니다.

OOP에 관한 건 책 오브젝트를 정말 추천합니다. 이 책은 다른 외국의 원서들보다도 좋은 내용을 포함하고 있어요. 이 책을 보면서 내 코드에 넘겨보는 경험이 필요할 것 같습니다.

테스트코드를 어떻게 하면 잘 짤지에 대해 고민하고 공부해 보는 걸 추천합니다. 예를 들면 Mocking test는 거의 의미가 없고 저장소를 이용한 테스트가 중요한데 왜 그런지 알아야 하는 등이 있을 겁니다.

모킹 vs 저장소를 이용한 테스트 : https://github.com/woowacourse/jwp-refactoring/pull/12?fbclid=IwAR22hXT931hlXcIuUwTQ2uo536SIU5NWRyfYAzOvhOcs_FUcrkRA_iZfACw#discussion_r503260073

좋은 테스트 코드를 짜려는 생각이 중요하며 코드 자체를 테스트하기 쉬운 코드로 작성하는 것이 중요합니다. 최근에는 신입 개발자라 하더라도 테스트 코드를 작성할 줄 모른다고 하면 붙기가 쉽지 않습니다.

테스트 코드도 Java의 경우가 좋은 자료들이 많기 때문에 다른 커뮤니티의 것들로 공부하는 걸 추천합니다.

영한님 강의를 예시로 들면 영한님 강의같은 경우는 테이블을 기준으로 설계를 시작하는 게 아닌 도메인부터 설계를 시작합니다. 말씀하신 Sequelize의 경우 테이블에 직접적인 영향이 가기 때문에 직접적인 영향이 가는데, 저장소가 Mongo로 바뀌어도 영향이 가지 않을 정도로 객체 설계부터 시작합니다.

테스트 코드에 대해선 .net 공식 문서 같은 것들을 찾아봐도 좋습니다. 공식 문서에 테스트 코드를 어떻게 짜야 하는지 같은 내용들이 잘 나와있습니다.

좋은 코드를 작성한 후에 말씀하신 DevOps 적인 역량을 키우는 것이 낫습니다. 만약 백엔드적인 역량이 부족한데 k8s를 쓴다고 말하면 ‘어림도 없지’라고 생각할 수밖에 없습니다.

사실 질문을 듣고 조금 놀랐습니다. 앞서 충환님이 질문해주신 건 하나를 얼만큼 공부해야 할지 물어보셨는데, 서경님 같은 경우에는 여러 가지를 어떻게 공부해야 할지 물어 보시더라구요. 같은 학교 같은 학과 같은 학번인데 이렇게 상반되는 질문을 하셨는데, 그 이유에 대해서도 한번 고민해보시면 좋을 것 같습니다.

추가) 영한님의 HTTP 강의는 모든 개발자에게 추천합니다.

https://www.inflearn.com/course/http-웹-네트워크

프론트엔드 개발자, 백엔드 개발자 모두 HTTP에 관한 지식은 필수적입니다. 김영한님 강의에서 개발자에게 필요한 내용을 정말 잘 정리되어 있습니다. 꼭 듣길 추천합니다!

11. Rust와 Web Assembly에 대해서 어떻게 생각하시나요?

동욱: Node가 나온지는 10년이 넘었습니다. 국내에는 2015년에서 2016년까지 Node가 핫하게 언급이 되었고 많은 백엔드 개발자들이 뛰어들었고 본인도 역시 그 중 하나였습니다. 하지만 결국 대세가 되진 못했습니다. 지금 Rust와 Web Assembly가 Node가 2015,16년도에 한창 뜨거웠을 때 받았던 그 느낌과 비슷합니다. 대세가 될지 제가 예측할수는 없을것 같습니다.

동욱님의 경험에서 우러나오는 답변을 들을 수 있었습니다.

12. 학생 스타트업에 대해서 질문

유성: 실제 배포하여 서비스중인 스타트업에서 PM을 맡고있습니다. 아키텍쳐, 기술스택 선정과 CI/CD, 모니터링등 부수적인 것들을 적용하며 과연 올바른 방향으로 가고 있는것인지 , 코드리뷰를 진행하면서도 제대로 되고 있는 것인지 생각이 많이 듭니다. 스타트업은 지속적으로 하고 싶으나 위 고민들 때문에 부스트캠프나 취업도 고려하게 됩니다. 선배 개발자로써의 조언을 듣고 싶습니다.

동욱: 가보진 않은 길이지만 성공한 케이스가 많아 개인적인 의견을 드리겠습니다.

저는 개인적으로 리스크 관리를 하는편입니다. 스타트업에 뜻이 있는 경우 경험이 많은 시니어 개발자는 크게 상관이 없지만 사회초년생일때는 시행착오가 많기 때문에 웬만하면 시리즈 C, B 규모의 회사에 가서 회사가 커지는 걸 보고 창업을 하는 걸 추천합니다.

본인이 창업 후 회사가 엔젤투자 받고 시드받고 A, B를 거치며 투자금 300억 정도를 받으면 시리즈 B급이라 하는데 이는 축구로 치면 2부리그라고 할 수 있습니다.

그 이상인 천억 부터는 1부리그 취급을하는데 이 단계에서 필요한 경험치는 정말 다릅니다.

사용자 트래픽이 늘면 경험이 없어 대응을 못하게 될텐데 이렇게 되면 서비스 매니징으로 배치 될 것이고, 결국 커리어가 생각했던 것과 조금 달라질 수 있습니다. 다만 피엠이나 대표는 본인의 경험치가 되고 커리어가 되기 때문에 괜찮은 편입니다.

또 주니어일수록 좋은 시니어에 경험치를 받아먹는게 정말 중요합니다. 단적으로 1년에게 삽질해서 얻은 경험치를 좋은 시니어 밑에서 두세달만에 배울 수 있기 때문입니다.

유성: 1년 정도는 이대로 진행해 보아도 괜찮을까요?

동욱: 1년정도는 괜찮은데 개발자의 커리어 목표가 있다 그러면 한 번은 커지고 있는 회사에 가서
어떤 변화를 일으키고 있는지, 요구치가 다 다르기 떄문에 그걸 한번 경험해보는 것이 중요합니다.
대표적으로 무중단 배포, 모니터링, 장애대응, 협업 등 이런 것들을 어떻게 하는지 배울 수 있습니다

13. Github Action에 대해서 어떻게 생각하시나요?

유성: 프로젝트 규모가 아무래도 작다보니 Github Action으로 시작했습니다. 사용하다보니 굉장히 좋다고 느꼈는데 현재 시니어 또는 개발자들 사이에선 어떤가요?? 또 Github Action을 한 번 깊에 파보는 것은 어떤가요?

동욱: Github Action은 좋습니다. 실제로 일부 빅테크 기업에서는 CI/CD 모두 Github Action을 사용하기도 합니다. 적은 번거로움과 마켓플레이스에 존재하는 다양한 action들은 강점입니다.

하지만 Github Action으로 jenkins나 다른 기존 CI/CD툴로 가능한 모든 일들을 처리할 수 없기에 사용한다면 Build까지 Github action으로 진행하는 것을 추천드립니다. 또한 당연한 말이지만 깊게 커스텀 하기 위해서는 문법을 공부해야하는 수고로움 역시 존재할 것입니다.

물론 Github Action 자체를 깊게 파보는 것은 좋다고 생각합니다.

14. 개발바닥을 시작한 계기에 대해서

동욱: 그냥 재미있을 것 같아서 시작했습니다. 호돌님과 예전 회사에서 계속 둘이서 얘기를 많이 했었는데 주변에서도 재미있다고 했습니다. 그런데 이런 얘기들을 유튜브로 남겨서 사람들에게 공유를 하면 어떨까 하는 생각을 했습니다.

그리고 우형을 나오게 된다면 커뮤니티적인 장점을 더 이상 누리기 힘드니, 그 전에 마케팅이나 커뮤니티적인 효과를 유튜브에서 이끌어 낼 수 있을까 해서 시작한 계기도 있지만, 제일 큰 계기는 그냥 재미있을 것 같아서 였습니다.

15. 첫 직장에 대한 조언

현수: 저는 프론트엔드 개발자를 희망하고 있는데 제가 인턴을 8개월 정도하면서 느낀건데 엄청나게 제가 맡고있는 프로덕트에 흥미가 없으면 일이 정말 일처럼 느껴지고 그래서 하루가 끝나면 너무너무 힘들더라구요

제가 지금 취준생인데 제가 일단 첫 직장으로 원하는 곳은 흔히 말하는 유니콘기업들입니다. 근데 만약 원하는 유니콘 기업에 입사를 했을 때 제가 원하는 일을 한다는 보장이 없잖아요. 그랬을 때 또 똑같은 피곤함과 보람을 잘 못 느낄 것 같습니다.

그런데 우선은 또 대기업의 복지나 또 돈을 무시못하기 때문에 월급같은 것들도 한번 느껴보고 싶고, 요즘 카카오 개발자다, 배민 개발자다 이런 타이틀도 한번 달아보고 싶기도하지만, 다른 면에선 제가 원하는 가치관을 가지고 프로젝트를 개발하는 곳도 들어가서 집중해서 개발도 한번 해보고 싶기도 한 마음들이 여기저기 떠다닙니다.

동욱님은 유니콘 기업도 가보셨고, 지금은 그거 보다 조금 작은 인프런에서 일도 해보고 계신데 저에게 조언같은 걸 주실 수 있으실까요?

동욱: 첫 직장으로서의 조언을 원하시는 건가요? 앞으로의 커리어에 대한 조언을 원하시는 건가요?

현수: 지금 당장은 첫 직장의 조언을 얻고 싶습니다.

동욱: 커리어가 결국 한 회사에서 멈추는 것은 아니고, 보통 2~3년 사이에 개발자들이 많이 이직합니다.

이직사유는 연봉, 권한 변경, 성장 등의 사유는 많습니다. 공통적으로 하는 이유는 보편적으로 팀으로서의 지식을 떼고, 자신 스스로가 잘하는 사람인지를 확인하고 싶은 이유도 있습니다. 내가 잘하는 것인지 아니면 내가 이 팀에서 같은 일을 많이 해봤기 때문에 잘하는 것처럼 보일 수 있는지 궁금해서 초기화하기 위해서 옮기는 이유가 있습니다. 너무 편안하면 불안한 사람들도 있기 때문입니다.

첫 직장은 당연히 빅 테크가 좋습니다. 당연히 첫 직장은 급여보다는 성장에 초점을 맞추는 것이 중요합니다. 빅테크 기업의 경우는 신입 개발자를 성장시킬 여유가 있을 확률이 높고, 빅 테크 기업에서는 대량의 트래픽을 받기 때문에 그걸 고려한 코드를 본 것 자체가 신입 개발자에게 좋은 경험이 됩니다. 그리고 장애 히스토리, 테스트 코드 등을 보는 것도 도움이 많이 될 것입니다. 자신의 팀이 아니여도 다른 팀에라도 좋은 끌어줄 사람이 있기 때문에 확실히 배울 수 있는 시니어가 존재하기 때문에 배울 기회 자체가 훨씬 많습니다.

그에 비해 스타트업의 경우에는 좋은 시니어를 만나지 못할 확률이 더 높습니다. 현수님이 원하는 프로젝트를 진행하는 곳에 들어가도 좋은 시니어를 만날 수 있다는 확률이 대기업보다는 확실히 적습니다.

반대로 대기업은 기술을 도입하는 데 훨씬 힘들거나 할 수도 있습니다. 새로운 기술을 도입하고 싶어도 해당 팀의 모든 사람을 설득해야 하기 때문에 가능성이 스타트업보다 적습니다. 예를 들어 이걸 안 쓰면 안 되는 경우에도 반대 때문에 도입할 수가 없습니다. 그런 경우 모든 시니어를 설득해야 하기 때문에 그 과정이 어렵습니다.

스타트업과 대기업은 스톡옵션 차이도 있습니다. 대부분의 대기업들은 이미 상장을 했기 때문에 스톡옵션을 받을 수 있는 가능성이 희박하지만, 스타트업의 경우에는 스톡옵션의 기회가 남아 있을 확률이 높습니다.

그러나 모든 스타트업이 이 모든 조건(좋은 시니어, 스톡옵션, 기술을 도입할 수 있는 가능성)을 만족할 확률은 낮다고 했습니다. 그런 조건들이 가질 확률이 미지수이기 때문입니다. 그러나 빅테크 기업의 경우 확실하게 이점을 취할 수 있기 때문에 빅테크 기업이 신입 개발자의 첫 직장으로서는 나은 것 같습니다. 자금적인 문제도 당연히 있습니다.

어쨌든 한 번 대기업의 맛을 보는 것이 좋습니다. 일단 지금 스타트업에 가게 된다면, 아쉬움이 너무 클 것입니다. 스타트업에서 빅테크로 가는 것은 어렵지만, 빅테크에서 스타트업으로 이동하는 것은 반대보단 쉬울 것 입니다. 따라서 빅테크에서 커리어를 쌓고, 그동안 거기서 공부했던 것을 바탕으로 시리즈 A 정도 급으로 이동해서 쌓아둔 내공을 사용할 수 있다면 훨씬 많은 선택권과 기회가 있을 것입니다.

16. 실무에서의 장애 대응 예시에 대해서

충환: 스프링 핵심 원리를 알면 장애를 대응할 때 도움이 된다고 하셨는데 실무에서 발생하는 예시를 들어주실 수 있으신가요?

동욱: 스프링의 핵심 원리를 잘 알면 기능 개발이나 확장에는 확실히 도움이 되겠지만 장애에 잘 대응할 수 있는 것은 아닙니다. 실제 서비스에서 장애는 굉장히 많기 때문에 직접 경험해보며 배워야 합니다.

실제 장애 경험을 예로 들자면, 이번 인프런 문제는 데이터베이스 문제였습니다. 이 뿐만 아니라 장애 요인에는 로드밸런서, 쿼리 문제 등 수 많은 요인이 있습니다.

스프링을 잘 아는 것이 애플리케이션 레벨의 기능 확장이나 코드 분석에 도움이 되겠지만, 장애에는 연관되어 있는 서비스가 너무 많아 전반적인 지식이 필요합니다.

추가로 백엔드 개발자 업무의 30% 이상이 데이터베이스와 관련돼있습니다. 어플리케이션 서버는 데이터베이스와 밀접하므로 관련 쿼리를 잘못 짜면 좋은 성능을 기대할 수 없습니다. JPA를 사용한다고 쿼리를 공부하지 않는 것은 옳지 못한 태도입니다.

SQL 첫걸음 → SQL 레벨업 → Real MySQL 1편 추천합니다.

• SQL 첫걸음: http://www.yes24.com/Product/Goods/22744867
• SQL 레벨업: http://www.yes24.com/Product/Goods/24089836
• Real MySQL 1편: http://www.yes24.com/Product/Goods/103415627

마무리

(방역수칙을 지키면서 서울의 한 스타벅스 카페에서 동욱님을 만났습니다.)

정말 말씀을 정성스럽게 잘해주셔서 생각없이 질문을 하다보니 두 시간이 그냥 지나가버렸습니다...

동욱님께서 유튜브에서 말씀하시거나 다른 개발 유튜버들이 말씀하신 부분들 말고 질문을 최대한 하려했지만, 결국 비슷하게 간 느낌도 있습니다. 그리고 저희가 주변에서 들을 수 없는 시니어 개발자를 통해서 들을 수 있는 내용들을 생각하다보니 조금 딥해진 부분도 있는 것 같습니다.

하지만 동욱님을 직접 만나서 직접 들은 피드백은 무엇보다도 값지고, 실시간으로 들으면서도 동욱님이 말씀을 너무 잘해주셨습니다. 그리고 동욱님과 얘기를 나누는 것도 중요하지만 존경하는 분을 뵙게 된 것 자체만으로도 너무나도 감격이었습니다. 그리고 동욱님께서 계속 저희에게 오히려 고맙다고 그러셨는데 그런 모습들을 보면서 많은 것을 느꼈습니다. 저희들도 저희가 시니어가 됐을 때 주니어들에게 선한 영향력을 줄 수 있는 개발자가 되겠다고 다짐하는 계기가 됐습니다.

정말 바쁜 업무 시간에도 시간을 내어서 만나주신 동욱님 다시 한번 정말 정말 감사합니다! 다음에 꼭 서울 판교에서 뵐 수 있었으면 좋겠습니다!