AI가 코드는 짜줘도,
판단은 네가 해야 한다.
바이브코더를 위한 실전형 개발 판단력 문제풀이.
실제 발생하는 상황 별 문제를 풀며, AI에게 정확히 지시하는 감각을 기릅니다.
안녕, 난 바이트!
하루 5문제면 충분해. 같이 판단력 키워보자
바이브코딩 초보라면, 기본기부터 차근차근 익혀봐요
AI로 웹을 만드는 입문자가 꼭 알아야 할 6단계 실전 개발 지식과 사전 개념을 퀴즈로 마스터하세요.
가장 많이 풀어본 문제
1위 문제는 1150번 도전받았어요.
보안이 제대로 되어 있는데 왜 해킹 당했을까?
굴지의 대기업 `404Vibe Corp`는 주요 사내 시스템을 외부 인터넷에서 직접 접근할 수 없도록 구성하고 있다. 직원이 외부에서 접속하려면 회사 VPN에 연결해야 하며, VPN 로그인에는 MFA도 적용되어 있다. 어느 날 한 직원의 업무용 노트북이 악성코드에 감염됐다. 공격자는 해당 노트북의 로그인된 세션을 이용해 활동하기 시작했고, 며칠 뒤 다음과 같은 사실이 발견됐다. - 정상적인 직원 계정과 회사 지급 노트북에서 요청이 발생했다. - VPN과 MFA 인증 기록에도 이상 징후가 없었다. - 외부에 공개되지 않은 여러 사내 시스템에 접근했다. - 해당 직원의 업무와 관계없는 시스템과 데이터까지 열람한 흔적이 있었다. - 대부분의 트래픽은 보안 장비에서 정상적인 사내 통신으로 기록됐다. 이런 문제를 방어하기 위한 가장 근본적인 보안 개선 방향은 무엇일까?
일 편하려고 AI에이전트를 도입했는데, 시스템이 망할 수 있다고?
김피엠이 사내용 AI 에이전트를 만들었다. 직원이 자연어로 물으면 ("이번 달 신규 가입자 수 알려줘") 에이전트가 SQL을 생성해주는 기능이다. 안정성을 위해 프롬프트에는 "SELECT만 생성하라, DELETE/UPDATE는 절대 금지" 라고 강하게 명시했다. 하지만 보안 리뷰에서 이 설계가 반려됐다. 가장 정확한 반려 사유는 무엇일까?
커넥션 풀을 10배 늘렸는데, 왜 API는 더 느려졌을까?
한 온라인 예약 서비스에서 트래픽이 증가한 뒤 API가 간헐적으로 다음 오류를 반환하기 시작했다. `Connection pool timeout` 운영팀은 애플리케이션의 DB 커넥션 풀 크기를 10개에서 100개로 늘렸다. 이후 커넥션을 기다리다 발생하는 오류는 줄었지만, 전체 API 응답 시간은 이전보다 느려졌다. 모니터링 결과 DB 서버의 CPU 사용률은 계속 100%에 가까웠고, 동시에 실행 중인 쿼리와 쿼리 대기 시간도 크게 증가해 있었다. 이 상황에 대한 판단과 우선 대응으로 가장 적절한 것은 무엇일까?
강제 로그아웃을 시킬 방법이 없다.
`404Vibe 로그인`을 만들 때 AI가 "요즘 표준"이라며 JWT를 추천했다. 서버는 세션을 저장하지 않고, 토큰의 서명만 검증한다(만료 24시간). 그런데 어느 날 한 사용자가 "노트북을 도난당했어요, 제 계정 로그아웃시켜주세요"라고 요청했다. 하지만 이미 발급된 토큰을 무효화할 방법이 서버에 없다. 이 상황에 대한 가장 정확한 이해는?
최근 문제 둘러보기
매주 최소 5개 이상의 문제가 추가됩니다. 판단력을 길러 바이브코딩 역량을 키우세요.
보안이 제대로 되어 있는데 왜 해킹 당했을까?
굴지의 대기업 `404Vibe Corp`는 주요 사내 시스템을 외부 인터넷에서 직접 접근할 수 없도록 구성하고 있다. 직원이 외부에서 접속하려면 회사 VPN에 연결해야 하며, VPN 로그인에는 MFA도 적용되어 있다. 어느 날 한 직원의 업무용 노트북이 악성코드에 감염됐다. 공격자는 해당 노트북의 로그인된 세션을 이용해 활동하기 시작했고, 며칠 뒤 다음과 같은 사실이 발견됐다. - 정상적인 직원 계정과 회사 지급 노트북에서 요청이 발생했다. - VPN과 MFA 인증 기록에도 이상 징후가 없었다. - 외부에 공개되지 않은 여러 사내 시스템에 접근했다. - 해당 직원의 업무와 관계없는 시스템과 데이터까지 열람한 흔적이 있었다. - 대부분의 트래픽은 보안 장비에서 정상적인 사내 통신으로 기록됐다. 이런 문제를 방어하기 위한 가장 근본적인 보안 개선 방향은 무엇일까?
좌석은 하나인데 예약이 두 건 생겼다.
`404Vibe 콘퍼런스`에는 좌석 예약 기능이 있다. 예약 테이블은 대략 다음과 같다. - id: 예약 ID - event_id: 행사 ID - seat_no: 좌석 번호 - user_id: 예약자 ID 예약 API는 사용자가 좌석을 선택하면 먼저 해당 좌석의 예약 여부를 조회하고, 예약된 데이터가 없으면 새로운 예약을 INSERT한다. 평소에는 문제가 없었지만 인기 세션 예약이 열린 직후 사고가 발생했다. 두 사용자가 거의 동시에 `A-17` 좌석을 선택했고, 두 요청 모두 조회 시점에는 "예약 가능"으로 판단됐다. 결과적으로 서로 다른 예약 ID를 가진 `A-17` 좌석 예약이 2건 저장됐다. 이 문제의 재발을 가장 확실하게 막기 위한 방법은?
홈 화면 하나 보여주는데 API를 5개나 호출해야 한다?
`404Vibe 앱`의 홈 화면은 사용자 프로필, 구독 상태, 오늘의 문제, 랭킹, 알림 정보를 보여준다. 서비스가 커지면서 각 기능은 별도 백엔드 서비스로 분리됐고, 현재 모바일 앱은 홈 화면을 열 때 각 서비스의 API를 직접 호출한다. 최근 랭킹 API 하나가 느려지자 홈 화면 전체가 늦게 뜨고, 일부 API의 응답 구조가 변경될 때마다 모바일 앱도 함께 수정해야 하는 문제가 반복되고 있다. 단, 프로필, 구독 상태 등 핵심 정보는 최신 데이터가 필요하며, 현재 규모에서 지나치게 복잡한 구조를 도입하고 싶지는 않다. 이 상황에서 가장 적절한 API 및 아키텍처 설계는?
인덱스가 있는데 왜 조회속도가 느리지?
`404Vibe 쇼핑몰`의 주문 데이터가 2,000만 건을 넘어가면서 특정 날짜의 주문을 조회하는 관리자 기능이 느려지기 시작했다. `orders` 테이블의 `created_at`에는 이미 B-Tree 인덱스가 존재한다. ```sql CREATE INDEX idx_orders_created_at ON orders(created_at); SELECT order_id, user_id, amount, created_at FROM orders WHERE DATE(created_at) = '2026-09-15'; ``` 그런데 실행 계획을 확인해보니 `idx_orders_created_at`을 사용하지 않고 많은 데이터를 순차적으로 읽고 있었다. DB 서버의 사양을 올리거나 새로운 캐시를 도입하기 전에, 가장 먼저 검토해야 할 개선 방법은 무엇일까?
카테고리별 탐색
관심 있는 영역부터 골라 실전 판단력을 훈련해보세요.