나 4년 차 서버개발자, 배달의민족의 지리 체계를 뒤흔들다

Jul.27.2023 김효건

{{item.name}}
- {{sub.name}}

포스팅 목적

어느덧 서버개발자로 일한 지 4년 차, 그중 최근 가장 큰 규모의 프로젝트인 ‘지리 관리 기준 체계 변경 프로젝트’를 진행하게 되었습니다.

‘지리 관리 기준 체계 변경 프로젝트’는 규모도 컸을 뿐 아니라 많은 경험도 할 수 있었던 프로젝트였기에 경험한 내용을 정리하고 싶었고, 많은 분들에게 경험을 공유하고 싶어 이 글도 작성하게 되었습니다.

먼저, 제가 속한 ‘셀러시스템팀’부터 간단히 소개해드리겠습니다.

셀러시스템팀의 역할은 업주/가게정보 데이터들을 다루고, 그에 따른 정책들을 관리하고 API, 배치, 어드민 등을 개발하고 있습니다.
배달의민족 앱에서 가게 목록을 조회하고, 메뉴를 고르고, 주문을 하고, 결제를 하는 등 모든 과정에는 가게/업주 정보의 데이터가 필요합니다.
배달의민족 앱 모든 곳에서 없어서는 안되는 데이터를 관리하고 있어서 팀을 소개할 때는 배달의민족의 심장이라고 표현하곤 합니다.

이제 셀러시스템팀에서는 어떤 과정으로 프로젝트를 진행하는지를 ‘지리 관리 기준 체계 변경 프로젝트’를 통해 공유하고자 합니다.

프젝젝트는 다음 순서대로 소개해 보겠습니다.

프로젝트 배경
방향성 검토
개발
검증
회고

전체적인 내용은 기술적인 내용보다는 셀러시스템팀에서 프로젝트를 어떻게 진행했는지에 대한 전체 과정을 소개하는 데 집중했습니다.

취업 준비 중인 분들이라면 프로젝트 과정을 간접적으로 경험해 보시면 좋겠고, 현업에 계신 분들이라면 속한 부서에서 진행하는 방법과 차이를 비교해 보면서 읽으시면 좋겠습니다.

프로젝트 배경

배달의민족에서는 가게주소, 고객주소, 배달팁, 광고 등 여러 도메인에서 지리 정보를 활용하고 있습니다.
여러 곳에서 활용하는 정보이다 보니 지리 정보를 어떤 기준으로 관리할 지를 정하는 것이 중요했습니다.

프로젝트 진행 전까지는 배달의민족의 지리 관리 기준 체계는 ‘행정동’이었습니다.
하지만, 행정동이 가지고 있는 몇 가지 한계점들이 있었고, 이를 해소하기 위해 지리 관리 기준 체계를 ‘행정동’에서 ‘법정동’으로 전환했습니다.

먼저 행정동과 법정동의 개념과 차이에 대해서 알아보겠습니다.

법정동

법으로 정한 동
1914년 시행된 행정구역 통폐합 때 정해진 것으로 거의 변동이 발생하지 않음

행정동

주민들의 거주지역을 행정능률, 주민편의에 따라 설정된 행정구역 단위
인구 수에 따라 1법정동이 2행정동으로 운영될 수 있고, 2법정동이 1행정동으로 운영될 수 있음
따라서 법정동에 비해 변경이 자주 발생

예를 들어 송파구의 법정동과 행정동은 다음과 같이 다릅니다.

