<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>StudyDad</title>
    <link>https://sses.tistory.com/</link>
    <description>운영의 복잡함보다
중요한 일에 더 많은 시간을 쓰게 만드는 구조를 고민합니다.</description>
    <language>ko</language>
    <pubDate>Sat, 11 Jul 2026 15:30:02 +0900</pubDate>
    <generator>TISTORY</generator>
    <ttl>100</ttl>
    <managingEditor>박세식</managingEditor>
    <image>
      <title>StudyDad</title>
      <url>https://tistory1.daumcdn.net/tistory/103293/attach/6424b88c52d34770b9563d5850a17aba</url>
      <link>https://sses.tistory.com</link>
    </image>
    <item>
      <title>서버리스만으로 부족했던 운영 콘솔 백엔드 설계</title>
      <link>https://sses.tistory.com/262</link>
      <description>운영 콘솔 아키텍처 시리즈 6/9

서버리스는 운영 부담을 크게 줄여준다. 트래픽이 없을 때 비용이 거의 없고, 갑작스러운 요청도 자동으로 확장된다. 그래서 운영 콘솔을 만들 때 모든 API를 Lambda로 만들고 싶어질 수 있다.
하지만 모든 요청이 Lambda에 잘 맞는 것은 아니다. 반대로 모든 요청을 상주 서버로 처리하는 것도 답은 아니었다.
문제 상황
운영 리포트 콘솔에는 성격이 다른 API가 섞여 있었다.
하나는 대시보드나 목록 조회처럼 짧고..</description>
      <category>성장과 기술/시스템 설계</category>
      <category>GitHub포트폴리오</category>
      <category>Lambda</category>
      <category>개발자성장</category>
      <category>백엔드설계</category>
      <category>상주서버</category>
      <category>서버리스</category>
      <category>시스템설계</category>
      <category>운영콘솔</category>
      <author>박세식</author>
      <guid isPermaLink="true">https://sses.tistory.com/262</guid>
      <comments>https://sses.tistory.com/262#entry262comment</comments>
      <pubDate>Sat, 11 Jul 2026 12:00:47 +0900</pubDate>
    </item>
    <item>
      <title>Lambda Function URL 대신 API Gateway를 선택한 이유</title>
      <link>https://sses.tistory.com/261</link>
      <description>운영 콘솔 아키텍처 시리즈 5/9
Lambda를 HTTP로 호출하려면 가장 단순한 방법은 Lambda Function URL이다. 별도 게이트웨이 없이 함수에 HTTPS URL을 붙일 수 있다. 작은 API라면 이 방식이 충분할 때도 많다.
그런데 운영 콘솔의 API 앞에는 API Gateway를 뒀다. 단순히 &amp;quot;원래 그렇게 하니까&amp;quot;가 아니라, 브라우저 기반 콘솔에서 필요한 운영 기능을 한곳에서 처리하기 위해서였다.
문제 상황
운영 콘..</description>
      <category>성장과 기술/시스템 설계</category>
      <category>apigateway</category>
      <category>GitHub포트폴리오</category>
      <category>Lambda</category>
      <category>개발자성장</category>
      <category>서버리스</category>
      <category>시스템설계</category>
      <category>아키텍처결정</category>
      <category>운영콘솔</category>
      <author>박세식</author>
      <guid isPermaLink="true">https://sses.tistory.com/261</guid>
      <comments>https://sses.tistory.com/261#entry261comment</comments>
      <pubDate>Fri, 10 Jul 2026 12:00:09 +0900</pubDate>
    </item>
    <item>
      <title>데이터베이스를 쓰지 않기로 한 아키텍처 결정</title>
      <link>https://sses.tistory.com/260</link>
      <description>운영 콘솔 아키텍처 시리즈 4/9
운영 도구를 만들 때 가장 먼저 데이터베이스를 떠올리는 경우가 많다. 목록이 있고, 상태가 있고, 조회 화면이 있으면 자연스럽게 RDB 테이블을 설계하게 된다.
하지만 모든 운영 콘솔에 데이터베이스가 필요한 것은 아니다. 어떤 경우에는 데이터베이스를 추가하지 않는 것이 더 단순하고 안전한 결정이 될 수 있다.
문제 상황
신청 관리 콘솔의 데이터 원천은 이미 외부에 있었다. 외부 파트너는 폼 도구로 신청했고, 운영자는 스..</description>
      <category>성장과 기술/시스템 설계</category>
      <category>GitHub포트폴리오</category>
      <category>json</category>
      <category>s3</category>
      <category>개발자성장</category>
      <category>데이터베이스</category>
      <category>시스템설계</category>
      <category>아키텍처결정</category>
      <category>운영콘솔</category>
      <author>박세식</author>
      <guid isPermaLink="true">https://sses.tistory.com/260</guid>
      <comments>https://sses.tistory.com/260#entry260comment</comments>
      <pubDate>Thu, 9 Jul 2026 12:00:30 +0900</pubDate>
    </item>
    <item>
      <title>관리자 페이지 배포에 서버가 꼭 필요할까?</title>
      <link>https://sses.tistory.com/259</link>
      <description>운영 콘솔 아키텍처 시리즈 3/9
