Quartz 4

AWS SAA Internship Questions - kor

21 min read

  1. 서류 지원
  2. Phone Interview (Phone Screening)
  3. Final Interview

AWS SAA Specific

  1. 2분 내로 자기소개
  2. Solutions Architect의 직무에 대해 간단히 설명해봐.

  • SA가 어떤 일을 하는 조직인지 알고 있는지?

  • 왜 SA 팀에서 일하고 싶은지?

  1. 왜 Solutions Architect가 되고 싶어?

  2. 너가 사용한 AWS 서버스 중 기억에 남는 Best 서비스 Worst 서비스 하나씩 소개해줘.

  3. 왜 AWS에 관심을 갖게 되었는지?

  4. 왜 클라우드 컴퓨팅 기술에 관심을 갖게 되었는지?

  5. Resume엔 개발 쪽 경험만 있고 AWS는 개발 일을 안 하는데 정규직 생각은 없고 인턴 경험만 쌓기 위해 지원하신 건지?

  • Resume엔 개발 쪽 경험만 있고 AWS는 개발 일을 안 하는데 정규직 생각은 없고 인턴 경험만 쌓기 위해 지원하신 건지?
    • 이력서의 간극
    • 마지막으로 물어보고 싶은 것?

Soft skills…

  1. 프로젝트가 많은데, 사람을 모으고 프로젝트를 하려 할 때 주로 발생하는 어려움과 구체적인 해결 방안은 무엇인지?
    • 커뮤니케이션?
      • 실제로 내가 팀장이였을 때 동료가 2틀동안 잠수탄적있었음.
      • 주체적인 해결방안 →그 팀원을 follow up 하고, 연락이 되지 않자 그 사람 진행사항을 보고 남은 것들능 남은 팀원들끼리 적절히 분배
    • 컨벤션/코드 방법 정할때?
  2. 프로젝트 발생 시 어려움에 대한 해결 방안은 본인이 제시하는지, 동료 간 커뮤니케이션을 통해 도출하는지?
    • 먼저 저는 스스로 해결방안이 있으면 스스로 제시해보지만, 나머지 팀원들의 생각도 되도록이면 들으려고 하는 편입니다. 머리가 많아야 좋은 솔루션이 나올 가능성도 높아진다고 생각합니다.
  3. 이전에 했던 프로젝트 중, 실패했다고 생각하는 것(지금 하면 더 잘 할 수 있는 것)은 무엇인지와 그 이유?
    • 개인 블로그
      • “개인 프로젝트로 진행했던 Personal Website & CMS가 아쉬움이 많이 남습니다. 기술적으로는 성공적으로 완성했지만, ‘사용자 관점’에서의 성공은 놓쳤다고 생각하기 때문입니다.
      • 초기에 저는 순수 React(CSR)로 블로그를 만들었습니다. 개발자로서 최신 기술을 사용하는 것에만 집중한 나머지, 검색 엔진 최적화(SEO)의 중요성을 완전히 간과했던 것입니다. 그 결과, 글을 아무리 열심히 써도 구글 검색에 거의 노출되지 않는 ‘아무도 찾아오지 않는 블로그’가 되었습니다.
      • 이 실패를 통해 저는 ‘잘 만든 제품’은 단순히 기능이 동작하는 것을 넘어, 최종 사용자에게 잘 전달되고 사용될 때 비로소 완성된다는 것을 깨달았습니다. 이 경험 이후 저는 서버 사이드 렌더링(SSR)의 필요성을 절감하고 Next.js를 깊이 있게 학습했습니다.
      • 만약 지금 다시 그 프로젝트를 한다면, 기획 단계부터 SEO, 웹 접근성, 성능 최적화 같은 비기능적 요구사항을 최우선으로 고려하여 아키텍처를 설계할 것입니다. 이 실패는 저를 ‘코더’에서 ‘엔지니어’로 성장시킨 값진 경험이었습니다.”
  4. 새로운 기술을 습득할 때, 어떤 방식을 선호하는지?
    • 저는 공식 문서나 기술 자료를 읽으면서, 작은 기능을 만들면서 기본적인 동작 방식을 배우는 것을 선호합니다.
    • 그 다음 제 개인 프로젝트나 현재 업무에 어떻게든 적용해서 작은 기능이라도 만들어 보는 것이 좋다고 생각합니다.
    • 그리고 또한 이론 적인 것에 헤매고 있다면, 친구에게 그 컨셉을 설명하면서 개념을 구체화 시키기도 합니다.

