(WEB_PORTAL) 사내 근태관리 서비스, 로우코드 프로토타입에서 정식 웹 서비스로 전환한 첫날

개요

사내에서 쓸 하이브리드 형태의 출퇴근·연차 관리 서비스를 신규로 구축하기 시작했습니다. 사내망에서는 출퇴근 기록이 가능하고, 외부망에서는 휴가 신청·조회만 가능하도록 네트워크 위치에 따라 기능을 다르게 노출해야 하는 요구사항이 있었습니다.

초기 접근과 당일 전환

최초 검증은 스프레드시트 기반 로우코드 자동화 도구로 빠르게 시작했습니다. 다만 망 분리에 따른 접근 제어, 로그인 세션 관리, 데이터 정합성 같은 요구사항을 다루기에는 로우코드 환경의 한계가 뚜렷하게 드러났고, 같은 날 안에 정식 웹 프레임워크 기반 스택으로 전환하기로 결정했습니다.

기술 선택 이유

• 프레임워크: API 라우트 기능 덕분에 별도의 백엔드 서버 없이도 프론트엔드와 API를 단일 프로젝트로 구성할 수 있어, 초기 구축·배포 부담을 줄일 수 있다고 판단했습니다.
• 데이터베이스: 사내 NAS 환경에 별도 DB 서버를 새로 두지 않고, 애플리케이션과 함께 배포할 수 있는 파일 기반 내장형 DB를 선택했습니다. 사용자 규모를 고려했을 때 외부 DB 서버를 운영하는 비용 대비 이점이 크지 않다고 봤습니다.
• 세션 관리: 서버 상태를 따로 두지 않아도 되는 토큰 기반 인증(HttpOnly 쿠키)을 채택해, 이후 배포 환경이 바뀌더라도 세션 저장소를 신경 쓰지 않도록 했습니다.

핵심 구현 포인트

망 위치에 따른 기능 분기

요청이 들어온 IP를 사내 네트워크 대역과 비교해 사내/외부망 여부를 판별하고, 이 결과에 따라 화면에서 특정 기능(출퇴근 기록)의 노출 여부를 다르게 처리하는 구조로 설계했습니다.

요청 수신 → 요청 IP 추출
사내 대역에 포함? → 출퇴근 관련 기능 활성화
아니면 → 조회·신청 관련 기능만 노출

시간 데이터 저장 방식

내부 저장은 표준시(UTC)로 통일하고, 화면에 보여줄 때만 사내 시간대로 변환하는 방식을 채택했습니다. 데이터를 표준 형식으로 저장해두면, 이후 서버 이전이나 다른 지역 사용자가 생기더라도 표시 로직만 바꾸면 되는 구조가 됩니다.

회고

• 로우코드 도구로 하루 만에 핵심 요구사항을 빠르게 검증해본 것이 오히려 "이 환경으로 인증·망분리까지 감당할 수 있는가"라는 한계를 빨리 파악하게 해줬고, 그 덕분에 정식 스택으로의 전환을 첫날 안에 결정할 수 있었습니다.
• 초반부터 데이터베이스를 과도하게 크게 설계하지 않고, 실제 사용 규모에 맞는 가벼운 선택을 한 것이 이후 운영 부담을 줄이는 데 도움이 됐습니다.