React로 만든 관리자 페이지를 배포한다고 하면 자연스럽게 웹 서버를 떠올리기 쉽다. EC2 인스턴스를 만들고, Nginx를 설치하고, 빌드된 파일을 복사하고, HTTPS 인증서를 붙이는 식이다.
하지만 React SPA의 빌드 결과물은 대부분 정적 파일이다. 서버가 매 요청마다 HTML을 렌더링하지 않는다면, 24시간 떠 있는 웹 서버가 꼭 필요하지 않을 수 있다.
문제 상황
운영 콘솔은 React SPA였다. SE..</description>
      <category>성장과 기술/시스템 설계</category>
      <category>GitHub포트폴리오</category>
      <category>SPA배포</category>
      <category>개발자성장</category>
      <category>관리자페이지</category>
      <category>시스템설계</category>
      <category>아키텍처</category>
      <category>운영콘솔</category>
      <category>정적호스팅</category>
      <author>박세식</author>
      <guid isPermaLink="true">https://sses.tistory.com/259</guid>
      <comments>https://sses.tistory.com/259#entry259comment</comments>
      <pubDate>Wed, 8 Jul 2026 12:00:37 +0900</pubDate>
    </item>
    <item>
      <title>같은 관리자 페이지처럼 보여도, 도메인이 다르면 콘솔을 나눠야 한다</title>
      <link>https://sses.tistory.com/258</link>
      <description>운영 콘솔 아키텍처 시리즈 2/9
운영 도구를 만들다 보면 처음에는 &amp;quot;관리자 페이지 하나에 메뉴만 추가하면 되지 않을까?&amp;quot;라는 생각을 하기 쉽다. 실제로 화면만 보면 비슷해 보인다. 로그인하고, 목록을 보고, 상태를 바꾸고, 파일을 내려받는다.
하지만 관리자 페이지가 비슷한 모양을 하고 있다고 해서 같은 애플리케이션이어야 하는 것은 아니다. 내가 운영 콘솔을 설계하면서 가장 먼저 내린 결정은 콘솔을 하나로 합치지 않는 것이었다.
문제 ..</description>
      <category>성장과 기술/시스템 설계</category>
      <category>GitHub포트폴리오</category>
      <category>개발자성장</category>
      <category>관리자페이지</category>
      <category>도메인분리</category>
      <category>시스템설계</category>
      <category>아키텍처</category>
      <category>운영콘솔</category>
      <category>콘솔분리</category>
      <author>박세식</author>
      <guid isPermaLink="true">https://sses.tistory.com/258</guid>
      <comments>https://sses.tistory.com/258#entry258comment</comments>
      <pubDate>Tue, 7 Jul 2026 12:00:16 +0900</pubDate>
    </item>
    <item>
      <title>작은 운영 콘솔을 안정적으로 굴리기 위한 아키텍처 결정들</title>
      <link>https://sses.tistory.com/257</link>
      <description>운영 콘솔 아키텍처 시리즈 1/9
관리자 페이지는 겉으로 보기에는 단순해 보인다. 목록을 보여주고, 상태를 바꾸고, 파일을 내려받고, 내부 사용자가 필요한 데이터를 확인한다.
하지만 실제로 운영되는 콘솔을 만들다 보면 생각보다 많은 질문을 만나게 된다.

React로 만든 관리자 페이지는 어디에 배포하는 것이 좋을까?
모든 데이터를 RDB에 넣어야 할까?
Lambda만으로 백엔드를 구성해도 괜찮을까?
API Gateway는 꼭 필요한가?
오래 걸리는 리..</description>
      <category>성장과 기술/시스템 설계</category>
      <category>GitHub포트폴리오</category>
      <category>개발자성장</category>
      <category>관리자페이지</category>
      <category>기술의사결정</category>
      <category>시스템설계</category>
      <category>실무회고</category>
      <category>아키텍처</category>
      <category>운영콘솔</category>
      <author>박세식</author>
      <guid isPermaLink="true">https://sses.tistory.com/257</guid>
      <comments>https://sses.tistory.com/257#entry257comment</comments>
      <pubDate>Mon, 6 Jul 2026 12:00:37 +0900</pubDate>
    </item>
    <item>
      <title>다시 설계한다면 무엇을 바꿀까</title>
      <link>https://sses.tistory.com/256</link>
      <description>기술 실무 설계 시리즈 8/8
