강의

멘토링

로드맵

개발 · 프로그래밍

/

개발 · 프로그래밍 기타

문제화: '개발 낭비'를 줄이는 기초 역량

문제화(Problematization)는 문제 제기, 문제짜기 등으로도 번역되는 용어입니다. 그리고 문제 설정이나 문제 정의로도 번역될 수 있습니다. 요청 사항이나 상식 같은 알려진 사실에 대해 새로운 관점에서 의문을 제기하고, 문제를 정의하고, 이 문제를 해결하는 방식을 짜 나가는 과정이 포함되어 있는 개념입니다. 문제화는 모든 개발의 출발점이 되어야 하지만 아직까지 개발 분야에서 충분히 논의되지 않은 주제입니다. 프로젝트를 수행하는 일이나 프로그램을 개발하는 일도 사실 문제를 해결하는 계획을 세우는 일입니다. 즉, 문제화와 관련이 있다는 말입니다. 문제를 해결하려면 먼저 문제가 명확히 정의되어 있어야 합니다. 그런데 대부분 애매한 요청 형태로 문제가 주어지게 됩니다. 그러므로 애매한 요청을 명확한 문제로 바꾸는 힘이 있어야 불필요한 '개발 낭비'를 줄이고, 협업은 원활해지며, 사용자의 진짜 필요를 제대로 파악할 수 있습니다. 이 강의는 실전 사례와 도구를 통해 문제를 ‘구성하는 사고’를 훈련하도록 돕습니다.

(5.0) 수강평 1개

수강생 28명

  • 아리가람
요구분석
코드리뷰
리팩토링
커뮤니케이션
pm/po
협업 툴소프트스킬문제해결능력

이런 걸 배울 수 있어요

  • 요청, 요구사항, 사용자 반응, 코드 리뷰 속에 숨은 진짜 문제를 찾는 방법

  • 진짜 문제를 문제 진술 공식 등을 사용해 구조화된 문제로 표현하는 방법

  • 문제의 근본 원인을 찾는 방법

  • 현상에서 본질을 통찰하는 '문제화'라는 철학적 개념

  • '문제화'를 수행하기 위한 여러 가지 도구

🎯문제화: '개발 낭비'를 줄이는 기초 역량

신입·주니어 개발자를 위한 협업, 요구분석, 코드리뷰의 출발점!

PM/PO 입장에서 '개발 낭비'를 막기 위해 모든 팀원에게 권장할 기본 역량!

협업 툴, 소프트스킬, 문제해결능력 등과 관련된 기초 역량!

인공지능이 코드를 짜는 시대에도 개발자의 일자리를 지킬 수 있게 하는 역량!

이런 고민, 해본 적 있으신가요?

  • "기획서가 너무 애매해서 뭘 만들어야 할지 모르겠어요."

  • "리뷰에서 피드백은 받았는데, 정확히 어디를 고쳐야 할지 감이 안 와요."

  • "막상 코드를 짜려고 하니까… 내가 뭘 해결하려고 했더라?"

  • "질문을 했더니 '그래서 뭐가 문제야?'라고 되묻더라고요."

이 모든 혼란의 핵심은 문제를 정확히 정의하지 못했기 때문입니다. 개발자는 끊임없이 문제를 마주합니다. 하지만 그 문제를 정확히 바라보고 정의할 수 있어야 올바른 해결이 시작됩니다.

모호한 요구사항: 신입 개발자는 프로젝트에서 종종 불명확한 요구사항을 부여받는다. 예를 들어 “위젯을 만들어 달라”는 식의 애매한 지시를 받으면, 구체적으로 어떤 기능을 구현해야 할지 혼란스러워한다. 개발자 대상 블로그에 따르면, 신규 입사자는 “불명확한 지시”(vague instructions)와 충분한 가이드 부재로 인해 혼란을 겪는다(codeanywhere.com).

경험 부족: 업무 경험이 적어 문제를 체계적으로 분해하거나 필요한 정보를 스스로 찾아내기 어려워한다. 실제 사례로, 한 신입 개발자는 얼마나 스스로 풀어야 할지 판단하기 힘들어하며 지나치게 오랜 시간 동안 해결을 시도했다가야 비로소 질문하도록 배웠다(rachsmith.com). 이러한 불확실성은 불안감(임포스터 증후군)으로 이어져 학습과 협업을 저해한다.

소통 격차: 도메인 지식이나 비즈니스 맥락이 부족하면, 요구사항의 핵심 문제를 정확히 파악하지 못한다. 개발 커뮤니티에서도 도메인 지식 부족이 요구사항 오해로 이어진다는 지적이 있으며(kedin.com), 이는 곧 잘못된 구현 및 재작업을 낳는다.

📌 이 강의에서 배우는 것

모호한 요구를 명확하게 정리하고, 핵심 문제를 설정하는 실질적인 사고법

  • 요구사항에서 문제를 끌어내는 질문법

  • ‘문제’를 문제답게 만드는 5가지 기준

  • 말이 다른 팀원과도 공감대를 형성하는 기술

  • 문제를 ‘정의’하고 ‘구조화’하는 도식화 방법

  • 코드리뷰, 기획회의, 업무 전달 시 정확히 되묻는 기술

  • 15개 주요 패턴

