실전 프로젝트 19일 회고

SaGo_MunGcci·2022년 9월 13일

Practice Project

실전 프로젝트

목록 보기

13/19

Today do list

⦁ 경매 입찰 하기 기능 개발

⦁ 다른 회원 조회시 해당 회원의 경매 리스트 추가하기 기능 개발

⦁ 낙찰된 경우 1:1 채팅 로직 논의

Retrospection

낙찰된 경우 1:1 채팅 로직 논의 시작

오늘 낙찰된 경우 1:1 채팅 로직에 대해서 전체 회의시간에 논의 하던 도중 처음으로 약간의 논점이 달라졌다.

나의 경우 백앤드이기 때문에 request로 경매게시자와 낙찰자의 닉네임 혹은 memberid만 요청 받으면 낙찰자의 정보를 호가테이블에서 가져오지 않고 한번에 response해서 채팅방을 열고 낙찰자가 들어오는 로직을 완성할 수 있을것 같았다.

그러나 프런트쪽에서 그리고 애초에 와이어프레임을 봐도 경매 낙찰가는 있었지만 낙찰자에 대한 정보가 없어서 이것을 인지하지 못한 내 잘못이 컸다.

이부분은 호가 테이블을 통해서 가져올 수 있다고 하더라도 전체로직을 완성하기 위해서는 최종적으로 낙찰자가 해당 상세페이지에 접근을 했을때 접근을 한 사람이 낙찰자 인지 아닌지 판별하는 로직이 필요했는데 여기서 프런트와 백앤드의 논점이 나뉘게 되었다.

최종적으로 낙찰자 인지 아닌지 해당 상세페이지에 접근하면 JWT토큰을 통해서 해당 회원이 상세페이지에서 response된 낙찰자인지 확인해서 낙찰자라면 1:1채팅을 할 수 있는 버튼을 보여주면 되고 낙찰자가 아니라면 이 버튼을 안보여 주면 된다고 생각했다.

프런트 쪽에서는 낙찰자가 아닌 사람도 1:1 채팅에 접근할 수 있고 이것을 검증하기 위해서는 해당 접근하는 낙찰자를 검증하는 api를 상세페이지마다 만들어야 되어서 버튼이 다 보여질 수 밖에 없다고 말했다.

논의 이후

프런트와 백앤드의 논의가 좁혀지지 않아서 내일 아침 회의때 다시 논의하기로 한 후 백앤드 회의실에 와서 다시 곰곰히 생각해보았다.

사실 백앤드는 백앤드만 보이고 프런트는 프런트만 보여서 의견이 좁혀지지 않아 보인다고 우리 팀원분들중 한분이 말씀하셨다.

곰곰히 생각해보았다. 같은 데이터를 요청 응답하는 부분인데도 왜이렇게 관점이 다를까? 솔직히 나는 우리 백앤드쪽의 의견이 맞다라고 생각했었다.

왜? 나는 백앤드만 알고 있으니까, 그러나 팀원의 말씀을 듣고 난 이후 프런트 분들도 프런트를 아니까 위와 같은 결론을 내리신것 아닐까? 라고 생각이 들었다.

그 순간 내머리 속에서 요즘 읽고 있던 readITzine #4에서 읽었던 부분이 기억이 났다.

사실 항해99를 시작하면서 여러 프로그램관련 서적을 구입했었는데 그때마다 사은품으로 주었던 조그마한 책이었는데, 읽어보니까 협업에대한 좋은 팁들이 있어서 시간이 나면 틈틈이 읽고 있는 중이다.(#5도 읽을 예정이다)

여튼 내가 기억했던 부분을 아니, 지금 다시금 읽고있는 부분을 정리해 본다.

[Tip 2] 논쟁은 증명으로 해결한다.

논쟁이 벌어졌다면 화를 내는 것이 아니라 증명을 해야 한다. 논리적인 증명과정을 통해 상대방을 납득시켜야 한다. 'A를 해야한다.

왜나하면 B이기 때문이다.'라는 식으로 항상 주장과 근거가 동반되어야 한다. A를 쓸것이냐, B를 쓸 것이냐라는 의견 충돌이 생겼던 적이 있다.

나는 만들어야 하는 피쳐(기능)에 대해 가장 적합한 것은 B라고 생각했고 이에 따른 용량, 속도, 사빙가능한 피쳐 등 근거를 대서 논쟁을 해결했던 기억이 있다.

그리고 조금은 다른 이야기지만 자신의 전문적인 영역이 아니니데 어떠한 기술에 대해 제안할 때는 '조심스럽게' 말해야 하는 것도 중요하다. '~하는 것이 어떨까요?'라는 화법들 말이다.

[Tip 4] 예의와 밥

예의를 갖추는 것은 팀 프로젝트에 매우 중요하다. 예를 들어 상대방이 바쁘든 안바쁘든 이런식으로 말하는 것이 좋다.

"안녕하세요 00님 바쁘시지만 이런 말씀을 드려서 죄송합니다. 지금 현재 서비스내에서 B때문에 A가 아니라, C를 하는것이 더 나을 것 같은데, 혹시 방법이 없을까요? 도와주시면 나중에 밥한끼 사겠습니다."

라고 말해야 한다. 그리고 같이 밥을 먹거나 커피 한 잔 하는 것도 중요하다.

readITzine #4 p.103 주홍철 어비스 대표님 -

이부분을 다시금 읽으면서 아하!라고 깨닫게 되었다.

나는 내딴에는 예의를 지키면서 논리적으로 말했다고 생각했지만, 지금 생각해보면 내 논리 내 주장만을 펼치고 있었다.

즉 나는 증명이 아닌 주장을 하고 있었던 것이다. 증명을 국어사전에서 찾아보면 '어떤 사항이나 판단 따위에 대하여 그것이 진실인지 아닌지 증거를 들어서 밝힘.'이라고 정의되어있다.

나는 증거가 없었다. 실제로 서버를 우리로직대로 돌려보지도 않았고 이전에 이와 비슷한 기능을 만들어 본적도 비슷한 로직도 짜본 경험도 없었다. 따라서 나는 신빙성이 전혀없는 될지도 안될지도 모르는 주장을 일방적으로 푸시하고 있었던 것이다.

따라서 프런트분들도 이러한 주장을 프런트로 해석하다보니 프런트와 백앤드간의 서로간의 논점이 벌어졌던 것이다.

증명이 없는 로직은 하나의 가능성일뿐이며 다르게 말하면 하나의 주장밖에 되지 않는다. 증명이 된 로직은 하나의 근거로써 내가 주장을 할때 합리적인 보충 설명이 된다.

오늘의 자그마한 헤프닝을 이해하고 나니까 정말 오래 질질끌던 에러를 해결한 것처럼 기분이 좋았다.

협업을 하면서 정말 정말 내가 상상도 못했던 부분들을 알게 되는 것 같았다.

여러가지 측면에서 나를 되돌아 볼 수 있고 내가 생각하는 것 만큼 항상 상대방도 충분히 생각하고 있다는 점을 항상 명심해야겠다.

비록 주니어개발자도 아닌 주니어개발자 준비생이지만 협업 즉 프로젝트의 성공과 실패가 이러한 사소하다고 하면 사소한 부분에서 어떤 선택을하느냐에 따라, 어떤 주장과 근거로써 합리적인 부분을 서로가 서로를 검증해야만 좋은 프로젝트 및 서비스가 나올 수 있다는 것을 최종적으로 깨닫게 되었다.

항상 숙고하자. 나만의 생각뿐만아니라, 상대방의 입장에서도.