[지원하기] DND 10기 백엔드 합격 후기 ( feat. 지원서 )

 

https://www.dnd.ac/

 

---

 

1. 들어가며

원래는 DND 합격 발표일인 23년 12월 28일에 합격 후기를 작성해야 헀는데,

개인적인 사정으로 인해 DND 최종 발표까지 마무리한 지금에서야 합격 후기를 작성하게 되었습니다.

부디 넓은 마음으로 양해 부탁드립니다 😉

 

1.1) DND 에 지원하게된 계기

저는 스타트업에서 2년 1개월의 경력을 마무리하고 나온시점에 그동안 바쁘다는 핑계로, 프로젝트를 진행해야 한다는 책임감으로 외면하고 회피했던 번아웃을 겪게 되었습니다. 퇴사를 하고 난뒤 시간이 많아져서 그런가, 흔히들 말하는 “놀면 병난다” 라는 말이 너무 공감 되던 시기 였습니다.

 

“1일 1커밋” , “수영 배우기” , “카페에서 업무하기” , “바빠서 만나지 못했던 사람들 만나기” , “블로그 글쓰기” , “요리 배우기” 등 이 상황을 벗어나고자 발버둥 쳤고 다방면으로 노력 했습니다. 하지만, 저에겐 예전과 같은 의욕도, 열정도 무언가에 대한 흥미도 느낄 수 없었습니다.

 

개발자라는 직업에 있어 커리어를 지속하는것을 고민하던중 인스타그램을 통해 DND 모집 공고를 보게 되었습니다.

대학생활과 회사 생활을 할때도 다양한 개발 프로그램을 지원했지만 한번도 합격한적이 없었습니다.하지만, 지원조차 하지 않으면 바늘구멍을 통과할 기회조차 주어지지 않는다는것을 알고 있었기에 붙을것이라는 기대는 내려놓고 DND 에 지원하게 되었습니다.

 

1.2) DND 합격

 

• 10기 합격 발표일 : 2023.12.28
• 10기 프로젝트 시작일 : 2024.01.01
• 10기 최종 발표일 : 2024.02.24
• 10기 지원 파트 : 백엔드

 

23년 12월 28일에 DND 10기 합격 메일을 받고 한편으로는 기쁘면서도 걱정이 많았습니다.

하지만, 최종 발표까지 마무리한 지금 지난 2달을 돌아보면 너무나 감사할따름 입니다.

---

 

 

2. 지원서 작성하기

다음 기수 지원시에는 질문의 내용이 이번 기수와는 다를 수 있기에 참고만 하시길 권장 합니다 :)

제가 DND 10기를 지원하며 작성한 지원서를 공개하는 이유는 크게 2가지 입니다.

 

첫번째는 저처럼 지원하는 개발 프로그램마다 떨어지시는 분들께 조금이나마 도움이 되었으면 좋겠습니다.

 

두번째는 자소서를 여러번 작성해봤지만 300자, 500자 와 같이 질문당 제한된 글자수로 인해 제가 어떤 경험을 했는지, 문제들을 어떻게 극복했는지에 대해 작성하기 어려웠습니다. 쓰다보면 금방 글자수 제한에 걸려버려서 제가 이야기하고자 하는 내용의 20% 도 작성하지 못하는 경우가 많았습니다. 하지만, DND 지원서를 작성할때는 글자수 제한이 없었기 때문에 제가 이야기하고자 하는 내용의 70%는 담아낼 수 있었다고 생각합니다. ( 나머지 30% 는 저의 미숙한 글쓰기로 인해… )

 

 

📌 DND에 지원하게 된 동기와 활동을 통해 이루고 싶은 목표에 대해 최대한 구체적으로 작성해주세요.

지난 2년, 개발자로 근무하면서 진행한 업무들은 개발을 처음 공부할때와는 다른 경험과 성장을 할 수 있었습니다.

하지만, 한가지 아쉬웠던 점은 스타트업 특성상 빈번히 교체되는 동료/선임 개발자들과 백엔드는 혼자서 감당했어야 했다는점입니다.

 

회사 전체 인력의 60%가 한순간에 날아가는 그 시기는 아직도 기억에 남습니다.

"이제 어떻게 하지, 내가 혼자서 잘 할 수 있을까 라는 불안", "매크로 유저들로 인해 RDS CPU 점유율이 99% 에 맴돌아 멈춰버린 서버를 수습할때의 초조함", "맘놓고 질문하고 함께 문제를 해결해나갈 동료, 선임 개발자들이 없는 막막함". 여러가지 벽을 넘어가며 성장했지만, 혼자였기에 넘지 못했던 벽들이 존재했고 이번 기회에 그 벽을 넘어서는 경험을 해보고 싶습니다.

 

 

