[위코드 X 원티드] 프리온보딩 백엔드 - 다섯 번째 기업과제 후기

절반 이상을 해냈다.

벌써 다섯 번째 기업과제이다.
이번 과제는 '휴먼스케이프'라는 회사의 기업과제이다.
힘들기도 했고, 재밌기도 했던 프로그램을 벌써 절반을 해냈다는 것이 아쉽기도하고, 개운하기도 한 이상한 기분이 든다.
너무 재밌는 프로그램이었고 나에겐, '개발자'라는 직업에 대해 확신을 준 프로그램이라 고마운 프로그램이기도 하다.

어찌됐던, 이번 과제를 해나가며 생겼던 고민들, 느낌들을 적고자 한다.
재밌게 읽어주십셔!

스무스한 시작

우리도 어느덧 네개의 기업과제를 이미 한 경험이 있기에, 순조롭게 어떤식으로 개발할지, 어떤 스택을 사용할지, 컨벤션을 어떻게 할지, 기능 분할을 어떻게 할지에 대해 얘기했다.

저번에는 기능에 대한 역할 분배가 적절치 않았지만 이번에는 일단 역할을 분배한다음 '내일 여덟시'까지 각자 기능을 완수한다음 코드리뷰와, 머지를 하기로 약속을 했다.

어떤식으로 분배할지에 대해선 '정답이 무엇인지', '어떤게 효율적인지'는 알 수는 없었지만 일단은 저번 기업과제할때와는 다르게 최대한 균등하게 역할 분배를 하였다.

결과부터 말하자면, 성공적이였다. 우리가 성장을 하여 전보다 더 빨리 개발을 마쳤는지, 기업과제가 비교적 쉬웠는지는 알 수 없지만 다른 과제를 할때보다 더 빨리 끝났다.(과제 제출일 새벽 3시 반에 끝났다는 것은 비밀.. 평소에는 아침까지 작업을 하였다.)

내가 생각하기엔, 개발을 착수하기 전 팀원 모두가 요구사항에 대해 100프로 이해하고, 우리가 만든 시나리오에 대해 100프로 이해하여 개발이 평소보다 더 일찍 끝났다 생각한다.

그렇기에 팀과 역할 분배를 적절히 하였기 때문이라 생각한다. 즉, 팀과의 소통이 원활했기 때문이라 생각한다.

• 어떠한 기능에 대해 팀들 각자가 모두 다르게 생각한다면, 기능에 대한 역할 분배도 어려울 것이고, 향후 차질이 생길것이다. 팀과의 원활한 소통이 중요하다는 것을 느꼈다.! 이해가 안되면 이해가 될때까지, 팀원과 소통하며 이해할 때까지 소통하자!!

소통의 충돌

팀원과 협업을 할 땐, 의견 충돌이 생기기 마련이다.
우린 과제에 대해 스스로 시나리오를 짜기에 '딱 요구사항 까지만 구현하도록 할지', '향후 기능이 추가될때를 더 고려할지'등에 대해 고민을 하곤 한다.
위와같은 관점에서 나도 이번 과제를 하며 살짝 의견 충돌이 있다고 느꼈다.(서로 싸우고 그런게 아니라, 단순한 의견충돌!)

상황

DB설계를 하는데, 임상정보 데이터에 대해 어떻게 설계할지 의견충돌이 살짝 있었다.

1. 임상정보 데이터를 한테이블에 다 박아버리기

• 솔직히 과제를 하는데 있어 이러한 방법이 더 편하다. 여러 관계들을 생각하지 않고, 단순히 하나의 테이블에만 데이터를 박아버렸기에 조회가 간단하다.(조인이 필요없음)
• 그러나 임상정보의 연구 단계라던가, 연구 종류는 중복이 되게 많을 것으로 사려된다. 그렇기에 임상정보 테이블 : 연구단계 테이블 = 일대다, 혹은 임상정보 테이블 : 연구 종류 테이블 = 일대다로 해서 한 테이블의 중복된 필드를 줄이는 것이 좋다고도 생각했다.

2. 임상정보 테이블을 하나 만들고, 중복되는 필드들은 별도의 테이블로써, 임상정보 테이블과 관계를 맺기

