분류화란 명확한 기준을 정해 그 기준으로 내용을 나눠 전달하는 기법이다. 핵심은 내용을 쏟아내기 전에 '어떠한 관점으로 크게 몇 가지로 나눠보겠다'고 분류 관점을 먼저 제시하는 것이다. 경영 이론의 MECE(맥킨지 문제분석 프레임워크)가 같은 원리로, 항목들이 서로 겹치지 않고(상호 배타) 전체적으로 빠짐이 없도록(누락 없음) 나누라는 뜻이다. 옷을 상의·하의·외투·속옷·양말 서랍으로 정리하면 나도 남도 한눈에 파악하듯, 말도 기준으로 정리하면 정돈되어 전달된다.
⚠️ 분류 기준은 한 주제에 하나만 쓰는 것이 원칙이다. 하나의 내용에 여러 기준을 마구잡이로 섞으면 오히려 듣는 사람이 더 혼란스러워진다.
▶️ 관련 스크립트
그러면 이 분류화가 뭘까요? 어떤 명확한 기준을 가지고 해당 기준으로 나누어서 말을 하는 것을 분류화라고 하죠.
'어떠어떠한 관점으로 크게 몇 가지로 나눠보겠습니다'라는 형태로 분류 관점을 먼저 제시하는 거죠.
경영 이론에도 MECE라는 게 있어요. 맥킨지에서 사용하는 문제 분석 프레임워크인데, 겹치지 않게 빠짐없이 분류하라는 것입니다. 분류가 그만큼 중요하다는 얘기죠.
여기서 하나의 주제는 하나의 기준을 사용하는 게 좋습니다.
2. WHO 프레임워크와 분류화의 결합
지난 영상의 WHO(Why·What·How·Opinion)가 전체적인 논리 '흐름'과 구조를 잡는 도구라면, 오늘의 분류화는 그 각 단계 안에서 내용을 어떻게 정리할지에 대한 구체적 기법이다. 주로 How 단계에서 쓰지만 Why·Opinion 단계에서도 활용할 수 있다.
구분
WHO 프레임워크
분류화
역할
전체 논리 흐름·구조
각 단계 내부 내용 정리
적용
Why→What→How→Opinion 전체
주로 How(Why·Opinion도 가능)
면접 답변
생략 가능
바로 적용
논술·임원 보고
흐름 잡기
각 단계 내용 채우기
핵심은 WHO로 전체 논리 흐름을 잡고 각 세부 단계를 분류화로 채우는 결합이다.
⚠️ WHO는 전체 논리의 '흐름'을, 분류화는 그 흐름 속 각 단계의 '내용'을 담당하는 층위가 다른 도구다. 면접처럼 짧은 자리에서는 WHO를 생략하고 분류화만 바로 적용해도 되지만, 논술·보고에서는 WHO로 흐름을 잡고 분류화로 각 단계를 채우는 것이 좋다.
▶️ 관련 스크립트
이전 영상 WHO는 전체적인 흐름과 논리적인 구조를 말씀드렸다면, 오늘 다루는 분류화는 Why·What·How·Opinion 각 단계에서 사용할 수 있는 구체적인 기법입니다.
How 단계에서 사용하면 좋은데요, 물론 Why 단계나 Opinion 단계에서도 사용할 수 있습니다.
핵심은 WHO로 전체적인 논리 흐름을 잡고, 각 세부 단계는 분류화를 통해 전달하려는 내용을 적절한 기준으로 나눠서 전달하는 것이죠.
3. 분류화가 전달력을 높이는 다섯 가지 원리
분류화의 효과는 말하는 사람과 듣는 사람 양쪽에 걸쳐 작동한다.
효과
설명
화자 본인이 정리됨
분류 기준을 가지면 내 머릿속이 먼저 구조화돼 기억·발화가 쉬워진다
청자 프레임 형성
'세 가지로 나누겠다'고 하면 청자 머릿속에 틀을 박아 넣어, 그 틀 안에서 사고하게 만든다
장기 기억
흐름과 체계가 있으면 단순 나열보다 훨씬 오래 기억된다
전문성 인상
같은 내용도 잘 구조화하는 사람이 더 전문가처럼 보인다
누락 방지
기준·관점이 있으면 놓치기 쉬운 항목까지 빠짐없이 말할 수 있다
아는 것이 많은 것과 그것을 잘 전달하는 것은 다른 문제다. 면접관 입장에서도 두서없는 답변은 기억에 남지 않지만, 체계적으로 말한 면접자는 수십 건의 면접 뒤에도 오래 기억된다.
⚠️ 분류화의 효과는 화자와 청자 양쪽에 걸쳐 있다 — 화자에게는 기억·구조화를, 청자에게는 프레임 형성과 장기 기억을 준다. 그래서 아는 것이 많은 것과 그것을 잘 전달하는 것은 별개의 능력이다.
📝 적용 예시
질문: "시스템 성능 개선 방법에 대해 말해보라"
— 분류 전(두서없는 나열): 캐시, 커넥션 풀 설정, DB 인덱스, 네트워크, 메모리 증설, 배치 처리, 비동기 처리… → 말은 많지만 핵심이 남지 않고 기억되지 않는다.
— 분류 후(레이어 기준 3분류):
계층
개선 전략
애플리케이션 계층
캐시 적용, 비동기 처리, 배치 처리 검토
데이터(DB) 계층
쿼리 최적화, 인덱스 설계, 커넥션 풀링 최적화
인프라 계층
메모리 증설, 스케일 아웃, 네트워크 튜닝
→ 기술 내용은 동일하지만 레이어로 분류하니 체계적으로 들리고, 청자 머릿속에 레이어 구분 그림이 그려진다.
▶️ 관련 스크립트
이걸 분류해서 말해 볼게요. 저는 크게 세 가지, 애플리케이션 계층·데이터 계층·인프라 계층으로 나눠서 말씀드려 보겠습니다.
그래서 아는 것이 많은 것과 그것을 잘 전달하는 것은 다른 문제일 수 있습니다.
세 가지로 나누어 말씀드리겠다고 하면, 듣는 사람 머릿속에 그 세 가지 틀을 딱 만들어 박아 넣는 겁니다. 그러면 그 사람도 내가 제시한 틀 안에서 사고하게 되죠.
사람은 흐름과 체계가 있으면 기억에 오래 남게 돼 있어요. 단순하게 나열하는 것보다 분류가 잘 돼 있으면 장기적으로 기억할 수 있습니다.
그리고 빠짐없이 말할 수 있어요. 기준과 분류 관점이 있으면 자칫 놓치기 쉬운 것까지 잘 정리해서 말할 수 있게 됩니다.
4. 상황별 분류 기준 카탈로그
어떤 기준으로 나눌지 대표 예시들이다. 특히 개발자의 기술 질문에는 계층(레이어)으로 나누면 대부분 잘 들어맞는다.
기준
구분 항목
적합한 질문·상황
레이어(계층)
애플리케이션·데이터·네트워크·인프라(+사용자·브라우저·단말)
성능 개선, 장애 원인 분석 등 기술 질문 전반
SDLC
요구분석·설계·구현·테스트·운영
"개발 과정에서 무엇을 어떻게?", 품질관리·보안
시간축
사전(예방)·대응·사후(개선)
장애 대응, 보안 사고 대응
보안 3요소(CIA)
기밀성·무결성·가용성
보안 관련 질문
관물기
관리적·물리적·기술적
보안 대책, 개인정보 보호, 기술사 답안
아키텍처 이론
Scale up/out, CAP(일관성·가용성·분단 내성), CAPEX/OPEX
확장성·분산 시스템·비용
품질 속성
성능·보안·확장성
트레이드오프 설명
이해관계자
고객·PM·운영·경영진·개발자
임원 보고, "가장 어려웠던 점"
일련의 처리 단계
개인정보: 수집·저장·이용·제공·폐기 / 위협: 내부·외부·공급망
도메인 절차·위협 분류
기타 축
단기/중기/장기, 기능/비기능, 내부/외부, 동기/비동기 등
상황에 맞게
이미 잘 알려진 기준(CIA, 관물기, CAP 등)을 쓰면 면접관도 아는 틀이라 오히려 더 신뢰감과 설득력을 준다.
⚠️ 기준은 무한히 많지만 모두 암기할 수는 없다. 처음에는 이해관계자·레이어·품질 속성 같은 대표 기준 두세 가지만 숙지했다가, 익숙해지면 점차 늘려가는 것이 현실적이다.
▶️ 관련 스크립트
둘째, 계층 즉 레이어로 나눌 수 있습니다. 애플리케이션 계층, 데이터 계층, 네트워크 계층, 인프라 계층. 상황에 따라 사용자 계층, 브라우저, 단말 계층도 있을 수 있죠.
특히 우리 개발자는 기술 질문에 계층으로 분류하면 대부분 잘 들어맞을 수 있습니다.
잘 알려진 기준으로도 할 수 있습니다. 보안 3요소, CIA라고 하죠. 기밀성·무결성·가용성 관점으로 나누면 보안 하는 분들은 다 아는 내용이라 더 설득력을 가집니다.
이해관계자 관점으로 분류하는 것도 좋은 방법입니다. 고객·PM·운영팀·경영진·개발자 관점. 임원 보고할 때 특히 유용하죠.
너무 많은 기준을 암기할 수는 없으니, 처음에는 이해관계자·레이어·품질 속성 같은 두세 가지 분류 관점을 숙지했다가 익숙해지면 점점 늘려가길 권합니다.
5. 실전 적용: 면접·논술·보고 워크스루
같은 답변도 분류 기준을 먼저 제시하느냐에 따라 입체감이 달라진다. 면접에서는 WHO 없이 분류화만 바로 적용하고, 기술사 논술은 분류 기준을 먼저 제시해 답안 구조를 명확히 하면 채점자도 빠르게 평가할 수 있다. 임원 보고는 보고의 밀도가 높아진다. 분류 기준을 먼저 제시하고 답안을 작성하면 구조가 훨씬 입체적이고 명확해진다.
⚠️ 같은 주제라도 청중에 따라 기준을 바꾼다 — 기술자에게는 레이어·품질 속성이, 임원에게는 이해관계자·비용 기준이 더 잘 와닿는다. 이해관계자 관점 분류는 특히 임원 보고에서 '조직 전체를 본다'는 인상을 준다.
📝 적용 예시
면접 질문: "모놀리식에서 마이크로서비스(MSA)로 전환할 때 어떤 어려움이 있었나?"
— 분류 전(나열): 서비스 간 통신 복잡, 배포 어려움, 데이터 일관성 문제, 모니터링 어려움, 팀 간 협업, 테스트 복잡, 네트워크 비용 증가… → 핵심이 흩어진다.
— 분류 후(세 관점):
관점
어려움
기술적
서비스 간 네트워크 통신 복잡도 증가, 분산 트랜잭션 처리
운영적
다수 서비스의 독립 배포 파이프라인 구성, 통합 모니터링 체계 수립
조직적
서비스 오너십 정의, 팀 간 API 계약 관리
— 다른 적용:
· 클라우드 보안 위협과 대응(기술사 논술) → 관물기(관리적·물리적·기술적)
· 시스템 장애 재발 방지(임원 보고) → 시간축(예방·대응·사후 개선)
▶️ 관련 스크립트
면접에서 '마이크로서비스 아키텍처 전환 시 어떤 어려움이 있었나요?'라고 물어봤다고 가정해 봅시다.
크게 세 가지 관점에서 어려움을 겪었습니다. 먼저 기술적 관점에서는 서비스 간 네트워크 통신 복잡도가 증가했고 분산 트랜잭션 처리에 문제가 있었습니다.
둘째 운영적 관점에서는 다수 서비스의 독립적인 배포 파이프라인 구성이 어려웠고, 통합 모니터링 체계 수립이 어려웠습니다.
6. 마무리: 적용 체크리스트와 핵심 정리
화자가 마지막에 직접 정리한 복습 포인트다.
체크리스트 (말하기 전에 스스로 점검)
답변 전에 분류 기준을 먼저 정했는가? ('크게 몇 가지로 나눠보겠습니다'라고 선언했는가)
분류 기준이 청중 수준에 맞는가? (임원 → 이해관계자·비용 / 기술자 → 레이어·품질 속성)
한 주제에 하나의 기준만 쓰고 있는가?
WHO의 논리적 흐름 안에서 분류화를 적절히 쓰고 있는가?
핵심 정리
기준을 먼저 정하고 그 기준에 맞춰 전달하면 같은 내용도 훨씬 체계적이고 입체적이 된다. 대표 기준 두세 가지는 항상 장착해 두되, 청중의 관심사에 맞게 골라 쓰는 것이 관건이다.
⚠️ 체크리스트의 핵심은 '말하기 전에 기준을 먼저 정했는가'이다. 기준을 먼저 정하고 그 기준에 맞춰 전달하면 같은 내용도 훨씬 체계적이고 입체적으로 들린다.
▶️ 관련 스크립트
답변하기 전에 분류 기준을 먼저 정하셨나요? '크게 몇 가지로 나눠볼 수 있겠습니다'라고 말하고 계신가요?
분류 기준이 청중 수준에 맞나요? 예를 들어 임원에게는 이해관계자·비용 기준, 기술자에게는 레이어와 품질 속성 기준으로 말하면 좋겠죠.
한 주제에 하나의 기준만 쓰고 있나요? 여러 기준을 한 주제에 섞으면 오히려 혼란스럽습니다.
정리하겠습니다. 기준을 먼저 정하시기 바랍니다. 그 기준에 맞춰 내용을 전달하면 훨씬 체계적이고 입체적이 됩니다.
개발 가이드라인
답변·발표·보고 전에 '어떤 관점으로 크게 몇 가지로 나누겠다'고 분류 관점을 먼저 선언한 뒤 내용을 채워라.
한 주제에는 하나의 분류 기준만 적용하라 — 레이어·시간축·이해관계자 등을 한 답변에 섞지 말 것(MECE: 겹치지 않고 빠짐없이).
대표 기준 2~3개(레이어, 이해관계자, 품질 속성)를 먼저 숙지하고 익숙해지면 점차 확장하라.
청중에 맞춰 기준을 선택하라 — 임원에겐 이해관계자·비용, 기술자에겐 레이어·품질 속성.
개발자의 기술 질문(성능 개선, 장애 원인 분석 등)은 일단 계층(레이어)로 분류해 보면 대부분 들어맞는다.
장애·보안 대응 질문은 사전(예방)·대응·사후(개선)의 시간축으로 나눠라.
WHO로 전체 논리 흐름을 잡고 각 세부 단계 내용을 분류화로 채워라 — 단, 짧은 면접 답변에서는 WHO를 생략하고 분류화만 바로 적용해도 된다.