입사 후 6개월 간의 개발 에피소드 회고

 

2024년 9월 2일 현재 회사에서 일을 시작했다.

처음 백엔드 직무로 일을 시작하게 되어 많은 설렘을 안고 출근했던 첫날이 떠오른다.

그동안 출장과 신규 서비스 런칭 등 많은 일이 있었는데 이번기회에 각 에피소드와 내 생각을 정리해보려고 한다.

 

쉽지 않았던 첫 번째 프로젝트

아키텍처 구조를 어떻게 해야 하나...

입사 후 주어졌던 첫 번째 업무는 외부 API를 기반으로 기업 정보 조회 후 자사 DB에 적치하는 프로젝트를 맡게 되었다.

DB 설계부터 모든 걸 스스로 해결했어야 했다.(물론 모르는 부분은 상급자에게 조언을 구했다.)

 

DB 설계 난관이었다.

기본적으로 사용자에게 요청을 받아 데이터를 생성 후 저장하는 것이 아닌, API로 받아온 정보에 의존할 수밖에 없어 테이블 스키마도 API 응답값과 동일하게 설계할 수 밖에 없었다. 

 

API는 기업일반, 재무, 신용 등의 정보를 제공한다.

예를 들어 기업 일반의 경우 기업 개요, 주주 정보, 국민연금에 등록된 종업원 수 등 한 API에 통합으로 제공되었다.

 

우선 기업 개요, 주주 정보 등을 기준으로 테이블 스키마를 결정했고, 스키마에 매핑된 엔티티를 만들었다. 각 엔티티의 CRUD를 위한 서비스 클래스를 생성하고 서비스 클래스를 사용하기 위한 서비스 클래스를 만들었다.

(이런 디자인 패턴이 퍼사드 패턴인 것은 나중에서야 알게 되었다.)

 

결과적으로 객체 지향적이라기 보단 데이터 지향적인 설계를 하게 되었는데, 코드 분석을 위해서 몇 개의 서비스 클래스를 지나는 게 맞는 설계인가라는 생각이 든다. 이에 대해선 아직도 여러 방법을 찾아보는 중이다.

 

중복저장 시 대처 방안은...?

프로젝트가 운영되기 시작했고, 첫 번째로 직면한 이슈는 중복저장이었다.

사용자가 특정 기업 조회를 할 때 연속으로 요청을 보내거나, 여러 사용자가 특정 기업으로 조회 시 모든 요청에 대해 외부 API를 사용하도록 로직을 구성했더니, 0.0001초 사이에 동일한 데이터가 여러 개 저장되었다. 원인 분석을 해본 결과 몇 가지 문제점이 있었다.

 

1. 모든 사용자의 요청 시 외부 API를 요청하는 게 맞는가?

지금이야 소수의 인원만 사용하기에 큰 문제는 아니지만, 결국 API 요청 한건 한건이 회사에서 지출해야 할 비용이기에 이 부분은 개선이 필요했다. 

 

우선, 기업 검색을 기록하는 테이블을 추가했다. 테이블은 사용자가 검색한 기업 사업자번호와 검색한 시간을 기록하는 역할을 한다.

이후 모든 요청을 해당 테이블에서 사업자번호를 조회해 검색 시간을 확인하고, 현재 기준 3시간 이내에 검색 기록이 있다면 외부 API를 호출하지 않고 이미 저장된 DB 테이블을 조회 후 응답하는 식으로 로직을 변경했다.

캐싱을 적용하면 되지 않나?
=> 기업 정보가 매일매일 변경되고 변경 시간이 정해지지 않다 보니, 첫 번째 조회한 사람과 두 번째 조회한 사람의 정보가 다를 수 있다.
      데이터 동기화를 위해 여러 번 외부 API이 불가피함으로 3시간 단위로 동기화작업을 하는 것이다.

그럼 첫 번째 조회 후 3시간 이내 데이터가 변경되었을 때 두 번째 조회한 사람은 변경 전 데이터를 받지 않나?
=> 그렇다. 이 부분은 현재로서 마땅한 해결방법이 없다. 잘못된 정보의 간극을 최소화할 방법을 지금도 고민 중이다.

그럼 배치를 이용해 기 저장된 기업을 조회 후 저장하면 되지 않나?
=> 계약한 기업에서 배치성 요청 시 강제로 IP를 막는다고 해 배치를 수행할 수 없는 상황이다.

 

 

2. 중복 저장을 어떻게 막을 것인가?

이 부분을 가장 많이 고민했는데, 이 문제 해결을 위해 여러 방법을 찾아봤다. 낙관적락, 비관적락, Redis를 이용한 큐잉 등 여러 방법을 고민했다. 

 

1. 낙관적 락 : 모든 테이블에 대해 버전관리를 위한 칼럼을 추가하는 것이 불필요하다고 생각했다. 낙관적락은 동시성 문제가 간혹 발생할 때 적용하는데 현재 프로젝트 실사용자는 회사 내 운용팀에서 한정으로 사용하는데 겨우 2~3명이다. 소규모 인원으로 운용해도 동시성이슈가 발생해 중복 저장이 되었는데, 낙관적 락으로 해결할 수 없을 것이라 판단했다.

2. 비관적 락: select for update와 같이 이미 기록된 데이터의 row lock을 수행하는 것인데, 현재 상황에서는 lock을 적용할 row가 없는 상태이기에 적용할 수 없었다.

