앞선 편에서 만든 자동화 결과(기사 모니터링, Slack 알림 등)를 매번 따로 돌리는 대신, 한 화면에 모아 버튼만 누르면 최신 상태로 보는 '나만의 업무 대시보드'를 만든다. 예약 실행(cron) 대신, 백엔드(데이터 수집·키 보관) + 프론트엔드(화면) 구조의 작은 로컬 웹앱으로 만들며, 5단계로 진행한다. ① 왜 프론트+백엔드인가 ② 담을 위젯 설계 ③ 백엔드 만들기 ④ 프론트엔드 만들기 ⑤ 실행·확장이다. 1편에서 익힌 '키는 .env에, 연결은 프롬프트로' 원칙을 그대로 확장하므로, 코드를 직접 짜지 않아도 된다.

1. 왜 '프론트+백엔드' 구조인가요?

대시보드를 정적 HTML 한 장으로 만들면, API 키가 브라우저(프론트엔드)에 그대로 노출된다. 그래서 키를 들고 외부 서비스를 호출하는 일은 백엔드가 맡고, 화면은 프론트엔드가 맡도록 역할을 나눈다. 1편의 "키는 .env에" 원칙을 한 단계 발전시킨 구조다.

동작 흐름은 다음과 같다.

1. 화면(프론트엔드)에서 새로고침 버튼을 누른다.
2. 프론트엔드가 내 컴퓨터의 백엔드에 "데이터 줘"라고 요청한다.
3. 백엔드가 .env의 키로 네이버 등 외부 API를 호출해 데이터를 받아온다.
4. 백엔드가 정리한 결과를 프론트엔드에 돌려주고, 화면이 위젯으로 그린다.

이렇게 나누면 키는 백엔드(.env)에만 머물고, 화면에는 결과만 표시되므로 안전하다. 모든 것이 내 컴퓨터 안에서 돌아가 외부로 새지 않는다.

왜 이 분리가 초보자에게 특히 중요한가

이 두 층 분리는 단순한 개발 관습이 아니라 '실수해도 안전한' 설계다. 코드를 직접 짜지 않는 사람일수록 API 키를 어디에 두는지 감각이 없어서, 편한 대로 HTML 안에 붙여 넣기 쉽다. 문제는 그 순간 키가 브라우저 개발자 도구, 페이지 소스 보기, 혹은 화면 캡처만으로도 그대로 노출된다는 점이다. 네이버 검색 API처럼 무료 할당량이 있는 키라도, 유출되면 남이 내 이름으로 호출량을 소진하거나 계정 제재로 이어질 수 있다.

백엔드를 한 겹 두면 브라우저는 "데이터 줘"라는 요청만 보내고, 실제 키는 내 컴퓨터의 서버 프로세스 안에만 존재한다. 즉 화면을 누가 열어 보든 키는 물리적으로 그 화면에 도달하지 않는다. 초보자가 저지르기 쉬운 가장 값비싼 사고 하나를 구조 자체가 막아 주는 셈이다. 나중에 위젯이 늘어 여러 API 키를 다루게 될 때 이 원칙이 더 큰 차이를 만든다.

2. 대시보드에 담을 것 설계하기

코드를 만들기 전에, 무엇을 한 화면에서 보고 싶은지 '위젯' 단위로 먼저 정한다. 위젯이란 대시보드 안의 작은 정보 카드 하나를 말한다. 각 위젯마다 '무슨 데이터를, 어디서, 어떻게 가져올지'를 적어 두면 다음 단계가 쉬워진다.

자주 쓰는 위젯 후보는 다음과 같다.

1. 경쟁사 뉴스: 2편에서 만든 네이버 검색 API 결과를 그대로 카드로 표시
2. 오늘 할 일: 직접 입력하거나 메모 파일을 읽어 표시
3. 주요 지표: 방문자·매출 등 매일 확인하는 숫자 한 줄 요약
4. 일정·마감: 캘린더 API나 마감 목록에서 임박한 항목 표시

