AI 제품 개발 핵심 개념 지도: 프롬프트에서 평가와 운영까지
데모는 십 분 만에 나오는데 제품이 되지 않는 일이 반복됩니다. 잘 되던 프롬프트가 입력이 조금 달라지면 무너지고, 고쳤더니 다른 경우가 깨지고, 무엇이 나아졌는지 말할 근거가 없습니다. 모델을 다루는 어려움보다는 정답이 하나가 아닌 시스템을 어떻게 판정하고 운영할지의 문제입니다.
데모는 십 분 만에 나오는데 제품이 되지 않는 일이 반복됩니다. 잘 되던 프롬프트가 입력이 조금 달라지면 무너지고, 고쳤더니 다른 경우가 깨지고, 무엇이 나아졌는지 말할 근거가 없습니다. 모델을 다루는 어려움보다는 정답이 하나가 아닌 시스템을 어떻게 판정하고 운영할지의 문제입니다.
보안 사고는 대개 아무도 모르던 정교한 기법이 아니라, 다들 알고 있었지만 이 자리에는 없을 거라고 생각한 실수에서 시작합니다. 검증하지 않은 입력 하나, 권한 확인을 빠뜨린 엔드포인트 하나, 저장소에 그대로 남은 토큰 하나면 충분합니다. 그래서 보안은 마지막에 붙이는 점검이 아니라 설계할 때 함께 정해지는 성질에 가깝…
웹을 만들던 방식 그대로 앱을 만들면 대개 두 지점에서 막힙니다. 하나는 화면이 언제 살아 있고 언제 죽는지 앱이 마음대로 정한다는 것이고, 다른 하나는 만든 것을 바로 내보낼 수 없다는 것입니다. 브라우저에서는 새로고침이 해결하던 문제를 앱에서는 상태 복원과 심사 대기가 대신합니다.
같은 기능을 만드는데 어떤 팀은 이틀에 끝내고 어떤 팀은 두 달을 씁니다. 실력 차이보다는 앞선 결정들이 무엇을 허용하고 무엇을 막아 놓았는지의 차이인 경우가 많습니다. 아키텍처는 화려한 다이어그램이 아니라, 나중에 바꾸기 어려운 결정들의 집합입니다.
새로 만든 서버를 점검하다가 이걸 봤습니다.
하루에 두 번 이 단어들을 만났습니다. 오전에는 터널 설정 화면에서 ingress 를 봤고, 오후에는 데이터베이스 청구 항목에서 egress 를 봤습니다. 몇 년째 둘 다 쓰고 있었는데, 그날에서야 같은 축의 양쪽이라는 게 눈에 들어왔습니다.
데모 사이트 하나가 느렸습니다. 첫 바이트까지 1초가 걸렸습니다. 대시보드를 여는 화면이라 무겁긴 한데, 그래도 1초는 이상했습니다. 앱을 뜯어볼 생각으로 시작했다가, 결국 앱은 한 줄도 안 고쳤습니다.
Vultr와 AWS를 비교하면서 처음에는 같은 vCPU와 메모리를 가진 서버의 월 요금만 표로 만들려고 했습니다. 그런데 이 방식은 시작부터 비교 대상을 잘못 잡은 것이었습니다. Vultr Cloud Compute는 디스크와 전송량이 묶인 VPS형 상품이고, AWS EC2는 컴퓨팅을 중심으로 EBS, 공개 IPv4, 데…
Vultr 인스턴스 생성 화면을 보면 운영체제를 고르는 일이 꽤 단순해 보입니다. 캡처 화면에서도 Operating System과 Ubuntu 26.04 LTS x64가 이미 선택되어 있습니다. 저도 처음에는 최신 LTS가 선택되어 있으니 그대로 진행하면 되겠다고 생각했습니다.
NGINX와 Caddy를 비교해 달라는 요청을 받고 처음 떠올린 답은 단순했습니다. Caddy는 설정이 쉽고 NGINX는 오래되고 강력하다는 구분이었습니다. 공식 문서를 확인하니 이 설명은 방향만 맞고, 2026년의 선택 기준으로 쓰기에는 빠진 내용이 많았습니다.