24.02.18~24.02.25

업무

1. Admin 기능 개발

guide, workspace 관련 CRUD 기능을 개발했다.

 

2. 시스템 테스트

staging 환경에서 시스템 테스트를 진행했다.

 

개발을 하다 보면

local에서는 동작하는데, 배포 환경만 가면 에러가 나는 기현상을 맞이하게 된다.

 

물론 대부분이 개발자의 탓이고, 이런 일이 발생하지 않도록 하는 것이 최우선이지만...

개발 환경과 배포 환경의 차이와 문제 사항을 빠르게 찾아내는 것 또한 하나의 방법!

 

따라서 목표한 개발 사항을 완료하지 못했더라도

현재까지의 모든 개발 결과물을 staging에 배포하고, 

배포된 staging 환경에서 각 서비스 간(Admin <-> Extension <-> Server) 시스템 테스트를 진행했다.

 

인수 테스트 전, 자체적인 테스트 단계를 수행했다는 건 칭찬할만했지만

아무래도 팀원들 모두 처음 시행한 시스템 테스트이다 보니...

1) 명확한 시나리오 없이, 동작을 확인하는데 급급했고

2) Extension의 경우 extension store 심사로 인해 배포 환경 테스트를 하지 못했다는 아쉬움이 남았다.

 

3. script-package 변경

사내 서비스에는 (FE 한정) 2개의 패키지가 사용된다.

1) interface 및 기본 service를 제공하는 core-package

2) 고객사 웹 페이지에 삽입된 script를 구성하는 script-package

이 중 script package의 동작 방식에 변경사항이 생겨, 이를 반영했다.

 

기존에는 고객사 admin에서 '배포'를 수행했을 때

서비스 동작을 위해 필요한 데이터를 script에 하드코딩 했었다.

이를 통해 고객사 페이지에서 우리 서버로의 API 요청 없이 곧바로 데이터를 조회해

1) 우리 측 서버 통신 비용을 낮추고

2) 고객사 측 페이지에서 빠르게 해당 데이터를 보여줄 수 있었다.

 

하지만 여러 고객사와의 협업을 진행하면서

1) 각 고객사의 데이터가 점점 많아질 게 예상되고 (배포 시 script 비용 증가 + 번들링 된 script 크기 증가)

2) 해당 데이터가 직접 노출된다 라는 문제가 논의되었다.

 

따라서 각 고객사 script에는 고유 식별자만 삽입해 둔 채

해당 식별자를 토대로 API 요청을 해, 데이터를 받아오는 형태로 변경했다.

 

4.. core-package 변경

데이터를 통해 고객사 페이지에 우리 서비스를 띄워주는 operator 모듈을 수정했다.

 

script-package가 변경되면서, 테스트 겸 배포된 결과물을 확인했는데

target의 offset 상태를 관리하는 hooks가 정상적으로 동작하지 않음을 확인했다.

고전은 언제나 유용하다

사실 해당 hooks를 작성하면서

'분명 내가 알기로는 동작하지 않아야 하는데, 왜 별 문제가 없지?'라고 생각했던 부분이 있었다.

그때는 '잘 동작하니까 된 거겠지?'라고 생각하며 그냥 넘어갔는데...

역시나 발목을 잡았달까.

 

해결 자체는 간단하게 했지만, 

조금 더 나를 믿으면서도(개념을 알고 있었으면서!)

조금 더 믿지 않아야 한다(테스트만 통과했다고 다가 아니다)는 생각이 들었다.

→ 사실, 잘못되었다는 확신이 부족했던 걸 테고... 이건 내 지식과 경험이 부족하기 때문!