더하기

서비스 운영&PM 3곳 면접 / 이후 취업 방향은 어떻게?

baektree — Mon, 6 Apr 2026 17:42:18 +0900

지난주 무려 3개 기업의 1차 면접을 치뤘다.
주요 직무는 서비스 운영, PM이었다.

면접을 통해 얻은 인사이트를 기반으로 이후 취업 방향을 점검 및 보완하고자 한다.

1. 퇴직, 부트캠프 꼭 묻더라!

3곳 모두 빠짐없이 퇴직 사유 및 부트캠프 경험에 대해 물었다.
이력이 있으니 묻는 건 당연지사, 또한 퇴사 사유의 주요 원인으로서 데이터 분석에 대한 업무 능력 함양을 어필했으니 두가지를 결부해 묻는 건 너무나 자연스럽다.

이때 나는 이렇게 답변했다.
"실무에서 문제를 정의하고 액션을 도출하는 과정에서 가장 몰입도가 높았어요. 예를 들어 교육 만족도 데이터를 분석해 불만족 원인을 카테고라이징하고, R&R 개편이라는 액션으로 연결해 유사 이슈 재발을 막은 경험이 있는데 그때 문제 해결의 효능감이 가장 컸어요. 그러면서 데이터로 패턴을 보면 더 빠르고 정확하게 인사이트를 뽑을 수 있겠다는 걸 느꼈고, 그 역량을 제대로 갖추고 싶어서 퇴사를 결심했습니다"

위와 같이 답변하면 반드시 후속질문이 들어온다. ("그거 재직 중에도 할 수 있잖아요?")
"4년간 일하면서 서비스를 개선하고 더 많은 사람에게 영향을 미치는 일을 하고 싶다는 방향이 점점 확고해졌어요. 그러려면 프로덕트 중심의 테크 조직이 맞다고 판단했고, 거기서 제대로 기여하려면 데이터를 다룰 수 있어야 한다고 생각했어요. 재직 중에 공부를 시작해봤지만 실무 수준까지 올리기엔 한계가 있어서 퇴사 후 집중하기로 했습니다."

2. AI 활용역량 묻더라.

역시 AI를 통해 어떻게 업무를 효율화 했는지 활용경험을 물었다.
나의 경우엔 업무 당시 활용경험이 별로 퇴직 후 클로드 API로 주소 데이터 정합성 검증하는 파이프라인을 구착한 소재로 답변했다.
"재직중엔 실무에 적용해보지 못했지만, 퇴사 후 직접 써봤습니다. 복지 서비스 운영 중 데이터 정합성 검토 작업에 클로드 API와 구글 스크립트를 연동해서 AI가 잘못된 주소를 자동 라벨링하고 사람이 한 번 검토한 뒤 정정 메일까지 자동 발송되는 파이프라인을 구축했습니다. 이를 통해 360분 걸리던 작업을 60분으로 줄여 83%의 운영효율을 높였습니다."

3. 기타 도움되었던 것들

- 면접 장소엔 30분 정도 일찍 도착해 마인트 컨트롤 하는것이 도움된다.
- 나의 경우 두괄식으로 답변, 수치화 활용, 경험(근거)기반 등을 되내이며 자신감있게 대화하듯이 답변하겠다고 다짐했다.
- 또한 질문의 의도를 파악해 의도에 맞는 답변을 위해 노력했지만 달성하진 못했다. 사실 이건 좀 더 실전 경험이 쌓여야할 것 같다.
- 묻는 말에 두괄식으로 답변하는 데 많은 노력을 기울인 것 같다.

4. 취업 포트폴리오 방향

- CX/서비스 운영 : PM/서비스 기획은 6:4 비율로 지원 계속 할 것
- CX는 문의감소, VOC 분석 강조할 것
- PM은 병원 내 직무 메뉴얼 구상, VOC 강조 할 것
- 간간히 바이브 코딩으로 현재 만들고 있는 앱 완성시키면서 프로덕트에 친화될 것
- 산업 헬스케어, 에듀테크 지속할 것

PM 현직자 인터뷰 " PM은 고객의 목소리를 프로덕트에 반영하는 자 "

baektree — Sun, 15 Mar 2026 19:09:30 +0900

체인지업을 통해 현직자 멘토링을 할 수 있었다.

깨달은 점, 적용할 점으로 나눠 기록해본다.

깨달은 점

1. 다자이너, 개발자 등의 메이커 만으로 프로덕트를 만들 수 있는데 왜 PM이 있어야 하나?

고객의 목소리 반영

PM은 그 누구보다 고객의 목소리를 제대로 듣고 반영하는 사람이다.
고객의 목소리가 제품에 반영되어 비즈니스 성과를 달성할 수 있도록 주도하는데 있어 PM이 필요한 것이다.