3. Redis 사용: 현재 회사 인프라 구성은 AWS EC2와 S3, RDS만 사용하고 있다. B2B 대상으로 서비스를 해오고 있기 때문에 인프라 구성을 최소화해야 하는 상황이다. Redis를 적용하는 게 비용적으로 많지 않다고 생각하겠지만, 일 이용자가 50명도 되지 않는 개발에 필요하단 이유로 여러 설루션을 추가하는 게 현재로서는 과하다는 생각 한다. 

 

결론은 PostgreSql의 advisory Lock으로 해결했는데, 특정 hash 값에 대해서 Lock을 걸 수 있는 기능으로 해결했다.

기업의 사업자번호와 조회, 저장 등 메서드 명을 hash값을 만든 후에 Lock을 거는 식으로 로직을 구성했다.

세부 내용은 해당 포스팅에서 설명되어 있다.

 

 

 

갑작스러운 베트남 비즈니스 출장

작년 10월 중순쯤 갑작스런 베트남 비지니스 출장이 잡혔다. 핀테크 관련 정부지원 사업의 일환으로 베트남 현지 진출을 지원해 주는 프로그램이 있는데, 프로그램 중 베트남 현지 출장이 있었다. 동남아는 여행으로 태국이나 싱가포르만 가봤지 베트남에 연고가 하나도 없었지만, 개발팀 베트남 현지 미팅을 담당하게 되었다. 베트남 현지 미팅 준비 관련해서 작성한 포스팅이 있으니 궁금하다면 한번 읽어보시길..

 

미팅을 진행하면서 베트남 현지 개발 현황 등 다양한 이야기를 들을 수 있었는데, 대략적으로 아래와 같이 정리해 보았다.

• 베트남 대졸 기준 평균 월급은 150~200 사이
• N사 베트남 지사에서 해당 기업의 사전 유지보수를 담당
• 한창 베트남 개발자 외주 시장이 유행했던 배경(중국 개발자 인건비 증가나 인도 개발자가 개발한 소스코드를 오픈소스해버린다든지)
• 지금은 베트남 개발자 외주 비용도 증가해 큰 메리트가 없음
• 국내에서 베트남 현지 진출 후 독립해 외주 중개업을 하는 회사가 많음
• 베트남 개발자들은 주로 플로터나 코틀린 등 최신 유행 언어를 많이 사용
• 일본 회사들이 베트남 외주 개발을 선호
• 베트남 개발자는 WBS와 같이 그날 하루 할 일을 직접 문서로 받아 진행, 한국과 개발 문화가 많이 다름

 

 

 

운영 중인 프로젝트의 고도화

첫 번째 프로젝트 1차 개발이 완료된 후 이미 운영 중인 프로젝트 고도화에 투입되었다.

기존 B2B 대상인 서비스 신청 부분을 B2C 대상으로 확장하고, 사용자 범위 확대(기존에는 한 기업 당 1개의 계정만 허용되었으나, 한 기업당 여러 개의 계정이 가능하도록 변경)와 신청 관리를 위한 대시보드 추가 등 많은 업무가 기다리고 있었다.

 

우선 기존 API를 사용하지 않고, 신규 API를 사용하기로 해서 프런트엔드 개발자와 병렬로 업무를 할 수 있도록 Swagger를 이용해 API를 명세화했다. 각 api 엔드포인트의 필요 파라미터와 응답 구조를 어떻게 할지 기준을 잡고 프런트는 퍼블리싱 선 작업 후 api 연동 작업을 하기로 했고, 백엔드는 DB와 엔티티 설계 후 api 기능 개발을 하기로 했다. 

 

기능 개발이 완료된 api는 프런트에서 테스트를 위해 docker compose을 적용하기로 했다. 기존에는 도커를 사용하지않고, 직접 데이터베이스 환경설정을 하고, 프론트에서 직접 git pull을 받아 maven으로 애플리케이션을 실행하는 식으로 진행해왔다고 한다.

규모가 작은 스타트업이다 보니 별도 테스트 서버가 없어 이런 부분은 개선이 필요하다고 생각해 향후 테스트 서버를 만들어볼 예정이다.

 

최근 이슈되었던 부분은 고객이 서류를 등록하는 기능이 있는데 미리 보기 기능을 지원했어야 했다. 이 부분은 아직 경험해보지 않은 기능이라서 고민했었다.

서버에서 파일 uuid로 S3에서 파일을 바이트 코드로 받아온걸 프런트서버로 전달해 주고, 프런트서버에 저장된 파일을 미리 보기 해주는 식으로 해야 하나?
그럼 직접 다운로드는 하는 것과 다른 게 없지 않나?
그럼 매번 다운로드 요청 시 프런트 서버에서 파일을 가지고 있다면 해당 인스턴스 디스크 용량이 기하급수적으로 늘어나야 하고,
스케쥴링으로 저장된 파일을 지우는 식으로 해야 하지 않나?

 

여러 고민에 고민을 하다, S3에서 presigned URL을 제공해 주는 것을 알게 되었다.(고민 하기 전에 구글링해볼걸..)
다음 주 중으로 해당 기능을 이용해 api를 완료할 예정이다.

 

 

지금까지 6개월간 경험했던 에피소드를 정리해보았다.

 

언젠가 지금 경험한 것들이 씨앗이 되어 꽃필날이 오기를..!!