공공데이터 API
Blocker
- 공공데이터 양식
공공데이터별로 데이터의 양식이 다릅니다. 어떤 api는 모든 날짜의 정보를 받아올 수 있는 반면, 제가 선택한 공공데이터는 한국언론진흥재단이 지정한 날짜의 데이터만 존재했습니다. 특히 메타버스의 경우 2007년과 2020년만 존재하고 공공데이터의 엔드포인트가 연도의 값이 아닌 특정 키값을 저장했기 때문에 키값을 따로 저장해주어야 하는 번거로움이 있었습니다.
// 연도별 키값 예시
const metabusUrl = {
"2007" : "/15097929/v1/uddi:e631fe5b-6674-4a78-b673-bd14f90f57f9",
"2020" : "/15097929/v1/uddi:898b5bb4-9d72-4aa0-a32e-b83cf1ce3df6"
}느낀 점
- fetch HTTP 통신 방식
fetch 통신의 경우 받아오는 데이터의 형태를 .then을 통해 json 형식으로 변경해주어야 합니다. 이전에는 axios으로만 통신을 해보았기 때문에 fetch 통신 방식을 새로 알게 되었습니다.
- 데이터 키값 지정
공공데이터의 경우 데이터들은 사람이 이해하기 쉬운 키값으로 전달하지 않는 경우가 있습니다. 따라서 공공데이터포털은 오픈 API Swagger을 통해 키값들이 가지고 있는 정보를 설명합니다. 우리가 앞으로 작성하게 될 Swagger을 실제로 공공데이터포털에서 사용한다는 점을 확인했고, 데이터의 정보를 토대로 정보를 가공할 수 있었습니다.
Swagger
Blocker
- swagger 파일 형식
swagger은 json, yaml, js 파일로 작성이 가능합니다. 하지만 세가지 모두 파일 형식이 다르므로 문법이 다릅니다. swagger을 제공하는 사이트들은 모두 다른 방식으로 작성되었기에 swagger 파일 형식을 지정하는데 이려움이 있었습니다. microsoft의 경우 json 작성방식을 제공했지만, swagger 공식문서는 yaml 파일로 작성할 것을 권장했기에 yaml으로 작성하게 되었습니다.
- swagger 버전
swagger은 3.0 버전이 존재합니다. 2.0까지는 json으로 작성하는 방식이었으나, 3.0 이후에는 yaml 형식을 권장합니다. 저는 처음에 microsoft에서 제공하는 json형식으로 파일을 작성했지만 이후에 yaml파일로 변경하는 번거로운 과정을 걸쳤습니다. 하지만 swagger 3.0은 구조가 더 간단하고, 다양한 기능을 제공하고 있다는 장점이 있었습니다.
느낀 점
- yaml 알기
yaml 파일 작성 양식을 배웠습니다. 띄어쓰기를 통해 객체의 key와 value를 결졍해주는 방식으로 이해했습니다. json과 yaml을 공통 부분이 많기 때문에 서로 변환이 가능합니다.
- API 문서 자동화 공부
API의 유지보수를 위해 API 문서를 작성해야 하는데 이때 자동으로 문서를 작업해주는 Swagger에 대해 자세히 알게 되었습니다. 프로젝트 진행시 postman을 통해 API 문서화를 진행한 적이 있습니다. postman과 다르게 Swagger은 html페이지로 문서화하기 때문에 공유하기가 편리하고, 무료인 장점이 있습니다.
Unit Test
Blocker
- Jest 외부 함수 호출
Unit Test의 작성에 성공하지 못한 이유는 Jest 모듈 사용시 외부 함수 호출입니다. 테스트해야 할 외부함수를 호출하고 jest를 실행하는 경우 외부함수를 읽지 못하고 에러가 발생합니다. 만약 내부에서 함수를 선언한 후 jest를 실행하면 성공적으로 jest 테스트 결과가 나옵니다. 그 이유에 대해 더 자세히 공부해야 할 거 같습니다.
느낀 점
- Unit Test 개념 공부
Unit Test의 과정, 필요성, 결과물에 대해 자세히 공부할 수 있었습니다. Unit Test를 실행할 시에 필요한 목데이터와 stub을 알 수 있었고, Unit Test를 실행하는 이유에 대해 자세히 공부할 수 있었습니다. 코드 구현시 필요한 기초들을 잘 다질 수 있는 경험이었습니다.
Unit Test
- E2E 테스트와 Unit Test의 차이
제가 구현했던 테스트 코드가 있었는데 E2E테스트임을 알게 되었습니다. Unit Test는 가장 작은 모듈의 테스트이기 때문에 결국 모듈의 크기를 어떻게 정의함에 따라 테스트 코드의 방식이 달라집니다. 하지만 제가 짠 코드들은 결국 end point가 잘 동작한지를 확인하는 것이기 때문에 가장 작은 단위의 모듈을 테스트하는 Unit Test가 아닌 End to End 테스트에 적합하다는 걸 배웠습니다.
Jmeter
Blocker
- 테스트 환경 (feat. wsl2) 와 띄어쓰기 중요성
wsl 우분투 환경에서 Jmeter를 설치 및 작동시킬 때 많은 에러를 접했습니다. 다른 MacOS나 Windows와 다른에 윈도우 환경 위에 설치된 Ubuntu에서 Jmeter 설치는 알 수 없는 에러가 많이 발생하였고, 결국 windows에서 다시 테스트하는 과정을 겪었습니다. 두 번째로 시간이 오래 걸렸던 이유는 port나 address에 보이지 않는 띄어쓰기가 있다면 바로 주소 접속이 불가능합니다. 당연한 점이지만 한 번에 주소를 넣는 것이 아니라 띄어쓰기가 눈에 띄지 않는 어려움이 있었습니다.
- 서버 크기에 따른 테스트 크기 축소
테스트할 서버는 pc 한대 뿐이라 테스트 코드가 복잡하지 않더라도 테스트 인원의 크기는 최대 2000명에 불가했습니다. 그리고 서버 pc가 1대이기에 여러 명이 테스트할 경우 테스트 결과는 매번 다양해져서 일정한 결과값이 도출되지 않아 시간이 오래걸렸습니다.
느낀 점
- 성능테스트
성능테스트의 중요성을 항상 봤지만, 실제로 구현해본 경험이 없는데 이번 Jmeter를 통해 성능테스트의 개념과 구현 모두를 해볼 수 있어서 좋았습니다. Jmeter에서 제공하는 다양한 plugin을 사용한다면 더 많은 통계를 확인할 수 있습니다. 통계에 대한 공부를 좀 더 한 후 성능테스트를 더 다양한 방식으로 해볼 수 있을 거 같습니다.
Terraform
Blocker
- 개념 복잡
테라폼은 간단하게 말해서 인프라를 관리하는 툴입니다. 인프라는 광대한 범위를 포괄하기 때문에 개념을 공부할 때 어려운 점이 많았습니다. 테라폼을 알기 위해서는 서버를 구동하기 위한 인프라에 대한 공부가 필요합니다. 그리고 각각의 인프라를 관리하기 위한 방법을 알고 있어야 테라폼을 작성할 수 있습니다. 짧은 시간내에 인프라 공부 및 테라폼을 알기에 너무 많은 정보가 있어 어려움이 있었습니다.
- AWS 개념 공부 필수
테라폼으로 AWS라는 인프라를 관리하기 위한 코드를 작성하는데 결국 AWS에 대한 공부가 필요했습니다. 이전에 AWS로 배포한 경험이 있어 직접적으로 AWS 배포에는 문제가 없었지만 테라폼으로 생성한 EC2의 경우 생성에는 성공했지만 구동이 되지 않았습니다. 구동이 되지 않는 원인으로는 포트의 문제 혹은 user 키가 존재하지 않는 것이 문제인 것으로 추정됩니다. 하지만 이에 대한 정확한 이유를 알지 못했고, 정보를 찾기도 어려웠던 기억이 납니다.
느낀 점
- 인프라 관리 공부
AWS로 EC2 및 S3를 만든 경험은 있지만 정확히 인프라의 개념을 알지 못했습니다. 하지만 이번 테라폼 공부를 통해 각각의 인프라의 목적을 좀 더 자세히 알게 되었습니다. 그리고 코드형 인프라의 용도를 알게 되었습니다. 다만 테라폼 코드 작성을 완료하지 않아 아쉬움이 있습니다.
정진하고 계시는군요.