좋은 설계는 영구적인 정답이 아니다.
당시의 조건에서 합리적이었던 선택도 시간이 지나면 다시 볼 수 있다.
사용자가 늘고, 작업량이 늘고, 보안 요구사항이 바뀌고, 운영 인력이 달라지면 설계도 달라져야 한다.
그래서 설계 회고에는 &amp;quot;다시 설계한다면 무엇을 볼 것인가&amp;quot;가 필요하다.
지금 구조가 틀렸다는 뜻은 아니다
다시 설계한다는 말은 현재 구조가 틀렸다는 뜻이 아니다.
현재 구조는 당시 조건에서 합리적일 ..</description>
      <category>성장과 기술/시스템 설계</category>
      <category>GitHub포트폴리오</category>
      <category>개발자성장</category>
      <category>기술회고</category>
      <category>내부도구</category>
      <category>시스템설계</category>
      <category>실무회고</category>
      <category>아키텍처</category>
      <category>운영콘솔</category>
      <author>박세식</author>
      <guid isPermaLink="true">https://sses.tistory.com/256</guid>
      <comments>https://sses.tistory.com/256#entry256comment</comments>
      <pubDate>Sun, 5 Jul 2026 12:00:10 +0900</pubDate>
    </item>
    <item>
      <title>운영 복잡도를 비용처럼 계산하기</title>
      <link>https://sses.tistory.com/255</link>
      <description>기술 실무 설계 시리즈 7/8
클라우드 비용은 숫자로 보인다.
월 몇 달러, 인스턴스 비용, Lambda 호출 비용, S3 저장 비용처럼 계산할 수 있다.
하지만 운영 복잡도는 잘 보이지 않는다.
배포할 때마다 사람이 확인해야 하는 절차, 장애 때마다 찾아야 하는 로그, 헷갈리는 도메인, 수동으로 맞춰야 하는 설정도 모두 비용이다.
작은 운영 도구에서는 이 보이지 않는 비용을 더 중요하게 봐야 할 때가 있다.
비용은 돈만이 아니다
기술 선택을 할 때 클..</description>
      <category>성장과 기술/시스템 설계</category>
      <category>GitHub포트폴리오</category>
      <category>개발자성장</category>
      <category>기술부채</category>
      <category>내부도구</category>
      <category>시스템설계</category>
      <category>아키텍처</category>
      <category>운영복잡도</category>
      <category>운영콘솔</category>
      <author>박세식</author>
      <guid isPermaLink="true">https://sses.tistory.com/255</guid>
      <comments>https://sses.tistory.com/255#entry255comment</comments>
      <pubDate>Sat, 4 Jul 2026 12:00:44 +0900</pubDate>
    </item>
    <item>
      <title>처음부터 완벽한 공통화를 하지 않은 이유</title>
      <link>https://sses.tistory.com/254</link>
      <description>기술 실무 설계 시리즈 6/8
비슷한 운영 콘솔을 여러 개 만들면 공통화 욕구가 생긴다.
같은 React를 쓰고, 비슷한 레이아웃을 쓰고, API 호출 방식도 비슷하다면 공통 패키지를 만들고 싶어진다.
하지만 처음부터 완벽한 공통화를 하는 것이 항상 좋은 선택은 아니다.
특히 도메인이 다른 운영 도구에서는 중복 제거보다 책임 경계가 더 중요할 때가 있다.
공통화가 매력적인 이유
공통화에는 분명한 장점이 있다.

중복 코드가 줄어든다.
UI 일관성이 생긴..</description>
      <category>성장과 기술/시스템 설계</category>
      <category>GitHub포트폴리오</category>
      <category>개발자성장</category>
      <category>공통화</category>
      <category>기술부채</category>
      <category>내부도구</category>
      <category>시스템설계</category>
      <category>아키텍처</category>
      <category>운영콘솔</category>
      <author>박세식</author>
      <guid isPermaLink="true">https://sses.tistory.com/254</guid>
      <comments>https://sses.tistory.com/254#entry254comment</comments>
      <pubDate>Fri, 3 Jul 2026 12:00:11 +0900</pubDate>
    </item>
    <item>
      <title>API Gateway를 운영 경계로 보는 법</title>
      <link>https://sses.tistory.com/253</link>
      <description>기술 실무 설계 시리즈 5/8
API Gateway는 종종 Lambda 앞에 붙이는 프록시처럼 여겨진다.
요청을 받아 Lambda로 넘겨주는 역할 말이다.
하지만 브라우저 기반 운영 콘솔에서는 API Gateway를 단순 프록시로 보면 부족하다.
CORS, 라우팅, 스로틀링, 로그, 인증 확장성, 백엔드 교체 가능성까지 포함한 운영 경계로 보는 편이 더 맞다.
API 앞단에는 정책이 필요하다
프론트엔드가 API를 호출할 때 단순히 백엔드 함수만 있으면 ..</description>
      <category>성장과 기술/시스템 설계</category>
      <category>apigateway</category>
      <category>api설계</category>
      <category>GitHub포트폴리오</category>
      <category>내부도구</category>
      <category>시스템설계</category>
      <category>아키텍처</category>
      <category>운영경계</category>
      <category>운영콘솔</category>
      <author>박세식</author>
      <guid isPermaLink="true">https://sses.tistory.com/253</guid>
      <comments>https://sses.tistory.com/253#entry253comment</comments>
      <pubDate>Thu, 2 Jul 2026 12:00:52 +0900</pubDate>
    </item>
  </channel>
</rss>