데이터 분석 부트캠프 : 실습에서 무엇을 배우고 어떻게 확인할까요?

부트캠프 실습에서 고칠 것이 여러 개 나오면, 얼마나 큰 문제인지(영향)와 고치는 데 손이 얼마나 가는지(품)를 보고 순서를 정합니다. 만든 결과는 실제로 값을 넣어 돌려 본 것만 성공으로 치고, 돌려 보지 않은 것은 남은 일로 따로 적습니다. 저는 2026년 8월 AI PM 부트캠프에서 주문 앱, 택배 접수 화면, 피드백 분석기를 직접 만들고 날마다 회고를 쓰며 이 기준을 익혔습니다. 실습 결과물을 포트폴리오에 남기는 법은 비개발자 프로젝트 글에 따로 정리했습니다.

데이터 분석 부트캠프, 비개발자도 따라갈 수 있나요?

명령어를 한 줄씩 직접 치고 결과를 확인하면 비개발자도 따라갈 수 있고, 막히는 곳은 코드보다 환경과 설정인 경우가 많습니다. 데이터 분석 부트캠프처럼 직접 만드는 실습은 처음 보는 명령어가 많아 겁이 나기 쉽습니다. 하지만 여러 줄을 한꺼번에 돌리지 않고 한 줄씩 실행하면, 오류가 어느 줄에서 났는지 바로 보입니다. 실습 오류를 찾는 방법도 결국 이것입니다.

Day18 실습에서 저는 고객 피드백 한 문장을 유형, 긴급도, 판단 이유, 다음 행동 네 줄로 나눠 주는 프로그램을 만들어 웹에 올렸습니다. 명령어를 한 줄씩 직접 쳤더니 오류 6개가 어느 줄에서 났는지 모두 짚을 수 있었고, 6개 모두 코드가 아니라 환경과 설정 문제였습니다.

배포에서도 비슷했습니다. Day11에는 앱이 데이터베이스 주소 같은 설정값을 읽어 오는 자리(환경변수)를 채우고 다시 배포하지 않아 화면이 비어 있었습니다. Day12에는 데이터베이스가 읽기를 막아 둔 탓에 조회 화면에 아무것도 뜨지 않았습니다. RLS 정책은 데이터베이스에서 행 단위로 읽기와 쓰기를 막거나 여는 규칙인데, 읽기를 열어 주는 정책을 넣고 나서야 데이터가 보였습니다. 그래서 배포 후 데이터가 안 보이면 환경변수를 넣은 뒤 다시 배포했는지, 데이터베이스 읽기 권한이 열려 있는지부터 확인합니다.

이 두 번의 일로 코드를 모르는 것보다 어디서 막혔는지 모르는 것이 더 큰 문제라는 것을 배웠습니다. 비개발자가 코드보다 먼저 볼 것은 AI 바이브코딩 글에서 확인할 수 있습니다.

데이터 분석 부트캠프 실습 회고는 어떻게 쓰나요?

실습 회고는 좋았던 것, 배운 것, 부족했던 것, 바라는 것 네 칸(4Ls)으로 나누고 다음에 할 행동을 적는 기록입니다. 4Ls는 Liked, Learned, Lacked, Longed for의 앞 글자를 딴 회고 틀입니다. 칸이 정해져 있어 그날 일을 빠뜨리지 않고, 같은 틀로 여러 번 쓰면 회차끼리 비교하기도 쉽습니다.

저는 Day12부터 Day21 사이에 회고 7편을 모두 이 틀로 썼고, 매번 지난 회차와 달라진 점을 표로 붙였습니다. 처음에는 막힌 자리를 적어 두려고 썼습니다. 하지만 쓰다 보니 회고가 다음에 무엇을 먼저 고칠지 정하는 기록이 됐습니다. Day21에는 관찰과 판단을 따로 적는 연습도 했습니다. 관찰은 실제로 일어난 현상이고 판단은 그 현상에 붙인 해석이라, 상황을 사용자, 과업, 목표, 관찰 현상, 제약으로 나눠 둘을 섞지 않고 적습니다. 둘을 나눠 적어야 해석이 사실처럼 굳지 않습니다.

그래서 회고는 감상을 남기는 칸이 아니라 다음에 무엇을 다르게 할지 정하는 칸이라는 것을 배웠습니다. 회고가 이렇게 바뀐 계기는 Day15의 일이었습니다.

버그 우선순위는 어떻게 정하나요?

버그 우선순위는 느낌이 아니라 영향의 크기와 고치는 데 드는 품을 기준으로 꼭 할 것, 할 것, 있으면 좋을 것, 안 할 것으로 나눠 정합니다. 기준 없이 고르면 눈에 띄는 것도, 있으면 좋아 보이는 것도 모두 급해 보입니다. 그래서 고르기 전에 기준부터 세워야 합니다.

