SA 기획: 경험 기반의 아이디어를 현실화
카카오 채널로 발주를 받아 자동으로 ERP에 넣는 화면을 만들었다고 해 봅시다. 데모에서는 문제없이 돌았고 고객도 만족했습니다. 그런데 출시 첫 주에 거래처 담당자가 수량 칸에 규격을 잘못 눌러 보냈고, 그 값이 그대로 ERP에 들어갔습니다. 이걸 누가 발견하고, 누구에게 알리고, ERP의 어느 값을 고쳐야 하는지는 화…
카카오 채널로 발주를 받아 자동으로 ERP에 넣는 화면을 만들었다고 해 봅시다. 데모에서는 문제없이 돌았고 고객도 만족했습니다. 그런데 출시 첫 주에 거래처 담당자가 수량 칸에 규격을 잘못 눌러 보냈고, 그 값이 그대로 ERP에 들어갔습니다. 이걸 누가 발견하고, 누구에게 알리고, ERP의 어느 값을 고쳐야 하는지는 화…
제조업체를 상대로 업무 시스템 제안서를 쓰다 보면 같은 지점에서 막힙니다. "이카운트보다 나은 ERP를 만들어 드리겠습니다"라는 문장을 쓰는 순간 이미 진 싸움이 됩니다. 회계, 세무, 급여, 4대보험, 전자세금계산서는 법과 제도가 정한 표준이고, 이카운트는 이걸 월 4만원에 처리합니다. 수천만원을 들여 같은 기능을 다…
관리자 화면 왼쪽 메뉴에 「상품 관리」, 「고객 관리」, 「주문 관리」, 「운영 정책」이 나란히 있습니다. 넷 다 누르면 목록이 뜨고, 한 줄을 누르면 수정 폼이 열리고, 저장 버튼이 있습니다. 화면만 보면 같은 물건입니다.
인쇄기 롤러를 만드는 제조사와 첫 협의를 했을 때 들은 요청은 두 가지였습니다. 견적 단계마다 영업사원이 직접 방문해야 해서 하루에 처리할 수 있는 건수가 막힌다는 것, 그리고 중국어와 독일어 대응이 필요하다는 것이었습니다.
요청 제한을 분당 30회로 걸어 두었습니다. 접근 로그에는 같은 초에 수백 건이 찍혀 있는데 429는 한 건도 없습니다.
브라우저 안에서 도는 데스크톱을 만들고 있습니다. 창과 Dock과 터미널은 있는데 그 위에 올릴 앱이 없어서, 유틸리티 칸에 지뢰찾기를 하나 넣었습니다. 잘 돌길래 다음으로 체스를 만들기 시작했는데, 규칙을 다 짜고 엔진을 붙이려는 자리에서 한 번 멈춰야 했습니다. 지뢰찾기에는 없던 문제가 있었기 때문입니다.
첫 고객의 업무 시스템을 만들기 시작하면 보안 항목 목록이 금세 길어집니다. MFA, 세션, 감사 로그, 백업, 접근 통제, SSO, 기기 인증, 로그 중앙화, 전용 네트워크. 목록을 다 채우고 시작하려 하면 업무 기능을 만들기 전에 인프라 설정으로 몇 주가 지나갑니다.
사내 업무 시스템을 만들 때 데이터베이스를 고르는 질문은 대개 이렇게 나옵니다. 「그냥 PostgreSQL 쓰면 되지 않나요? Supabase 는 뭐가 다른가요?」
사내 업무 시스템을 만들 때 자주 나오는 질문이 있습니다. 「앞에 Cloudflare Access 같은 걸 두면 보안은 끝나는 것 아닌가요?」
사진 목록에서 사진을 누르면 모달로 크게 보여 주고, 같은 주소를 새 탭에서 열면 전체 페이지로 보여 주는 화면이 있습니다. 주소는 /photo/123 하나인데 보이는 모양이 둘입니다.
서버 컴포넌트에서 데이터를 읽는 코드는 이렇게 생깁니다.
공개하지 않고 내부에서만 여는 제품 카탈로그 데모에 언어 전환을 붙였습니다. 한국어, 영어, 중국어, 일본어, 독일어, 프랑스어 여섯 개입니다. 고른 언어는 쿠키에 저장하고, 쿠키가 없으면 브라우저의 Accept-Language 헤더를 봅니다. 주소는 나누지 않았습니다. /products/<기종> 하나로 여섯 언어를 모…
앱 라우터에서 서버로 무언가를 보내는 방법이 둘입니다. app/api/.../route.ts 에 라우트 핸들러를 만들거나, "use server" 를 붙인 서버 함수를 부르는 것입니다. 폼 하나를 붙일 때마다 어느 쪽을 쓸지 정해야 하는데, 「둘 다 서버에서 도니 아무거나」로 두면 나중에 갈립니다.
제품 카탈로그 데모를 만들면서 이미지 처리 방식을 정해야 했습니다. 화면에 나가는 사진은 제품 사진 몇 장과 로고뿐이고, 모두 저장소에 들어 있는 파일입니다. 요청마다 달라질 것이 없습니다.
같은 Docker 이미지를 스테이징과 운영에 함께 올리는 구성이 있습니다. 환경 변수는 각 환경의 설정으로 주입합니다. 서버 쪽 값은 환경에 맞게 잘 바뀌는데, 브라우저에서 쓰는 분석 도구 ID 만 두 환경에서 같은 값이 나옵니다. 스테이징의 방문 기록이 운영 통계에 섞입니다.
글을 발행하면 블로그의 RSS 에는 몇 초 만에 새 글이 들어오는데, 사이트맵에는 며칠째 들어오지 않았습니다. 응답 헤더의 age 값만 계속 올라갔습니다. 발행할 때 캐시 태그를 무효화하고 있었고, 그 태그는 글 목록과 RSS 가 함께 쓰는 태그였습니다. RSS 는 갱신되는데 사이트맵만 멈춰 있었습니다.
Next.js 앱 라우터에는 오류를 다루는 파일이 셋 있습니다. error.tsx, global-error.tsx, not-found.tsx 입니다. 이름만 보면 「오류 화면, 전체 오류 화면, 404 화면」으로 나뉘는 것 같은데, 실제로는 각자 감싸는 범위와 잡는 대상이 다릅니다. 하나로 다 될 것 같아서 error.…
Next.js 16 으로 올리면 middleware.ts 에 경고가 붙습니다. 파일 규칙 이름이 proxy 로 바뀌었다는 안내입니다. Proxy 문서의 첫 문장은 기능이 그대로라고 적습니다.
로딩 화면 파일 하나의 위치를 옮겨 push 했는데 Vercel 빌드가 실패했습니다. 페이지의 동작을 바꾸는 코드는 건드리지 않은 커밋이었습니다. 빌드 로그의 오류 줄은 이랬습니다.
Next.js 앱 라우터에서 한 폴더에는 이런 파일들이 함께 놓입니다.