Private DEVLOG
Back to projects
4 min read

Tech Stack

Table of Contents

저의 프로젝트에서 사용하는 기술 스택과 핵심 원칙을 정리한 문서입니다.

Backend

백엔드는 API + MCP, 그리고 추후에도 바뀔 수 있는 프로토콜에 유연하게 대응하고,
최대한 공통된 구조를 유지하여 서비스 확장과 유지보수를 쉽게 하는 것을 목표로 하고 있습니다.

Tech stack & direction

  1. Go를 주 언어, Python을 보조 언어로 사용합니다.
    • Go는 프론트엔드가 아니라면 어떤 서비스를 만들건 유용하게 사용할 수 있습니다.
      • 컴파일 언어라서 이미지 용량도 적고, 성능이 좋은 것도 마움에 들었습니다.
    • Python은 압도적으로 풍부한 라이브러리 환경과 편의성이 강점입니다.
      • 특히 LangChain이 지원하는 유이한 언어입니다. (다른 언어는 JS/TS)
      • 다른 언어에서 불가능하거나 공수가 많이 들어가는 작업을 Python으로 쉽게 처리할 수도 있습니다.
      • 최근 uv의 등장 이후 개발 경험도 많이 좋아졌습니다.
      • 다만 Go에 비해 성능이 떨어지고, AI를 활용한 개발을 할 때 가상환경이 방해된다고 판단하여 보조 언어로 사용합니다.
  2. 최대한 MSA 아키텍쳐를 지향합니다.
  3. 비즈니스 로직은 프로토콜 의존성을 가지지 않도록 합니다.
    • 의도적으로 Request와 Response라는 네이밍도 사용하지 않고 대신 Input과 Output을 사용하고 있습니다.
      미래에 어떤 프로토콜이 등장해도 Input과 Output이라는 명칭은 유효하다고 생각했기 때문입니다.
  4. API/MCP 등의 인터페이스에서는 Protocol-specific한 로직만 처리합니다.
    • 공통적으로 Auth → 입력값 추출,검증 → 비즈니스 로직 호출 → Return 이라는 Flow로 단순하게 유지하고 있습니다.
  5. 폴더 구조는 Golang 표준을 기반으로 하되, 개인의 성향에 맞추어 재구성하였습니다.
    또한 Batch Job이나 일반적이지 않은 서비스가 필요해 구조가 달라지는 경우도 있었습니다.
    이 부분은 지속적인 리팩토링으로 계속 개선해 나가고 있습니다.

인증 (Authentication & Authorization)

  • API만 있는 경우: MSA Best Practice를 따라 API Gateway에서 인증(Authentication)을 처리합니다. 각 Backend Service는 JWT claims를 기반으로 인가(Authorization)만 담당합니다.
  • API + MCP가 있는 경우: “MCP Gateway”라는 개념은 아직 표준이 성숙하지 않았고, 저의 경우에는 API와 MCP를 한 서버에 동시 배포하기 때문에 공통된 인증 수단이 필요합니다. 따라서 인증용 공통 모듈을 별도로 구현하여 API/MCP 인터페이스에서 동일하게 사용합니다.

보안 원칙

  1. Zero Trust: 보안의 기본값은 Allow가 아닌 Deny입니다. 내부 서비스 간 통신도 검증합니다.
  2. 인증 로직 중앙화: 인증 Middleware 또는 모듈 한 곳만 봐도 보안 정책을 파악할 수 있어야 합니다.
  3. 명시적 허용 정책: Public Path도 명시적으로 표기하여 의도적으로 Pass됨을 알 수 있어야 합니다.
  4. 민감 정보 암호화: 사용자 정보, 비밀은 반드시 암호화하여 처리합니다.
  5. 명확한 네이밍: verify, check 같은 모호한 이름 대신 validateJWTSignature, authorizeUserForResource 등 명확하게 작성합니다.

Other

  • Go는 CPU 코어에 따라 프로세스 최적화가 가능한데, 서비스 규모가 적고 대부분 CPU 리소스가 1000m 미만으로 할당되어 있어 따로 설정하지 않았습니다.
  • sqlc를 사용하여 RDBMS 로직을 구현하였습니다. 초기에 GORM을 고려했지만, 속도가 느리다 판단하여 사용하지 않았습니다.

DevOps

별도 문서를 참고해 주세요.

Frontend

현업 FE 개발자 정도는 아니지만 원하는 기능을 구현할 정도의 역량은 가지고 있습니다.

  1. 웹 개발에는 React 또는 Next.js를 사용합니다.
    • 2025년 기준 아직까지는 사실상 FE의 표준입니다.
    • TypeScript를 사용하여 타입 안정성을 높입니다.
    • E2E 테스트용으로 Playwright를 사용합니다. Storybook은 사용하지 않습니다.
  2. 모바일 개발에는 Flutter를 사용합니다.
    • 모바일 경험이 상대적으로 많지 않고 적은 공수를 원했기 때문에, 크로스플랫폼 프레임워크를 사용하는 것이 좋다고 생각했습니다.
    • React Native도 다룰 수 있지만 Flutter로 개발한 앱이 더 가볍고 성능이 좋다고 생각하여 선택하였습니다.
  3. 인증은 Supabase SDK를 사용하여 간편하게 처리합니다.

Design

  1. Figma 무료 버전을 사용합니다. 이견이 없는 개발자 - 디자이너 협업에 사용되는 표준 도구입니다.
  2. 단, 저는 디자이너가 아니라 감각도 부족하고 디자인에 소비할 시간도 많지 않습니다.
    그래서 최대한 도구와 참고 자료를 활용하여 초기 구현을 하고 있습니다.
    • v0나 Lovable 같은 도구로 프로토타이핑을 합니다.
      • Figma Make는 위 2개 서비스와 크게 차이점이 없어 사용하지 않고 있습니다.
    • AI와 함께 추가 구현을 진행하고 html.to.design 등으로 Figma에 UI를 옮깁니다.
    • 이후 Cursor Talk to Figma MCP를 사용하거나, 직접 기존 Figma 디자인을 수정하거나, 커뮤니티에 공유된 컴포넌트를 가져와 수정하기도 합니다.