📌 개발 활동(학교 수업, 프로젝트, 경진대회 등)을 진행하며 모르는 문제를 마주했을 때 해결한 경험에 대해 설명해주세요. 얼마나 기술적으로 어려운 문제였는지는 중요하지 않습니다. 사소하더라도 본인의 접근 방법과 해결 과정, 해결하지 못했더라도 그것을 통해 어떻게 성장했는지를 중점적으로 최대한 자세히 작성해주세요.

다수의 인력이 퇴사한 이후, 회사는 주요 비즈니스를 WEB 에서 APP 으로 변경하고자 하였고,

이 과정에서 1달이라는 시간안에 외주 개발사로부터 프로젝트를 인수인계 받아 서비스 출시 및 배포, 운영해야하는 상황이었습니다.

외주사와의 의견차이, 기존 설계와는 다른 결과물, 빈약한 인수인계 문서등의 부차적인 문제를 제외하고 우여곡절 끝에 출시한 서비스는 많은 부분에서 문제가 있었습니다.

 

오후 7시 40분 퇴근을 하고 지하철을 타기위해 지하철 게이트에 카드를 찍은 순간 걸려온 이사님의 전화 한통. '창훈님 지금 APP 에 들어가면 무한 로딩이 되고 아무 기능을 쓸 수 없어요. 빨리 와주셔야 할것 같아요."

당시에는 AWS 에 대한 지식이 부족했기 때문에 RDS Performance Insight 를 확인하고 문제가 되는 쿼리를 확인하고 DB 락을 풀고 문제가 되는 유저를 벤하는등의 자연스러운 프로세스를 진행하지 못했습니다.

 

당시에 제가 문제를 파악했던 방법은

1. 해당 서버가 배포된 AWS EC2 접속
2. docker swarm 의 형태로 배포된 서버의 로그 확인
3. 서버의 로그 확인 결과 API 요청에 대한 조회 결과가 null 로 리턴되는것을 확인
4. 옆에 같이 계시던 이사님에게 해당 내용 전달 및 대응
5. EC2 재부팅 ( 실제 운영중인 서비스에서 운영중인 서버를 꺼버린다는게 말이 안되었지만 무한로딩의 상태에서 사용자들의 지속적인 접속으로 인해 API 요청이 계속해서 쌓이고 DB 에 락된 쿼리들이 늘어나는것을 방지하기 위해 생각난 방법이 이것 밖에 없었다.. )
6. DB 트랜잭션 모니터링 ( select * from information_schema.innodb_trx; )
7. RDS 인스턴스 임시 업그레이드 ( large > xlarge )
8. AWS RDS CPU 점유율 모니터링
9. 락된 트랜잭션 해제 작업 진행
10. DB 쿼리별 통계 모니터링 ( select * from sys.schema_table_statistics LIMIT 1; )
11. 문제가 발생한 DB 테이블 및 쿼리 확인
12. 해당 쿼리의 userId 확인
13. 해당 유저의 API 요청 빈도수 확인 ( 룰렛 API 의 경우 평균 3 ~ 5 초를 정상 유저로 판단 )
14. 메크로 유저 판단 및 벤 처리
15. EC2 부팅
16. EC2 CPU 및 RDS CPU 점유율 모니터링
17. 경과 보고 및 문제 원인 공유

해당 작업을 마치고 나서 여러가지 생각이 들었다.

내가 조금 더 많은 지식을 알고 있고 다양한 경험이 있었으면, 좀 더 빠르게 대응할 수 있지 않았을까.

이후에 AWS 에 대한 공부를 진행하며, 출시한 서비스의 인프라 및 빠른 대응을 위한 방법들을 찾을 수 있었고 하나씩 적용해나갔다.

 

첫번째는 Grafana 를 사용한 회사내 인원들이 RDS 모니터링을 할 수 있게끔 구성하는것이었다.

실 서비스에서 문제가 발생하여 대응하는것이 아닌 누구나 지표상 문제가 있다고 생각되면 개발자나 대표님에게 알릴 수 있도록 하기 위함이었다. 여기에 더해서 CloudWatch 를 통해서 RDS 의 CPU 점유율이 일정 비율을 넘어가면 특정 인원에게 알림과 메일이 발송되도록 구성하였다. 기준이 되는 CPU 점유율은 30% ~ 50% 였고 80%가 넘어가면 무조건 모니터링 해야한다는 텍스트가 담긴 메일이 전송되게 구성하였다.

 