LP Principles!

  1. (Customer Obsession) 고객의 기대를 뛰어넘는 결과를 만들기 위해 노력했던 경험이 있다면 말씀해 주세요.
    • Makeability lab
      1. (S) 네, 청각 장애 사용자를 위한 AR 시스템을 개발할 때였습니다. 초기 목표는 단순히 소리를 시각화하는 것이었지만, 저는 실제 사용자들이 ‘가장 자연스럽고 쉽게’ 사용하는 것에 집착했습니다.
      2. (T) 기술 중심이 아닌, 철저히 사용자 중심의 경험을 만드는 것을 제 목표로 삼았습니다.
      3. (A) 이를 위해, 먼저 DHH 사용자의 시각 정보 인지 특성에 대한 관련 연구 자료들을 분석하여 가장 효과적인 시각화 방법에 대한 몇 가지 가설을 세웠습니다. 그 가설을 바탕으로, 자연어 명령을 UI로 즉시 변환하는 LLM 파이프라인을 설계했습니다. 특히 프롬프트 엔지니어링을 반복적으로 개선하여, ‘파도’ 같은 추상적인 단어를 사용자가 가장 편안하게 인지하는 검증된 형태(예: 부드러운 곡선, 특정 색상 패턴)로 다듬어 표현하도록 시스템을 최적화했습니다.
      4. (R) 그 결과, 사용자의 인지 부하를 최소화하면서도 평균 36.6초 만에 맞춤형 시각 효과를 만들 수 있었고, 사용자 테스트에서 ‘내 생각을 그대로 읽는 것 같다’는 최고의 피드백을 받았습니다. 
    • IT Assistant
      1. (S) Pierce College에서 Assistant Technician으로 일하며 매일 기술적 문제로 어려움을 겪는 수십 명의 학생들을 도왔습니다. 이 학생들이 바로 저의 ‘고객’이었습니다.
      2. (T) 단순히 문제를 해결해주는 것을 넘어, 학생들이 기술에 대한 불안감 없이 학업에만 집중할 수 있도록 돕는 것을 제 목표로 삼았습니다.
      3. (A) 그래서 저는 문제가 발생했을 때 단순히 해결법만 알려주는 대신, 문제의 근본 원인을 이해하기 쉽게 설명하고 다음에 스스로 해결할 수 있는 팁까지 함께 전달했습니다. 예를 들어, Canva 사용에 어려움을 겪는 학생에게는 특정 기능만 알려주는 게 아니라, 가장 자주 쓰는 기능 3가지를 1분짜리 퀵가이드로 만들어 공유하기도 했습니다.
      4. (R) 이런 노력이 쌓여 학생들로부터 꾸준히 긍정적인 피드백을 받았고, 그 결과 ‘올해의 직원(Employee of the Year)‘으로 선정될 수 있었습니다. 고객의 진짜 필요는 ‘당장의 문제 해결’을 넘어 ‘성장과 안정감’에 있다는 것을 배운 소중한 경험입니다.
  2. Dive Deep (깊이 파고들라) 표면적으로 해결하기 어려운 기술적 문제의 근본 원인을 파고들어 해결한 경험이 있나요?
    • Findex
      1. (S) Findex 프로젝트에서 API 응답 속도가 900ms가 넘어 서비스 사용이 어려울 정도였습니다. 처음에는 다들 서버 문제라고 추측했습니다.
      2. (T) 저는 서버 같은 인프라가 아닌, 코드 레벨에서 진짜 병목 지점을 찾아내는 것을 제 목표로 삼았습니다.
      3. (A) 로그와 쿼리 실행 계획을 깊이 분석한 결과, ORM 사용 시 발생하는 전형적인 ‘N+1 쿼리’가 문제의 근본 원인임을 증명해냈습니다. 이후 가장 성능이 좋은 Native SQL 쿼리를 직접 작성하여 데이터 조회 로직을 최적화했습니다.
      4. (R) 그 결과, API 응답 속도를 900ms에서 80ms로 90% 이상 단축시키는 성과를 냈습니다. 현상에 안주하지 않고 데이터에 기반해 끝까지 파고들어 근본 원인을 해결한 경험입니다.
  3. Invent and Simplify (발명하고 단순화하라) “기존의 복잡하고 비효율적인 프로세스를 당신만의 방법으로 더 단순하게 개선한 경험이 있습니까?”
    • Discodeit
      1. (S) Discodeit 프로젝트의 수동 배포 프로세스는 1시간이 넘게 걸리고 실수가 잦아 발목을 잡는 고질적인 문제였습니다.
      2. (T) 이 복잡한 과정을 자동화하고 단순화하여, 코드에만 집중할 수 있는 환경을 만드는 것을 목표로 했습니다.
      3. (A) 저는 GitHub Actions를 활용해 테스트, 빌드, ECR 푸시, ECS 배포까지 이어지는 전체 CI/CD 파이프라인을 새롭게 설계하고 구축했습니다. 특히 멀티-스테이지 Docker 빌드를 적용해 이미지 용량을 60% 줄여 배포 속도를 더욱 높였습니다.
      4. (R) 그 결과, 1시간 걸리던 배포 시간을 3분으로 95% 단축했습니다. 복잡했던 수동 작업을 개발자들이 버튼 하나로 해결할 수 있도록 발명하고 단순화한 것입니다
  4. Bias for Action (행동 지향성) 정보가 부족하거나 상황이 불확실할 때, 어떻게 행동하여 프로젝트를 진행시킨 경험이 있나요?
    • 개인 블로그
      1. (S) 옛날부터 개인 웹사이트 블로그를 운영해보고 싶었지만, 실제로 개발에 실천하자고 결정했을때 어떤 기술 스택이 최선일지에 대한 정보가 너무 많아 조금 부담이 됐습니다.
      2. (T) 완벽한 분석을 기다리며 시간을 허비하기보다, 빠르게 실행 가능한 계획을 세워 일단 프로젝트를 시작하고 반복적으로 개선해나가는 것을 목표로 삼았습니다.
      3. (A) 저는 분석에만 매몰되지 않기 위해, ‘빠른 개발 속도’와 유연성’이라는 원칙을 세웠습니다. 프론트엔드와 백엔드를 하나의 언어(JavaScript)로 관리해 생산성을 높일 수 있는 Node.js와 React, 그리고 스키마 변경이 자유로워 초기 단계에 적합한 MongoDB가 최선이라고 2일 안에 판단했습니다. 가장 중요하고 불확실성이 큰 백엔드 API부터 개발하여 Render에 먼저 배포했습니다. 먼저 핵심 기능을 동작하게 만든 뒤, 이를 바탕으로 프론트엔드 블로그와 관리자 대시보드를 안정적으로 구축해 나갔습니다.
      4. (R) 이처럼 빠른 결정과 행동 덕분에, 몇 주 만에 완전한 기능을 갖춘 풀스택 애플리케이션을 완성하고 배포할 수 있었습니다. 불확실성 속에서도 계산된 행동을 우선시하는 것이 프로젝트를 앞으로 나아가게 한다는 것을 배웠습니다
  5. Learn and Be Curious (끊임없이 배우고 호기심을 갖기) - 당신의 전문 분야가 아닌 새로운 기술이나 지식을 빠르게 배워서 업무에 적용한 사례가 있나요?
    • Artygenspace AR/XR projects
      1. (S) Artygenspace 인턴십에서 Apple Vision Pro용 AR 프로토타입을 개발해야 했습니다. 당시 저는 Unity/C#과 공간 컴퓨팅에 대한 경험이 거의 없었습니다.
      2. (T) 최대한 빠른 시간 안에 visionOS 개발 환경과 C#을 습득하여, 실제 동작하는 프로토타입을 만들어내는 것이 제 목표였습니다.
      3. (A) 저는 업무 시간 외에 개인적으로 관련 온라인 강의를 수강하고, 애플의 개발자 문서를 밤새 읽으며 학습했습니다. 주말에는 LiDAR 센서 데이터를 실시간으로 처리하는 작은 테스트 프로젝트들을 만들며 기술을 체화했습니다. 모르는 부분은 주저하지 않고 시니어 개발자에게 적극적으로 질문하며 해결했습니다.
      4. (R) 그 결과, 2주 만에 첫 AR 프로토타입을 성공적으로 시연할 수 있었고, 인턴십 기간 동안 여러 실험적인 기능을 갖춘 다수의 프로토타입을 개발하며 팀에 기여했습니다. 새로운 기술 스택 앞에서도 두려워하지 않고 호기심을 가지고 빠르게 학습하는 저의 강점을 증명한 경험입니다.
    • Discodeit
      • (S) 저는 Spring Boot를 이용한 백엔드 개발 경험은 있었지만, 이를 클라우드 네이티브 환경에 실제 배포하는 전체 아키텍처 설계 경험은 부족했습니다.
      • (T) 단순히 API를 개발하는 것을 넘어, AWS의 여러 서비스를 조합하여 확장 가능하고 안정적인 클라우드 아키텍처를 직접 설계하고 구축하는 것을 학습 목표로 삼았습니다.
      • (A) 저는 호기심을 가지고 AWS의 VPC, 서브넷, 보안 그룹 같은 네트워킹 개념부터 공부하기 시작했습니다. 또한, 컨테이너 오케스트레이션을 위해 ECS를, 관리형 데이터베이스를 위해 RDS를, 오브젝트 스토리지를 위해 S3를 선택한 이유를 각각 문서와 사례를 찾아보며 깊이 있게 학습했고, 이를 바탕으로 전체 인프라를 직접 설계했습니다.
      • (R) 그 결과, 단순히 코드를 짜는 개발자를 넘어, 인프라 전체를 이해하고 설계할 수 있는 시야를 갖게 되었습니다. 저의 지적 호기심 덕분에 백엔드 개발자에서 클라우드 엔지니어로 역량을 확장할 수 있었습니다.
  6. Frugality (근면, 검소) 제한된 예산이나 리소스를 가지고 더 적은 것으로 더 많은 것을 달성한 경험이 있나요?
    • Artygenspace RAG pipeline
      1. (S) Artygenspace에서 GenAI 기반 음향 효과 검색 시스템을 개발할 때, 가장 성능 좋은 LLM은 API 호출 비용이 매우 비싸다는 제약이 있었습니다.
      2. (T) 무조건 비싼 모델을 쓰는 것이 아니라, 비용, 속도, 정확도 세 가지 측면에서 최적의 균형점을 찾는 것을 목표로 했습니다.
      3. (A) 저는 1,000개 이상의 사운드 샘플 데이터셋을 직접 구축하여, 여러 상용 LLM과 오픈소스 경량 모델들의 성능을 체계적으로 벤치마킹했습니다. 각 모델의 비용당 성능(performance-per-dollar)을 정량적으로 분석하고 비교했습니다.
      4. (R) 분석 결과, 가장 비싼 모델 대비 정확도는 95% 수준을 유지하면서도 API 호출 비용은 70%나 저렴한 특정 경량 모델 조합을 찾아냈습니다. 이로써 제한된 리소스 안에서 사용자 경험 저하 없이 서비스의 운영 비용을 크게 절감할 수 있었습니다.
    • Discodeit CI/CD 파이프라인

백엔드/CS stuff

Project + 꼬리 질문

  1. 최근에 너가 진행한 가장 재밌었던 프로젝트에 대해 소개해봐. (여기서부터 재앙 시작)

  2. SQL DB랑 NoSQL DB를 비교해봐.

  3. SQL DB, NoSQL DB 설명하다 수평 확장, 수직 확장 언급함) 너가 SQL DB는 수직 확장을 한다고 말했는데, SQL DB는 수평 확장이 불가능해?

  4. (NoSQL DB 설명하다 빅데이터라는 단어를 말함) 너가 빅데이터에 대해 얘기해서 말인데, Hadoop ecosystem의 소프트웨어 써본 적 있어?

  5. ETL이라는 개념에 대해 들어봤어?

  6. 너가 진행한 프로젝트 중 ETL을 수행한 프로젝트가 있다면 그 프로젝트에서 한 ETL을 단계별로 자세히 설명해봐.

  7. Cache에 대해 설명해봐.

  8. 마지막으로 물어보고 싶은 것?

이제부터 재앙

Networking

Storage

Security

Database Analytics

Architecture/Infrastructure/OS

Web/App Development

Graph View