기술 스택
프로젝트에 쓰는 기술과 이유
기술 선택은 유행이 아니라 유지보수 가능성으로 결정합니다. 웹, 모바일, 소프트웨어, AI, ERP 프로젝트에서 실제로 쓰는 클라우드와 백엔드, AI 프레임워크, 결제 연동, 데이터 구성, 배포 방식을 한자리에 정리했습니다.
DAMONG · technology
검토 중인 기술 항목
각 항목은 프로젝트의 데이터 흐름과 운영 인력 상황을 확인한 뒤 확정합니다.
기술마다 적용 지점이 다릅니다
같은 프로젝트 안에서도 구간마다 필요한 기술이 다릅니다. 화면을 만드는 일, 트래픽을 받아내는 일, 결제를 붙이는 일, 사내 시스템과 데이터를 주고받는 일은 요구 조건이 서로 다릅니다. 아래 표는 어떤 상황에서 어떤 기술을 우선 검토하는지 정리한 기준입니다. 실제 확정은 상담과 기술 검토에서 상세 요구사항을 확인한 뒤에 진행합니다.
기술
적용하는 상황
AWS
웹, 모바일, AI 서비스의 인프라. 트래픽 변동이 큰 서비스에 적합합니다.
Node.js
실시간 처리와 외부 연동이 많은 통합 계층, 운영 패널에 자주 선택됩니다.
TensorFlow
모델 학습과 배포. 검증 가능한 업무부터 단계적으로 붙입니다.
Kakao Pay 연동
국내 서비스 결제 수단. 실패, 취소, 환불 흐름까지 함께 설계합니다.
데이터 연동
여러 시스템을 잇는 중간 계층. 결합도를 낮추고 마이그레이션을 준비합니다.
시스템 통합
ERP, 사내 업무 시스템, 외부 API를 하나의 흐름으로 묶는 작업입니다.
클라우드
클라우드 기반 구성
AWS는 웹, 모바일, AI 서비스의 인프라로 폭넓게 쓰입니다. 트래픽이 몰리는 시간대와 한산한 시간대가 뚜렷한 서비스는 서버를 고정해 두는 편보다 자원을 탄력적으로 운영하는 편이 유리합니다. 저장, 연산, 큐, 모니터링을 필요한 만큼 조합하고, 배포와 복구 절차가 단순해지는 방향으로 설계합니다.
컴퓨팅
요청량에 따라 늘리고 줄이는 실행 환경. 배포 단위를 작게 나눠 복구 시간을 줄입니다.
스토리지
이미지, 첨부 파일, 로그를 용도별로 분리 저장하고 접근 권한을 따로 관리합니다.
큐와 비동기
알림 발송, 대량 처리처럼 오래 걸리는 작업을 사용자 요청에서 떼어냅니다.
모니터링
장애 감지용 지표와 성능 추세용 지표를 나눠서 봅니다. 알림 기준을 문서로 남깁니다.
요청 흐름
클라이언트 요청 수신
통합 계층에서 외부 시스템 연결
정합성 필요 구간은 별도 런타임으로 분리
결과 기록과 재처리 기준 유지
백엔드 런타임
Node.js는 실시간 처리와 외부 시스템 연결이 많은 구간에서 자주 선택됩니다. 특히 통합 계층이나 운영 패널처럼 요청이 잦고 응답이 짧아야 하는 서비스에 잘 맞습니다. 반대로 트랜잭션 정합성이 중요한 회계 처리 구간에는 다른 런타임과 조합하는 편이 안전합니다.
언어 자체보다 데이터 흐름 설계가 결과를 좌우합니다. 어떤 요청이 어디에서 만들어지고, 어떤 순서로 기록되며, 실패했을 때 어디까지 되돌릴 수 있는지를 먼저 정리한 다음 런타임을 고릅니다. 이 순서를 지키면 나중에 담당자가 바뀌어도 같은 판단을 반복할 수 있습니다.
- 요청이 잦은 통합 계층과 운영 패널은 빠른 응답 구조로 설계합니다.
- 정합성이 중요한 구간은 분리하고, 두 영역 사이 경계를 문서로 남깁니다.
- 실패한 요청을 다시 처리하는 기준을 처음부터 정해 둡니다.
3년 뒤에도 관리할 수 있는 기술을 먼저 고릅니다
기술을 고를 때 가장 먼저 보는 것은 지금 만들기 쉬운가가 아니라, 3년 뒤에도 관리할 수 있는가입니다. 문서화 수준과 커뮤니티 규모도 함께 판단합니다. 사내에 관리 인력이 없다면 운영 지원 범위를 처음부터 함께 정합니다.
AI
AI와 머신러닝
TensorFlow는 모델 학습과 배포에 쓰이는 대표적인 프레임워크입니다. 학습 환경과 서비스 환경을 분리해 운영 부담을 줄이는 방식을 씁니다.
데이터 준비
학습에 쓸 데이터의 출처, 정제 기준, 보관 기간을 먼저 정합니다. 모델 정확도보다 이 단계가 결과를 더 크게 좌우합니다.
학습과 배포 분리
학습 환경과 서비스 환경을 나눠 두면 재학습 중에도 운영 서비스에 부담이 가지 않습니다.
재학습 주기
언제, 어떤 기준으로 모델을 다시 학습할지 미리 정해 둡니다. 기준이 없으면 정확도가 조용히 떨어집니다.
단계적 적용
결과를 검증할 수 있는 업무부터 AI 기능을 붙입니다. 검증이 끝난 범위만 다음 단계로 넓힙니다.
모델 정확도만큼 재학습 주기와 데이터 관리가 중요합니다. AI 기능은 검증 가능한 업무부터 단계적으로 붙이는 방식을 기본으로 합니다.
결제와 인증 연동
국내 서비스에서는 Kakao Pay 같은 결제 수단 연동이 자연스럽게 요구됩니다. 결제 성공 화면만 만드는 것으로는 부족합니다. 결제 실패, 사용자 취소, 환불 요청까지가 실제 운영에서 가장 자주 발생하는 흐름이고, 이 세 가지를 설계 범위에 포함해야 문의가 줄어듭니다.
본인 인증과 로그인 방식도 사용자 기대에 맞춰 정합니다. 연동 지점마다 오류 처리 기준을 문서화하고, 어떤 응답을 사용자에게 보여주고 어떤 응답을 운영 로그로만 남길지 구분합니다.
결제 수단 연동
국내 결제 수단의 승인, 실패, 취소 응답을 각각 처리 기준과 함께 정의합니다.
본인 인증과 로그인
서비스 성격에 맞는 인증 방식을 고르고, 재인증이 필요한 시점을 함께 정합니다.
오류 처리 기준 문서화
연동 지점마다 발생 가능한 오류와 대응 순서를 문서로 남겨 인수인계에 씁니다.
데이터베이스와 데이터 연동
데이터 저장 방식은 조회 패턴에 따라 달라집니다. 정합성이 중요한 업무 데이터와 로그성 데이터는 같은 방식으로 다루지 않습니다. 여러 시스템을 잇는 경우에는 중간 계층을 두어 결합도를 낮추고, 마이그레이션 계획은 초기부터 세웁니다.
데이터 구분과 처리 방식
업무 데이터
정합성이 우선. 트랜잭션 경계를 명확히 하고 변경 이력을 남깁니다.
로그성 데이터
쓰기량이 많고 갱신이 드묾. 보관 기간과 조회 목적을 먼저 정합니다.
연동 중간 계층
외부 시스템과 직접 붙지 않고 경계를 둡니다. 교체와 장애 격리가 쉬워집니다.
마이그레이션
초기 스키마 설계 단계에서 이전 계획을 함께 세웁니다. 나중에 붙이는 작업은 비용이 큽니다.
화면 설계
프론트엔드와 화면 설계
공개 화면과 관리 화면은 요구가 다릅니다. 공개 화면은 로딩 속도와 접근성이, 관리 화면은 입력 효율이 우선입니다. 같은 데이터라도 사용자에 따라 다른 형태로 보여줍니다. 반응형 대응은 실제 모바일 사용 비중을 기준으로 정하고, 관리 화면은 데스크톱 입력 흐름을 먼저 완성한 뒤 좁은 화면을 맞춥니다.
공개 화면
첫 화면에서 핵심 정보가 보이도록 구성합니다. 이미지와 폰트 용량을 줄이고 접근성 속성을 함께 점검합니다.
관리 화면
반복 입력을 줄이는 배치와 키보드 흐름을 우선합니다. 목록, 필터, 일괄 처리를 업무 순서대로 배치합니다.
권한별 화면
같은 데이터라도 역할에 따라 다른 항목을 보여줍니다. 노출 범위는 권한 설계와 함께 정합니다.
보안과 권한 관리
권한은 역할 단위로 설계하고, 민감 데이터 접근은 기록을 남깁니다. 외부 연동이 늘수록 권한 지점이 늘어나므로 관리 방식을 통일합니다. 국내 개인정보 기준과 사내 감사 요구를 함께 확인하고, 보안 항목은 배포 전 점검 목록으로 관리합니다.
배포와 모니터링
배포는 자동화된 절차로 진행해 실수를 줄입니다. 모니터링은 장애를 빠르게 발견하는 목적과, 성능 추세를 보는 목적으로 나눠 운영합니다. 알림 기준을 정해두면 대응 속도가 달라집니다. 운영 인수인계 문서를 함께 남기는 것도 이 단계의 일부입니다.
배포 자동화
사람 손을 거치는 단계를 줄이고, 배포 이력을 남깁니다.
장애 감지 알림
알림 기준을 문서로 정해 두면 밤 사이 문제도 빠르게 확인합니다.
성능 추세 기록
응답 시간과 자원 사용량 추세를 보며 확장 시점을 판단합니다.
인수인계 문서
운영 절차와 복구 순서를 문서로 남겨 담당자가 바뀌어도 이어집니다.
웹사이트 개발
AWS 인프라 위에 반응형 공개 사이트를 구성하고, 로딩 속도와 접근성을 함께 맞춥니다.
모바일 앱 개발
모바일 사용 비중을 기준으로 화면을 설계하고, 앱과 서버 사이 데이터 흐름을 정리합니다.
소프트웨어 개발
사내 업무에 맞춘 맞춤 소프트웨어를 만들고, 기존 시스템과의 연동 지점을 문서화합니다.
AI 솔루션
TensorFlow 기반 모델을 검증 가능한 업무부터 적용하고, 재학습 주기를 함께 정합니다.
ERP 시스템
회계, 재고, 인사 데이터를 하나의 흐름으로 묶습니다. 정합성이 중요한 구간은 별도 런타임으로 분리하고, 기존 시스템과의 데이터 연동 계층을 두어 교체와 장애 격리가 쉬운 구조로 만듭니다.
유지보수 가능성
기술을 고를 때 가장 먼저 보는 것은 3년 뒤에도 관리할 수 있는가입니다. 문서화 수준과 커뮤니티 규모도 판단 기준입니다. 사내에 관리 인력이 없다면 운영 지원 범위를 함께 정합니다.
문서화 수준
설계 결정의 이유를 남깁니다. 남은 문서가 없으면 다음 담당자는 같은 고민을 처음부터 반복합니다.
커뮤니티 규모
문제가 생겼을 때 참고할 자료가 충분한 기술을 우선합니다. 자료가 적으면 대응 시간이 길어집니다.
운영 지원 범위
사내 인력이 없는 경우 지원 범위를 처음부터 명확히 정하고 문서로 남깁니다.
자주 나오는 질문
클라우드는 항상 AWS로만 구성하나요?
AWS를 기준으로 검토하는 경우가 많지만, 트래픽 규모와 사내에서 이미 쓰는 환경에 따라 다릅니다. 기존 인프라가 있다면 연동 방식을 우선 확인하고, 옮길 필요가 있는 범위만 따로 정합니다.
AI 기능은 어디부터 적용하는 게 좋은가요?
결과를 검증할 수 있는 업무부터 시작합니다. 예를 들어 분류나 요약처럼 정답을 사람이 확인할 수 있는 작업이 적합합니다. 검증이 끝난 범위만 다음 단계로 넓히는 편이 안전합니다.
결제 연동은 어떤 범위까지 확인해야 하나요?
승인 성공만 보면 부족합니다. 결제 실패, 사용자 취소, 환불 요청, 재결제까지가 운영에서 자주 발생하는 흐름입니다. 이 네 가지에 대한 처리 기준을 문서로 남기는 것을 기본으로 합니다.
ERP를 기존 시스템과 함께 쓸 수 있나요?
가능합니다. 기존 시스템과 직접 붙이지 않고 중간 계층을 두어 결합도를 낮춥니다. 데이터 형식과 동기화 주기를 먼저 정하고, 이전 계획을 처음부터 함께 세웁니다.
기술 검토는 상담에서 어떻게 진행되나요?
현재 시스템 구성과 데이터 흐름을 먼저 확인합니다. 그다음 유지보수 가능성을 기준으로 후보 기술을 좁히고, 각 선택의 이유와 예상 범위를 문서로 정리해 전달합니다.
기술 검토가 필요하신가요
이 페이지에 정리한 기술은 고정된 목록이 아니라 판단 기준입니다. 진행 중인 시스템 구성, 데이터 흐름, 사내 운영 인력 상황을 알려주시면 어떤 기술을 어떤 순서로 검토하면 좋을지 함께 정리해 드립니다. 기존 프로젝트가 어떻게 구성됐는지는 사례 페이지에서 확인하실 수 있습니다.
경기도 화성시 동탄영천로 150, 동탄 실리콘앨리 B동 1032, 1033호, 대한민국
월요일–금요일 09:00–18:00