두번째는 DB 쿼리의 용도에 따른 RO/WO ( ReadOnly/WriteOnly ) 쿼리 분리 작업이었다.

기존에 회사에서 개발하던 서비스의 백엔드는 해당 작업이 적용되어 있지만, 외주 작업으로 진행된 백엔드에는 해당 작업이 진행되어 있지 않았다. 그렇기 때문에 모든 쿼리가 W/O 로만 요청되어 과도한 트래픽이 발생되었고 이로 인해서 RDS CPU 가 튀는 현상이 발생했던것이었다. 외주 프로젝트의 백엔드 코드중 db client 코드를 수정하여 dbROClient, dbWOClient 를 추가하여 쿼리 작업을 세분화하는 작업을 진행했다.

 

마지막으로 해당 이슈가 발생한 원인과 대응작업에 대한 내용을 공유하기 위해서 포스트모멘텀을 작성하여 공유하였다.

 

 

📌 본인이 열정을 가지고 깊게 몰입하여 목표했던 것을 성취한 경험에 대해서 최대한 자세히 작성해주세요. 개발 관련 경험이 아니어도 괜찮습니다.

내가 겪은 스타트업이란 투자금을 기반으로한 회사 유지에 있어서 서비스의 출시와 운영, 매출 발생까지 필사의 사투를 이어 나가는것이었다. 그렇기에 회사의 런웨이 자금의 소모에 있어서 지출을 줄이는것은 개발자에게 주어진 하나의 숙제였다.

 

'서버 운영비' 지레 짐작하건데 인건비와 광고비를 제외하고 제일 많은 비용이 발생하는 부분이다. 당시 매월 약 500 만원 가량의 비용을 AWS 에 지불하고 있는 상황에서 받은 컨설팅 결과 회원수와 DAU/MAU 대비 과도한 비용이라는 지적이 나왔다. 약 1주일의 기간동안 서버 비용을 절감 하기 위한 작업에 착수 하였다.

 

우선적으로 작업한 부분은 AWS cost explorer 를 통해서 사용하고 있는 AWS 서비스별 발생 금액에 대한 지표 정보를 확인하는것이었다. 서비스별, 월별, 그룹별 지표를 다운로드하여 정리한 다음 가장 비용이 많이 발생하는 EC2 와 RDS 비용에 대해서 절감 방법을 모색하였다.

지난번 이슈로 인하여 임시로 변경한 RDS 인스턴스는 다음 앱 버전 업데이트에 맞춰 변경하기로 하였다.

 

EC2 의 경우 회사가 PR 을 위해 테스트용으로 운영했던 서버, 해외 진출 과정에서 해외 리전에 구성한 서버, 지금은 개발하고 있지 않는 프로젝트 서버등 별에 별 용도의 불필요한 서버가 동작하고 있었다. 해당 서버를 리스트업한다음에 대표님께 컨펌을 받고 서버를 종료하는 작업을 진행하였다. 이 과정에서 기존에 운영되고 있는 서비스들에 영향이 없는지 확인하기위해 모든 서비스를 8개 정도의 크롬창에 띄워놓고, 기획팀에도 요청드려 같이 체크해가면서 진행하였다. 그 결과 서버 비용은 약 500만원에서 200만원 중후반대까지 비용을 줄 일 수 있었다.

 

📌 공동의 목표를 달성하기 위해 타인과 협업했던 경험과 본인이 수행한 역할에 대해 작성해주세요. 또한 갈등, 의견 차이 등 문제 발생 시 해결 경험과 해당 경험을 통해 얻은 것은 무엇인지도 최대한 구체적으로 기술해 주세요.

개발 관련 경험이 아니어도 되며, 만약 협업 경험이 없다면 본인의 협업 가치관과 문제 발생시 어떻게 해결할 수 있을지에 대해 작성해주세요.

 

스타트업은 실력 좋은 동료들과 새로운 기술스택을 기반으로 빠르게 서비스 출시를 위해 달린다.

내가 합류한 시점의 회사에서도 기존 서비스 리뉴얼하고 신규 프로젝트의 시작을 준비하던 시점이었다.

