<아직도 내가 데이터 통신을 몰랐구나...>

강민수·2022년 1월 2일
0

진실의 방

목록 보기
23/26

필자가 1차 프로젝트 프론트 코드 작성 중 발견한 무지함에 대해 풀어보고 싶어, 컴퓨터 자판에 손을 올렸다.

그렇다. 이 말 너무 와 닿는다. 마치 나를 두고 하는 말인가 싶을 정도로...

1. 사건의 발단

필자는 일단 상품 리스트 페이지 ui를 만드는 과정에 임했다. 생각보다 빨리 백엔드 회원가입, 로그인 api가 구축이 끝나 여유롭겠다는 생각을 했었다...

하지만, 그것은 잘못된 착각이었다.

특히 프론트를 손 놓은 지 2주가 넘은 시점의 이 나에겐...

01) 처음에는 괜찮았다.

이커머스 사이트이다 보니, 특히 상품 리스트에는 상품 사진이 필수적이었다. 그래서 일단, 리스트 백엔드를 맡은 태영님께 문의를 하니, 아직 데이터 완성이 덜 되었다고 전달 받았다. 그래서 일단, 필자가 가지고 있는 목데이터로 진행하기로 했다.

그래서 진짜 딱 이전에 개인 프로젝트에서 썼던 커피리스트 목데이터를 가져다 썼고, 그래서 코드도 그에 맞춰서 비슷하게 쓸 수 있었다.

02) 그의 부름~

그렇게 이제 막 그리드 배치에 대해 생각하면서 css를 만지고 있는 시점에, 슬랙에 태영님이 백엔드 통신을 해 보자고 연락이 왔다. 그래서 필자는 당당하게 그래 뭐 그거는 바로 할 수 있지라는 생각에 바로 태영님의 라이브 서버로 들어갔다.

그리고 그가 보내준 서버 주소를 받고 데이터를 받아 봤다. 자신 만만하던 내 얼굴은 금새 잿빛으로 바뀔 수 밖에 없었다...

이럴 수가....

갑자기 맵이 안 돈다는 오류가 떴다ㅜㅜ

2. 본격 문제의 점검.

01). 목 데이터 구조의 변화.

그래서 필자는 바로 태영님에게 데이터 구조가 어떻게 되어있는 지 확인을 했다.
그러자, 필연적으로 다름을 직감했다.

이를 통해 다시 한 번 내가 너무 백엔드 개발자에게 아무 것도 안 물어보고 목데이터로만 생각을 한 것이라는 생각이 들었다. 그래서 코드를 다시 짜야겠다는 생각이 들어, 일단 통신은 중단했다.

02). 그에 따른 코드의 변화.

이후 필자는 먼저, 태영님의 구조에 맞춰 목 데이터를 다시 만들었다. 그리고 그에 맞춰 코드를 바꿔나가기 시작했다.

하지만, 너무 목데이터에만 길이 들여 있던 것인지...

응용 자체가 잘 되지 않았다. 분명 문제를 알고 있는데... 문제가 안 풀리는 느낌이었다. 그렇게 몇 시간을 흘러 보내면서 머리를 쥐어뜯다가..

결국 집으로 귀가했고, 머리 속에는 해당 문제에 대해서만 가득했다.

03). 코드 수정

에러 코드를 다시 살펴봤다.

productList.js:72 Uncaught TypeError: Cannot read properties of undefined (reading '0')

그리고 해당 부분을 폭풍 구글링해 봤다.

그러다 문득 하나의 글을 봤는데...

필자와 똑같은 오류 + 비슷한 상황?
그래서 필자의 코드를 살펴봤다.

일단, 맵핑을 돌리는 것 자체가 문제였다. 그래서 보니까... 위의 코드처럼 맵매서드를 하니 안 되는 것이라는 직감이 들었고, 맵핑 코드가 잘못 된 것을 알 수 있었다.

1) 1차 시도.


하지만, 되지 않았다. 처음에는 조건부 랜더링을 걸지 않고 돌렸기에 조건부 랜더링 까지 걸어서 돌렸지만,

집나간 이미지는 돌아오지 않았다....

2) 2차 시도.

그래서 필자는 다시 문제를 살펴봤다. 그리고 다시 검색을 해보니...

다시 이런 문제를 겪은 블로그를 발견했다.

그래서 바로 바꿔 봤다. 그랬더니, 집나갔던 이미지들이 잘 돌아오는 것이 아닌가... 물론 맵매서드 코드 아래에 프롭스에서도 약간 어려움이 있었다.

프롭스도 접근을 객체와 배열의 접근을 통해 해당 이미지 url키 값의 벨류를 끄집어 내는 작업을 잘 해줘야만 맵이 잘 돌고 이미지가 잘 나왔다.

3. 문제 분석

01). 목 데이터 구조에 따른 잘못된 코드 구현.

즉, 맵은 배열만을 어떤 기준을 가지고 순회하는 메서드다. 그런데 필자는 그러니까 맵을 써놓고 객체에다가 맵을 돌린 것이다. 그래서 맵을 돌릴 배열을 지정해 주니 끝이 났다.

02) 프롭스의 객체 접근법

물론 이하에 보이는 저 프롭스 설정하는 것 역시 수많은 시행착오 끝에 나온 결과물이긴 하다.

즉, 필자 역시 처음에는 이미지 url만 받아오면 되지 않을까 생각했지만...

저렇게만 하면, 정말 좋겠지만, 저러면 또 이미지가 날라간다..

그래서 원인을 확인해 보니...

개발자 도구에서 저렇게 src 이미지 주소가 안 들어간 것을 확인할 수 있었다.
그래서 다시 받아오는 데이터 구조를 확인해 봤다. 결국 프롭스도 저렇게 접근을 해야만 한다는 결론을 내리고 코드를 다음과 같이 수정했다.

그렇다. 우리가 흔히 아는 그 기초적인 닷 노테이션과 브라켓 노테이션의 조합. 그게 키였던 것이다...

4. 느낀점.

이번 문제를 겪으면서. 크게 2가지가 와 닿았다.

  1. 개발자간의 소통은 꼭 필요하다.
    물론 나와 태영님은 많은 소통을 했음에도 불구하고, 이렇게 서로 이해하는 바라던지 앎의 정도가 충분히 다를 수 있다. 그래서 그때는 이실직고하고 해당 부분에 대해 특히 데이터 받는 부분의 경우 서로 협의가 충분히 된 상태에서 진행을 하고 코드를 짜야만 하겠다고 느꼈다.

  2. 다 안다고 생각할 때가 가장 무서운 것이다.
    다 안다고 생각한 패치 구조에서 목 데이터를 받아온 경험이 오히려 독이 되었다고 느꼈다. 특히 실제 통신 구조에 있어서 데이터를 주고 받는 것은 어떤 경우라도 분명 변수가 많고, 조금만 트러져도 문제가 생길 수 있다. 그렇기에 본인이 다 안다고 생각하는 것이 가장 위험하다는 것을 깨달았다. 해당 오류를 하루 종일 잡아가면서 느낀 결론은. 많이 경험하고 공부해서 최대한 그 간극을 좁혀 나가도록 노력하는 것이다.

선무당이 사람잡는다는 말처럼 선무당이 되지말자!

profile
개발도 예능처럼 재미지게~

0개의 댓글