🎓 이 강의는 누구를 위한 걸까요?

1. 모호한 요구사항 앞에서 막막한 개발자

  • 클라이언트나 기획자가 던진 말이 너무 애매해서 뭘 만들어야 할지 모르겠는 경우

  • 예: “UX가 좀 별로예요”, “느려요”, “좀 더 직관적으로 해주세요”

  • → 요청을 문제로 바꾸는 힘이 부족한 상태

요청: "UX 좀 더 좋게 해 주세요"
반응: "그냥 UX 좀 좋게 만들어 달라고만 하는데.....무슨 뜻이지?"

“‘그냥 좀 더 직관적으로요’라는 말에 멈칫한 적 있나요? 애매한 요청을 명확한 문제로 바꾸는 기술, 지금부터 시작하세요.”

2. 요구 분석이나 설계 단계에 자신감이 없는 신입·주니어

  • 문제를 분석하고 구조화하는 능력이 아직 익숙하지 않음

  • 기획자의 말을 받아 적는 수준에 머무르는 경우

  • → 스스로 문제를 정의할 수 있는 기술이 필요함

요청: 'OO' 기능 - 미정 상태임. 곧 결정될 것임.
반응: "몇 가지 기능이 결정되지 않은 현재 상태 그대로 개발해도 괜찮은 것일까?"


“시킨 대로만 만들고 있진 않나요? 기획을 해석하고, 문제를 스스로 정의할 줄 아는 개발자로 성장하세요.”

3. “왜 이걸 개발하는지”를 설명하는 데 어려움을 겪는 개발자

  • 기능 구현은 잘하지만, 그 기능이 왜 필요한지 설명 못함

  • 개발의 목적과 문제 맥락을 설계하는 데 어려움이 있음

  • → 개발자 → 문제 해결자 → 문제 설정자로 성장하려는 사람

요청: 버튼 크기 + 10픽셀
반응: "그게 ... 그냥 그런 식으로 만들면 좋을 것 같은 생각이 들어서 ..."


“기능을 구현할 수는 있는데, 이유를 설명하지 못한다면? 문제의 본질을 꿰뚫는 사고가 지금 필요한 시점입니다.”

4. 기획자나 디자이너와 협업하는 일에 어려움을 겪는 개발자

  • 말은 많이 오가는데, “무엇이 문제인지”에 대한 공감대가 형성되지 않음

  • 피드백이 반복되거나, 커뮤니케이션 충돌이 자주 일어남

  • → 서로 다른 언어를 구조화해 협업의 중심을 잡고 싶은 사람

요청: "제발 더 직관적인 느낌이 들게"
반응: "디자이너는 왜 자꾸 어떤 '느낌' 같은 것들만 말하는 건지 .... ?"


“기획자와 말이 안 통한다고 느껴지나요? 서로의 언어를 ‘문제’로 정리하면, 협업이 달라집니다.”

5. 기획, PM, 지휘 업무를 준비하는 주니어 이상

  • 문제를 정의하고 방향을 제시해야 할 역할로 성장 중인 개발자

  • 막연한 요청을 팀의 할 일로 구조화하는 능력이 필요함

  • 문제 설정은 곧 리더십의 시작

요청: [정보요청(Request) > 원인(Cause) > 사용자 상황(User Situation)] 구조에 맞게 ...
반응: "이것을 팀 과제로 삼으려면 어떻게 정의해야 하지?"


“막연한 요청을 할 일로 구조화하는 능력, 지금 당신이 팀을 이끄는 개발자가 되는 첫걸음입니다.”

6. 요약

  • 이 강의는 “코드는 짜는데, 뭘 짜야 하는지 모르겠다”는 고민이 드는 모든 개발자에게 꼭 필요한 강의입니다.

  • 특히 신입~3년 차 주니어 개발자에게는 필수 역량이라 할 수 있어요.

요구사항 수집 질문: 개발자 게시판이나 Reddit에서 신입·준비생이 “요구사항을 어떻게 수집·분석하나요?”를 묻는 글들이 종종 보인다. 예를 들어, 한 컴퓨터공학과 학생은 “실무에서 이해관계자 요구사항을 어떻게 모으나요?”라며 선배 개발자의 조언을 구했다(reddit.com). 이는 실제 프로젝트에서 명확한 요구를 얻는 법에 대한 수요를 보여준다.

역할 강조: 중견 개발자의 조언에 따르면, 소프트웨어 개발의 핵심은 “문제 정의(Problem definition)”이며 진정한 전문가는 요구 사항을 정확히 정의하는 능력이 필요하다고 언급된다(medium.com). 개발자 커뮤니티에서도 이처럼 문제 정의의 중요성을 강조하는 의견이 자주 발견된다.

