문제 정의와 추상화: 무엇이 문제인지 판단하기
문제 정의와 추상화가 중요한 이유
AI는 개발 방식의 변화는 물론, 개발의 진입 장벽을 낮추고 개발을 통해 창출할 수 있는 가치를 높이고 있습니다. 과거에는 대기업만이 가능했던 AI 알고리즘 적용(추천 엔진, 데이터 분석 등)을 이제는 개인 개발자도 오픈 소스 API를 통해서 쉽게 구현할 수 있으며, MVP(최소 기능 제품) 제작 속도 역시 빨라져 시장 검증이 쉬워졌습니다. 심지어는 Cursor와 같은 도구를 통해 프로그래밍 언어를 모르더라도 자연어 기반으로 코드를 생성하는 게 가능해지기도 했습니다.
물론 앞서 이야기했듯이 여전히 AI를 더 잘 활용하기 위해 소프트웨어 개발과 프로그래밍에 대한 이해가 필요합니다. 다만, 이러한 기본기를 갖추는 것만으로 AI를 활용하여 가치를 만들어 낼 수는 없습니다. 기술적 구현에 앞서 "해결해야 할 문제를 정의하는 일"이 선행되지 않는다면 아무리 뛰어난 기술도 가치를 창출하기 어렵기 때문입니다.
Cursor의 창업자가 AI로 인해 소프트웨어 개발의 방식이 변화하더라도 개발자의 역할은 여전히 중요할 것이라고 이야기하는 것도 같은 맥락입니다. 그는 AI가 많은 부분을 도와줄 테지만, 결국 무엇을 만들지, 어떻게 만들지를 결정하는 것은 프로그래머가 될 것이라고 말합니다. 또한 프로그래밍의 본질은 결국 문제를 해결하고 아이디어를 현실로 만드는 것이며, 이는 앞으로도 변하지 않을 것이라고 강조합니다(링크).
무엇이 문제인지 정의하고 컴퓨터가 해결 가능한 단위로 구조화하는 추상화 역량은 기존에도 개발자에게 중요한 역량이었지만 AI시대에는 개발자의 핵심 경쟁력으로 떠오르고 있습니다. 아래 이미지는 2024년 부스트캠프 설명회에서 개발자의 문제 해결 과정과 컴퓨팅 사고를 설명하기 위해 마스터(기술 교육 전문가) JK가 도식화한 모델입니다. 부스트캠프는 문제 도출 → 문제 해결(추상화) → 문제 해결(자동화)로 이어지는 컴퓨팅 사고의 전 과정을 학습자가 경험할 수 있도록 설계되어 있으며, 최근에는 학습자가 문제 정의와 추상화 단계에 더욱 집중할 수 있도록 커리큘럼과 학습 환경을 강화했습니다.
문제 도출: 현실의 크고 작은 문제에서 본질을 찾아내는 것
문제 해결(추상화): 정의한 문제를 컴퓨터가 해결할 수 있도록 불필요한 요소를 제거하고 일반화하여 단순한 형태로 만드는 것
문제 해결(자동화): 문제 해결을 위해 도출된 절차나 알고리즘을 컴퓨터(기계)가 수행할 수 있도록 절차화 하는 것
입문 단계에서의 문제정의와 추상화
2024년 베이직이라는 신규 과정을 개설하고 ‘문제 정의와 추상화'를 누구나 연습할 수 있는 기회를 제공했습니다. 베이직은 2주 동안 매일 하나의 미션이 주어집니다. 모든 미션에는 정해진 방법도, 의도하는 정답도, 채점 기준도, 해설도 존재하지 않습니다. 학습자는 열린 조건 속에서 주어진 문제를 스스로 해석하고 정의한 후, 자신만의 방식으로 해결 방법을 설계하고 타당하게 구현해야 합니다. 심지어 일부 미션은 아예 코드를 작성하지 않고 분석과 설계만을 깊게 경험하도록 제공하기도 합니다. 학습자가 스스로의 해석과 논리를 바탕으로 문제를 정의하고 이를 구조화한 후 구현에 이르기까지의 전 과정을 주도적으로 수행할 수 있도록 설계한 것입니다. 베이직의 설계 및 운영에 대한 보다 자세한 내용은 Chapter1. 3. AI 시대 부스트캠프가 다시 기본기를 말하는 이유에서 확인할 수 있습니다.
프로그래밍 미션 속에서의 문제 정의와 추상화
챌린지는 CS 지식과 소프트웨어 기본 원리를 만들면서 배우는 과정(Learning by doing)입니다. 프로그래밍 미션이 매일 제공되며, 미션의 요구사항을 스스로 해석하여 문제를 해결해야 합니다. 이때 미션의 요구사항에서 학습자가 스스로 해석할 여지를 열어두는 것이 핵심입니다. 학습해야 할 핵심 개념이나 주제는 공통되지만 미션의 요구사항을 어떻게 정의하고 해석했는지에 따라 학습자의 미션 수행 결과물에는 조금씩 차이가 발생합니다. 동료와 소통하며 이 차이를 확인하고, 서로의 문제 정의와 추상화 과정을 점검하며 문제 해결의 시야를 넓히는 것이 챌린지의 필수적인 학습 경험입니다.
챌린지에서는 Learning by doing의 경험을 학습자가 온전히 수행할 수 있도록 학습 메모 활용하기, 회고, 개선하기(리팩토링) 등의 의도적 장치를 마련합니다. 그중 가장 핵심적인 장치는 학습자가 자신의 미션 수행 과정을 스스로 점검할 수 있는 기준인 체크포인트입니다. 체크포인트는 구현해야 할 ‘코드’를 의미하지 않습니다. 기술적 개념이나 지식을 판단의 근거로 적절하게 활용했는지, 설계 시 구조나 데이터 타입을 충분히 고려했는지, 그리고 핵심 기능이 의도대로 동작하는지를 종합적으로 검토하기 위한 일종의 '나침반'입니다.
부스트캠프는 체크포인트의 공개 시점을 미션 해결 중반에서 종료 이후로 변경하여 학습의 무게 중심을 ‘구현’에서 '문제 정의와 추상화'로 옮겼습니다.
기존 문제 해결 루틴에서 체크포인트를 미션 수행 중반에 공개한 이유는, 체크포인트를 이정표 삼아 놓친 개념을 단단히 하고 설계를 개선하는 등 더 나은 방법을 찾아 나가길 기대했기 때문입니다. 그러나 시간이 흐를수록 체크포인트를 ‘정답지’로 인지하고 구현의 완성도에만 매몰되는 현상이 발견되었습니다. 특히 AI의 구현 능력이 비약적으로 발전함에 따라 학습자가 “무엇을, 왜 그리고 어떻게” 만들지에 대해 깊이 고민하지 않더라도 어느 정도의 결과물을 만들어 낼 수 있게 되며 이러한 현상이 가속화될 수 있다는 문제의식을 가지게 되었습니다. 이에 2025년 문제 해결의 루틴을 변경하고, 그 결과를 비교해 봤습니다.
기존 문제 해결 루틴
1. 미션 공개 후 학습자는 스스로 문제를 정의하고 설계와 구현을 고민합니다.
2. 미션 공개 당일 오후 체크포인트를 공개하여 학습자가 자신의 설계를 1차적으로 점검합니다.
3. 업데이트 된 자신의 체크포인트를 기준으로 다음날 오전까지 미션을 해결합니다.
4. 4~5명의 동료가 줌(zoom)에서 만나 미션에 대한 서로의 문제 정의와 추상화, 해결 과정과 결과를 공유합니다.
변경된 문제 해결 루틴
1. 미션 공개 후 학습자는 스스로 문제를 정의하고 설계와 구현을 고민합니다.
2. 스스로의 해석과 풀이 방법에 따라 다음날 오전까지 미션을 해결합니다.
3. 미션 해결이 종료된 후(다음날 오전) 체크포인트를 공개하여 학습자가 자신의 문제 해결 과정을 점검합니다.
4. 4~5명의 동료가 줌(zoom)에서 만나 미션에 대한 서로의 문제 정의와 추상화, 해결 과정과 결과를 공유합니다.
그 결과 학습자의 절반 이상이 미션 완수율 70%를 상회하던 우편향 그래프는 2025년을 기점으로 정규분포 형태로 변화했습니다. 부스트캠프는 매년 동일한 선발 기준(절대평가)을 적용하므로 연도별 학습자의 평균적인 역량 편차는 크지 않다고 가정합니다. 이를 전제로 할 때, 대다수 학습자가 상위권에 몰린 2024년의 우편향 그래프는 상당수 학습자가 기존의 '체크포인트'에 의존해 구현의 완성도를 높이는 데 많은 시간을 투입했음을 보여줍니다.
반면, 체크포인트라는 보조 장치를 제거한 새로운 루틴에서는 오직 스스로의 해석에 의존해 길을 찾아야 합니다. 이로 인해 전체적인 미션 완수율은 전년 대비 하락했으나, 부스트캠프는 이를 성취 결과의 저하가 아닌 미션 해결의 난이도가 높아졌다고 해석합니다. 체크포인트의 제공 시점을 변경하여 코드를 작성하기 전 문제 정의와 추상화에 더 많은 공을 들여야만 결과물을 낼 수 있도록 환경으로 개선되었고, 체크포인트 공개 시점 지연(Delay)은 학습자에게 바람직한 어려움(desirable difficulties)으로 작용하여 겉보기에는 어려움을 야기하지만 실제로는 더 지속적이고 유연한 학습으로 이어지는 학습 환경을 구축한 것입니다.(Bjork, 1994; Bjork & Bjork, 2011에서 재인용).
나아가 기존에는 우편향된 미션 완수율로 인해 학습자 개개인의 고유한 문제 해결 역량을 파악하는 데 한계가 있었습니다. 그러나 완수율이 정규 분포의 형태를 띠게 되며 학습자의 현 위치와 마주하고 있는 어려움을 명확하게 확인할 수 있었고, 학습자의 회고 및 커뮤니티 영향력 데이터와 결합하여 학습자를 종합적으로 관찰할 수 있었습니다. 문제 정의와 추상화는 눈으로 보여지는 과정이 아니기에 다수의 학습자를 대상으로 지표화하기 어렵다는 점에서 이는 유의미한 성과입니다.
사용자 관점을 고려한 문제 정의와 추상화
부스트캠프는 단계적 설계를 통해 학습자의 자기주도적 의사결정의 범위를 점차 확장합니다. 예를 들어, 챌린지 초반에서는 하루 단위로 해결할 수 있는 미션을 제공했다면 멤버십에서는 일주일, 이 주일 단위로 확장하고 최종적으로 6주 단위의 프로젝트를 학습자가 스스로 기획하고 배포하는 경험까지 할 수 있도록 설계했습니다.
특히 프로젝트 기획에서는 학습자가 실제 현실의 크고 작은 현상에서 스스로 문제를 도출하고 정의해야 합니다. 이 과정에서 부스트캠프가 가장 강조하는 것은 최종 사용자(End-User)를 고려한 의사결정입니다. 개발자는 사람과 사회에 대한 이해를 바탕으로 소프트웨어 개발을 통해 비즈니스 가치를 창출하는 사람이기 때문입니다. 학습 단계에서 비즈니스 가치까지 경험하기는 어렵지만 사용자를 중심에 둠으로써 현실의 불편함을 해소하는 본질적인 경험은 가능합니다. 사용자를 고려하는 것이 거창할 필요는 없습니다. 대상을 ‘나’로 가정하여 적어도 본인이 겪는 어려움을 해결하고 스스로가 만족하며 사용할 만한 프로덕트를 만드는 것이 그 시작점이자 목표입니다.
사용자를 고려한 기획을 강조하면 “개발자가 기획까지 해야 하나요?”라는 질문이 반드시 따라옵니다. 부스트캠프는 개발자의 역할을 더 잘 수행하기 위해 기획(문제 정의)을 경험하고 고민하는 것이라고 답변합니다. 먼저, 현실의 문제가 무엇인지, 왜 그것이 문제인지 스스로 정의할 수 있어야 무엇을 어떻게 만들지의 기준과 맥락을 파악할 수 있습니다. 예를 들어, 웹 소캣(Web socket)을 활용한 실시간 서비스를 만들어야겠다는 의사결정을 하기 위해서는 단순히 '이 기술을 사용해 보고 싶어서'가 아니라 '우리 서비스의 사용자가 1초의 지연 시간도 없이 즉각적인 피드백을 받아야만 하는 긴박한 문제(예: 실시간 경매나 주식 거래)를 겪고 있는가?'에 대한 판단이 선행되어야 합니다. 결국 개발자로서의 판단 기준에는 이 프로덕트의 사용자가 있습니다.
또한 현실의 문제를 컴퓨터로 해결할 수 있도록 추상화하는 작업은 개발자로서 무엇을 해야할지 결정하기 위해 반드시 선행되어야 하는 작업입니다. 이 프로덕트에서 사용자의 즉각적인 피드백이 필요하여 웹 소켓이라는 기술을 활용하기로 했다면 “사용자가 지하철을 타서 네트워크가 잠시 끊겼을 때, 기존의 연결을 어떻게 안전하게 복구하고 놓친 메시지를 순서대로 다시 전달할 것인가?”, “수만 명의 사용자가 동시에 접속했을 때, 서버 한 대가 감당할 수 있는 연결 수는 얼마이며, 부하를 분산하기 위해 서버를 어떻게 증설하고 동기화할 것인가?”같은 문제를 연속적으로 정의하고 결정해야 합니다.
이러한 의사결정 과정은 결코 쉽지 않습니다. 학습자들은 프로젝트 진행 시 AI를 기술적으로 활용하는 것에는 비교적 쉽게 접근하지만, 그것을 사용자 가치와 연결해 의사결정을 내리는 데에는 큰 어려움을 겪습니다. 대다수의 학습자가 프로젝트가 끝날 때쯤에야 사용자 관점에서 문제를 정의한다는 것의 실질적인 의미를 깨닫곤 합니다.
사용자 피드백에서 우리 서비스를 Q&A라는 목적으로 제대로 사용해 본 적이 있는지를 질문 받은 게 기억납니다. 아쉽게도 저희는 서비스를 개발자 시각이 아닌 사용자 시각으로 딥하게 사용해본 경험이 있지는 않았습니다. 이로 인해 AI를 활용한 기능 추가 과정에서 의사 결정을 서비스에 대한 이해도를 기반으로 해내지는 못했다는 아쉬움이 남았습니다. 이를테면 인공지능에게 넣어줄 맥락을 어디까지 포함시킬 것인지에 대한 의사 결정에 있어 단순히 인공지능의 비용 절감 측면에서만 고려했던 저희였지만, 보다 더 깊은 서비스 이해도가 있었더라면 서비스의 특성과 맥락에 알맞은 선택을 해낼 수 있었을 것 같습니다.
멤버십 학습자 후기
부스트캠프는 베이직, 챌린지, 멤버십을 거치며 프로그래밍 미션에서 현실 문제로 학습자가 해결해야 할 과업을 단계적으로 확장해 왔습니다. 이 확장을 통해 사용자 중심의 문제 정의와 추상화 역량이 자연스럽게 체득되길 기대했으나, 주어진 미션을 해결하는 것과 현실에서 직접 문제를 도출하는 경험 사이에는 여전히 큰 간극이 존재함을 확인했습니다. 이에 앞선 단계에서도 사용자 관점을 고려하는 의사결정을 추가하거나, 보다 덜 구조화된 미션을 제공하는 다양한 방안을 고려하고 있습니다.
Last updated