우선순위 결정

개발자·디자이너는 각자 전문 영역 관점에서 본다.
비즈니스 임팩트 기준으로 "뭘 먼저 만들지" 결정하는 사람이 없으면 중요하지 않은 것부터 만들게 된다.

조율과 언어 번역

개발자·디자이너·영업팀은 서로 다른 언어로 말한다.
사이에서 맥락을 연결하고 오해 없이 실행되게 하는 역할이 필요하다.

왜 만드는지 anchor

만들다 보면 "이거 왜 만들고 있지?"를 잃기 쉽니다.
PM이 목표와 방향을 계속 붙들고 있는 역할이다.

리스크 관리

잘못된 방향으로 열심히 만드는 것 막고, 빠르게 검증하고 방향 수정을 주도하는 것도 PM이다.

2. 기업에서 어필되는 경험

단연 실무 경험이다.
단, 본인이 원하는 대기업 등은 바로 진입이 어려울 수 있으니, 중간에 다른 회사에 진입하더라도 최종 목적지 진입에 도움이 될만한 경험을 가져잘 수 있는지 잘 판단하여 지원해야 한다.
즉 유사 도메인 내 성공경험이 중요하다는 뜻이다.

3. KPI

"우리 회사에서도 고무적인 퍼포먼스를 달성할 수 있을까?"
일을 잘 할 수 있을지 확인하는 목적 (지원 하는 곳의 아웃풋 재현가능성 짐작용)
따라서 유사 도메인 내의 성공경험 내에서 KPI 달성여부를 확인한다.

4. 주요 산출물

