AI가 코드는 짜줘도,
판단은 네가 해야 한다.
바이브코더를 위한 실전형 개발 판단력 문제풀이.
실제 발생하는 상황 별 문제를 풀며, AI에게 정확히 지시하는 감각을 기릅니다.
안녕, 난 바이트!
하루 5문제면 충분해. 같이 판단력 키워보자
가장 많이 풀어본 문제
1위 문제는 729번 도전받았어요.
커넥션 풀을 10배 늘렸는데, 왜 API는 더 느려졌을까?
한 온라인 예약 서비스에서 트래픽이 증가한 뒤 API가 간헐적으로 다음 오류를 반환하기 시작했다. `Connection pool timeout` 운영팀은 애플리케이션의 DB 커넥션 풀 크기를 10개에서 100개로 늘렸다. 이후 커넥션을 기다리다 발생하는 오류는 줄었지만, 전체 API 응답 시간은 이전보다 느려졌다. 모니터링 결과 DB 서버의 CPU 사용률은 계속 100%에 가까웠고, 동시에 실행 중인 쿼리와 쿼리 대기 시간도 크게 증가해 있었다. 이 상황에 대한 판단과 우선 대응으로 가장 적절한 것은 무엇일까?
강제 로그아웃을 시킬 방법이 없다.
`404Vibe 로그인`을 만들 때 AI가 "요즘 표준"이라며 JWT를 추천했다. 서버는 세션을 저장하지 않고, 토큰의 서명만 검증한다(만료 24시간). 그런데 어느 날 한 사용자가 "노트북을 도난당했어요, 제 계정 로그아웃시켜주세요"라고 요청했다. 하지만 이미 발급된 토큰을 무효화할 방법이 서버에 없다. 이 상황에 대한 가장 정확한 이해는?
주문 테이블에 메모를 길게 넣었더니 갑자기 느려졌다
주문 관리 시스템을 만들었다. 처음에는 주문 테이블에 주문번호, 회원번호, 금액, 상태 정도만 있었다. 그런데 운영팀 요청으로 “관리자 메모”, “상담 이력”, “배송 특이사항”, “CS 처리 내용”을 전부 주문 테이블에 TEXT 컬럼으로 추가했다. 처음엔 잘 됐지만 시간이 지나자 주문 목록 조회가 느려졌다. 목록 화면은 주문번호, 금액, 상태만 보여주는데도 느리다. 이를 해결하기 위해 가장 적절한 판단은?
RAG를 붙였는데 챗봇이 더 당당하게 틀린다.
사내 규정 챗봇에 RAG를 붙였다. 문서를 청크로 쪼개 벡터DB에 넣고, 질문과 유사한 청크를 검색해 LLM에 넘기는 표준 구성이다. 그런데 테스트해보니 이상하다. "연차 이월 규정"을 물으면 출장비 규정을 근거로 그럴듯한 답을 지어낸다. 심지어 "규정 제12조에 따르면"이라며 출처까지 단다. 검색 로그를 보니 연차 관련 청크의 유사도 점수가 낮은데도 상위 3개가 무조건 LLM에 전달되고 있었다. 가장 효과적인 개선 조합은?
최근 문제 둘러보기
매주 최소 5개 이상의 문제가 추가됩니다. 판단력을 길러 바이브코딩 역량을 키우세요.
로그를 지우다가 데이터베이스를 날려버렸다...
404Vibe의 내부시스템인 `404Vibe ERP`는 온프레미스 환경이다. 이 중, Linux 서버에서 운영 중인 Oracle DB의 디스크 사용량이 빠르게 증가하고 있었다. 김피엠은 불필요한 로그 파일을 정리하기 위해 서버에 접속해 삭제 명령을 실행했다. 그런데 작업 경로를 잘못 지정하면서 로그 파일뿐 아니라 Oracle 데이터파일 일부까지 삭제됐다. 잠시 뒤 특정 테이블스페이스를 사용하는 업무에서 오류가 발생했고, ERP 서비스가 중단됐다. 삭제 명령을 잘못 실행한 것이 직접적인 원인이지만, 같은 실수가 다시 발생하더라도 핵심 데이터파일 삭제까지 이어지지 않게 하려면 어떤 조치가 가장 우선일까?
1,000포인트를 썼는데 왜 잔액이 0이 아닐까?
한 서비스는 사용자가 기능을 실행할 때마다 0.1포인트를 차감한다. 김피엠은 AI가 만들어준 코드로 포인트 기능을 구현했고, 포인트 잔액을 DB의 `FLOAT` 컬럼에 저장했다. 화면에서는 별문제 없어 보였지만, 0.1포인트를 여러 번 차감한 사용자의 잔액을 확인해보니 다음과 같은 값이 저장되어 있었다. `0.0000000000001421` 실제로는 포인트를 모두 사용했으므로 잔액이 정확히 0이어야 한다. 이 현상의 원인과 가장 적절한 개선 방법은 무엇일까?
쓴 만큼만 낸다는 서버리스, 왜 고정 서버보다 비싸졌을까?
요즘 트랜드하게 뜨는 예약 서비스인 `404Vibe 예약`은 기존에 월 5만 원 정도의 소형 서버 한 대에서 API를 운영하고 있었다. 운영자인 김PM은 서버 관리 부담을 줄이고 트래픽에 따라 자동 확장하기 위해 모든 API를 서버리스 함수로 전환했다. 기능 전환에는 성공했지만 다음 달 관련 클라우드 비용은 약 50만 원으로 증가했다. 운영 지표를 확인해보니 다음과 같았다. * 트래픽은 하루 종일 평균 초당 5~10건으로 꾸준하게 발생했다. * 대부분의 시간대에 요청이 완전히 사라지는 구간은 없었다. * 함수는 요청 한 건당 평균 800ms 동안 실행됐다. * 함수는 호출될 때마다 DB 커넥션을 새로 생성했고, 연결에 평균 300ms가 걸렸다. * 비용에는 함수 실행 비용뿐 아니라 요청 처리와 API 게이트웨이 비용도 포함돼 있었다. 이 상황에 대한 판단과 개선 방향으로 가장 적절한 것은 무엇일까?
커넥션 풀을 10배 늘렸는데, 왜 API는 더 느려졌을까?
한 온라인 예약 서비스에서 트래픽이 증가한 뒤 API가 간헐적으로 다음 오류를 반환하기 시작했다. `Connection pool timeout` 운영팀은 애플리케이션의 DB 커넥션 풀 크기를 10개에서 100개로 늘렸다. 이후 커넥션을 기다리다 발생하는 오류는 줄었지만, 전체 API 응답 시간은 이전보다 느려졌다. 모니터링 결과 DB 서버의 CPU 사용률은 계속 100%에 가까웠고, 동시에 실행 중인 쿼리와 쿼리 대기 시간도 크게 증가해 있었다. 이 상황에 대한 판단과 우선 대응으로 가장 적절한 것은 무엇일까?
카테고리별 탐색
관심 있는 영역부터 골라 실전 판단력을 훈련해보세요.