서울 송파구의 법정동과 행정동
(출처: https://realty.chosun.com/site/data/html_dir/2019/12/13/2019121301421.html)

행정동은 변경이 잦기 때문에, 실시간으로 반영하지 않으면 내부에서 관리하는 행정동과 실제 행정동이 달라 배달팁이 실제 ‘동’ 기준으로 부과되지 못하는 문제가 발생합니다.

주문이 가능한 지역인데 배달 불가 지역으로 판단되거나, 주문이 불가한 지역인데 주문이 가능한 지역으로 판단되는 문제도 발생합니다.

이러한 문제를 해결하고자 지리 정보 기준 체계를 ‘법정동’으로 전환하는 동시에 ‘거리별 배달팁 부과’ 프로젝트도 진행하게 되었습니다.

프로젝트 방향성 검토: 원천 데이터 비교 선택

개발에 들어가기 전에 활용하기에 가장 리스크가 적은 원천 데이터를 찾는 것에 초점을 두고 방향성을 검토했습니다.

법정동 공간 데이터는 어떤 데이터를 사용할 것인가?

공간 데이터란, 점,선,면과 같은 공간에서 표현할 수 있는 정보를 정의하는 방식입니다.

행정동, 법정동과 같은 영역의 개념은 면으로 다룰 수 있습니다.

좀 더 자세한 개발 내용은 뒤에서 다루겠습니다.

실제 개발에 들어가기 전에 가장 중요했던 것은 제공처 중에서 어떤 제공처가 가장 우리의 요구 사항을 많이 맞출 수 있는지 여부 였습니다.

여러 제공처의 데이터를 직접 비교 분석해서, 가장 사용하기에 적합한 데이터를 선택했습니다.

여러 제공처의 데이터를 살펴보다 마주한 문제는 다음과 같습니다.

실제 국내 지역 영역을 빈 공간 없이 모두 채우고 있는 공간 데이터인가?
- 해안가, 섬 지역을 빈 공간 없이 잘 채우고 있는가?
- 내륙 지역을 빈 공간 없이 잘 채우고 있는가?
업데이트 주기는 어떠한가? 최신 데이터가 잘 반영이 되는가?
각 동의 영역 간에 겹치는 부분이 발생하는가?
데이터를 무료로 사용할 수 있는가? 비용이 든다면 어느정도인가?
데이터가 API 형태로 제공 되는가? 아니면 다른 형태로 제공 받을 수 있는가?

이 중 몇 가지를 자세히 살펴보겠습니다.

해안가 영역 빈 공간 이슈

아래 그림처럼 실제 주문이 발생할 수 있는 해안가 지역을 포함하지 못하는 데이터가 존재했습니다.

해안가 영역의 빈 공간 이슈는 대부분의 원천 데이터에서 조금씩은 모두 발생하였습니다.

원천 데이터 보정을 요청할 수 있는지와 빠르게 보정될 수 있는지가 중요했습니다.

해안가 영역의 빈 공간이 발생한 공간 데이터

내륙 영역 빈 공간 이슈

해안가 영역의 빈 공간 문제와 마찬가지로 내륙에서 빈 공간이 발생하는 원천 데이터들이 있었습니다.

내륙에서 발생하는 것은 해안가 지역에서 발생하는 것보다 더 치명적이므로, 원천데이터 선택할 때 상당히 중요한 문제입니다.
이렇게 빈 공간이 발생한다는 의미는 시스템에서 관리할 수 없는 영역이 되어버리는 것이기 때문입니다. 그렇게 되면 사장님들이 배달지역으로 설정할 수 없는 문제가 발생합니다. 이 외에도 광고, 주문 등이 불가하게 됩니다.

아래 그림은 내륙의 빈 공간들이 발생한 예입니다.

내륙 영역에 빈공간이 발생한 공간 데이터

겹치는 영역 이슈

각 동의 영역이 겹치는 공간 데이터도 발견되었습니다.

영역이 겹치면, 겹치는 영역 어느 동인지 판단하기 어려워 원천 데이터를 사용하기에 무리가 있습니다.

인접한 영역이 겹치는 공간 데이터

앞에서 설명한 검토 기준들을 가지고 총 7개의 외주사의 원천 데이터를 비교하고 분석한 표입니다.

	해안가 커버 이슈	내륙커버 이슈	최신 행안부 고시 데이터 반영	겹치는 영역	비용	데이터 제공 형태	데이터 수정 요청 및 반영 어려움
A사	발생	발생하지 않음	반영되어 있지 않음	발생	발생	API	어려움
B사	발생	발생	반영되어 있음	발생하지 않음	발생하지 않음	API	어려움
C사	발생하지 않음	발생하지 않음	반영되어 있음	발생	확인불가	제공하지 않음	어려움
D사	발생	발생	반영되어 있지 않음	확인불가	확인불가	API	어려움
E사	확인불가	발생	확인불가	확인불가	확인불가	API	어려움
F사	확인불가	확인불가	확인불가	확인불가	매우 높은 비용	API	수시 요청 가능
아이나비시스템즈	발생	발생하지 않음	반영되어 있음	발생	발생	API, GeoJSON	수시 요청 가능

위 표처럼 여러 외주사의 데이터를 정확성과 사용성 측면에서 고려하여, 비교적 정확한 데이터를 제공해주고 있고 수정요청에 대해 가장 빠르게 대응해주는 아이나비시스템즈를 채택하게 되었습니다.

개발

프로젝트 개발 단계에서 새로 알게 된 지식과 고민한 내용, 문제 해결한 내용에 대해서 소개해 드리겠습니다.

공간데이터 및 GeoJSON

공간 (Spatial) 데이터 타입이란?

MySQL에서 공간 데이터 관리를 위해 OpenGIS의 일부 기능을 지원하고 있습니다.
공간데이터란, GPS를 이용한 위치 정보를 포함해 모든 좌표 형식의 데이터를 관리할 수 있는 개념입니다.

MySQL 공간 정보 관리 기능에는 다음과 같은 것들이 존재합니다.

라인이나 점 또는 다각형과 같은 정보를 저장할 수 있는 데이터 타입
- 하나의 단위 정보를 저장하는 타입 : GEOMETRY, POINT, LINESTRING, POLYGON
- 여러 개의 단위 정보를 저장할 수 있는 타입 : MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION
공간 데이터의 연산을 위한 확장 함수
또한 공간 데이터의 빠른 검색을 위한 인덱싱 알고리즘 (R-Tree) 존재

MySQL에서 공간 데이터 타입은 모두 이진값으로 저장됩니다.
AsText() 와 같은 함수를 통해서 지정된 문자열 포맷 WKT(Well Known Text)로 조회할 수 있습니다.

-- 변환전 
0x00000000010300000001000000810000003F599CE88A4660408EC47FBF8E104040BDE96C7

-- 변환후
POLYGON((130.2044566205677 32.12935632456457,130.20440551063612 32.131 ...

GeoJSON과 S2 데이터

GeoJSON이란, 위에서 언급한 공간데이터를 포함한 다양한 지리 데이터 구조를 JSON 형식으로 인코딩하기 위한 포맷입니다.

또한, 셀러시스템팀에서는 배달지역 데이터를 좀 더 유연하게 사용하기 위해, 공간데이터를 구글에서 개발한 S2라는 형태의 데이터로 변환하여 저장합니다.

S2 라이브러리

S2 개념과 공간데이터가 어떻게 S2로 변환되는지와 그에 대한 검증의 내용이 궁금하시다면, 아래 글을 참고해주세요.

가게 배달지역 관리방식 개편 프로젝트

S2 데이터를 생성하기 위한 과정은 다음과 같습니다.

아이나비시스템즈에서 GeoJSON 의 형태로 공간 데이터를 제공
GeoJSON 에서 필요한 정보를 추출해 공간데이터 생성 및 저장
Polygon 데이터를 S2 데이터로 변환하여 저장
S2 데이터 검증

가게주소 법정동 코드 마이그레이션 배치 개발 및 성능 개선

가게주소를 별도의 테이블로 관리하고 있습니다. 해당 테이블에는 실주소(도로명주소, 지번주소)와 우편번호, 좌표 등을 포함하고, 해당 가게 주소가 속한 행정동의 시도/구군/동 코드를 포함하고 있습니다.

법정동 관리 체계로 변경이 되면서 해당 테이블에는 법정동의 시도/구군/동 코드도 추가하기 위해 컬럼을 추가하였습니다.

법정동 관련 작업들이 배포 된 이후에는 신규 가게 생성이나 가게주소 변경 시 자동으로 법정동 코드가 업데이트 되도록 개발이 되었지만, 배포 전 전체 데이터에 대해서 법정동 코드를 매핑해주어야 하는 작업이 필요해 배치 프로그램을 개발하게 되었습니다.

초기 개발내용 요약

법정동 코드를 확인하는 방법은 다음과 같습니다.

가게의 가게주소 좌표를 조회합니다.
전체 법정동 공간 데이터(Polygon) 테이블 탐색하여 해당 좌표가 속한 법정동 공간 데이터(Polygon)을 찾습니다.
해당 법정동 공간 데이터(Polygon)의 법정동코드를 추출합니다.
해당 가게주소 데이터에 추출된 법정동코드를 업데이트합니다.

최초에 해당 배치를 개발하고 성능 측정을 해보았을 때, 운영환경의 데이터 기준 약 40시간 이상이 걸릴 것으로 예측이 되었습니다.
마이그레이션 예정일과 실제 전체 기능 오픈일이 이틀밖에 차이가 나지 않아, 40시간은 매우 촉박한 시간이었습니다.
그래서 성능개선 점을 찾아 소요시간을 단축하는 작업을 진행했습니다.

개선 사항

크게 두가지 측면에서 성능을 개선할 수 있었습니다.

전체 법정동 폴리곤 데이터를 탐색할 때 조회방식
- 개선 전 : 매번 DB에 조회 및 탐색
  - 하나의 가게주소가 속하는 폴리곤 데이터를 찾기 위해 아래의 쿼리가 매번 호출되었습니다
```
SELECT dong_code
       FROM legal_dong_geo
       WHERE ST_CONTAINS(geofence,
                         ST_GEOMFROMTEXT(CONCAT('POINT(', 130.16202567550553, ' ', 32.12935632456457, ')')));
```
- 개선 후 : 메모리에 올려놓고 조회 및 탐색
  - 폴리곤 데이터는 실시간으로 변경되는 데이터가 아니기 때문에 메모리에 올려놓고 사용해도 무방했습니다.
  - 전체 법정동 데이터 용량은 1MB 도 되지 않아 메모리에 올려놓고 사용하기에 무방하다고 판단했습니다.

실제 법정동 폴리곤을 찾은 후 해당하는 동코드를 업데이트하는 쿼리도 가게주소의 수 만큼 실행되기 때문에 같은 법정동에 속하는 가게주소들은 최대한 묶어서 쿼리가 나갈 수 있도록 수정하였습니다.

청크사이즈 만큼 읽은 가게주소 데이터를 MultiValueMap 을 사용해 같은 동코드에 속하는 데이터 끼리 묶고, 한번에 업데이트 할 수 있도록 수정하였습니다.

// 키가 법정동 코드, Value가 속하는 가게주소 데이터의 PK 인 MultiValueMap 생성 메서드

private MultiValueMap getLegalDongCodeToShopAddressIds(List items) {
        MultiValueMap legalDongCodeToShopAddressIds = new LinkedMultiValueMap();

        for (ShopAddress shopAddress : items) {
            Point point = PolygonUtils.createPointByCoordinate(shopAddress.getLongitude(), shopAddress.getLatitude());

            LEGAL_DONG_GEOS.stream()
                           .filter(legalDongGeo -> legalDongGeo.getGeofence()
                                                               .contains(point))
                           .findFirst()
                           .ifPresent(legalDongGeo -> legalDongCodeToShopAddressIds.add(legalDongGeo.getDongCode(), shopAddress.getId()));
        }

        return legalDongCodeToShopAddressIds;
    }

이점을 더욱 살리기 위해 청크사이즈를 10000~100000 까지 늘렸습니다.

결과

실제 베타환경의 배치 수행이력입니다.

기존에는 약 4시간이 소요되었고, 개선 후에는 약 1분이 소요되었습니다.

이렇게 데이터 저장 및 조회 방식을 개선하고, DB 쿼리 수를 줄여 초기 40시간을 예상한 배치가 실제로는 16분이 소요되었습니다.

성능을 약 150배 향상 할 수 있었습니다.

행정동-법정동 매핑 추출 배치

행정동에서 법정동으로 관리체계가 전환됨에 따라, 어떤 행정동이 어떤 법정동으로 매핑되는지를 알고 싶다는 유관부서 요구사항이 발생했습니다.
활용 예시로는 특정 가게가 A행정동에 속해 있었을 때의 주문 수와 B법정동에 속해 있을 때의 주문 수를 비교하는 통계에 활용할 수 있습니다.

데이터 추출

일단 먼저 데이터 추출을 해보고 활용한 가능한 데이터가 나올지 판단하기 위해 배치를 개발했습니다.
각 법정동의 폴리곤 별로 어떤 행정동과 겹치는지, 어느 정도의 영역이 겹치는지에 대한 데이터를 추출하였습니다.

MySQL 공간연산함수를 이용해 추출하였습니다.

ST_Intersection : 두 폴리곤의 겹치는 영역 추출
ST_AREA : 폴리곤 영역 크기 추출

한계점

데이터를 추출하고 보니, 이 배치를 통해 정확한 매핑 데이터를 추출하기에는 한계가 있었습니다.

명확하게 행정동과 법정동이 겹치는 경우가 있는가하면 (좌측은 법정동인 송파동, 우측은 행정동인 송파1동, 송파 2동)

매우 미세하게 겹쳐 이것을 매핑이라고 봐야할지 애매한 경우도 다량 발생하였습니다.

좌측 검은색 영역 (행정동 송파6동) 과 우측 (법정동 송파동)은 매우 미세하게 겹침이 발생합니다.

모호한 데이터들이 발생하는 원인은 다음과 같습니다.

행정동과 법정동이 정확한 포함관계를 가지는 관계가 아닙니다.
기존 행정동 데이터 제공처(기존 외주사)와 법정동 데이터 제공사(아이나비시스템즈) 도 데이터 출처가 다르기 때문에 미세한 차이가 많이 발생하였습니다.

미세한 겹침에 대해서 데이터 관리 주체인 셀러시스템팀에서 어느 정도의 겹침부터 특정 행정동과 법정동이 매핑된다라고 기준점을 정하기 애매하다고 결론지었습니다.

결론

매핑의 기준점을 정하기가 어렵기 때문에 이 데이터는 활용하기 어렵다고 판단하였습니다.
이 데이터는 참고용으로 활용하고, 실제 행정안전부가 제공하는 공시데이터를 함께 사용할 수 있도록 안내하였습니다.

MySQL에서 대량 데이터 복사 시 문제 해결

문제

개발환경(배치, DB)에서 생성 및 보정이 끝난 S2 데이터를 베타 환경으로 옮겨서 테스트하고, 운영환경으로 옮겨 배포하는 작업을 반복했습니다.

S2 데이터는 몇천만건 단위의 대규모 데이터이다 보니, 데이터를 옮기는 데에 시행착오를 겪었습니다.

데이터베이스 툴로 DataGrip을 사용하는데, 내장되어 있는 데이터 복사 기능을 사용하면, 매우 느리기도 하고 계속 중단되어 데이터를 옮길 수 없었습니다.

해결방법

DataGrip에 내장된 테이블 간의 데이터 복제기능은 내부적으로 직접 INSERT를 하는 것으로 보여, 직접 INSERT 방식 말고, 파일로 데이터를 적재하는 방법을 선택했습니다.

파일에서 컬럼을 읽어서 저장하기에 INSERT에 비해 약 20배 정도까지 빠를 수 있습니다.
다음 명령어를 통해서 몇천만건의 데이터를 손쉽게 옮길 수 있었습니다.

명령어는 다음과 같습니다.

LOAD DATA INFILE '/tmp/employees.csv'
IGNORE INTO TABLE employees
FIELDS
    TERMINATED BY ','
    OPTIONALLY ENCLOSED BY '"' ESCAPED BY '"'
LINES
    TERMINATED BY '\n'
    STARTING BY
(emp_no, birth_date, first_name, last_name, gender, hire_date);

필드 구분자와 라인 구분자를 명시할 수 있습니다.

검증

개발이 끝나면, 여러가지 형태의 검증(QA)을 진행합니다.
지리 기준 체계 전환 프로젝트에서도 다양한 QA를 진행해 간단히 소개하고자 합니다.

규모나 영향범위가 적을 경우 팀 자체적으로 QA를 진행할 때도 있지만, 이번 작업과 같이 규모, 영향범위가 큰 경우 QA부서와 협업을 진행합니다.

데이터 품질을 포함해서 까다로운 데이터 검수가 필수적이었기 때문에, QA부서의 꼼꼼한 확인이 필수였고 그 덕에 무사히 배포할 수 있었습니다.

API 테스트

셀러시스템팀에서는 API 문서 작성과 테스트 용도로 Swagger를 사용하고 있습니다.
개발자가 각 API 마다 Request / Response 구조와 응답 코드 등을 전달하면 QA 부서에서는 스프레드 시트 등을 활용해 다음과 같이 정리하고 QA를 진행합니다.

일반적인 API 정상 수행 테스트 케이스 예시

실패 케이스가 발견되면, 문제가 되는 로직을 수정하고 다시 실패 건을 테스트 하는 과정을 반복합니다.

폴리곤 테스트

폴리곤 영역에 대한 테스트는 일반적이지는 않아 QA부서와 어떠한 검증들을 진행하면 좋을지 여러 차례 논의 후에 검증 목록들을 정의하고 테스트를 진행하였습니다.

검증 목록 예시를 간단히 소개해드리겠습니다.

폴리곤 형태가 정상적인지
- 폴리곤 데이터에 꼬임 현상이 있는지
- 겹치는 폴리곤이 있는지
- 내륙/해안가 지역에 전부 포함되지 않은 영역이 있는지
여러 제공 출처의 데이터와 차이가 발생하는지

위의 검증과정을 거쳐 실패 케이스가 발생하면 아이나비시스템즈에 전달합니다.

아이나비시스템즈에서 수정본을 전달받아 다시 적용한 후 QA를 재진행하는 과정을 반복해 현재의 안정적인 데이터를 갖출 수 있게 되었습니다.

회고

이번 프로젝트는 수 많은 유관부서가 참여한 대규모 프로젝트이다보니 특별히 전체 유관부서들과 함께 회고를 진행하였습니다.

회고 방식

사전 설문조사 실시
- 일정, 커뮤니케이션, 프로젝트 관리 등 항목을 나누어 만족도 조사 및 의견 수렴

실제 회고 진행
- 프로젝트를 진행하면서 각자 좋았던 점 / 아쉬운 점 / 앞으로 시도해볼만 한 것들에 대해서 작성하고 공유하는 방식으로 진행하였습니다.

회고 내용

회고를 진행하면서 의견을 나눈 몇가지 내용들을 소개해드리겠습니다.

테스트(QA) 관련

좋았던 점
- QA부서에서 여러유관부서들 모두 함께 QA 진행사항에 대해서 정기적으로 공유하는 자리를 만들어주셔서 좋았음
아쉬운 점
- 테스트 환경 세팅 및 진행과 관련하여 미리 관련부서와 확인을 하지 않아서 실제 진행을 할 때 시행착오가 많이 발생
- 사람의 판단이 필요한 검증의 경우에 오차가 발생
시도해볼만 한 점
- 사전 데이터세팅 및 QA 진행방식에 대해서 관련 부서와 싱크할 수 있는 자리를 마련
- 사람의 판단이 필요한 검증은 사전에 기준을 최대한 명확히 해 오차를 줄임

커뮤니케이션 관련

좋았던 점
- 전반적으로 유관부서 간의 문의 대응이 빨랐음
- 용도에 맞게 슬랙 채널이 잘 구분되어 있어서 필요한 정보만 집중적으로 확인하기에 수월했음
- 정책/일정 등에서 변경사항 공유가 빨랐음
아쉬운 점
- 이슈를 해소할 유관부서를 정확히 파악하지 못해 시행착오를 겪은 점
시도해볼만 한 점
- 이슈 발생 시 도움을 받을 수 있는 유관부서를 빠르게 파악할 수 있는 프로세스 만들기
- 최신 기준의 통합 정책서를 접근이 편리한 문서로 작성해 공유하기

프로젝트를 성공적으로 잘 진행하고 마무리 하는 것이 물론 가장 중요합니다.

하지만, 어떠한 일이든 완벽하게 할 수는 없고 늘 아쉬운 점이 생기기 마련입니다.

그래서 이러한 것들을 생각만 하고 넘어가는 것보다 서로 의견을 주고 받으면서 다시 되짚어 보고 정리하는 회고 자리를 가지는 것도 매우 중요한 일입니다.

이번 회고 자리를 통해서 다음 프로젝트에는 어떤 부분에 좀 더 신경을 써야 좋을지 명확하게 짚어보는 계기가 되었습니다.

느낀 점

이번 과제는 제가 입사를 한 이래로 가장 큰규모이면서 장기간 진행한 프로젝트였습니다.
그만큼 경험한 것도 많고 배운 점도 많았습니다.
그래서 마지막으로 이번 과제를 진행하면서 크게 느끼고 배운 점 두 가지를 말씀드리면서 마무리 하고자 합니다.

협업하는 재미

협업하는 재미는 항상 느껴왔던 것이지만, 이번에는 제가 메인 담당자로써 수많은 유관부서, 외주사와 함께 소통을 하면서 프로젝트를 진행하다보니 더 크게 느낄 수 있었습니다.

하나의 기능을 만들기 위해서 수 많은 팀들과 함께 고민하고 논의하다보니 다른 분들의 새로운 시각이나 경험들을 배울 수 있어서 너무 좋았습니다.

특히 외주사와 긴밀하게 소통을 하면서, 우리 회사와는 어떻게 다르게 일을 하는지, 또 서로의 입장을 배려하면서 소통을 하는 법을 배울 수 있어서 좋았습니다.

앞으로도 저와 일하는 수많은 분들이 즐겁고 의미있게 일할 수 있는 사람이 되도록 노력할 것입니다.

예기치 못한 상황에도 평정심을 유지하자

이번 프로젝트를 진행하면서, 여러가지 이유로 프로젝트 일정이 변경되거나 정책이 변경되거나 해서 개발이 중단되기도 하고, 개발한 것들을 갈아 엎어야 하는 경험을 많이 해보았습니다.

어느정도 개발이 많이 진행된 상태에서 이런 상황이 닥치면 의욕이 상실되기도 하고, 대상 없는 원망이 생기기도 합니다.

하지만, 어떤 상황이든 제가 해소할 수 없는 상황이라면 그대로 받아들이고 다음 할 일을 빠르게 찾아서 진행하면서 거기에 몰두하는 것이 저에게도, 회사에게도 좋다는 것을 느꼈고, 제가 해소할 수 없는 상황에 빠져서 헤매는 것이 오히려 손해라는 생각이 들었습니다.

이번 프로젝트를 진행하면서 느끼고 경험한 것들을 발판 삼아 더 나은 개발자가 되도록 앞으로도 많이 노력할 것입니다.

프로젝트를 함께한 모든 분께 감사드리며, 이 글을 읽은 모든 분들도 항상 재밌게 일하고, 성장하는 개발자 (혹은 다른 직무더라도..) 가 되길 기원합니다!

김효건

대동여지도 김정호가 있다면,
배달의민족 지도에는 김효건이 있다.

셀러시스템팀 백엔드 개발자