• 솔직히 요구사항을 구현하는데 이게 더 복잡할 것으로 사려된다. 왜냐면 데이터를 조회할 때마다 조인을 통해서 해당 데이터와 관계된 데이터 모두를 가져와야 하기 때문이다.
• 그러나 임상정보 테이블하나만 만드는 것보단 중복된 필드가 줄어들 것이다. 그리고 향후에 기능이 추가된다면, 해당 연구종류의 모든 데이터를 뽑을 때 해당 연구종류의 임상정보만 조인하여 가져오면 되기에 더 편하다.

이러한 고민중, 나를 제외한 팀원분들은 모두 1번이 좋다고 하셔서 1번으로 하였다.
나는 마음속에 작은 아쉬움이 있었지만 나도 다시 생각해보니, 요구사항에 맞춰 개발을 하려면 1번이 좋기에 그게 좋다고 수긍 할수 있었다.

나의 의견을 내는 것에는 두려워하지 않는 것이 중요하다.

다른사람의 의견에만 따라 다닐 거면, 개발을 왜하나? 그럼 코딩하는 기계를 하나 사버리는게 낫지,,,
좋은 개발자는 어떤 것이 더 좋은 설계일지, 어떤 방법이 더 효율적일지를 팀원과 소통하며 찾아내는 것이 중요하다 생각한다.
그렇기에 자신의 의견을 내는 것에 두려움을 없애자!!

나의 의견을 중요하게 생각하는 것만큼 다른 사람의 의견도 중요하다.

사실 난 똥고집이 있어 내 의견을 잘 굽히지 않는 못된 성격을 가지고 있다.
그러나 다른사람과 협업을 할땐, 이러한 못된 성격을 내려놔야 생각한다. 왜냐면 실제로 다른 사람의 의견을 듣고 '내 의견보다 더 나은 생각이 있을수 있구나'라는 경험을 되게 많이 했기 때문이다. (협업하며)
하나의 문제에 대해 사람들은 '경험', '환경', '성격'등등의 다양한 외부적인 이유로 모두 다르게 생각한다.
그렇기에 '나의 생각은 너무 나 자신에만 맞춰서 생각 하는 것이고 더 효율적이지 않을 수도 있다'고 생각한다.

항상 다른 사람의 의견을 경청하며 내 의견과 비교하며 뭐가더 나을지, 절충안은 무엇일지를 고려해보자. 그렇다면 좋은 결과를 가져올수 있다고 믿는다!!

새로운 기술 습득에 대한 두려움 0%

이 프로그램을 참여하기전의 나는 너무 겁쟁이였다.
새로운 기술에 대한 두려움이 너무 컸었다.

그러나 과제를 하면 할 수록 그러한 두려움이 줄어들었다.

이번 과제를 하며 새롭게 도입한 기술로는

• GraphQL
• jest 테스트 프레임워크

이다.

예전의 나는 '아 그냥 잘 아는 REST API를 이용해야지'라고 생각했을 것이다. (분명히!)

그러나 나는 '검색 조건이 매우 다양한데, 해당 조건마다 API를 만들어야 하나??', '더 나은 방법이 없을 까?'라는 생각을 할수 있게 되었고 'GraphQL이라는 새로운 기술을 도입해야 겠다'라는 생각까지 하고 실제로 적용했다.

실제로 새로운 기술을 도입하며 동작하는 걸 보면 너무 재밌고 흥미로웠다. (살짝 흥분되었다.)

jest를 통한 목테스팅도 그러하다. 이번엔 팀원인 갓태희형이 목테스트에 대하여 강의 해주셔서 어느 정도 이해할 수 있게 되었고, 적용할 수 있게 되었다.

새로운 기술을 배우는 것은 너무 재밌는 일이고, 흥분되는 일인 것 같다. 실제로 적용하여 동작된다면 너무 기분 좋다.

결론

• 팀원과 소통을 원활히 하자!!
• 상대방의 의견을 잘 듣자. 고집 부리지 말자!
• 새로운 기술에 대한 두려움이 없어지고있다!! 너무 좋다.
• 고민은 행복한것, 팀원과 서로의 개발 고민을 얘기하며 좋은 소프트웨어를 만들자!!!