Developer
Created: 2020, 04 08 >Updated: 2026, 05 21Why me?
데브옵스로서 개발자가 코드에만 집중하고, 배포 된 서버의 안정적인 구동까지 단순화하는 것을 할 수 있다 언어나 환경에 구애받지 않고 0과 1의 세계에서 어떤 것이든 본질을 이해하면 수단은 관계없이 문제해결은 가능하다. 정답은 없고 트레이드오프를 고려한 선택만이 있다. 일관성을 중요시한다
어떤 문제가 있었고 어떤 과정을 통해 어떻게 개선했고 어떤걸 배웠는지 힘들었던 경험을 통해 어떻게 성장했는지 (쌓아왔는지) 어떤 성과를 냈는지 포트폴리오에 성과가 안나타나있다 그래서 뭔가 별거없는 업무로 내가 느끼는 듯 가장 어려운 문제를 해결한 사례는? 작년 나의 챌린지 이력서에 어떤 것을 넣고싶은가 회사 문제점 하나 개선하기
회사마다 다르겠지만 회사는 맡은 일을 잘해 성과를 낼 수 있는 사람 회사를 성장시켜줄 사람을 뽑고 싶을 것이다 시키는 일을 하는게 아니라 같이 고민해서 나아지는 방향으로 만들어나갈 수 있어야한다 회사를 다니면서 배웠던 부분과 사람들에 대한 고마움을 스토리로 풀면 좋아할 것이다 운영을 하면서 되돌릴 수 있는 변경을 만들어야 한다는 주의와 문제 발생 시 공유 후 대처 방법에 대해 논의하는 것, 후속 조치 및 근본 원인 파악 및 개선에 대해 많은 경험을 할 수 있었다
그래프는 “15% 줄였다” 같은 문장보다 규모·추세·변동성·시점을 한 번에 드러내며, 임팩트를 설명하고 검증 가능한 신뢰를 얻는 가장 강력한 커뮤니케이션 도구임
'완료'가 아니라 '의사결정의 맥락'을 적어보세요. 차이를 비교해 보세요.
- 완료 중심: 결제 버튼 위치를 변경함
- 의사결정 맥락 중심: 영업팀은 상단 배치를 원했으나, 데이터팀은 하단을 주장함. 내가 A/B 테스트를 제안해 3일간 데이터를 모았고, 그 근거로 하단 배치를 관철시킴
나중에 당신을 증명해 주는 것은 '버튼을 바꿨다'는 사실이 아니라, '갈등 상황에서 데이터 기반으로 의사결정을 조율했다'는 맥락입니다. 이것이 진짜 성과입니다.
옵저버빌리티나 iac나 스크립팅은 다 그냥 핸즈온하면 하게 되는 영역인거 같은데 여기서 퀄리티를 내려면 어떤 관점으로 보는게 좋을까 아키텍쳐링은 인프라를 어떻게 구성하면 좋을까를 특정 기준을 두고 트레이드오프를 보면서 다양한 서비스를 비교해서 보면 결국 되는 영역인거 같은데 지속가능성을 기준으로 두면 될까 카펜터 도입처럼 신규 인프라 도입 및 검증이 내가 원하는 긱한 업무인거 같다. 이 과정이나 힘들었던 점이 궁금함
Resume
- 나를 세일즈
- 인터뷰는 서로가 서로를 알아가는 과정이다. 쫄면 안되고 질문에 대답만 하려는 태도도 안되고 내가 뭘 해줄 수 있는지 어필해야 한다
- 상대방이 원하는 것을 알아보고 그것에 맞는 사람임을 어필
- 상대가 뽑을 이유가 있게 만들어야 한다
- 문제 해결 경험을 적는다
- 경험이 아닌 경력위주로
- Delete don’t explain project
- 무엇을 했고, 어떻게 했고, 결과는 어땠는지
- y를 구현해서 x를 성취했고, 그 결과 z를 이루었다
- 이런 일을 했고, 이런 문제가 있었고, 그래서 이렇게 해결했다는 과정을 중요하게 봅니다.
- 분산 캐시를 구현해서 오브젝트 렌더링 시간을 75% 줄였고, 그 결과 로그인 시간을 10% 경감할 수 있었다. windiff에 기반한 새로운 비교 알고리즘을 구현한 결과, 평균 비교 정확도를 1.2에서 1.5로 개선했다
- 쿠버네티스를 이용한 개발환경을 구성했다 까지만 적고 어떤 문제를 해결하기 위해 뭘했는지를 적어야 한다
- 이력서를 보고 관심이 가고, 목적에 부합하고, 호기심이 가고, 회사와 맞을 거 같다는 느낌이 들어야 한다
- 그림을 잘 그리는지 보기 위한 테스트에 맞춰 결과를 생각하는 것보다 어떻게 하면 새롭게 그릴 수 있는지 보기 위한 테스트에 맞춰 생각하는 것이 더 좋은 결과를 만들어 낼 것 같다
- 결과에 집중하기보다 과정을 즐겨야 한다는 상투적인 말이 생각난다
- 내 업무가 파악이 바로 되는가?
- 내 역량이 파악이 되는가?
- 어떤 경험을 했고 어떤 마음을 가지고 있는지 잘 어필하고 싶다
- 서류에는 이제까지 회사에서 진행했던 프로젝트를 상세히 썼고, 거기서 내가 수행한 역할과 책임을 작성했다. 자소서 부분은 '문과생'이었던 내가 회사에 들어오기까지 얼만큼 노력했고, 들어오고 나서도 어떠한 노력을 하고 있는지 작성했다.
- 문장이 길어지면 첫 문장을 읽고, 뒷 문장을 읽고 싶게끔 되야 한다.
- 대답을 구조화해서 사례를 들면서 한다
- 회사의 요구사항을 조사해서 내가 그걸 할 수 있다는걸 어필해야 할 것 같다
- 회사 지원할 때마다 지원동기 한문단씩 적기. 기업별 맞춤 지원 내용, 제안을 서머리에 적자
- 2025년의 성과 뽑기
- 선택지에서 어떤 선택을 했는지가 궁금할 것이다
- 취업/진학
- 이직
- 진로변경
- 아키텍처 전향
- 가상 면접 영상 찍기
- 기술적 이론 채우기
- 원하는 기업에 대한 심층분석
- 데브옵스의 kpi는 뭘까
- 배포 시간과 안정성을 동시에
- 수동 운영 작업 X% 감소
- resume에는 최대 5개만 남겨놓고 포트폴리오에 쓴다
- 성과 how and result
- 역할 action 문제를 해결한 액션
- 면접에서 5가지 핵심 이야기를 준비해놓는다
- 즐거웠던 경험
- 싫었던 경험
- 가장 도전적이었던 경험
- 가장 어려웠던 버그
- 협업에서 힘들었던 점
제가 신입이라면 시리즈 B이상 투자받은 스타트업을 리스트 업하고 그중에 내가 쓰는 서비스나 마음에 드는 서비스를 고른뒤 그 서비스중 기능하나를 구현해서 포폴만든다음 링크드인 주소와 함께 깃허브 주소 첨부해 보낼거에요.
- 어딘가에서 본 내용
대외활동보다
대외활동보다 중요한 것은 뭔가를 했고, 그것을 통해 어떻게, 얼마나 성장했는가이다. 왜 했고, 어떻게 했고, 무엇을 얻었고, 어떤 생각을 했고, 어떻게 되었는지를 잘 정리하는게 중요하겠다.
- 그럼에도 대외활동은 신청부터 완료까지 사이클을 경험할 수 있고, 프로젝트도 명확해서 도움은 될 것 같다. 자기가 혼자 생각한 것을 개발해서 성과를 얻을 수도 있지만 오히려 쉽지 않다.
- 나이를 먹으면서 성장하게 되지만, 회사에서 일하면서 더 성장하게 되는 것 같다.
회사가 뽑고 싶은 개발자
- 쓰고 있는 기술에 경험이 있는 사람
- 회사 상황에 대한 경험
- 인간적인 매력
- 얼마나 깊이 생각했는가
- 구체적인 구현 능력
- 신규 기술에 대한 접근법
- 신규 기술을 도입하는 회사 -> 신규 기술에 대한 접근법을 잘 전달해야겠다
About_Development#같이 일하고 싶은 개발자
내가 회사파악할 때 보는 과정처럼 회사도 나를 파악하기 위해 보고싶은게 있을거다 그걸 보여주려고 해야한다 회사파악할 때 개발문화가 어떻고 문제를 얼마나 깊게 다뤄봤는지 알고싶다 이력서에도 문제를 얼마나 깊게 파악하고 해결했는지 과정을 적는게 낫겠다
내가 데브옵스 신입을 뽑는다면 어떤 자격을 원할까
백엔드는 복잡한 요구사항을 어떻게 풀어냈느냐를 볼 수 있으면 좋다 그러면 데브옵스는?
- 어떤 최적화와 자동화를 해서 어떤 개선점이 있었냐
- 팀원들의 개발환경을 어떻게 개선해주었느냐
회사에 질문
이직하길 원하는 회사의 조건
- 큰 조직임에도 개발문화를 존중하는 회사
- 인프라 업무
면접관에 궁금한거
- 나도 개념은 알고있지만 그걸 설명하려면 이직준비를 하면서 공부를 따로 해서 말할 수 있는건데 면접관들은 어떻게 알고 잘 말하는 것일까
- 그러고보니 팀장님들은 다들 어떻게 그렇게 개념을 잘 기억하고 계실까
들어가는 회사에 질문
- 팀 커뮤니케이션 어떻게, 어떤 프로그램
- 메뉴얼 있는지, 목차 확인
- 린트 체크, 테스트 하고 있는지
- 팀 단위, 팀 구성 어떻게 되있는지
- orm을 쓰면서 한계를 느낀 경험 있는지?
- 조직의 경험을 어떻게 축적하고 있는가? 신입이 문서를 보고 배우나?
- 개발 프로세스 등
경력직 사수에게서 무엇을 배웠는가
- 실무적으로 안정적인 운영을 위해 리스크를 줄이는 노하우
- 기술적으로 겪었던 경험에 대한 공유
- 기술에 대한 시선, 가치관
- 인프라적으로 남아있는 코드 5개 채득하자
- 코드적으로 남아있는 코드 5개 채득하자
이직사유
- 지금 퍼플아이오에서는 개발하면서 인프라를 다루는 경험을 해봤으니 다음 회사에서는 인프라에 대한 깊이를 가질 수 있으면 좋겠다. 커뮤니케이션 부분은 고민
회사의 인프라에 어떤 개선점을 만들었는가
- 이걸 만들어야 한다. 이직 전 반드시.
- CI/CD 환경? 오래걸리고 에러가 뜨는 상황이 종종 발생한다
- 배포본의 가시성 확보?
그동안 해온 일에서 내가 추구해온 가치
- 쉽고 가볍고 의존성 없고 단순한 프로그램 -> 변화에 대응하기 쉬운 프로그램
그동안 프로젝트 경험을 통해 잘 할 수 있는 일
- container를 이용한 서비스 개발과 운영
- 원하는 기능이 필요할 때 적합한 툴을 찾고 사용해서 요구사항을 실현하는 일
나는 앞으로 어떤 일을 하고 싶은가
- 스케일이 커지는 경우에도 간단한 형태를 유지하면서 변화에 대응할 수 있는 서비스를 개발하는 것
일하고 싶은 회사는 어디인가
- 사용자에게 가치를 전달해주는 것에 가치를 두는 회사. 내가 관심 있는 영역에 맞는 회사
- 문제해결에 있어서 정신적 지원을 해주는 회사. 문제발생의 원인을 해결하려고 하지 문책을 하려고 하지 않는 회사
이전 경력에서 무엇을 배웠나
- 백엔드 개발자로 입사했는데 회사가 데브옵스 문화를 지향하기도 하고 인프라에 관심 많은 것을 도와줘서 인프라 관련 업무도 같이 할 수 있도록 맡겨주었음
- 회사에 내가 배울만한 전문가가 있었고 그 분이 어떻게 일하는지를 관찰할 수 있었다
전체적인 구성을 익히고 조금씩 발전시나가는걸 좋아하는데 이 회사에서 그걸 한 경험이 있는가?
경험
쿰스에서의 경험
- 대용량시스템 아키텍처 설계 및 운영
- 1년 1억건 이상의 데이터가 쌓이는 환경
- 100만 사용자에게 발송되는 메시지 발송 시스템
- 람다와 메시지큐(키네시스)를 이용하여 비동기 메시징 시스템 구현
- 분당 10만건 발송
- 람다가 받을 수 있는 트래픽의 한계를 확인하고 더 많은 처리를 위해 어떻게 해야하는지에 대한 경험
- 람다로 대용량 데이터 처리 경험
코몰
- 100만 사용자가 이용하는 이커머스 쇼핑몰
- 자바, nextjs, aws 이용
erp를 구성하면서 힘들었던 점
- ERP 개발을 하면서 container를 이용한 서비스 개발과 운영, 원하는 기능이 필요할 때 적합한 툴을 찾고 사용해서 요구사항을 실현하는 경험을 쌓았다
- 이전 직장에서는 사내 ERP 서버를 구축하고 개발하는 업무를 혼자 맡았다. 제가 그만두면 서버가 유지가 안되는 상황을 우려해서 최소한의 기술 스택을 유지하면서 안정적인 운영을 할 수 있도록 하는 점에 중점을 두어 Docker 외에는 인프라 도구를 도입하지 않음.
얘기하고 싶은 내 경험 4가지
-
서버리스 람다 SQS 이벤트 드리븐 (AWS 이해도)
-
쿠버네티스 등 (컨테이너 이해)
-
개발부터 배포까지 과정 이해, 자동화 개발 효율 (CI/CD)
-
대용량 전송 (문제 해결 능력)
-
람다 문제 해결 사례 + 키네시스
-
스크립트화의 자유
-
ci/cd의 분리의 필요성과 트레이드오프
승규님이 했던 작업들 리스트업해보자 이걸 내가 했으면 내가 의미있는 작업을 했다고 생각했을 수 있을텐데
- karpenter
- vpn 세팅
- eks upgrade
- robusta
람다 해결사항
팬아웃 plimit 키네시스 설정 성능 테스트
- putRecords, aggregate,
인프라적 아키텍처링 - 쿰스 설계, 클라우드프론트, cka 인프라적 개발환경 개선 - 깃랩 캐시, 스케줄러 인프라적 성능 개선 - 쿰스 람다, 배포봇
사용자에 맞게 확장 가능한 아키텍처를 클라우드 환경, 온 프레미스 환경에서 구축 가능
- terraform, ansible로 반복되는 아키텍처 관리 작업을 코드로 관리
- 초기 스타트업의 환경
- 사용자가 늘어가는 환경
- 대용량 아키텍처
인프라를 바닥부터 가벼운 상태로 최적화하여 구축할 수 있고, 현실의 데이터를 전산화하여 사용하였음. 필요한 도구들을 직접 개발하여 사용하고 있음 아무것도 없는 상황에서 요구사항에 맞게 적합한 도구를 선택하여 구축할 수 있음 필요한 기능을 설계하고 개발하여 피드백을 통해 개선하는 작업을 계속 했음
내가 할 수 있는 것
- 가볍고 범용적인 인프라
- 컨테이너를 이용한 효율적인 시스템 구축
- 실전 경험이 없어서 우려하는 점을 어떻게 풀어나갈까
- 시행착오가 일어날 것이다
- 느릴 것이다
- 나만의 킥
- 남들 한거 따라가는데 그치면 안되고, 내 필요를 추가해야한다
- problem solving ability
- I've maintain machine before being developer. that's always been occurred error. and error have core cause, I have found 5 years. and then I think I have major of solving problem.
나의 장점
- 능동적 업무 진행 능력 : 인프라 개선을 스스로 찾아서 한다 어필
- 문제해결능력 : 문제 해결을 잘한다 어필
- 스크립트화로 빠르게 업무를 자동화한다 어필
- 커뮤니케이션 - 능동적 문제 파악을 위해서는 어떤 문베를 갖고 있는지 계속 대화해봐야 한다
- 문서화 - 문제의 해결 뿐 아니라 깊게 파악하고 나만의 언어로 남들과 공유할 수 있는 능력
- 비용 최적화 및 효율화 아키텍처링 능력
Container
가볍게 os를 쓸 수 있게 해준다. 여러 환경에서 일관성 있는 환경으로 쓸 수 있고 클라우드 등 배포 시에 이식이 용이하다. 하지만 개발하면서 컨테이너 위에서만 작업하는 것은 불편함이 있을 수 있고, 그래서 모든 개발자에게 컨테이너 위에서 개발하라고 하는 것은 힘든 부분이 있다 (데이터 이동의 번거로움, 서비스 연결의 번거로움, 깨끗한 환경 유지에 대한 압박, 새로 개발 시 설정 필요, 매번 연결해야 하는 번거로움) 그래서 컨테이너의 일관성과 자연스러운 개발환경을 모두 만족시키기 위해 신경을 써야겠다
개발자의 편의를 개선하는 작업
리소스를 한 곳에 모으고 쉽게 접근 가능한 웹페이지 검색의 확장을 위한 유의어 단어 사전 마이크로서비스에서 반복적으로 필요한 crud api 패키징 프로젝트 생성부터 배포까지 커맨드 하나로 셋팅하는 클라이언트 툴
나의 개발 성향
전체적인 개발철학은 충섭님에게 공감 오버엔지니어링을 피하고 관리하기 쉽고 많이 사용되는 걸 최소한으로 사용한다
인생을 살면서 배움이 없이 살 수 없다. 그렇다면 즐겁게 배울 수는 없는가? 있다. 그래서 개발자라는 직업이 매력있다. 개발을 공부하는 것은 공부가 아니라 놀다보면 습득되는 것이고 보람찬 작업이다.
사람 중심 개발
깊이 있는 경험
"제한된 시간에 모든 걸 공부하는 건 불가능하기 때문에 몇 가지를 깊이 이해하는 것이 중요합니다. “내가 시간이 없어서 그렇지 깊게 파면 이렇게 잘할 수 있다!”라는 걸 어필할 수 있다면, 회사 입장에서도 “뽑은 다음에 키우면 되겠다”라고 생각할 수 있습니다." https://subicura.com/2021/06/27/study-guide
현업에서 문제는 수없이 많고 고도화된 뭔가를 개선하는 임무는 단기간에 미션이 주어진다고 바로 해결할 수 있는 건 아니다. 문제가 닥쳤을때 하나씩 개선해보면서 결과적으로 하나씩 바꿔나가는거지 한번에 다 해결할 수도 없고 그러길 원하지도 않는다. 과제가 주어졌을 때 엄청난 뭔가를 만들려고 하지말고 기본적인 걸 잘 챙기도록 해야겠다
주절 주절
정리하는 것이 좋습니다. 물건 정리에서부터 지식 정리 등을 포함하여 정보를 쌓고 핵심만 추려서 남기는 작업을 좋아합니다. 물건으로서는 미니멀하게 갖고 있는 물건을 줄이며 효율성을 높이고, 물리적 데이터를 전산화하는 작업을 통해 자료를 집적하고, 관리하고 있습니다. 인프라 개발자는 소프트웨어에서 정리를 하는 직업이라 생각하고, 기존에 두 단계로 거치는 작업을 한 단계로 정리하는 작업에서 많은 기쁨을 느꼈습니다. 인프라를 개선하면서 개발자들이 메인 비즈니스 로직에만 집중할 수 있는 환경을 만들기 위해 고민하고 있습니다. 정리하는 것은 가치 있습니다. 기술적으로 효율성을 높일 수 있고, 사람들에게 직관적으로 다가가기도 좋습니다.
개발자는 책 편집자처럼 편집의 역할, 영화감독의 전체를 관리하는 역할, 그리고 작가의 상상을 쌓고 자신의 것만 남기는 정리 작업을 실체적 구현으로 하는 작업이 가능합니다. 개발자로서 이전보다 더 나아지기 위해 고민하고 실제로 구현을 해서 개선시키는 작업이 좋습니다. 영화를 보면서 떠오른 생각을 개발과 연관시키고, 다른 분야에서의 훌륭한 결과물을 보고 개발과 연관시킬 수 있는 이 개발자라는 직업이 좋습니다.
미니멀리즘에 대해 관심 있게 지켜보고 있습니다. 미니멀리즘은 적게 가지는 게 아니라 더 뺄 게 없을 때까지 고민하고 알아가서 줄여나가는 과정이라는 것에 공감했습니다. 그래서 미니멀과 소프트웨어를 같이 고민할 수 있는 것이 무엇이 있을까 고민하다가 인프라 관리 영역이 딱 맞다고 생각하게 되었습니다. 예전에는 인프라 관리를 위해 수많은 툴들을 설치하고 관리했어야 했습니다. 그리고 시간이 흘러 컨테이너가 등장하면서 쿠버네티스라는 적절한 툴이 인프라 관리를 한 단계 추상화해주었습니다. 또 테라폼 등 코드로 인프라를 관리할 수 있게 되어 한층 더 효율적으로 된 것 같습니다. 이제 인프라 관리에 이것저것 섞인 형태가 아니라 쿠버네티스를 잘 관리하면 인프라 관리가 되겠다고 가능성을 보았고, 개인적으로 쿠버네티스를 구축해 사용하고 있었습니다. 그리고 이 교육과정을 보게 되었고, 그동안 못 해봤던 실제 운영 환경에서 다루는 경험을 해보게 되는 것이 저를 성장시켜줄 수 있을 거라 생각해 지원하게 되었습니다.
DevOps, 인프라 엔지니어로 계속 성장해 나가고 싶습니다. 현실 세계를 탐구해나가면서 생활과 밀접한 다른 분야에서의 좋은 점을 배우고 소프트웨어에 적용해 나가고 싶습니다. 지금도 테라폼, 쿠버네티스 등 기가 막힌 툴들이 있지만, 저도 인프라 관리를 쉽게 하는 통찰력 있는 툴을 만들어봤으면 좋겠습니다.
QA, data science, ml, design, server, architecture, test 데브옵스로서 역할에 대한 공부 뿐 아니라 개발자들의 편의를 위해 각 분야의 사이클을 경험함으로써 와닿는 경험 개선을 줄 수 있다고 생각했다. 트레이드 오프로 데브옵스의 일에만 집중하여 기술적 고도화를 이루는 것은 뒤로 미뤘는데, 고도화된 경험은 직접적인 경험을 통해서 개선시킬 수 있다고 생각하고, 실제로 일을 하면 공부해왔던 것과는 다른 경험을 하게 될 것이라는 생각이 있었다. 내가 혼자 시뮬레이션하는 것도 의미있지만 실제로 업무 중에 겪는 경험을 따라갈 수 없다고 생각. 그래서 실제 경험을 하게 될 때의 시행착오를 줄이는 방법을 연구하고 전체적인 흐름을 파악하는 것에 집중하여, 실제 문제 상황이 닥쳤을 때 유연하게 생각할 수 있는 능력을 길렀다고 생각한다.
Top Personal Question
- What is the biggest failure you’ve had?
- I’ve made many same failure. I didn’t think deeply each failure. I would have remind my failure.
- Worst failure is I didn’t made backup. And I lost my server everything. Especially updated code lost is very annoying.
- If i didn’t use docker. Maybe It was can’t recovery... after these time. I’ve always think backup.
- Server need snapshot, drive backup, DB backup, source backup like that.
- What is your greatest achievement?
- Can you explain your experience?
- blog/Deploy_ERP_server_story
- I've build internal ERP server for 40 employees
- Why you apply this position?
- Why you come in Berlin?
- to know how people work in here
- to improve my skill to face to big problem
- I want to work with variety people, and new environment challenge.
- What you can bring benefit for company? Why we choice you
- I like make system organize and cleaning.
- I will make all system automatically and easy take feedback.
- benchmark, test, feedback.
- I'm wondering how improve my skill and system make easy.
- every node connection, control, feedback.
- I'm gonna make developer work with keep focusing on development and easy to upgrade your business logic.
- What about the software appeals to you? Do you like programming? If yes, why?
- can program self-check and self-upgrade
- universal used
- no matter age
- can 1 person make many thing
- and small group can make many thing
- how did the problem relate to advancing in the dev process and the final product?
- What do you do when an application stops working?
- check the log, find situation, mock test, fix it
- if the log not exist, remove code to as skeleton, and simulation, and then add some code and simulation when find the bug.
- Tell me about the largest scale development process problem that you or your team have faced and worked through.
Technical interview
- how to make pipeline
- which tool to use
- how to choice a new tool
- about docker, kubernetes, cloud
- devops going to be reduce that system switching annoying.
- make easy add new program. but consist minimum program.
- What’s the difference between SOAP and REST?
- OOP (what is good, why use this)
- oop의 문제점
- 객체에 데이터를 감추는 캡슐화를 중요시하지만 언젠가는 객체의 데이터 접근이 필요할 것이다. 동일한 호출이 매번 다른 결과를 생성할 수 있다.
- 수학적이지 않다. 상태가 가변적이라서.
- go로 배우는 함수형 프로그래밍
- when cache is not useful, and even dangerous
- 새로운 데이터만 계속 들어오면 캐시미스가 발생.
- mvc problem
- too large controller
- view, model이 많아질수록 복잡해져서 추적이 어려워진다
Coding#SOLID Software#Concurrency Architecture#Database Architecture#Distributed Systems Computer_Architecture#Process, Thread Computer_Architecture#memory management
Software Data_Structure Teamwork
리액트 기본 면접 질문
기술관련 리액트가 어떻게 작동되나요? virtual Dom은 무엇인가요? 어떻게 만들어지나요? Hook의 조건은 무엇이 있나요? 리액트 github에서 소스를 살펴보셨나요?
- 리액트 작동방식에 대해 설명해주세요
redux-thunk와 redux-saga의 차이점은 무엇인가요? redux-saga에서 generator에 대해 설명해주세요 immer와 같은 불변성라이브러리의 원리는 무엇인가요? immer와 redux의 shallowEqual을 같이 사용했을 때 얻는 이점은 무엇인가요? context api를 통해 redux를 대체할 수 있는데 왜 사용하셨나요? front에서 CORS를 어떻게 해결할 수 있을까요?
- Back-end에서 처리할 수 없을 때 front에서 어떤 방식을 사용해야 할까요?
렉시컬 스코프와 다이나믹 스코프의 차이점에 대해서 알려주세요 크로스 브라우징이란 무엇인가요? 해보셨나요? css-in-js에서 왜 00를 사용하셨나요? ES5, ES6, Typescript를 연결해서 설명해주세요 빌드된 파일이 너무 크다면, 줄이기 위한 방식은 어떤 것이 있나요?
Reference
- https://github.com/arialdomartini/Back-End-Developer-Interview-Questions
- https://wonny.space/writing/work/engineer-resume
Interview
Experience 1
우리 회사에 대해 아는게 있니 너의 여태까지의 경험을 얘기해줘
- 여기서 챌린징을 하고 공부하려는 의지를 더 보일 수 있게 했어야 했다
왜 데브옵스에 지원했니
- 완전 버벅였다.
5년 후에 어떤 모습이 되있을거 같니
- 완전 횡설수설 했다
- 회사의 변화를 얘기하고, 내 변화도 얘기했으면 좋았겠다
질문있니 연봉은 얼마나 원하니
Experience 2
어떤 개발 문화를 만들고 싶나 자기소개 힘들었던 경험, 어떻게 이겨냈나 제일 어려웠던 문제, 고난 왜 개발자가 되었나 우리 제품 알고 있나 ci/cd에 대해 알고 있나 어떤 것을 가져다 줄 수 있나(뽑을 이유) 커뮤니케이션 스타일 좋아하는 기술 리팩토링 경험
회사에 대해 좀 물어봤어야 했다 의사소통이 느리다고 했을 때 대표님은 호탕하시니 저도 호탕해질 수 있다고 하면 좋았겠다 얘기만 잘 통하면 저의 신중한 부분과 시너지를 낼 수 있다고도. 독일 간 이유에 대해 좀 더 잘 말했으면 좋았겠다
내가 성장할 수 있는 회사일까에 대해서 의문이 든다
두나무
지원동기
- 인프라적인 측면에서 대규모 트래픽 서비스와 실시간 서비스를 경험해보고 싶은 점과 데브옵스 엔지니어로서 개발팀이 서비스에 집중할 수 있도록 하는 작업을 할 수 있다는 점과 데브옵스 팀에 대한 존중이 있는 것 같아서 지원하게 되었습니다.
DevOps 직무 전향에 대한 동기
- 두가지 측면이 있습니다. 하나는 코드 자체보다는 인프라를 구성하는 것과 구성된 인프라를 관리하는 것에 흥미가 있는 것이고 하나는 같이 일하는 동료들이 더 편하게 일하게 해줄 수 있는 환경을 만들어 주는 것에 가장 큰 보람을 느낀다고 생각했습니다.
질문들
- 개발을 시작하게 된 계기와 어떤 개발 경험을 해오셨는지
- 그 과정에서 특히 기억에 남거나 의미 있었던 경험
- 도커가지고 어디까지 해보셨는지
- 쿠버네티스는 어떻게 접하게 되었는지
- 쿠버네티스를 어느 정도까지 스케일링 해봤고 스케일링 하는 과정에서 어떤 의사결정이 있었는지 그리고 어떤 애로사항이 있었는지
- 두배 정도 띄워놓는 것에 대해서는 기술적으로 어떻게 해결하셨는지
- 현재 회사에서 담당하고 계신 데브옵스 관련 업무를 전반적으로 설명
- 데브옵스 문화 중에 적용하거나 신경 쓰는 부분이 있었는지
- 개발자에서 데브옵스로 전향하려는 이유가 뭔지
- 현재 담당하고 계신 업무 외에 관심을 가지거나 배우고 싶은 데브옵스 관련 분야
- 만약에 있다면 어떤 흥미를 가지게 되었고 현재 이거를 배우기 위해서 어떤 노력을 하고 계시는지
- GET과 POST의 차이. 보안성에 차이가 있는지
- 상황 - 과도한 요청이 오는데 데브옵스로서 취할 기술적 방법에 어떤 것이 있는지
- 보안적으로 고려해서 뭔가 뭐 인프라를 만들거나 개발하시는 부분이 있다면 뭐 최근에 적용한 사례라든가 이런 게 있다면 알려주시면 좋을 것 같습니다
바로고
- 이력서 위주의 질문
- 시스템 구성이 어떻게 되어있는지
- kubernetes cluster 업그레이드 할 때 트래픽 관리 어떻게 했는지
- cni는 어떤걸 쓰는지
- ingress에서 service로 통신하는 방식과 service에서 pod로 통신하는 방식 차이
- secret 관리는 어떻게 하는지
- loki가 어떤 파이프라인으로 동작하는지
- ci/cd 어떻게 구성되어 있는지
- 장애 경험과 어떻게 해결했는지. 근데 발견을 할 때 어떻게 했는지 1~2가지
메이크스타 면접 회고
대화는 잘 진행된거 같다 잘 맞춰주신건지 뭔진 모르겠지만
- 회사 소개 팀 소개 해주시고
- 자기소개 간단하게 하고
- 과제 객관식으로 한거 리뷰
- 간단한 문제였긴 했고 간단한 인프라 관련 cs 지식을 보면서 입을 풀 수 있었던 듯
- 과제 아키텍처 리뷰 - 설명 - 우려했던 것보다 매끄럽게 흘러가긴 함 준비를 좀 해서 그런가
- 문제 풀이 - 알고리즘 문제 풀기 - 푸는 과정을 상세하게 설명했으면 좋았을 듯 그치만 쉬운 문제였음
- 피보나치 문제였는데 재귀와 꼬리재귀를 언급했으면 좋았을 듯
- 회사에 있었던 거 어떻게 같이 해결해나갈지 시뮬레이션 - 이건 aws에 있던 리소스를 gcp로 이전하던 상황에서 어떻게 해결할지를 같이 고민해보면서 마이그레이션 능력을 보려고 한 듯
- 이력서를 보고 물어보신거
- 인프라 관리가 무슨 의미인지
- 배포 작업이 뭔지
- 스크립트 작업은 어떤걸 했는지
- Aws서비스는 어떤 프로젝트에서 어떻게 왜 사용했는지
- 답을 잘하려고 태도는 신경 못쓴듯 개발팀장님은 목소리에 힘이 있으셨다.
- 어미를 좀 잘 말하면 좋겠다
- 아키텍처에는 그리 확신이 없는데 이 능력도 키워야할 듯
채팅 시스템 설계
다양한 서비스에서 사용할 수 있는 채팅 시스템을 설계해 봅니다. 채팅 시스템의 주요 기능은 다음과 같습니다:
- 사용자는 1:1 채팅 및 그룹채팅을 사용할 수 있습니다.
- 사용자는 모바일 앱 및 웹 앱에서 접속할 수 있습니다.
- 글로벌 유저에게 최상의 유저 경험을 제공할 수 있도록 합니다.
- 감당 가능한 트래픽 규모는 클수록 좋습니다.
- 텍스트 메시지 외에, 미디어 파일을 첨부할 수 있습니다.
- 사용자의 접속 상태를 표시할 수 있습니다.
시스템을 설계할 때 다음 사항을 고려하세요:
- 프런트엔드 프레임워크와 백엔드 언어는 중요하지 않습니다. 세부적인 사항은 적당한 가정을 사용하여 워크플로를 설계하기만 하면 됩니다.
제출물
- 워크플로가 포함된 아키텍처 다이어그램
설계과정
- 특이 고려 사항
- 글로벌 유저
- 트래픽은 제한 없이
- 미디어 첨부 가능
- 접속 상태 표시
- 기본 아키텍처
- 웹소켓을 이용한 채팅 서비스 -> 정적 html에 람다로 웹소켓 통신
- 유저를 이용해야 하므로 aws cognito 사용
- 글로벌 유저 서빙을 위해 cdn 활용
- 접속 상태는 redis나 dynamodb 활용
- 데이터 관리
- 채팅 이력을 모두 관리하기 위해서 rds를 써야할까 dynamodb로 충분할까
- bedrock 예제에서는 토큰 제한도 있어서 오래되고 큰 데이터를 저장할 필요는 없는데 지속가능한 채팅 서비스를 원하면 rds를 써야할 수도 있다
- 채팅 이력을 모두 관리하기 위해서 rds를 써야할까 dynamodb로 충분할까
- 확장
- 미디어 첨부 기능을 위해 특별한 서비스가 있을까
- 채팅 시스템 설계 사례 한번 확인해보기
- https://jjingho.tistory.com/161 대규모시스템설계라는 책에 이 사례가 그대로 있는 듯
- 통신방식이 주요 고려사항 중 하나인듯 -> HTTP 기반의 웹소켓
- 그룹채팅이라는 점도 유의미하게 설계과정에 들어가야 하는 듯
- 그룹채팅이라서 달라져야하는 점은?
- 궁금증
- 웹소켓이 1대1 통신만 되는건 아니겠지? -> 아닌듯, 다른 예제에서도 다 웹소켓 씀
- 채팅 서비스의 확장으로 알림까지 해주는 것도 고려해야할까? -> 일단 빼자
- 서버가 처리해야하는 로직들은 어떤게 있을까
- 유저목록?
- 채팅이력?
- 람다로 다 처리 가능하지 않을까? -> 실시간이랑은 안맞다
- 아키텍처 설계 시 방향성
- 변경 가능하게
- 관리 쉽게
- 단일 고장점 없애기
- 채팅 서비스로의 특성 : 실시간,
- 무상태
- 예상질문
- dynamoDB에 저장된 데이터와 RDS에 저장되는 데이터는 어떻게 다른지
- 람다가 어떤 것들을 처리하는지 / 서버는 어떤 것들을 처리하는지
- 람다가 웹소켓 통신을 쭉 이어서 처리할 수 있는지
- 왜 주기적으로 RDS에 저장하는지
- 1:1 통신을 할 때의 흐름 설명
- 그룹통신을 할 때의 흐름 설명 -> 데이터 순서 꼬이지 않나요?
- 데이터
- 채팅 이력
- 채팅방 정보
- 유저 정보
- 접속 여부
설계를 왜 그렇게 했느냐
- 기획부터 운영까지 고려하는 아키텍처링을 하고 싶었고 그래서 운영에서 중요하다고 느꼈던 점 중에 관리 포인트를 줄이는 점을 위해 클라우드 매니지드 서비스로 구성하려고 했습니다. 그리고 비용 효율적인 측면을 위해 서버리스를 최대한 활용하려고 했습니다.
- 기본 요구사항을 모두 만족 시키고 제가 만든 제약사항을 기준으로 설계했습니다
- 채팅 서비스 -> 실시간 서비스
- 글로벌 유저 -> 정적 페이지를 최대한 활용하고 cdn을 이용한다
- 트래픽 제한 없이 -> 서버리스, 오토스케일링
- 미디어 첨부 가능 -> s3에 미디어 첨부 후 주소를 dynamodb에 채팅 데이터와 저장 - 람다로 처리
- 접속 상태 표시 -> 현재 접속한 유저에 대한 정보 디비에 업데이트 - 람다로 처리
- 그룹 채팅 -> 이게 좀 고려가 안됐는데
- 그리고 개인적으로 만든 기준
- 채팅 서비스는 인스턴트 성격이 강하고 각 유저별로 독립적인 환경에서 운영한다고 생각했습니다 -> 람다로 가능하겠다
- 그런데 아키텍처를 제출하고나서 계속 생각해보다가 람다가 부적합한 서비스라고 생각되서 v2, v3를 만들어봤습니다. v2에서는 람다를 대체해서 fargate를 쓰도록 했고, v3에서는 fargate를 쓰게 된다면 eks를 쓰지 않아도 될 것 같아서 큐, eks, rds 영역을 제거하고 fargate에 redis pub/sub을 둬서 dynamodb가 하는 역할을 하게 하고 dynamodb는 rds를 대체해서 고정 데이터를 저장하도록 했습니다
- 람다가 부적합한 서비스라고 생각한 이유
- 실시간을 처리하기 위한 용도로는 쓰기 어렵다 -> 연결 유지가 안될 수 있고, 처음 시작 시 지연 시간이 있고, 이를 해결하기 위해 계속 켜놓으려면 비용이 과다해져 람다를 쓰는 의미가 없다
- fargate를 쓰는게 대안이고 redis pub/sub도 써서 메시지 브로드캐스팅용으로 쓰기를 제안한다
- rds를 dynamodb가 대체 할 수 있을까
- 당근 채팅 아키텍처에서 참고를 했는데 인덱스 키 설계를 잘 하는게 중요한데 이것만 잘하면 운영상 이슈가 없었다고 한다
- 채팅목록의 키는 PK는 채팅방 ID를 쓰고, Sort key는 생성시간으로 하면 될 것 같다
- 채팅 서비스는 여러 테이블 간의 복잡한 참조와 연결을 최대한 배제한 설계가 가능할 것이라는 제약조건을 둠
- 당근 채팅 아키텍처에서 참고를 했는데 인덱스 키 설계를 잘 하는게 중요한데 이것만 잘하면 운영상 이슈가 없었다고 한다
- 람다가 부적합한 서비스라고 생각한 이유
- 설계를 함에 있어서 완벽하게 바로 설계할 수는 없고 안정적으로, 변경하기 쉽게 하는게 최선이지 않을까 싶은데 설계했던 것에서 람다를 fargate로 바꾸는 작업은 모놀리스를 마이크로서비스로 바꾸는 작업보다 굉장히 수월한 작업일 거 같아서 서버리스 서비스에 매력을 더 느끼게 된 것 같습니다
- 채용공고를 보니 AWS에서 GCP로 마이그레이션 하고 계신다는걸 봤는데 변경 가능한 아키텍처로 구성되어있어서 마이그레이션을 과감히 시도하는 것인가 싶어 흥미롭고 혹시 제가 그 작업을 하게 된다면 많은 도움이 될 수 있을 것 같습니다
- 테라폼으로 개인적으로 aws 환경과 gcp 환경에서 k8s를 구성하는 연습을 했었는데
- 데이터를 어떻게 쓰는지에 따라 아키텍처가 결정된다고 볼 수 있을 거 같은데 채팅서비스는 nosql로 처리가 가능한 것 같고 이번에 찾아보니까 당근에서는 dynamodb와 redis cluster로 구성을 했다고 하더라
- 데이터베이스는
- 실시간 메시지 전송은 Elasticache
- 채팅 로그 단순 저장은 DynamoDB, (유저 정보도 여기 저장하지 못할 이유가 없다)
- 채팅방/유저 데이터 관리는 RDS
다이어그램
유저 - route53 - cdn - api gateway - lambda - queue(?) - lb - server s3 dynamodb rdb
25/02/12 1차면접
자기소개 이직사유 백엔드는 어느정도 한다고 보면 되는지? 데브옵스로서 커리어패스 왜 데브옵스가 되려는지 블로그를 봤는데 노트정리에 대해 파악한거처럼 장단점 고려해서 뭔가 선택한 사례가 있는지 키네시스 sqs 어떻게 고르게 되었는지 카프카나 래빗mq 같은건 고려 안했는지 여러 환경에서 ci를 했는지 Ci cd 경험 Ci cd 최적화 경험 스프링 ci 했던 과정 스프링 서비스 배포과정 설명 (코드부터 고객 접속하는 것 까지) 로드밸런서 왜 필요한지 커뮤니케이션 어떻게 하는지 개발하면서 이슈있을 때 해결한 경험
전화면접 문제
구글에서 주소 입력 이후에 과정 tls의 동작 순서 http1.1 과 2의 차이 vm과 컨테이너의 차이 서브넷 프라이빗과 퍼블릭 차이 L4, L7 로드밸런서 차이 쿠버네티스 api 통신은 어떻게 동작하는지 쿠버네티스 팟들의 통신 - 팟들끼리 네트워크를 어떻게 찾는지 쿠버네티스 cpu 제한을 왜 사용하는지 서비스 메시 사용 이유와 어떨 때 사용하는지 스프링의 콜드스타트를 개선하기 위해 데브옵스로서 어떤 것을 해줄 수 있을지 nextjs와 스프링을 쿠버네티스에 띄울 때 관리 측면에서의 차이
- AWS 네트워크
- Public/Private 분리
- VPC 서브넷팅 진행
- Bastion 서버
- Public 영역에 설정
- Security Group 설정
- Kubernetes
- EKS 및 기타 사용 가능
- Private 영역 설정
- Bastion 서버와 Admin 통신 가능
- CI/CD 파이프라인
- CI/CD 자동화 완성
- Simple Application 배포
- IaC 활용
- 심플한 애플리케이션 추가 기능 개발
- 과제 수행 과정 설명 문서 제출
- 네트워크 설정
- CIDR 설정은 일단 1/2
- 10.10.4.0 ~ 10.10.5.255
- 10.10.6.0 ~ 10.10.7.255
- CIDR 설정은 일단 1/2
- bastion 서버 설정
- security group 은 ssh만 허용으로 놔두면 될까
- bastion 접속 테스트
- ec2 생성 시 eip 할당 안해놔서 수동으로 진행
- vpc에 igw도 수동으로 연결해줘야 하나 -> 해줌
- ssh 접속 안됨
- subnet의 routing table을 설정 안해줬었음
- public routing table에 igw 연결해주니까 됐음
- eks 세팅
- terraform으로 진행하자
- 기본 예제에 vpc만 하드코딩
- subnet id 수동 - subnet-01a47c30e19f0b895 (private), subnet-07a1df2de3f8bccb3 (public)
- bastion에서 명령어를 실행시키도록 하면 되는데 괜히 엑세스키를 만들었군
- terraform 실행을 bastion에서 해야하나 -> 터널링을 써도 될까
- 로컬에서 terraform 실행 시 권한이 없다 bastion은 권한이 될까?
- eks를 만드려면 AZ 가 2개 이상 있어야 하는데 subnet을 1/2로 해놔서 subnet을 더 못만든다
- 다시 만들어야 할듯.. - private만 /24로 다시 만듬
- argocd로 ci/cd 만들자
- bastion에서 ssh로 접속해서 kubectl 명령어를 날려야하나?
- https://velog.io/@aylee5/EKS-Bastion-%EC%84%9C%EB%B2%84%EC%97%90%EC%84%9C-Private-Cluster%EC%99%80-%ED%86%B5%EC%8B%A0
- node group을 수동으로 생성해줘야 하나
- 생성했는데 node가 빨리 안뜬다. ec2에서 생성은 됐는데 계속 creating 상태
- 생성 실패!
- iam role을 바꿔서 다시 생성해본다
- 실패!
- 유저 그룹에 테라폼 권한을 추가해서 실행해본다
curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
eksctl create cluster --name exam-eks2-pgd-d-guest-002 --version 1.29 --region=ap-northeast-2 --managed
면접 예상 시나리오
이전 면접에서의 기억
- 회사에 대해 알고 있는지 - 지원동기
- 이직사유
- 키네시스 SQS 비교
- 배포 - 모든 고객이 같은 버전으로 업그레이드 할 수 있나
- 물리적 네트워크 장치
- L4, L7
- 가장 기여가 컸던 작업에 대해 소개
-
인적사항에 대한 질문
-
업무경험에 대한 질문
-
기본에 대한 질문 - 네트워크, 서버, 인프라
-
개발 경험 - 코틀린, 자바
-
인적사항에 대한 질문
- 본인에 대해 간단히 소개해주세요
- 6년차 데브옵스 엔지니어로 현재 이커머스 회사에서 AWS와 Kubernetes를 활용한 인프라 개발 및 백엔드 개발을 진행하고 있습니다.
- 데브옵스 엔지니어에 지원하게 된 노성호라고 합니다. 현재 이커머스 회사에서 인프라 관리 및 백엔드 개발을 하고 있고, 백엔드 엔지니어로 입사했는데 인프라 쪽에 관심이 많다는 것을 잘 봐주셔서 인프라 쪽으로 많이 맡겨주셔서 AWS와 Kubernetes를 많이 다뤄볼 수 있는 경험을 했습니다. 또 프론트엔드 업무도 종종 맡았는데 저는 언어에 구애 받지 않고 문제 해결 자체에 흥미가 있어 거부감 없이 잘 처리했고 이런 경험으로 개발 환경 전체를 이해하고 최적화 하는데 큰 도움이 될 거라 생각합니다.
- 왜 지원하셨나요
- 사회적 기여를 하는 회사, 고객에게 가치를 전달하는 것에 가치를 두는 회사에 일하고 싶었습니다. 이 회사는 식량 문제와 지구 온난화라는 사회적 가치에 기여를 하는 회사라는 점에서 관심이 갔고 AI와 데이터를 활용해 지속가능성을 추구한다는 점에서 공감했고 제가 기여할 부분이 많이 있을 수 있겠다 싶어 지원하게 되었습니다. 저는 개발자를 하기 전에 반도체 장비 제작 업무를 해서 하드웨어에도 익숙하고 개발 업무를 하면서 소프트웨어에도 익숙해 모든 파이프라인에서의 이해도를 가지고 개발에 있어서 최적화하는 일을 잘 해낼 수 있을 거라 생각합니다.
- 왜 이직 하시나요
- 인프라적으로 전문적인 경험을 갖고 싶습니다.
- AWS 환경에서 인프라 구축 경험에 대해 말씀해주세요
- EKS로 구축된 환경에서 CI/CD 파이프라인을 관리하고 배포 및 운영 상에 문제가 있으면 해결하는 경험이 있고, CDN과 Route53 등 고객의 요청을 비용 효율적으로 처리하는 서비스를 활용하고, 람다와 키네시스 등 서버리스 서비스도 적극적으로 활용하여 개발하는 경험을 했습니다.
- CDN이 뭔가요
- CDN은 Content Delivery Network의 약자인데 정적페이지 등을 여러 네트워크 저장소에 미리 저장해놓고 지리적으로 가까운 저장소에서 빠르게 응답할 수 있도록 만들어 놓은 서버입니다. AWS에서는 Cloudfront라는 서비스로 제공 중이고 S3등 AWS의 여러 서비스와 연계해서 사용하기 좋은 서비스여서 활용도가 높았습니다.
- CI/CD 파이프라인은 어떻게 관리하셨나요
- 지금 회사에서는 gitlab을 사용하는데 gitlab ci를 이용해서 docker 이미지를 빌드하고 aws ecr에 올리는 ci를 진행하고, argocd를 이용해서 배포 관리를 했습니다
- argocd는 뭔가요
- kubernetes에 특화된 cd 서비스로 쿠버네티스에 리소스를 올려서 argocd가 직접 쿠버네티스의 인그레스, 서비스, 디플로이먼트 등을 시각적으로도 보여주고 생성 및 삭제를 관리해주는 툴입니다
- argocd는 jenkins와 어떻게 달랐나요
- argocd는 cd에 특화된 서비스라서 배포가 된 화면을 시각적으로 잘 보여줬고 설정파일 관리가 간편했습니다
- argocd는 뭔가요
- 지금 회사에서는 gitlab을 사용하는데 gitlab ci를 이용해서 docker 이미지를 빌드하고 aws ecr에 올리는 ci를 진행하고, argocd를 이용해서 배포 관리를 했습니다
- 서버리스 서비스는 왜 사용하셨나요
- 비용 효율적인 부분에서 이점이 있었고
- CDN이 뭔가요
- EKS로 구축된 환경에서 CI/CD 파이프라인을 관리하고 배포 및 운영 상에 문제가 있으면 해결하는 경험이 있고, CDN과 Route53 등 고객의 요청을 비용 효율적으로 처리하는 서비스를 활용하고, 람다와 키네시스 등 서버리스 서비스도 적극적으로 활용하여 개발하는 경험을 했습니다.
- 메시징 서비스에 대해 소개해주세요
- 고객에게 SMS/이메일/카카오톡 등을 보내는 서비스를 외부업체와 계약해 사용하고 있었는데 내재화하는 상황이었습니다.
- 인프라 설계부터 백엔드 개발까지 참여를 했고 기존의 EKS 환경과 다른 모회사의 AWS 환경에서 작업해야하는 환경이라 독립적이면서도 관리포인트가 적은 것이 좋을 것 같아 Elastic Beanstalk이라는 AWS에서 지원하는 관리형 서비스를 이용하게 되었고 여기에 kotlin spring boot를 띄우고, 메시지의 비동기 처리를 위해 이벤트 드리븐 아키텍처를 접목하여 키네시스와 람다를 이용해 대량 데이터를 효율적으로 처리하려고 했습니다
- 설계에서 중요하게 생각한 부분은 무엇인가요
- 멱등성
- 오류 발생 시 처리
- 대량의 데이터에 대한
- Elatic Beanstalk은 무엇이고 이걸 선택한 이유는 뭔가요
- AWS 서비스들을 연계해서 쉽게 쓸 수 있게 해주는 서비스인데 이것 자체로 오토 스케일링이나 로드밸런싱 및 디비연결까지 한번에 관리해주는 서비스입니다. 이런 특징들로 인해 인프라를 관리할 포인트를 줄여주어 모회사의 AWS 권한 요청을 최소화 할 수 있고 빠르고 간편하게 서비스를 구축할 수 있는 장점이 있었습니다
- 이벤트 드리븐 아키텍처는 뭔가요
- 시스템 간의 통신을 이벤트를 기반으로 처리하는 방식을 말하고, 기술적으로는 중간에 큐를 두고 비동기적으로 데이터를 전달하여 처리하는 방식을 말하고 이를 통해 비동기처리와 느슨한 결합과 확장성을 얻게 되는 아키텍처입니다. 대량의 데이터를 빠르게, 손실 없이 전달하기 위해 적합한 방식이었습니다.
-
비동기 처리가 뭔가요
- 설계에서 중요하게 생각한 부분은 무엇인가요
- 본인에 대해 간단히 소개해주세요
회사 분석
가고 싶은 업체의 특성을 파악하여 거기에 맞는 자소서를 준비할 수 있도록 하자
- 데브시스터즈
- 리디북스
- 카카오?
데브시스터즈
- 본인의 커리어에서 추구하는 방향성은 무엇인가요?
- 본인이 전문성과 자신감을 갖추고 있어 강점이 드러나는 영역들이 무엇인가요?
- 데브시스터즈는 이미 10년간 성장하면서 같이 동거동락한 동료들이 있고 나름 학연으로 이어져있는 부분도 있지만 외부에서 온 사람이 다른 시선으로 보여줄 수 있다는 걸 어필할 수 있으면 좋겠다
- 외부를 바라보니 시야가 확장되는 느낌이다. 퍼플에서도 영향을 줄 수 있으면 좋겠다
- 마케팅 리드분의 EO 인터뷰를 보니 자유로운 조직, 열려있는 조직으로 보인다. 실제로 그럴지는 확인해보고 싶다