Tech Square
2022.04 – Present화면
목적
수요기업과 공급기업이 스마트공장 구축 파트너를 찾고 멘토링, 중고설비 거래, 운영 정보를 이용할 수 있는 B2B 제조 플랫폼입니다.
역할 · 기술스택
Node.js · Express · TypeORM · MySQL · Vue 3 · AWS · GitLab CI/CD
성과 01
Java 시스템에서 Node.js 플랫폼으로 단계적 전환
- 배경·원인
- 기존 Java 8 시스템은 품질과 유지보수에 한계가 있었고, Vue 3 고객·관리자 채널과 기술 구성을 맞춘 신규 플랫폼이 필요했습니다.
- 고민·선택 이유
- 전환 결정에는 참여하지 않았지만 Node.js·Express·TypeORM 기반 시스템 공동 구축과 데이터 이관을 맡았습니다. 프론트엔드와 언어 생태계를 통일해 협업 경계를 줄이고, 구·신 시스템을 병행해 기능과 데이터를 검증한 뒤 운영을 인수했습니다.
- 결과
- 운영 중단 없이 신규 플랫폼으로 전환했으며, 이후 API와 고객·관리자 채널의 운영·고도화를 단독으로 이어갔습니다.
- 회고
- 운영 시스템 전환은 새 기술보다 데이터 이관, 병행 운영과 인수 종료 기준을 함께 설계해야 안정적으로 끝낼 수 있습니다.
성과 02
공통 트랜잭션 계층으로 데이터 정합성 기준 통일
- 배경·원인
- 업무 모듈이 늘면서 SQL 실행과 트랜잭션 경계가 서비스마다 흩어졌고, 동시 요청이나 부분 실패에서 데이터 정합성을 일관되게 다루기 어려웠습니다.
- 고민·선택 이유
- 각 서비스가 TypeORM을 직접 제어하게 두는 대신 공통 SQL·트랜잭션 계층을 만들었습니다. 격리 수준과 커밋·롤백 책임을 한곳에 모아 업무 단위의 성공·실패 기준을 통일하고, 중복 요청은 업무 조건과 트랜잭션으로 함께 차단했습니다.
- 결과
- 여러 업무 모듈이 같은 실행·복구 기준을 사용하게 되었고, 동시 요청에서도 중복 저장과 부분 반영을 제어할 기반을 마련했습니다.
- 회고
- 트랜잭션 공통화의 목적은 코드 재사용보다 업무 단위의 성공과 실패 경계를 일관되게 만드는 데 있습니다.
성과 03
반복 조회 구조를 쿼리 재구성으로 개선
- 배경·원인
- 회원·기업·멘토링 데이터가 늘면서 목록 한 건마다 연관 정보를 다시 조회하는 구조가 생겼고, 검색 조건이 추가될수록 쿼리 조합도 복잡해졌습니다.
- 고민·선택 이유
- 제한 시간을 늘리거나 인덱스를 무작정 추가하기보다 반복 조회를 조인·일괄 조회로 전환했습니다. 동적 검색 조건은 파라미터 바인딩 기반 쿼리 빌더로 정리해 실행 구조와 입력 안전성을 함께 개선했습니다.
- 결과
- 반복 조회를 줄이고 검색 조건을 안전하게 조합할 수 있게 했으며, 목록과 엑셀 다운로드가 같은 조회 기준을 공유하도록 정리했습니다.
- 회고
- 느린 조회는 결과 집합과 반복 횟수를 먼저 확인하고 쿼리 구조를 바로잡은 뒤 필요한 인덱스를 선택해야 합니다.
성과 04
로컬 파일을 S3 기반 공통 파일 흐름으로 전환
- 배경·원인
- 업로드 파일이 서버 로컬 경로에 묶여 있어 환경이 바뀌면 탐색·다운로드 처리가 달라졌고, PDF·Excel·이미지마다 별도 예외가 쌓였습니다.
- 고민·선택 이유
- 서버 인스턴스와 파일 생명주기를 분리하기 위해 S3로 전환하되 기존 파일을 한 번에 폐기하지 않고 두 경로를 함께 읽는 기간을 뒀습니다. 업로드·조회·삭제·원본 파일명 복원을 공통 유틸리티로 모아 저장 방식 변경이 업무 코드로 퍼지지 않게 했습니다.
- 결과
- 공지·보고서·견적·이미지 등 서로 다른 파일 흐름이 공통 저장 방식을 사용하게 되었고, 환경에 종속된 파일 경로와 중복 처리를 줄였습니다.
- 회고
- 파일 저장소 전환은 객체 복사뿐 아니라 기존 키, 원본 이름과 조회 경로의 호환성을 함께 보존해야 하는 데이터 이관입니다.
성과 05
인증과 입력 경계를 단계적으로 보안 강화
- 배경·원인
- 브라우저에서 접근 가능한 인증 토큰, 동적 SQL, HTML 입력과 다양한 업로드 경로가 각각 다른 보안 위험을 만들고 있었습니다.
- 고민·선택 이유
- JWT는 HttpOnly 쿠키로 옮겨 브라우저 스크립트의 직접 접근을 막고, 동시 401 요청은 한 번의 토큰 갱신으로 수렴시켰습니다. SQL은 파라미터화하고 HTML과 파일은 허용 목록으로 검증해 인증·데이터·입력·파일 경계마다 적합한 방어를 적용했습니다.
- 결과
- 고객·관리자 채널의 인증 흐름을 통일하고, 스크립트 입력·SQL 삽입·위험 파일 렌더링으로 이어질 수 있는 노출 경로를 줄였습니다.
- 회고
- 보안은 하나의 필터로 해결되지 않으며 인증, 입력, 데이터와 파일 경계를 각각 확인해 단계적으로 좁혀야 합니다.
성과 06
로그 단편을 요청 흐름으로 연결한 관측성 구축
- 배경·원인
- 서비스별 `console` 로그만으로는 한 요청이 API와 데이터 처리 과정에서 어디까지 진행됐는지 연결해 보기 어려웠습니다.
- 고민·선택 이유
- 로그를 더 추가하는 대신 전 소스를 구조화 로거로 통일하고 요청별 상관관계 ID를 부여했습니다. OpenTelemetry traceId까지 연결해 로그 형식을 유지하면서도 요청 흐름을 서비스 경계 너머로 추적할 수 있게 했습니다.
- 결과
- 개별 로그를 따로 검색하던 방식에서 벗어나 요청 단위로 문제 발생 지점을 좁힐 수 있는 운영 기반을 마련했습니다.
- 회고
- 관측성은 로그의 양보다 서로 다른 기록을 같은 요청 흐름으로 연결할 수 있는지가 중요합니다.
성과 07
시크릿과 로컬 개발환경을 재현 가능한 구성으로 전환
- 배경·원인
- 환경별 설정과 시크릿 관리 방식이 분산되어 있었고, 로컬 데이터베이스 터널이 끊기면 애플리케이션 연결도 함께 불안정해졌습니다.
- 고민·선택 이유
- 소규모 혼합 인력 팀의 운영 부담을 고려해 Vault보다 진입 장벽이 낮은 Infisical을 선택했습니다. Docker Compose로 실행 환경을 통일하고 DB 터널은 별도 프로세스로 분리해 끊김 감지, 지수 백오프 재연결과 중복 실행 방지를 적용했습니다.
- 결과
- 시크릿을 코드와 배포 파일에서 분리하고 개발자가 같은 실행 절차를 재현할 수 있게 했습니다. 터널 장애도 애플리케이션 전체 재시작에 의존하지 않고 복구할 수 있게 했습니다.
- 회고
- 개발환경 표준화는 도구를 맞추는 것보다 설정·시크릿·외부 연결의 실패와 복구 방식을 함께 정의하는 일입니다.
성과 08
반복 업무를 배치·알림 파이프라인으로 자동화
- 배경·원인
- 외부 데이터 적재, 상태 확인과 담당자 안내를 사람이 반복하면 누락과 처리 지연이 발생할 수 있었습니다.
- 고민·선택 이유
- 대량 데이터는 건별 요청 대신 일괄 적재해 데이터베이스 왕복을 줄이고, 업무 조건별 cron 작업과 알림 흐름을 구성했습니다. 중복 실행·빈 결과·환경별 발송 여부를 분리해 자동화가 예외 상황에서 불필요한 작업을 만들지 않게 했습니다.
- 결과
- 기업 데이터 적재와 운영 알림이 정해진 조건과 일정에 따라 실행되어 담당자의 반복 확인 업무를 줄였습니다.
- 회고
- 배치 자동화는 주기적 실행보다 중복 처리, 빈 결과와 부분 실패를 안전하게 다루는 것이 핵심입니다.