부스트캠프 5기 멤버십 3주 프로젝트 회고

3주가 모두 끝난 오늘, 이제 서로의 회고만을 남긴 시점에 혼자서 글을 쓴다. 3주는 짧았지만, 그럼에도 충분히 여러 가지를 배울 수 있을 만큼 긴 시간이었다, 데일리 회고를 하지 않은 게 아쉬울 정도이다. 내가 이 시간동안 배운 게 뭐가 있는지, 나중에 전체적인 회고를 해볼 생각이지만, 위의 이유로 인해 중간 회고를 작성해본다.

 

1. 협업은 어떻게 하는가 (with iOS)

iOS와 협업을 해야 했다. 그래서 iOS가 필요로 하는 API를 만드는 데에 매우 많은 시간을 투자했다. API가 뭐지 하던 시간들은 이제 끝났다. 지금까지는 내가 필요한 걸 만드는 시간이었다.

내가 필요해서 내가 만드는 것을 API라고 부르기엔 너무 해야 할 게 많았다. API는 개발을 용이하게 하고, 또 사용자를 편리하게 하기 위함인데, 그 API를 만드는 게 쉽지 않았으니까.

마치 예전에 본, 주식투자자와 어부 이야기를 떠올리게 했다.

하지만 이번에는, 내가 필요로 하지 않더라도, iOS 쪽에서 필요로 하는 기능들을 구현하기 위해서 매우 많은 시간을 투자했다, 까놓고 말하면 거기에 더 많은 시간을 투자했다고 해도 과언이 아니다.

iOS와 협업, 아니, 다른 분야와의 협업을 하게 되더라도 이 점은 기억해둬야 할 거 같다. 백엔드는 봉사하는 쪽이다. 그러나 모든 걸 다 해줘야 하는 건 아니다.

왜 그런지에 대해서는 예를 들어 이야기해보자.

 

상황 1.

client : 이런 기능이 필요한데 만들어줘요.
Back : 저희 지금 Front 작업도 하고 있어서 그런데, Back 나중에 해도 될까요?
client : 그거 안 하면 저희는 작업이 All stop 되는데요?

 

이런 상황이 생길 수도 있는 것이고,

 

상황 2.

client : 이런 기능이 필요한데 만들어줘요.
Back : (이건 client 쪽의 문제 아닌가, 근데 난 client는 모르니까 내가 고친다고 해야 겠다.) 알겠습니다.

 

이럴 수도 있다. 한 두 번은 괜찮지만 이런 문제가 많아지면 다음과 같은 문제가 생긴다.

 

상황 3.

Back : 제 서버는 id라는 key 값에 value를 string 타입으로 주면 됩니다.
client : 하지만 저는 id라는 key 값에 value를 배열로 주고 싶어요. 예를 들면 {id : [myID, myID2]} 형식이요.
Back : 그것도 해놨습니다.
client : 그리고 id가 1개인 경우에는 배열이 아니게 해서 주고 싶어요, 예를 들면 {id: myID} 라는 형식이요.
Back : 그것도 해놨고요.
client : 그리고 ids가 배열일 때에는 key 값을 복수형으로 쓰고 타입을 명시해서 ids[] 라고 하는 게 맞지 않나요? 예를 들면 {ids[] : myID} 라고 할게요.
Back : ...
client : 아, 얘기 나와서 말인데, 저는 URL에 id를 넣어서 params로 전달하는 것도 필요해요.
Back : 그러면 저는 params에 id를 체크하고, body에 id와 ids[]를 체크한 다음, null 값을 제거하고 id가 있는지 없는지 단수인지 복수인지 스트링인지 배열인지 파악하면 되는 거군요!

 

요구가 늘어남에 따라서 서버는 정말 다양한 처리를 하게 된다. 그러면 API, 즉 Application Programming Interface의 정의란 도대체 어디에 있게 되는 걸까?

interface는 마치 자판기의 버튼처럼, 이걸 누르면 이 음료가 나올 거란 믿음을 담보로 한다. 그런데 마치 이스터 에그마냥 숨겨진 버튼들이 있고,

실수로 사용자가 다른 부분을 눌렸을 경우도 대비해야 한다? 심지어 버튼을 빗겨 맞아 다른 부분을 눌려도 사용자의 의도를 예측해야 한다?

서버의 기술 요구 사항이 극악하게 커질 수 밖에 없다, 고로 서버를 개발하는 백엔드 개발자 입장에서는 이렇게 말할 수도 있어야 한다.

 

Back : NO. 그것은 제 일이 아닙니다.

 

협업에 대해서 잘 생각해봐야 한다. 협업을 한다는 게 상대방의 의견을 무조건적으로 수용하여, 상대방의 개발을 용이하게 한다는 것인지, 아니면 약속을 지킨다는 것인지.