합류하자마자 기존 프로젝트를 팔로우업하고 새로운 프로젝트 요구사항을 분석하는 과정에서 들었던 한가지 의문은 기존 프로젝트들의 문서가 거의 존재하지 않는다는점이었다. 그렇기에 신규 입사자가 들어올때마다 주어진 가이드 문서를 기반으로 기존 프로젝트를 학습하는것이 아닌 팀장님이 직접 가르치고 계셨다. 당시에 내가 가장 잘하는것이 정리하는 글쓰기 라고 생각했었기에 프로젝트를 팔로우를 위해 주어진 기간동안에 내가 파악한 기존 프로젝트의 구조와 API 제작 방식등을 정리해서 공유하였고 이후에 들어온 신규 입사자는 해당 자료를 통해서 기존 프로젝트를 팔로우하여 신규 입사자의 교육을 담당하던 팀장님과 동료들의 공수를 줄일 수 있었다.

 

프로젝트가 커지면 커질 수록 개발 문서의 중요성은 수직 상승하는것 같다.

하지만, 문서를 정리하는것을 '일 이 늘어나는것' 이라고 생각하여 지양하는 개발자도 존재한다.

 

설득하기 위해 시도했던 방법은 솔선수범하는것과 문제를 정의하고 이를 해결하기 위한 방법을 적용했을때의 결과를 공유하는것이다.

앞서 문서화를 예로 들어보자면,

 

첫번째 문제로 기능별로 API 를 분담해서 작업하는 개발자 특성상 내가 룰렛 API 를 제작하고 동료 개발자가 뽑기 API 를 제작한다고 하면 자기가 개발할 API 에 대한 부분은 인지하고 있을지라도 다른 사람의 담당 API 는 알지 못하는 문제가 있다. "이게 뭐가 문제야" 라고 할 수도 있지만, 해당 API 를 담당한 개발자가 휴가를 해외로 가거나 전화를 받을 수 없는 상황인 경우 문서가 없기 때문에 코드로만 원인을 파악해야나가야한다. 우리도 알다시피 남이짠 코드는 선뜻 수정하기에 어려움이 있다.

 

두번째 문제로 기존에 개발을 진행한 개발자가 다 빠진 상황에서 새로운 개발자로 투입되어 프로젝트를 파악하고 신규 기능을 업데이트 할때이다. 기존에 개발에 참여한 개발자가 존재한다면 해당 개발자에게 프로젝트의 전반적인 내용, 배포 방법, 프로젝트 이슈 히스토리 등을 물어볼 수 있지만 개발팀 교체인 경우 물어볼 사람도 없을뿐더러 퇴사한 사람에게 연락하여 "혹시 00님이 개발한 00 부분 기억나세요?" 라고 물어보는것도 전화를 받는다는 가정하에 가능하다.

 

세번째 문제는 첫번째 문제와 비슷하다. 만약 신규 기능을 업데이트 한뒤 룰렛 API 에서 문제가 발생하여 해당 API 개발을 담당한 A 라는 개발자가 이슈를 수정한뒤, 원인과 코드를 수정한 부분/해결 과정등을 정리하여 공유하지 않았다고 가정한다. 그러면 해당 개발자가 자리를 비운 사이에 동일한 CS 가 발생할 경우 해당 이슈의 처리를 할당 받은 B 라는 개발자는 어느정도의 삽질을 감수해야한다.

 

경험에서 얻은 문제점을 정의하고나서 이를 기반으로 기능 제작 작업 과정 및 이슈 처리 과정에 대한 문서를 정리하여 개발팀 세미나 시간에 공유하였다. 대표적으로 가장 큰 호응을 얻었던 문서는 이사님 전화를 받고 부랴부랴 회사에 와서 처리한 이슈에 대해 정리된 문서였다. 해당 문서에는 문제의 원인, 해결 과정, 후속 대응에 대해 적어놓은 포스트모멘텀 문서였다. 이후에, 내가 휴가를 갔거나 한 상황에서 RDS CPU 점유율 이슈가 발생한적이 있었는데 이때도 사전에 공유한 문서를 기반으로 문제가 될 수 있는 부분을 확인하고 해결 과정에 정리되어 있는 DB 쿼리 통계 SQL 등을 참고하여 이슈를 해결하는데 참고 할 수 있었다고 전해들었다.

---

 

 

3. 글을 마무리하며

다음 기수에 지원하시는 분들도 DND 가 좋은 경험이 되었으면 좋겠습니다.

기존 기수는 DND 참여가 1회정도 더 가능하기에 연이 닿는다면 프로젝트를 같이 하게 될 수도 있겠네요 :)

 

마지막으로 제가 DND 에서 진행한 프로젝트가 궁금한 분들을 위해 링크를 남깁니다 XD

링크 : DND 를 마무리하며 ( feat. 최종 발표 )