교육 필요성: 한국 개발자 블로그에서는 “기본기”로 문제 정의 능력을 꼽으며(medium.com), 데이터를 분석하거나 시스템을 설계할 때 도구보다도 해결해야 할 문제를 먼저 정의하는 것이 필수적임을 지적한다(inflearn.com, velog.io). 이런 글들은 학습자들에게 문제 정의 스킬의 필요성을 부각한다.

💡 강의 특징

  • 실무 기반 사고법:

    실제 협업에서 겪는 문제 사례를 중심으로 구성

  • 짧고 명확한 강의:

    각 수업은 일반적으로 10분 이내로 구성(예외도 있음)되어, 몰입도 높은 학습 가능

  • 사고 구조화 훈련:

    문제를 정의하는 ‘사고 흐름’을 시각적으로 정리하는 슬라이드 중심 강의

  • 실전 예시:

    애매한 피드백, 추상적 기획을 명확한 문제로 바꾸는 대화 방식 수록

📂 커리큘럼 미리보기 (일부)

  1. 문제 설정이란 무엇인가 – 문제 해결의 출발점

  2. 애매한 요청, 어디서부터 잘못됐는가

  3. 문제를 문제답게 만드는 5가지 기준

  4. "그래서 뭐가 문제야?"를 다르게 묻는 기술

  5. 코드리뷰, 기획, 일정조율… 문제 설정이 쓰이는 모든 순간들

💬 수강 후 기대 효과

  • 혼란스러운 요청도 스스로 구조화하고 정리할 수 있어요

  • 질문 하나로 핵심을 짚는 개발자가 될 수 있어요

  • 업무 협업 시 불필요한 오해를 줄이고, 정확한 대화를 주도할 수 있어요

  • 리뷰 피드백도 단순 지적이 아닌 해결 가능한 문제로 변환할 수 있어요

💬 개발자에게 이 강의가 실질적으로 유익한 이유


1. 실무에서 가장 자주 부딪히는 문제를 다룬다

개발자가 하는 일의 시작은 언제나 ‘요청’을 받는 것에서 출발합니다. 하지만 요청은 대부분 모호하고 애매합니다. 이걸 정확한 문제로 바꾸지 못하면 기획이 어긋나고, 개발은 헛돌고, 일정은 밀립니다.

예:“버튼을 좀 더 크게 해주세요” →→ 왜? 누구에게? 무엇이 문제지?


2. 신입과 주니어가 가장 부족해하는 능력이다

신입 개발자나 주니어에게 가장 어려운 부분은 단순한 구현이 아니라 '무엇을 구현해야 하는가'를 판단하는 능력입니다. 이 강의는 바로 그 지점을 짚어줍니다.


3. 협업 역량 향상에 직결된다

요구 분석, 코드 리뷰, 커뮤니케이션, PM과 협의… 모두 문제 정의를 잘해야 흐름이 매끄럽습니다. 이 강의는 말을 듣고 본질을 끌어내는 사고법을 훈련시켜 줍니다.


4. 현실적인 실전 프레임과 도구를 제공한다

실습 없는 이론이 아니라, 바로 실무에서 써먹을 수 있는 문제 진술 공식, 피드백 기준, 질문 기법 등을 제공합니다.


요약하면, 이 강의는 “왜 이걸 개발해야 하죠?”, “이건 진짜 문제인가요?”라는 질문 앞에서 멈추지 않고
명확한 판단과 말하기가 가능한 개발자가 되도록 돕습니다.

🎯 지금의 개발자 시장에서는 이런 식으로 ‘생각할 줄 아는 개발자’가 가장 빠르게 성장합니다.

이제, 문제 해결이 아닌 문제 설정부터 잘하는 개발자가 되어 보세요.

문제를 정확히 볼 수 있어야 해결도, 성장도 시작됩니다.

이런 분들께
추천드려요

학습 대상은
누구일까요?

  • 주어진 요청을 그대로 구현하기보다, 무엇이 진짜 문제인지 스스로 사고하고 판단하는 역량을 키우고 싶은 개발자

  • 모호한 요구와 의견 속에서 팀의 방향을 정하고, 개발자와 원활하게 소통하고 싶은 기획자, 디자이너, PM/PO

안녕하세요
입니다.

408

수강생

20

수강평

1

답변

4.7

강의 평점

17

강의

IT가 취미이자 직업인 사람입니다.

다양한 저술, 번역, 자문, 개발, 강의 경력이 있습니다.

커리큘럼

전체

72개 ∙ (17시간 16분)

해당 강의에서 제공:

수업자료
강의 게시일: 
마지막 업데이트일: 

수강평

전체

1개

5.0

1개의 수강평

  • HelloWorld님의 프로필 이미지
    HelloWorld

    수강평 2

    평균 평점 4.5

    5

    31% 수강 후 작성

    • 아리가람
      지식공유자

      감사합니다.

₩55,000

아리가람님의 다른 강의

지식공유자님의 다른 강의를 만나보세요!

비슷한 강의

같은 분야의 다른 강의를 만나보세요!