처음에는 위젯 1~2개로 작게 시작하고, 익숙해지면 늘리는 것이 좋다. 핵심은 "매일 아침 이 화면 하나만 보면 되는" 구성이다.

위젯을 먼저 종이에 적는 이유

위젯을 미리 정의하라는 조언은 단순한 정리 습관이 아니라, AI에게 일을 시킬 때 결과 품질을 좌우하는 실질적 장치다. Claude Code 같은 도구에 "대시보드 만들어줘"라고만 하면 AI는 무엇을 담을지 스스로 추측하고, 그 추측은 대개 내 업무와 어긋난다. 반대로 "경쟁사 뉴스 5건, 오늘 할 일, 방문자 수 한 줄" 이라고 위젯 목록을 명시하면, 각 위젯이 필요로 하는 데이터 소스와 API 주소가 자동으로 정리된다. 즉 위젯 목록은 곧 백엔드가 만들어야 할 /api/... 주소 목록이 된다.

한국 실무자 관점에서 한 가지 더 짚을 점은 데이터 소스의 현실성이다. 방문자·매출 같은 지표는 회사마다 GA, 자체 DB, 스프레드시트 등으로 흩어져 있어 API 연결 난이도가 제각각이다. 그래서 4개를 한꺼번에 붙이려 하기보다, API가 이미 준비된 경쟁사 뉴스(2편의 네이버 검색)부터 붙여 한 사이클을 끝내 보는 편이 낫다. 작동하는 위젯 하나를 손에 쥐면 나머지는 같은 패턴을 복사·확장하는 일이 되기 때문이다.

3. 백엔드 만들기 (데이터와 키 담당)

먼저 데이터를 모아 주는 백엔드를 만든다. 직접 코드를 짜는 대신, Claude Code에 ".env 키로 데이터를 받아 화면에 넘겨줄 작은 로컬 서버"를 만들어 달라고 요청하면 된다. 예를 들어 이렇게 적는다.

내 컴퓨터에서만 도는 작은 백엔드 서버를 만들어줘. (Python FastAPI)
.env의 NAVER_CLIENT_ID·NAVER_CLIENT_SECRET로 네이버 검색 API를 호출해서
'버거킹' 최신 뉴스 5건을 가져오는 /api/news 주소를 만들어줘.
키는 코드에 쓰지 말고 .env에서 읽고, 결과는 제목·링크만 JSON으로 돌려줘.

이렇게 요청하면 AI가 .env에서 키를 읽어 네이버 API를 호출하고, 정리한 결과를 /api/news 주소로 내려주는 서버 코드를 만들어 준다. 위젯을 추가할 때마다 "할 일 목록을 주는 /api/todos도 만들어줘"처럼 주소를 하나씩 늘리면 된다.

프롬프트 한 문장이 왜 그렇게 구체적인가

위 프롬프트가 짧아 보여도, 실은 백엔드가 갖춰야 할 조건을 빠짐없이 담고 있다. "내 컴퓨터에서만 도는"은 외부에 공개하지 말라는 범위 지정이고, "(Python FastAPI)"는 기술 스택을 못 박아 AI가 매번 다른 프레임워크를 고르지 않게 한다. "키는 코드에 쓰지 말고 .env에서 읽고"는 1편의 보안 원칙을 프롬프트 안에서 재확인하는 안전장치다. 마지막 "제목·링크만 JSON으로"는 응답 형식을 좁혀, 프론트엔드가 나중에 다루기 쉬운 깔끔한 데이터를 받도록 한다.

이 구조가 강력한 이유는 확장이 곧 문장 추가이기 때문이다. 새 위젯이 필요하면 새 코드를 배우는 대신 "/api/todos도 만들어줘"라는 주소 하나를 말로 늘리면 된다. 백엔드는 이렇게 주소(엔드포인트)가 쌓여 가는 서랍장 같은 구조가 되고, 각 서랍이 위젯 하나와 일대일로 대응한다. 다만 주의할 점은 무료 API의 호출 한도다. 네이버 검색 API는 일일 호출 제한이 있으므로, 뒤이어 다룰 자동 새로고침 주기를 너무 짧게 잡으면 한도를 빠르게 소진할 수 있다.