당장은 전자가 편할 것이다. 그리고 우리가 개발 로봇이 아닌 이상에, 개발만 고려할 게 아니라 인간관계도 생각해야 하는데 어떻게 매번 전자를 고를 수가 있을까?

당장은 전자가 편하더라도 후자를 말할 수 있는 팀이 훨씬 개발 속도나 퀄리티 면에서 낫지 않을까? 이번 프로젝트를 통해서 내가 생각한 것은, 제대로 된 백엔드 프로젝트가 아니었던 것 같다.

나는 일단,

1. API 설계는 꼭 모든 인원이 모일 필요가 없을 거 같아, 왜냐하면 만들어주고 나서 그걸 갖다 쓰라고 하면 되거든.
2. 그리고 플랫폼이 어쨌든 다 같은 API를 쓸 거니까, 관련해서 이슈가 생길 거 같지도 않고.
3. API는 각 요청에 따라 DB를 참조하게끔 하면 돼.

이렇게 세 가지를 생각했고, 세 가지 다 나쁜 쪽으로 배신당하였다.

 

Back : Front에서 issue를 만들 때 레이블, 마일스톤, 담당자, 타이틀, 내용, 작성자... 데이터를 받으면 되겠군. (POST 1번이면 된다고 판단한다.)
client : 저희는 post 요청 날린 후에 레이블이나 마일스톤, 담당자는 나중에 추가하는데요?

 

플랫폼에 따라서 동작 원리가 다를 수도 있고,

 

client : 문제가 있어요. issue에 담당자를 추가해야 하는데 그러면 이슈를 생성해서 그 이슈 아이디를 가져다가 담당자 테이블에 전달해야 하잖아요?
client : POST 1번으로는 절대 못하는데요?

 

시나리오를 작성할 때 API의 치명적인 문제가 발견될 수도 있었다.

관련된 내용은 3번 주제로 이어진다.

 

2. 협업은 어떻게 하는가 (with WEB)

WEB (우리의 경우는 풀스택) 개발자들과 이야기하는 것은 크게 어렵지 않았다, 같은 것을 개발하는 사람들끼리 이야기가 통하지 않는다면 애초에 같은 것을 개발하지 않는 것일지도 모른다.

그런 면에서, 같은 것을 개발하는 개발자들 사이에서는 iOS 개발자들과 협업할 때와 다른 문제를 직면하게 되었다. 내가 겪은 문제는, 인간관계 라고 할 수 있겠다. 사이가 나빴다는 의미는 결코 아니다.

눈치를 보는 것. 또는 미안함 같은 것들이 개발을 더 어렵게 만든 걸지도 모른다. 자기 자신에 대해서도 돌아봐야 한다. 나는 이런 상황에서 더 채찍질을 하고 발전하는 스타일인가?

나는 아닌 거 같다. 처음에는 이 마음이 나를 주말에도 일하게 만들었고 그 결과, 가장 많은 커밋과 가장 많은 코드를 작성한 사람이 나였지만, 그럼에도 이런 생각은 떠나질 않았다.

왜냐하면 나는 코드를 짜는데, 다른 팀원들은 환경 설정을 해결하는 데에 주력했기 때문이다.

나는 그걸 하고 싶지 않았고 할 자신도 없었다. 개발에서 가장 많은 시간을 투자하는 게 환경 설정인데 될 거란 보장도 없고 되더라도 허무할 뿐더러 개발 시간까지 뺏긴다니!

개발 스타일 상 나는 일단 개발을 하고 막히는 부분만 찾아보는 식인데 팀원들은 그러지 않았고, 초장에 모든 것을 해결하려고 했다, 그게 바로 NCP (Naver Cloud Platform) object storage였다.

travis도 한 몫 했다.

나는 다른 팀원들과 달리 서버 개발이 가장 우선이야 라는 것을 모토로 가지고 있는 개발자였기 때문에, 나도 뭔가 열심히 한다는 걸 보여줘야 해 라고 생각했다.

그래서 서버 개발에 더욱 더 매진했지만, 일주일 정도 시간이 지나고 나니까 다른 생각이 들었다.

 

나 : 저 사람들은 어떤 일을 하지? (나중에 면접관들이 질문하면 나는 내 프로젝트인데도 대답 못하는 거 아니야?)

분업보다는 협업을 이라는 말이, 이러한 까닭에서 비롯된 것은 정말 아니겠지만, 면접관에게 대답하지 못한다는 것에는 다른 바도 시사하고 있다고 생각한다.

나는 시킨대로 따를 뿐인 코더인가, 아니면 개발자인가?

