1. 신입 때 서비스의 DB를 설계해야 했을 때
입사 후 신규 서비스 개발에 즉시 투입되어 직접 DB를 설계해야 했다. 원칙을 세우고 그에 따라 맞춰갔다. 개발하는 과정에서 몇몇 보완이 있었지만 이후 서비스 운영을 충분히 감당했다.
기본 원칙
- 정규화 목표에 따라 설계
- 시행착오를 통해 보완: 적당한 선에서 구현해보고 미비한 점이 발견되면 수정해서 보완
완벽한 구조는 추구하는 것이지 달성하는 것이 아니라고 느꼈다. 처음부터 완벽한 구조를 만들어낼 수는 없었다. 하지만 당시 요구사항을 구현하기에 충분한 구조는 만들어냈다. 서비스가 고도화될수록 요구사항 자체가 변경될 수도 있고, 그 때가 되면 바람직한 구조 자체가 다를 수 있다. 회사의 업무인 해외송금업에서는 확장을 감당할 수 있는 구조를 만들어 낼 수 있었다.
사례
DB구조를 설계하는 과정에서 특별히 기억나는 일은 아래와 같다.
제1 정규화 사례
국가마다 은행 계좌 정보의 데이터 타입이 다르다. 가령 한국은 이름을 한 컬럼에 쓰지만 영미권에서는 first/middle/last로 나눠서 작성한다. 또, 계좌가 은행, 계좌번호만으로 특정되는 경우도 있지만 branch code등의 정보가 추가로 필요한 국가도 있다.
처음에는 테이블을 모두 통일하고 국가마다 달라지는 데이터를 1개의 컬럼에 json으로 저장하는 방법을 고려했지만 제1 정규화 원칙에 어긋나기 때문에 폐기했다. 컬럼이 원자값을 가지도록 구성하지 않으면 차후에 검색할 때 오버헤드가 발생한다. DB에서 json으로 저장된 정보를 검색하는 방법이 복잡해지고 성능도 저하된다.
따라서 국가마다 테이블을 다르게 정의하고 은행 계좌를 처리하는 인터페이스를 만들었다. 각 은행별로 인터페이스를 구현하는 클래스를 작성했고 API에서 팩토리패턴을 사용해 국가별로 각각 처리했다.
2. 전문 자격을 갖추지 못한 분야에 대한 문제 해결
개발자로서 네트워크에 대한 어느 정도의 지식은 있으나 사무실, IDC의 네트워크를 구성하고 서버 컴퓨터 및 작업용 컴퓨터를 배치하는 일을 직접 해본 적은 없었다. 회사가 서비스를 런칭하기 위해서 금감원으로부터 소액해외송금업, 전자금융업 라이센스를 취득해야만 했고, 요건에 맞는 전산설비를 구축해야만 했다.
관련 법령과 시행령을 읽어보고 숙지한 다음 요건에 맞게 설비를 구축하고 문서화 한 다음 금감원 실사까지 맡아서 진행했다. (전자금융거래법, 전자금융거래법시행령, 전자금융감독규정, 전자금융감독규정 해설) 개념적으로 어려운 문제는 없었지만, 회사의 명운이 걸린 일인데 개발 외적인 업무다보니 부담이 컸다. 게다가 금감원을 상대하고 실사 책임까지 지는 것은 심적으로 큰 스트레스였다. 다행히 무사히 라이센스 취득했고 내가 퇴사한 이후에도 회사는 잘 운영되고 있다.
3. 개발팀 관리, 개발 문화 고도화를 위한 노력
중간 관리자 없이 대표 아래 바로 사원으로 구성된 스타트업이었다. 선임 개발자로서 초년차부터 개발팀 일정을 관리하고 경영진과 소통했다. 중소기업 특성상 주먹구구식 운영이 되기 쉬웠지만 처음부터 끝까지 체계를 도입하려고 애썼다.
회사의 개발팀 일정 관리 상 발생한 문제를 나열하고 해결 방법을 모색했다. 가장 두드러지는 문제는 회의 소집 또는 직접 대면 대화로만 정보가 교환된다는 점이다. 시간적으로 비효율적이고 정보가 휘발기도 한다. 추가로 아래의 문제가 수반되었다.
- 개발자 개개인의 업무 현황이 경영진에게 전달되기 어려움
- 경영진의 업무 우선도가 개발팀에 전달되기 어려움
- 구두로 전달했더라도 쉽게 잊어버리고 재차 소통하는 시간이 소요됨
- 업무 일정이 중도에 변경되는 일이 잦음
가장 적절한 해결 방법은 업무 관리 도구를 도입하는 것이라고 판단했다. 필요할 때 즉시 확인할 수 있고 히스토리가 보존된다. 발전된 툴을 잘 사용하면 업무 효율도 개선할 수 있을 것으로 생각했다.
처음에는 내부망에 Redmine 설치하여 사용하도록 추진했다. 결과적으로 대표가 툴 사용이 어렵다고 하여 무산되었지만 이후에 Trello, 구글 캘린더 등의 다른 툴을 도입해봤다. 원하는 바를 완수하지는 못했지만 올바른 방향이라고 생각했기 때문에 끝까지 노력했다.
4. 실수가 허용되지 않는 분야에 대한 처리
가령 유저에게 푸시 알림을 발송할 때 발생하는 버그와 결제 단계에서 발생하는 오류는 결과의 심각도가 다르다. 서비스에서 심각도가 높은 부분은 모두 직접 맡아서 진행했다. 결제 시스템은 모두 책임지고 개발하고, 여러 PG사와의 결제 모듈 연동도 직접 했다. 송금거래정보를 금융당국에 보고하는 시스템도 만들었다.
이런 분야는 두 가지 기준을 가지고 개발했다.
- 서비스 흐름을 안전한 방향으로 구성
- 충분한 테스트를 꼼꼼하게 진행
안전한 방향이란 결제 상태값을 빠짐없이 모두 관리하고 결제가 완료된 상태를 엄밀하게 확인한 다음에야 이후 과정으로 진행하도록 처리하는 것이다. 예로 들 만한 특별한 케이스가 있는데, 가상계좌의 경우 입금 이후에도 환불 통보가 오는 경우가 존재한다. 실제로 고객이 입금 완료한 즉시 창구에 가서 직원 권한으로 환불 처리를 진행하는 경우 발생할 수 있다는 점을 확인했다. 입금 완료 통보를 받으면 시스템은 즉시 송금 과정을 시작하도록 되어 있었지만, 환불 통보를 받게 되는 경우도 그 이후의 프로세스를 경우의 수마다 모두 대비해뒀다. 어떤 경우에도 금전적 손실이 발생하지 않는 방향으로 서비스 흐름을 구성했다.
충분한 테스트는, 먼저 테스트베드에서 충분히 수행한다. 유저가 입력하는 모든 경우의 수 및 결제사의 모든 상태값과 통보 유형을 확인한다. 이후 결제부를 실제 운영환경으로 변경하고 실결제 테스트까지 수행한다. 문제 없음을 확인한 다음 배포했다.
5. 문서화를 위한 노력
문서는 두 가지 이유로 반드시 필요하다고 생각했다. 협업을 위해서이고, 또 시간이 지나면 작업자 본인이 잊을 수도 있기 때문에 히스토리를 만들어 두기 위함이다.
2인 개발팀으로 개발, 운영을 모두 하느라 늘 일정에 쫓겼다. 회사는 개발자의 문서 작성을 권하지 않았다. 문서를 만들 시간에 밀린 개발 업무를 더 하는 것이 회사의 방침이었다. 그러나 퇴사 전까지 본인이 개발한 모든 부분에 대해서 문서화를 했다. 문서만으로 모든 내용을 확인할 수 있도록 작성했다.
소감
작은 스타트업에서 겪은 개발 문화는 바람직하지 못한 케이스에 가깝다고 느낀다. 다음에는 어느 정도는 업무 문화가 잘 만들어진 곳으로 가고 싶다.