4. 프론트엔드(대시보드 화면) 만들기

백엔드가 데이터를 내려주면, 그 데이터를 보기 좋게 그리는 화면을 만든다. 이것도 프롬프트로 맡긴다. 백엔드가 만든 주소를 불러와 위젯으로 배치해 달라고 요청한다.

방금 만든 백엔드의 /api/news를 불러와서 보여주는 대시보드 화면을 HTML로 만들어줘.
- 위쪽에 '새로고침' 버튼, 누르면 최신 데이터를 다시 불러오기
- 뉴스는 카드 형태로, 제목을 누르면 원문 링크로 이동
- 카드들을 격자(그리드)로 배치하고, 다크 네이비 톤으로 깔끔하게

이렇게 하면 버튼 한 번에 백엔드를 다시 호출해 화면이 갱신되는 대시보드가 완성된다. 위젯을 늘릴 때는 "오른쪽에 할 일(/api/todos) 위젯도 추가해줘"처럼 화면 구성만 말로 지시하면 된다.

5. 실행하고 한 걸음 더

마지막으로 백엔드 서버를 켠 다음, 브라우저에서 localhost 주소로 대시보드 화면을 열면 끝이다. 실행 방법도 Claude Code에게 물어보면 명령어를 알려 주며, 보통 한 줄이면 충분하다.

이 백엔드를 내 컴퓨터에서 실행하는 방법을 알려줘.
그리고 실행한 뒤 브라우저에서 어떤 주소(localhost)로 들어가면
대시보드가 보이는지 알려줘.

서버를 켠 상태에서 안내받은 localhost 주소로 들어가면 대시보드가 뜨고, 새로고침 버튼으로 언제든 최신 상태를 볼 수 있다. 켜 두는 동안 자동으로 일정 시간마다 갱신되게 하고 싶다면 "화면이 5분마다 자동으로 새로고침되게 해줘"라고 한 줄 덧붙이면 된다. 위젯을 하나씩 늘려 가면, 매일 아침 이 화면 하나로 업무를 시작하는 '나만의 일잘러 대시보드'가 완성된다.

이 방식의 한계와 현실적 판단

이 대시보드는 어디까지나 '내 컴퓨터에서 도는' 개인용 도구다. 서버를 끄면 화면도 멈추고, localhost 주소는 남에게 공유되지 않는다. 이것은 단점이 아니라 의도된 경계다. 회사 데이터를 다루는 개인이 별도 서버 비용이나 보안 검토 없이 즉시 쓸 수 있고, 문제가 생겨도 영향 범위가 내 노트북 안에 갇힌다. 반대로 팀 전체가 함께 보는 상시 대시보드가 필요하다면 이 방식은 적합하지 않으며, 그때는 별도 배포와 접근 권한 관리가 필요한 다른 층위의 작업이 된다.

또 하나 유념할 점은 이 구조가 예약 실행(cron)을 완전히 대체하지는 않는다는 것이다. 대시보드는 '내가 볼 때 최신으로 당겨오는' 풀(pull) 방식이라, 내가 화면을 열지 않으면 아무 일도 일어나지 않는다. 반대로 앞선 편의 Slack 알림 같은 '변화가 생기면 나에게 밀어주는' 푸시(push)형 자동화는 여전히 유효하다. 따라서 현명한 조합은 즉각 대응이 필요한 사건은 알림으로 밀어 두고, 매일 아침 훑어보는 종합 현황은 대시보드로 당겨 보는 두 방식의 역할 분담이다. 이 편에서 만든 화면은 그 아침 루틴의 시작점에 해당한다.

---

참고: FastAPI 공식 문서 · 네이버 검색 API 문서 · Claude Code 공식 문서