자기 자신이 어떤 개발자인지 생각해볼 좋은 시간이었다.

 

3. 시나리오를 작성해야 했거늘

하나의 이슈를 만들기 위해서는 사용자가 title, contents, author, milestone_id를 줄 수도 있고 안 줄 수도 있다. 이것은 데이터를 만드는데 필요한 로직에 해당한다. 이 단계에서는 실수가 보통 없다.

그러나 당장 issues table에는 없지만 assignees나 Issue_labels도 고민해봐야 한다. 사실 assignees는 user이다. user table을 참조한다. issues_labels도 결국 label tabel과 issue table을 참조하고 있다.

어쨌든 하나의 issue를 만드는 데 최소 1개, 또는 3개의 table을 참조할 필요가 있다는 의미이다.

그러니 submit button을 누를 때, issue table 말고 다른 table을 참조하는 경우를 해결할 수 있어야 한다.

해결은 어떻게든 가능할 것이다, 그러나 나는 이번 프로젝트 개발 단계의 마지막 날에 이러한 이슈를 발견했다. 이는 단순히 API만 설계하고 실제 시나리오에 대한 고려를 하지 않았기 때문이다.

시나리오 작성은 필수다. 이 역시 이후로 갈 수록 늘어나는 개발 시간을 줄이는 데에 큰 도움이 될 것이다.

(5주 프로젝트에는 이를 도입하기로 했다.)

 

4. 사용자 중심의 사고 (HTTP)

나 : res.body, res.params. res.query... 어떤 거로 해야 하지?
나 : PUT과 PATCH 메서드의 차이가 뭐지?

 

이전이라면 대답하지 못할 문제들에 대해서 명쾌한 답을 얻었다. 아니, 어쩌면 나만의 생각일지도 모르지만, 나만의 답이라도 안 게 어딘가 싶다.

res.params는 단일 요소에 접근할 때에는 좋지만, checkbox처럼 여러 개를 동시에 접근하는 경우에는 지나치게 어렵다. 그러므로 res.body가 가장 호환성이 좋다.

또한 값이 공개적으로 드러나는 속성 때문에 res.params는 조심할 필요가 있다. 그 점을 염두해두고 사용해야 한다.

그러나 반대로, res.body는 값이 숨겨져서 공유하기는 어렵다.

그래서 검색 필터 같은 경우에는 query를 써서, 사용자가 공유하기 쉽게 만들어주는 것이 좋았다.

PUT과 PATCH의 메서드 차이?

이건 수정할 때에는 PUT인데, 수정하는 사고 방식에 차이가 있음을 깨달았다. PUT은 ~로 바꾸는 것이고, PATCH는 ~하게 바꾼다, 즉 토글에 가깝다는 점이다.

말하자면 PUT이 5살을 6살로 바꿔줘. 즉 1살을 먹게 해줘, 라는 명령이라면 PATCH는 1살 늘려줘 라는 명령어다. 여러 번의 중복 사용이 문제가 되지 않는다.

PUT과 PATCH가 값을 주어지지 않은 column에 대해서 다르게 동작한다는 점, 그것이 PATCH와의 기능적 차이라면, 위는 RESTful한 API를 만들기 위한 차이였다.

 

5. 3주동안 내가 배운 것들

1에서 4까지, 사실 까먹더라도 한 번 더 실패를 겪으면 배울 수 있는 내용이다. 앞으로도 실패할 기회(?)는 많기 때문에 이런 문제에 있어서는 크게 연연하지 않았다.

실수도 많이 했다. 자신있게 내가 하겠다고 말한 부분을 하지 못했던 것도, 팀원들에게 많이 미안하다. 하지만 실수도, 실패와 마찬가지로 점진적으로는 개선될 문제였다.

중요한 것은 다른 부분이다. 도전해서 실패해도, 또 다음 번엔 잘할 수 있을 거라고 확답하지 못하는 부분이 있는데, 그건 내가 즐길 수 있을까 라는 문제라고 생각한다.

솔직히 이번 3주는 즐기지 못했다.

좋은 팀원들임은 분명하지만, 사실 아무리 좋은 사람들이라고 하더라도 사람과 사람의 성향이 맞고 틀리고는 별개의 문제가 아니던가. 그런 점에서 이번은 즐거울 수 없었다.

조금 더 가벼운 분위기에서, 얘기를 많이 해보고 싶었는데, 다들 말 수가 별로 없었다. 서로 나이를 의식하진 않았던(?) 거 같은데, 뭐가 문제였는지도 모르는 상태로 끝나버렸다.

어떻게 즐길 수 있을까, 기술적인 문제보다도, 결국 중요한 것은 이런 주제들이 아닌가 싶다.