회사에서 antd 라이브러리를 계속 사용하다보니,
딕셔너리 형태의 data를 넣어주면 컴포넌트를 알아서 그려주는 것에 영감을 받아서
컴포넌트에서도 UI가 어떻게 그려지는 알 필요없이
필요한 정보들을 string이나 ReactNode만 넘겨준다면
확장성과 가독성을 모두 가져가는 것이라 생각하여 이를 바로 적용해봤다.
이를 적용했던 페이지는 파트너 어드민 회원가입 페이지다.
아래의 페이지를 새롭게 구현해야하는데 든 시간은 단 하루가 걸렸다.

아래와 같은 구조로 딕셔너리 데이터를 입력받아 데이터에 따라 값을 넣어주고
map함수를 통해 각 아이템 타입에 따라 컴포넌트를 그려줬다.
그리고 해당하는 키에 따라 이벤트를 발생시켜 기능을 동작시키도록했다.
사내 다른 프로젝트에 같은 UI를 그리고 동작시키는 회원가입 코드의 경우에는
3000줄이 넘어갔는데, 이와 같은 구조를 통해 600줄의 코드로 이를 구현했다.

![]() | ![]() | ![]() |
|---|
무엇보다 단순하게 data만 넣어줬을 뿐인데, 알아서 컴포넌트가 완성되고
내가 구상한대로 UI가 그려졌을 때의 짜릿함은 이루어 말할 수 없었다🙈
그리고 이러한 구조에 대해 CTO님과 다른 팀원 개발자분의 피드백을 받고 싶어,
스프린트 회고에서 아래의 구조에 대해 의견을 여쭤봤다.
결과는 "반려"였다.
빠르게 구현하고 antd 라이브러리를 사용해보고 비슷한 구조로 컴포넌트를
구현해보는 시도는 좋았으나, 직관적이지 않고 수정에 용이하지 못하다고 하셨다.
이러한 코드는 코드 없이 UI를 수정할 수 있는 곳에 적합하다고 하셨다.
그러면서 짧은 코드가 언제나 좋은 것은 아니고,
때로는 코드가 길더라도
직관적인 코드가 빠르게 변화하는 서비스의 구조에 적합하다고 말해주셨다.
그리고 이와 비슷한 같은 구조를 사용하는 antd의 table의 경우에는
데이터가 정형화 되어 있어도 되고,
다양한 케이스를 수용할 수 있게 구현이 되어있다고 말씀해주셨다.
시간보다 빨리 구현했으니,
한 번 해당 코드를 수정해보며 감을 찾아보라고 하셨다.
나만의 생각에 갇혀있지 않고, 다른 사람들의 이야기를 들으며
나의 코드를 객관적인 시선에서 비판적으로 생각하며,
부족한 점을 수용하여 우물 안 개구리가 되지 말아야겠다.
(하지만 잘 키운 자식을 떠나 보내는 기분이였다...🥲)
파트너 어드민 작업 막바지에 들어가면서,
내가 작업했던 영역의 구현이 빨리 끝나,
다른 개발자분의 티켓을 받아 기능을 구현했다.
그리고 파트너 어드민 1차 QA가 진행됐고,
다른 분이 작업하신 상품 쪽에서 QA 사안들이 많아 내가 작업했던 곳까지
많이 넘어오지 못했다.
그래서 1차 QA 사안을 함께 작업하여 빠르게 수정했다.
그 이후, 2차 QA가 진행됐는데 골고루 다양한 영역에 대한 QA 사안들이 나왔다.
하지만 이번 QA 작업 반영은 혼자 진행하라고 CTO님께서 말하셨다.
그래서 물론 혼자 작업해도 기한 안에는 끝낼 수는 있을 것 같지만,
각자가 작업한 코드를 수정하는 것이 더 빠르고 효율적이지 않을까 생각했다.
근데 그러다 여태까지 내가 잘못 생각하고 있다는 느낌이 팍 들었다.
왜 내코드 네코드 하고 있었던 거지….?
결국에 회사 코드는 우리의 코드이고,
내가 작성하지 않는 코드도 모두 이해하고 있어야했는데
내가 작업한 코드만 수정해야지라고 무의식적으로 생각하고 있었다.
우리는 하나의 공동체이고, 회사의 방향에 맞게 나아가야한다!
스스로를 자기 객관화하여 내 생각이 엇나가고 있는지 꾸준히 체크해야 할 것이다!!
터득한 Point.
1. 구조를 위한 코딩을 하지말자.
2. 굳어진 코드가 아닌, 말랑한 코드를 작성하자.
3. 내 코드를 내 자식으로 생각하지 말자. 우리의 코드이다.