Day15에 만든 것을 점검하자 안 되는 것이 12개 나왔습니다. 저는 처음에 그중 6개를 꼭 고칠 것(Must)으로 골랐는데, "그게 꼭 해야 해?"라는 질문을 듣고 다시 보니 진짜 급한 것은 2개였습니다. 하나는 문서에는 못 바꾼다고 적혀 있는데 실제로는 바뀌던 것, 다른 하나는 저장이 안 됐는데 완료 화면을 띄우던 것이었습니다.

처음 판단이 틀린 이유는 기준을 먼저 세우지 않고 느낌으로 골랐기 때문입니다. 그 뒤로는 네 칸으로 나눠 순서를 정했고, 여러 명이 말한 것과 한 명만 말한 것도 구분했습니다.

사용자 피드백은 그대로 반영해야 하나요?

사용자 피드백은 요청 그대로 반영하기보다 화면, 로직, 데이터, API, 배포 가운데 어느 층에서 생긴 문제인지 먼저 가려낸 뒤 반영합니다. 사용자는 겪은 불편을 말하지만, 그 불편이 어디서 생겼는지까지 알고 말하지는 않습니다. 같은 불편이라도 원인은 화면에 있을 수도, 데이터나 다른 서비스와의 연결(API)에 있을 수도 있습니다.

Day16에는 택배 접수 화면에 들어온 피드백 3건을 이 다섯 층으로 나눠 살폈습니다. 지점을 1개만 보여 달라는 요청이 있었는데, 들여다보니 원인은 지점 데이터에 위치 좌표가 없다는 데 있었습니다. 그 과정에서 아무도 말하지 않은 더 큰 결함도 찾았습니다. 지역 이름에서 「구」를 떼는 처리 때문에 대구와 광주에서는 추천이 아예 뜨지 않았습니다. 그래서 순서는 누가 먼저 말했느냐가 아니라 영향과 품으로 정했습니다.

Day17에는 화면에 들어서자마자 빨간 오류가 뜨는 문제 하나만 골랐습니다. 처음 들어온 상태, 지역을 고른 상태, 제대로 입력한 상태, 진짜 오류 네 상태로 나눠, 진짜 오류일 때만 메시지를 띄우도록 규칙을 정리했습니다. 이 실습으로 피드백은 받은 문장이 아니라 원인이 있는 층을 보고 반영해야 한다는 것을 배웠습니다.

AI 검증 프로그램 결과를 그대로 믿어도 되나요?

검증 결과는 그대로 믿지 말고 실제 입력을 직접 넣어 확인해야 하며, 확인하지 않은 성공은 남은 일로 따로 적습니다. AI 검증 프로그램이나 테스트 기록이 통과라고 알려 줘도, 어떤 값을 넣어서 나온 결과인지는 따로 봐야 합니다. 기록에 적힌 값과 실제로 넣은 값이 다르면, 그 통과는 지금 만든 것을 확인해 주지 못합니다.

Day18에 피드백 분석기를 만들면서 저는 남이 적어 둔 테스트 기록과 제가 실제로 넣은 값이 다르다는 것을 알아챘습니다. 그래서 직접 돌려 보지 않은 성공은 성공 칸에 두지 않고 남은 일로 적었습니다. 이 습관은 Day15에 Must를 6개로 봤다가 2개로 고친 일에서 시작됐고, 그 뒤 회고의 다음 행동도 끝났다고 말하기 전에 직접 해 보기로 바뀌었습니다.

그래서 결과가 맞는지는 도구의 판정보다 직접 넣어 본 값으로 가려야 한다는 것을 배웠습니다. 데이터를 고친 뒤 무엇으로 확인하는지는 데이터 정제 글에 따로 정리했습니다.

데이터 분석 부트캠프 실습에서 무엇을 배우고 어떻게 확인할까요?

부트캠프 실습에서 배우는 것은 만드는 법보다, 무엇을 먼저 고칠지 정하고 만든 결과를 직접 확인하는 법입니다. 명령어를 한 줄씩 치면 막힌 자리가 보이고, 4Ls 회고를 이어 쓰면 판단이 어떻게 바뀌었는지 남습니다. 결함은 영향과 품으로 네 칸에 나누고, 피드백은 원인 층부터 가려냅니다. 마지막으로 결과는 실제 값을 넣어 다시 확인하고, 확인하지 않은 것은 남은 일로 적습니다.

저는 8월 실습에서 Must를 6개로 봤다가 2개로 다시 고른 뒤에야 이 순서를 세울 수 있었습니다. 이런 실습 경험을 면접에서 어떻게 꺼내 답하는지는 AI PM 면접 질문 글에서 확인할 수 있습니다.