RFP (Request For Proposal 요구사항 명세서)
- 목적
- 고객
- 니즈
- 페인포인트
- 기대사항
기획
- 서비스 기획서
- 플로우 차트
- 와이어프레임(스케치
- 화면 설계서(스케치 + 동작설명 + 개발지침)
- 서비스 정책집
- 데이터 정책집
관리
- 계약서
- WBS(작업 일정표)
- 의사소통/요구사항 정리

=> 위와 같은 작업 산출물을 만들어본 경험 강조

5. 산업의 지식정도

산업 트렌드, 고객 니즈, 페인 포인트 정도 알고 이어야 함.
덧붙여 어떤 식으로 인공지능을 도입할 수 있을지 알고 있으면 좋음.
고객의 유저 저니 맵 참고

6. 채용공고 분석

회사가 지금 유저수를 늘리는 단계인지, 그 이후 리텐션을 고민하는 단계인지에 따라 강조해야 하는 KPI가 다를 수 있음.
단 이는 데스크 리서치 만으로 파악이 어려우므로 면접 준비 단계에서 파악해서 어필하면 효과적!

적용점

1. 운영/PM 관점에 따라 핵심 KPI 조정하고 서류합격률 변화 추이를 관찰하자

2. 과정-조사-개선-성과 형태로 3C4P 수정하자

3. 하프래디 웹/앱 서비스 만들면서 주요 산출물 경험하고, 포트폴리오에 녹이자 (올바른 방향임을 입증)

PM/PO 직무 파헤치기 | 현직자 만남 | "서비스를 만들고 배포하세요."

baektree — Wed, 4 Mar 2026 01:27:51 +0900

DDP에서 열린 서울시 주관, 청년 성장 올인데이에 다녀왔다.

목적은 2가지, (1) PO 현직자 만나서 사고 확장 (2) 이력서 및 포트폴리오 첨삭이었다.

이번 프로그램 참여를 통해 인사이트 부분을 정리하고 내 커리어 방향성에 녹여보고자 한다.

(1) PO 현직자 소통

내가 만난 분은 토스의 부동산 프로덕트 PO셨다.

창업의 경험을 보유하셨고, 토스의 미션과 비전 일하는 방식에 공감하여 입사를 하셨다고 한다.

하는 일부터 어떤 자세와 태도로 커리어 로드맵을 그려가야 하는지 많은 조언을 해주셔서 매우 유익했다.

그중 내 마음에 콕 남게 된 인사이트 몇 가지를 적고 나는 앞으로 어떻게 하면 좋을지 생각해 보았다.

DA가 분석한 결과물을 토대로 서비스 성장을 위한 가설을 수립한다. 가설을 실험하기 위해선 Maker(디자이너, 개발자)를 설득해야 하는데, 이때 비즈니스 비전과 유의미한 아젠다를 건네는 게 중요하다. 이후 초기 수립한 가설을 검증하게 되고, 이러한 사이클을 매번 반복한다고 한다.
토스에 입사를 희망하면 코어밸류 3.0을 잘 살펴보라고 하셨다. 토스팀의 일하는 방식이 담겨있는 아티클이다.

토스 핵심 가치 3.0의 탄생 : 실패와 패배가 지긋지긋할 때

토스팀이 일하는 방식을 담은 토스 핵심 가치가 최근 3.0으로 업데이트됐어요. 코어 밸류라고도 부르는데요. 아이폰이나 안드로이드폰의 운영체계(OS)도 아닌데 이렇게 버전을 붙이고 업데이트

toss.im

AI로 인해 직무의 경계가 허물어지고 있다. PRD 역시 AI가 작성한다. AI를 활용하여 어떻게 PM/PO 업무를 효율화할 것인지, 보다 근원적인 부분에만 집중하기 위해선 어떻게 해야 하는지 고민하는 게 중요하다고 생각했다.
한 프로젝트를 하더라도 딥 다이브를 하는 게 중요하다고 한다. 그 과정에서 WHY를 계속 던지며 설계, 실험을 반복해야 한다. 토스는 얼마나 깊이 있게 고민하고 실험하고 시도해 보았는지 본다.
앱인토스라고 토스 내 서비스를 배포할 수 있는 플랫폼 환경이다. 해당 앱을 살펴보며 사람들의 수요와 어떤 문제를 어떤 방식으로 풀어냈는지, 왜 그 방식을 채택했는지, 사람들의 반응은 어떤지, 선택되는 앱과 선택되지 않는 앱의 차이는 뭔지 보고 나도 내가 풀고 싶은 문제를 한번 풀어봐야겠다.
최고의 포트폴리오는 서비스 개발 및 배포이다.
기업은 실무에 투입했을 때 바로 성과를 만들어 낼 수 있는 사람을 뽑고 싶어 한다. 즉 회사가 당면한 문제를 해결할 수 있는 역량이 있나 검증하고 싶을 것이다. 따라서 링크드인을 활용해 현직자에게 해당 포지션의 채용 이유를 물어보면 좋다. 즉 기업에서 해당 포지션의 사람을 뽑으려는 이유, 그 사람을 통해 풀려고 하는 문제를 파악하면 좋다. 그러면 면접에서 직무 핏을 소구 할 수 있다.
실제 생활하며 경험하는 모든 데이터를 통해 가설을 설정해 보는 사고 연습을 해보면 좋다고 느꼈다. 가령 당일 현장에서 9시라는 이른 시각임에도 높은 참여율을 보고 현직자 소통에 대한 구직자들의 갈증으로 해석해 "구직자들은 현직자와의 접점을 갈망하고 있다. 이에 관련된 서비스를 구축하면 사람들이 모여들 것이다. "라는 가설을 수립해 볼 수 있다.
디자인 씽킹 프레임 활용해 사고 체계를 연습하면 좋다. (디자인 씽킹에 대해선 잘 몰라서 한 번 찾아봐야 할 것 같다.)

역시 PM/PO의 최고의 결산물은 서비스 배포라는 것을 뼈저리게 느낀 시간이었다. 아무리 AI가 개발에 대한 장벽을 낮춰졌다고 한들, 나에게는 여전히 장벽처럼 느껴졌다. 그리고 무엇보다 어떤 문제를 어떤 방식으로 해결할 것인가에 대한 아이디어가 떠오르지 않았다. 내 삶의 바운더리가 좁아서인지, 문제해결식 사고 과정을 연습하지 않아서 인지... (지금 생각해 보니 둘 다 인 것 같다.)

그렇다면 뭐 연습해야지 별 수 있나, 아무튼 인앱토스를 활용해 사람들이 업로드한 앱들은 뭐가 있는지, 이 앱은 어떤 문제를 풀고자 했는지 한번 탐색 후 나도 내 문제를 서비스 배포로 풀어봐야겠다. 따지고 보면 취업을 하더라도 은퇴할 텐데, 그땐 내 이름 걸고 내 서비스를 내세울 수밖에 없는 사회 구조가 도래하지 않을까 싶다. 즉 나이 듦이나 사회변화로 인해 더 이상 회사 내에서 내 생계를 연명하기 어려운 때는 반드시 올 거란 무서운 예감이 든다. 그 시기를 미리 준비한다 생각하고, 실패해도 상관없다 치고~ 해보자!

(2) 이력서 및 포트폴리오 첨삭

준비해 간 이력서와 포트폴리오를 첨삭받았다.

하나부터 열까지 꼼꼼히 읽어주신 모습에 조금 감동을 받기도 하였다.

타자의 시선에서 이게 이해가 될지 염려되었는데 그 부분에 대한 부정적 피드백은 없었다.

다만, 여태까지 해왔던 outcome과 현재 내가 가고자 하는 방향(IT/PM/PO)과의 접점을 찾기 어렵다는 지적을 받았다.

즉 복지나 운영 측면에선 괄목할만한 성과라고 생각되고, 서류단계에서 검토될만하나 내가 지원하는 분야에선 의구심이 든다는 것이다. 그래서 집으로 돌아오는 길에 생각해 봤다.

난 왜 굳이 IT를 희망하는 걸까? 내가 원하고자 하는 꿈을 IT가 아닌 곳에서도 풀 수 있지 않을까?

이 질문엔 난 2가지 답을 할 수 있겠다. 내 성장의 영역과 영향력을 확장하고 싶어서 그리고 멋지니까 ^^

지난 회사에서 내가 가장 몰입하고 보람되었던 과정에 대해 말하자면, 단연 운영 모델을 설계한 일을 꼽을 수 있다. 1단계부터 9단계까지 어떤 방식으로, 어떤 도구를 가지고 작업을 수행할지 결정한 것, 작업 과정에서 발견한 페인 포인트를 해결할 방법을 강구하고 적용해 본 것, 사람이 아닌 구조에 의해 output이 나오도록 표준화한 것, 당사자의 참여 정도와 의욕을 고취시키기 위해 그 일의 공헌과 나의 역할을 충분히 납득시키려고 노력한 점 등 0에서 1을 구축해 나가는 그 과정 자체가 고되지만 가장 몰입했고 보람되었다고 자신한다.

하지만 내가 활동했던 영역은 오프라인으로 내가 설계한 구조를 누리는 인원은 제약되었으며, 물리적인 환경 내에서 개선 포인트를 포착해 내는 한계도 있었다. (물론 내 시야가 좁아서 더 이상 업그레이드 할 부분을 정의하지 못했을 수 있다.) 어찌 되었건 난 작동하는 구조를 만들어 더 많은 사람들이 그 효용을 누리게끔 그 영향력의 범위를 넓히고 싶었다. 그러한 조건이 잘 갖춰진 그라운드가 it라 생각했던 것이다. 또한 it는 실험의 반복 아닌가? 내가 생각했던 가설을 수없이 많이 실험할 수 있다. 그러면서 내 성장엔 가속도가 붙을 것이라고 의심치 않는다. 그리고 그냥 간지가 난다. IDE에서 로직을 구상하며 타닥타닥 타자를 치는 그런 전형적인 it직군의 모습이 난 예전부터 존멋이라고 생각했다. 그리고 완전히는 아니지만 Python, SQL을 공부했으니 일부분 흉내를 낼 수 있게 된 내 모습도 자랑스럽다.

오프라인 환경에서 벗어나 온라인 환경에서 100 단위, 1000 단위 이상의 고객에게 영향력을 끼치고 구상한 가설과 실험을 반복하며 서비스를 최적화하는 일, 그것을 잘할 수 있는 분야가 IT라 생각했고, 나는 거기에 지원하고 있다.

그러니, 일단은 이 방향 유지하며 킵고잉 한다. 뭐~ 내 인생이니까^^

프로젝트의 뼈대를 구성하는 핵심 문서: User Flow IA, 기능 명세서, 스토리보드, WBS

baektree — Wed, 25 Feb 2026 10:25:00 +0900

1. 유저 플로우

- 사용자가 서비스에 진입해서 목표를 달성하기까지의 이동경로를 도식화한 문서

- 사용자의 논리적 동선과 예외 상황(로그인 실패)을 시각적으로 표현

- 예시 : 더 알아보기

2. 정보 구조도(IA, Information Architecture)

- 서비스의 전체 메뉴 구조와 콘텐츠의 계층 구조를 설계한 지도

- 서비스의 전체 규모를 파악하고, 각 페이지에 담길 정보의 위치를 결정하는데 사용

- 더 알아보기

3. 기능 명세서 (Functional Specification)

- 서비스가 작동하기 위해 필요한 모든 기능을 텍스트로 정의한 문서

- 버튼 동작 조건, 데이터 처리 방식 등을 상세히 기록, 개발자가 코드를 작성할 때 참고하는 가장 중요한 기준이 됨

- 더 알아보기

4. 스토리보드(Storyboard / Wireframes)

- 화면 설계도와 해당 화면에 대한 설명이 결합한 문서

- 와이어 프레임 옆에 정책과 인터랙션을 기술

- 디자이너는 이 화면을 보고 디자인하고, 개발자는 기능 설명을 보고 화면을 구현

- 더 알아보기

5. 작업 분할 구조도 (WBS, Work Breakdown Structure)

- 프로젝트 전체 일정을 세부 작업 단위로 쪼개어 담당자, 시작일, 종료일을 정리한 일정표

- 주로 간트 차트 형식으로 작성

- 프로젝트가 계획대로 진행되고 있는지 관리하고, 마감 기한을 준수하기 위해 사용

- 더 알아보기

<비교표>

구분	주요 특징	주요 대상	작성 시점
유저 플로우	사용자의 행동 흐름 시각화	UX 기획자, 개발자	서비스 논리 설계 단계
정보 구조도(IA)	서비스 전체 구조 및 메뉴 체계 설계	기획자, 클라이언트	구조 설계 단계
기능 명세서	기능 구현에 필요한 상세 요건 정의	개발자, QA(검수)	개발 시작 전
스토리보드	화면 디자인 및 상세 작동 가이드	디자이너, 개발자	상세 설계 단계
WBS	업무 분담 및 프로젝트 일정 관리	PM, 모든 이해관계자	프로젝트 전체 기간

헷갈리는 개념: dict, JSON, XML

baektree — Thu, 19 Feb 2026 17:10:41 +0900

생김새가 비슷하여 자꾸 헷갈리는 개념들 디셔너리, JSON..

제대로 숙지하기 위해 정리해보았다.

✅ 1. 딕셔너리 (dictionary, dict)

run = {
    "distance": 5000,
    "time": 1800
}

- 파이썬 쓰는 자료구조

- 키와 값으로 쌍으로 이루어진 자료 구조

- 키(key) : distance, time

- 값(value): 5000, 1800

- 키는 중복될 수 없다.

✅ 2. JSON

{
  "distance": 5000,
  "time": 1800
}

- 텍스트 기반 데이터 포맷

- 즉 시스템끼리 데이터를 주고받기 위한 텍스트 포맷으로 api응답용으로 활용한다.

- 파이썬에서는 보통 json.loads() 로 읽어서 dict으로 바꿔 사용한다.

✅ 3. XML(Extensible Markup Language)

<run>
    <distance>5000</distance>
    <time>1800</time>
</run>

- 태그로 구조를 표현하는 데이터 포맷

- 파이썬에선 파싱해서 구조로 바꿔 사용

- 파싱? json, xml 같은 파일을 파이썬에서 다룰 수 있는 구조로 변환하는 단계

- json을 dict으로, xml을 element나 tree로

- 따라서 파싱 후 일부 데이터(필드)를 추출하다라고 표현할 수 있음.

✅ 마지막 정리 : 비교표

구분	딕셔너리(dict)	JSON	XML
정체	파이썬 자료구조	데이터 포맷	데이터 포맷
사용 위치	파이썬 코드 내부	파일 / API / 통신	파일 / 시스템 연동
형태	{ key: value }	{ "key": value }	<tag>value</tag>
사람이 보기	쉬움	쉬움	상대적으로 복잡
파이썬에서 사용	그대로 사용	파싱해서 dict로 변환	파싱해서 구조로 변환
핵심 용도	계산·처리용	데이터 전달·저장	구조화된 데이터 전달

정리하자면

파이썬 내부 자료구조는 딕셔너리

파이썬 외부 데이터 포맷은 JSON, XML

이 두가지 파일 포맷을 파이썬 내부에서 사용하기 위해선 딕셔너리 등으로 파싱해서 사용하면 됨.

파싱이란 XML, JSON같은 문자열 파일을 파이썬에서 다룰 수 있는 자료 구조로 변환하는 과정을 말함.

MySQL_정규표현식_개념, 활용사례

baektree — Sun, 18 Jan 2026 16:49:41 +0900

정규표현식이란?

[문자열 컬럼]  REGEXP  [정규표현식 패턴]

정규표현식은 특정 규칙이 있는 문자열을 걸러내는 규칙 언어이다.
- 예시
  - ing로 끝나는 문자만 추출: ing$ → ending, running
  - A로 시작하는 문자만 추출: ^A → APPLE, APPLY
^[A-Z][a-z]+$ 와 같은 문자 패턴으로 표현된다.
REGEXP는 정규표현식 패턴을 문자열에 적용해 결과를 판단하는 SQL 문법이다.

정규표현식 적용 결과 어떻게 확인하나?

https://regexr.com/
regexr.com은 정규표현식이 어떤 문자열과 어떻게 매칭되는지 실시간으로 보여주는 도구이다. 테스트하는데 유용하다.

실무 예시 (MySQL)

1. 완전히 숫자로만 이루어진 문자열

^[0-9]+$

^ : 문자열 시작
[0-9] : 0~9 사이 숫자 하나
+ : 앞 패턴이 1개 이상 반복
$ : 문자열의 끝

2. 영문자 + 숫자로 이뤄진 문자열

^[a-zA-Z0-9]+$

^ : 시작
[A-Za-z0-9] : 소문자영문, 대문자영문, 숫자 중 아무거나 1개
+ : 1개 이상
$ : 끝 (소문자영문, 대문자영문, 숫자 중 1개로 끝나야함)

3. 이메일 간단 유효성 검사

^[a-zA-Z0-9]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$

^[a-zA-Z0-9]+ : 소문자 또는 대문자 또는 숫자로 1개 이상 시작
@: 반드시 @ 있어야 함
[a-zA-Z0-9.-] : 소문자 또는 대문자 도는 숫자 또는 . 또는 - 로 1개 이상
\. : 문자 자체 (\로 escape)
[a-zA-Z]{2,}$ : 소문자 또는 대문자로 마무리 대신 2글자 이상으로 끝남

정규표현식은 원하는 패턴의 문자열을 추출할 때 유용한 표현식이다.

특정 문자나 숫자로 시작되는 값 등을 편리하게 필터링 할 수 있다.

SQL (다중 JOIN) - Top Competitors

baektree — Fri, 2 Jan 2026 15:48:16 +0900

문제

https://www.hackerrank.com/challenges/full-score/problem?isFullScreen=true

목표/풀이

[리더보드 만들기]

조회: 해커 아이디, 이름을 출력하기
조건: 단 2개 이상의 챌린지에서 만점을 받은 사람에 한해서
정렬 : 만점 받은 챌린지 개수 내림차순, 아이디 오름차순

[테이블 살펴보기]

hackers
- hacker_id
- name
difficulty
- difficulty_level
- score : 최대점수(=만점)
challenges
- challenge_id
- hacker_id : 챌린지를 만든 아이디 ⭐
- difficulty_level
submissions
- submission_id : 제출 아이디
- hacker_id : 제출한 아이디(=문제를 푼 아이디) ⭐
- challenge_id
- score: 자기점수

[문장을 SQL 코드로 맵핑]

print the respective hacker_id and name (해커 아이디와 이름을 출력하세요)
- ⇒ SELECT hacker_id, name
who achieved full scores for more than one challenge (2개 이상의 챌린지에서 만점을 받은 사람만)
- ⇒ COUNT(challenge_id) > 1
- ⇒ difficulty_level이 같을 때, WHRE s.score = d.score
order by the total number of challenges in which the hacker earned a full score. / then sort them by ascending hacker_id. (만점 받은 챌린지 개수 내림차순, 해커 아이디 오름차순)
- ⇒ COUNT() DESC, hacker_id ASC

틀린 코드

submissions ↔ challenges 관계 해석 오인
- s.hacker_id는 문제를 푼 사람, c.hacker_id는 문제를 만든 사람으로 같지 않는데, 컬럼명이 똑같아서 연결했다. 테이블의 컬럼 간 관계를 제대로 파악하자 (무엇을 기준으로 연결할 수 있을지)
챌린지 개수 세기
- COUNT(hacker_id)로 함.
- 해커 아이디를 세는 것이 아니라 만점 받은 챌린지 개수를 세는 것이므로 COUNT(challenge_id)가 되어야 함

SELECT s.hacker_id , h.name , COUNT(s.hacker_id) 
FROM submissions s 
	INNER JOIN challenges c ON s.hacker_id = c.hacker_id 
	INNER JOIN difficulty d ON c.difficulty_level = d.difficulty_level 
	INNER JOIN hackers h ON s.hacker_id = h.hacker_id
WHERE s.score = d.score 
GROUP BY s.hacker_id, h.name
ORDER BY COUNT(s.hacker_id) DESC, s.hacker_id

정답 코드

/*
[로직]
1. 만점 챌린지가 2개 이상인 해커 정보를 구하기 위해서 난이도, 만점 점수, 자기 점수 등을 결합해서 볼 필요가 있음 -> 조인
2. submissions ---- challenge_id ----- challenges
3. challenges ---- difficulty_level ---- difficulty
4. difficulty --- hacker_id ---- hackers
5. 본인 점수가 만점인 경우 : s.score = d.score
6. 해커 아이디, 이름 별 그룹핑
7. 이때 챌린지 2개 이상 만점자에 한함 HAVING COUNT(...) > 1 
8. 정렬조건 추가 
*/

SELECT s.hacker_id , h.name , COUNT(s.hacker_id) 
FROM submissions s 
	INNER JOIN challenges c ON s.challenge_id = c.challenge_id 
	INNER JOIN difficulty d ON c.difficulty_level = d.difficulty_level 
	INNER JOIN hackers h ON s.hacker_id = h.hacker_id
WHERE s.score = d.score 
GROUP BY s.hacker_id, h.name
HAVING COUNT(s.challenge_id) > 1
ORDER BY COUNT(s.challenge_id)  DESC, s.hacker_id ASC;

주의사항

최종적으로 구하려는 값을 가지고 어떻게 조인하면 좋을지 생각하기
- 이때 연결하려는 두 테이블의 관계를 잘 살펴보기
- 어떤 컬럼을 기준으로 연결해야 하는가
- 1:1 관계인가 1:N 관계인가
- 특별한 결합 조건이 없는 INNER JOIN인가, 한쪽 테이블의 모든 정보가 포함되어야 하는 LEFT JOIN 인가
챌린지 개수를 세고 있음
- COUNT(s.challenge_id) 떠올리기

SQL (MySQL, Oracle 중앙값 구하기) - Weather Observation Station 20

baektree — Thu, 1 Jan 2026 14:24:19 +0900

문제

https://www.hackerrank.com/challenges/weather-observation-station-20/problem?isFullScreen=true

목표/풀이

A median is defined as a number separating the higher half of a data set from the lower half. Query the median of the Northern Latitudes (LAT_N) from STATION and round your answer to 4 decimal places.

중앙값은 전체 데이터에서 상위 50%와 하위 50%로 나뉘는 숫자이다.

북위도의 중앙값을 구하고, 소수점 4자리까지 반올림해서 표현하라

코드

DBMS에 따라 중앙값을 구할 수 있는 함수가 다르다.

Oracle

Oracle은 간단하다. MEDIAN을 활용하면 중앙값을 쉽게 구할 수 있다.

SELECT ROUND(MEDIAN(LAT_N), 4)
FROM STATION;

MySQL

MySQL은 MEDIAN 함수가 없다. 그래서 PERCENT_RANK()를 활용해 볼 수 있다.
PERCENT_RANK()는 백분율 순위를 계산하는 윈도우 함수로 0.0에서 1.0 사이의 값을 반환한다.
따라서 중앙값에 해당하는 값을 출력하기 위해 PERCENT_RANK() 가 0.5인 북위도 값을 출력하면 된다.

SELECT ROUND(LAT_N, 4)
FROM ( SELECT LAT_N, PERCENT_RANK () OVER (ORDER BY LAT_N) AS percent
       FROM STATION ) t
WHERE percent = 0.5

SQL (계층쿼리, INNER JOIN) - New Companies

baektree — Wed, 31 Dec 2025 14:35:51 +0900

문제

https://www.hackerrank.com/challenges/the-company/problem?isFullScreen=true

목표/풀이

회사, 설립자별 리더, 시니어, 매니저, 직원 명수 구하기

처음 작성한 코드

SELECT c.company_code
    ,  c.founder
    ,  COUNT(DISTINCT l.lead_manager_code)
    ,  COUNT(DISTINCT s.senior_manager_code)
    ,  COUNT(DISTINCT m.manager_code)
    ,  COUNT(DISTINCT e.employee_code)
FROM company c
INNER JOIN lead_manager l ON c.company_code = l.company_code 
INNER JOIN senior_manager s ON c.company_code = s.company_code
INNER JOIN manager m ON c.company_code = m.company_code
INNER JOIN employee e ON c.company_code = e.company_code
GROUP BY c.company_code, c.founder
ORDER BY c.company_code;

OUTPUT은 정답처리 되었지만 소요시간이 꽤나 길었음.
이는 company_code로 묶어 불필요한 조합이 무수히 많이 생성되었기 때문
즉 ‘A회사에 속하기만 하면 다 연결해’라는 형식이라 카디널리티 곱폭발 문제가 발생

상세

회사 A에 이런 데이터가 있다고 해보자.

company_code lead_manager_code

A L1

A L2

company_code senior_manager_code lead_manager_code

A S1 L1

A S2 L2

현실은:
- L1 아래엔 S1만
- L2 아래엔 S2만
- 즉, (L1,S2), (L2,S1) 조합은 존재하면 안 됨.
company_code로만 붙이면 무슨 일이 벌어지냐?
이건 “A회사에 속하기만 하면 다 연결해” 라는 뜻이라서 결과가 이렇게 된다:

company_code lead senior

A L1 S1

A L1 S2

A L2 S1

A L2 S2

즉, 서로 상관없는 행들을 회사 단위로 섞어서 “실제론 없는 관계”를 만들어버린다.
만약 회사 A에:
- lead 100명
- senior 200명
- manager 500명
- employee 10,000명
이면 회사 A에서만 대략 행이
- 100 × 200 × 500 × 10,000 = 100,000,000,000 (천억 행 수준) 이나 생겨 처리 과정이 느려짐
- 즉 카디널리티 곱폭발의 시작

수정한 코드

따라서 계층 관계가 명확하다면, 회사별로 조직 계층 (Lead → Senior → Manager → Employee)을 따라 내려가면서 각 레벨에 몇 명이 있는 집계

company
 └─ lead_manager
     └─ senior_manager
         └─ manager
             └─ employee

- 기준 집합: company
- 구조: 계층형 (트리 구조)
- 집계: 회사 단위 GROUP BY

SELECT c.company_code,
         c.founder,
         COUNT(DISTINCT l.lead_manager_code),
         COUNT(DISTINCT s.senior_manager_code),
         COUNT(DISTINCT m.manager_code),
         COUNT(DISTINCT e.employee_code)
FROM company c
LEFT JOIN lead_manager l 
	ON c.company_code = l.company_code
LEFT JOIN senior_manager s 
	ON l.lead_manager_code = s.lead_manager_code
LEFT JOIN manager m 
	ON s.senior_manager_code = m.senior_manager_code
LEFT JOIN employee e 
	ON m.manager_code = e.manager_code
GROUP BY c.company_code, c.founder
ORDER BY c.company_code

주의사항

왜 LEFT JOIN인지?
- 상위 계층은 무조건 유지하고 하위 계층이 없으면 NULL로 두기 위해
- 예를 들어 매니저는 있지만 직원이 0명 인경우도 결과에 포함하기 위함
GROUP BY c.company_code, c.founder
- 회사 단위로 결과 1행으로 만들기 위함
COUNT(DISTINCT l.lead_manager_code)
- 해당 회사에 실제로 연결된 리드 매니저 수 집계
- LEFT JOIN 특성상 매칭되지 않은 경우 NULL이 되며 COUNT는 자동으로 NULL을 제외 함.
왜 DISTINCT인가?
- 계층 JOIN에서는 1:N 관계의 N쪽 조인으로 행이 증가함.
- 예를들어 L1 아래 senior가 2명(S1, S2) 이라면 조인 시 결과에서 L1 행이 2번 반복됨.
- 이 상태에서 COUNT(l.lead_manager_code)를 쓰면 같은 리드가 중복 카운트 되므로 중복 제거를 위해 DISTINCT 필요

SQL (CONCAT, ORDER BY) - The PADS

baektree — Mon, 29 Dec 2025 15:37:57 +0900

해커랭크를 통해 SQL 연습 중이다.

확실히 영문으로 된 문제라 난이도 자체는 쉽지 않지만 독해하는데 꽤 시간이 걸리는 것 같다.

그래도 하다보면 익숙해지겠거니 하면서 천천히 풀고 있다.

문제

https://www.hackerrank.com/challenges/the-pads/problem?isFullScreen=true

목표/풀이

두개의 쿼리를 만들기

첫번째 쿼리
- 이름 오름차순 정렬
- 단, 직업명 첫 글자를 괄호로 감싸서 삽입어구로 제시 예 AnActorName(A), ADoctorName(D), AProfessorName(P),
두번째 쿼리
- 직업 개수 구하기
- 직업 개수 오름차순 정렬 → 직업명 오름차순 정렬
- 아웃풋 포맷: There are a total of [occupation_count] [occupation]s.
  - occupation_count : 직업 존재 개수
  - occupation : 직업명 소문자 </aside>

코드

-- 첫번째 쿼리
SELECT CONCAT(Name, '(', LEFT(Occupation, 1), ')') AS output1
FROM OCCUPATIONS 
ORDER BY Names;
-- 두번째 쿼리
SELECT COANCAT('There are a total of', COUNT(*), ' ', LOWER(Occupation), 's.') AS output2
FROM OCCUPATIONS
GROUP BY Occupation
ORDER BY COUNT(*), Occupation;

주의사항

Query an alphabetically ordered list of all names in OCCUPATIONS, immediately followed by the first letter of each profession as a parenthetical (i.e.: enclosed in parentheses).

→ 모든 이름 알파벳 오름차순으로 정렬하라, 바로 옆에 각 직업명의 첫 글자를 붙여라(삽입어구로, 괄호를 감싸서)

The results of the second query are ascendingly ordered first by number of names corresponding to each profession, and then alphabetically by profession

→ 두번째 쿼리의 결과는 직업 개수 오름차순으로 정렬하라, 그 다음에 직업명 알파벳 오름차순으로 정렬하라

company_code	lead_manager_code
A	L1
A	L2

company_code	senior_manager_code	lead_manager_code
A	S1	L1
A	S2	L2

company_code	lead	senior
A	L1	S1
A	L1	S2
A	L2	S1
A	L2	S2