9차 스프린트 기간: 24.11.04(월) ~ 24.11.15(금)
3번의 전체QA를 통해 약 70여건이 넘는 사안들을 수정했다.
아예 새로운 하나의 서비스가 새롭게 출시되는만큼
작업한 영역이나 QA 사안들도 많았던 프로젝트였다.
그리고 해당 업무를 진행하며 큰 우여곡절이 2가지가 있었다.
기존 상품의 경우 상태값을 8가지로 정의하고 있었다.
상품의 권한이 파트너에게도 부여됨으로서,
원활한 관리를 위해 이를 판매상태와 승인상태로 나누어 관리할 필요성이 생겼다.
이를 위해 상태값에 대하여 운영팀과 의논하여
필요없는 값들을 제거하고, 기존 상태값들이 어떤 것을 나타내는지 명확하게 잡고갔다.
그 이후에, 이에 따라 해당 상태들이 어떤 값들로 마이그레이션해야하는지 작성하고,
이를 로컬DB와 개발DB에서 테스트를 거친 후에, 운영 DB에 마이그레이션을 했다.
결과는 실패였다.
모든 경우의 수에 대해 완벽하게 잡았다고 생각했지만, 구멍이 3군데가 있었다.
처음에 구멍 1가지를 발견하고 이를 보완하기 위해
약 3000개의 상품들을 일일히 확인하여,
테스트 상품과 같이 상품명으로 잡을 수 있는 상품들을 판매중지 상태로 변경했다.
이후 또 다른 상황에 마주쳤는데,
판매상태가 변경될 때마다 판매자들에게 카카오 알림톡이 갔었는데
이 부분 때문에 알림톡이 간 수많은 판매자들에게 혼동이 있었던 것이다.
(잠깐동안에 많은 cs가 몰려들었다😱)
그러다 노출이 되면 안되는 상품인데 노출이 되고 있다는 것을 들었다.
그렇다. 나머지 구멍 2개(노출상태 미적용)를 생각해낸것이다.
결국 이를 해결하기 위해 DB 복제셋을 가져와
도커에 새롭게 파일을 DB를 판 뒤에, 해당 도커 파일에 올리고
해당 DB에 쿼리를 쏴 노출이 되면 안되는 상품들의 ID를 가져왔다.
이를 기반으로 운영 DB에서 해당 ID들의 상태값을 변경시킨 뒤에,
변경시킨 상품의 상품명, 판매자 이름, 상품 ID를 운영팀에 전달해드렸다.
단순하게 고쳤다가 아닌, 어떠한 정보들을 이러이러하게 고쳤다로
최대한 구체적이게 데이터로 설명하고,
받아들이는 사람이 해당 정보들에서 필요한 데이터를 알아서
선택적으로 받아들일 수 있도록 최대한 읽을 수 있는 데이터 기반으로
1차적으로 필터한 뒤, 구체적으로 말해주자.
(CTO님께 일잘하는 법을 또 한가지 배웠다🐥)
이 날따라 약간의 마가 끼었다.
평소에 늘 근무시간이 지나도, 일을 더 하다가 퇴근을 했는데
그 날따라 집에가고 싶어, 하던 코드를 마무리짓고 정시퇴근을 했다.
그리고 다음날 QA를 오전에 진행했는데 상품 옵션등록이 되지 않았다.
알고보니, 해당 부분이 서버코드에서 로직 흐름상 이상한 부분이 있어
전날 분리를 하고 그에 맞춰 클라이언트 코드도 변경했는데,
클라이언트 코드가 푸시하여 개발서버에 반영되고,
서버 코드를 푸시하지 않아 PR도 안 올리고, 개발서버에 반영도 안됐었다.
그래서 QA도 무산되고 테스트 해야했던 일도 있었는데 기간이 늦춰졌다.
혼나지는 않았지만, 정말 혼나지 싶은 심정으로 내내 가시방석이었다.
공과 사를 명확히 구분하지 못했다.
앞으로 이런 실수는 절대 하지 말자!!!!
터득한 Point.
1. 복제셋을 이용한 데이터 복구 방법
2. 일 잘하는 또 한가지 방법(오류 복구 이후 사후작업)
3. 공과 사 구분하기(스스로의 행동에 책임지기)
옵션 엑셀 업로드 관련하여 운영팀에서 아래와 같은 작업 수정 주문을 주셨다.
요구사항
1. 유저에게 정렬순서를 받지말고 엑셀 row 순서대로 옵션을 정렬해줄 것.
2. 옵션에서 시간관련하여 텍스트 타입이 아니라 Date 타입도 입력이 가능할 것
옵션 엑셀 업로드 관련하여 작업을 하신 분이 휴가를 가셔서,
해당 작업 수정부분을 내가 맡았고, 해당 부분 코드를 파악하고 작업에 들어갔다.
1번의 경우에는 엑셀 옵션 샘플을 만들어주는 코드에서,
정렬부분을 수정하고 Index를 추가하면 되는 작업이라 금방 끝이 났다.
2번의 경우에는 12:00의 경우 0.5로 받게되는데 이를 계산할까 하다가
시간일수도 있고 날짜일 수도 있고 다양한 케이스가 있어
코드로서 변환해주는 것보다 파싱이 조금 더 커스터마이징이 필요하겠다고 판단했다.
지금 현재 엑셀 파싱을 해주는 라이브러리코드에서는 불가능하여
조금 더 커스터마이징이 가능한 라이브러리를 통해 raw data를 받을 수 있도록 했다.
그리고 옵션 엑셀 관련 코드를 분석하다가,
엑셀에 어느 칸이 비워져있을 경우에도 업로드가 가능하게 되어 있는 것을 파악했고,
결제에서 오류가 날 것 같다고 생각하여 테스트를 해봤더니, 역시 문제가 발생해
빈칸이 있을 경우 해당 엑셀 파일이 업로드가 되지 않도록 수정했다.
터득한 Point.
1. 내가 고민하는 문제는 다른 사람도 고민했을 확률이 높다. (물론 영어로)
2. 코드로 불가능은 없다. 안된다면 더 row 단계로 내려가자.
3. 코드를 의심하고 또 의심하자.