[AWS Winter Camp X SMWU] Check-bara 서비스 프로젝트 최종 회고

AWS Winter Camp에서 12월말~2월말까지 진행한 프로젝트 최종 회고!

Team Coffe-bara에 속하여 진행하였다.

COFFEE-BARA

 

 

서비스 기능과 아키텍처 소개

 

---

Plan : 하려고 했던 것, 목표

 

우선 가장 포괄적인 목표 == 프로젝트 경험 

• 나는 아직 확고한 전문 분야 (BE, FE, Data)가 없었기 때문에
• 내가 어떤 분야에 맞는지 적성을 점검해보고 최대한 다양한 경험을 해보고 싶었다

그래서 처음에 팀 구성해서 들어갈 때

"뭐든 시켜만 주세요. (어차피 다 처음부터 배워서 해야하니까...)" 라고 했음

 

하지만 개인적으로 맡고 싶었던 분야는 아무래도 Infra

클라우드 서버 연결하고 시스템 아키텍처 짜고, 배포 하는 서비스들을 좀 더 효율적으로 활용해 보고 싶었다.

 

더 자세히는 AWS랑 도커를 더 잘 이해하고 싶었음.

(Elasticsearch이 중점이 된 플젝이긴 했지만... 검색엔진 클라우드라서 대단히 끌리진 않았다)

 

 

DO : 실제 한 것 

- 정량(기술&기능적인 면에서의 회고)

 

1. 기획 

근데 느낀 점 - 나는 창의적인 사람이 아니구나! 

기존에 있는 시스템에서 불편함이나 번거로움을 느껴서 좀 더 개선됐으면 하는 점을 기반으로만 아이디어 생각하고

이미 나쁘지 않은 시스템에서 이런 게 있으면 더 좋을 것 같은데? 싶은 창의성은 없었다

(이래서 기획팀이 있구나... 느낌)

 

 

2. 디자인

Figma의 두 번째 사용

첫 번째 사용할 때는 짧게 사용하기도 했고 디자인으로 참여한 게 아니라서 적당히 이용했었는데

이번에는 뷰 디자인을 많이 구성했기 때문에 피그마 활용에 익숙해졌다

 

그리고 피그마 쓰면서 있었던 이슈

• 피그마에 dev mode를 활용해서 FE 개발을 하려고 했으나
• 놀랍게도 프론트 개발 들어가는 2월 1일부터 프로만 사용하도록 유료로 바뀜
• 처음엔 framer라는 노코드툴을 사용하려 했으나 코드가 다 깨짐!

-> 그래서 anima라는 노코드툴을 사용해서, 피그마에 plugin연결해서 react 코드를 받아보았는데

 

Anima 사용후기 

- html/css만 참고하기엔 아주 굿인듯

- 하지만 리액트, js 참고하려면 별로

• 왜냐면 그냥 하드코딩임
• storybook같은 workflow확인할 수 있는 것 같은 게 있었는데 동작 안함
• 진짜 그냥 뷰를 코드로 바꿔놓음. 그래서 css는 정말 참고 많이 했다(하지만 react는 1도 참고할 수 없었음)

그리고 디자인을 구상할 때 느낀점

• 내 눈에 예쁜 게 남들에게도 예쁘지 않다
• 이건 내 초기 디자인이 내 맘엔 드는데 남들 맘엔 안들고 이런 문제가 아니라
• 주관적인 시야로 디자인을 하기보다 최신 디자인 동향/트렌드를 참고해서 만드는 게 확실히 좋다는 생각을 함!

최신 트렌드가 글레스모피즘/클레이모피즘

이라는 키워드를 가지고 디자인트렌드가 있다는 걸 다른 팀원이 알려줌

이 트렌드를 잡고 디자인을 하니 훨씬 수월하고 대중적으로 예쁜 디자인을 구성할 수 있었음

그래서 확실히 대중성있고 유행하는 게 예뻐보이는구나~ 도 느낌

 

3. 크롤링

Beautifulsoup을 활용해서 웹페이지 정보 크롤러를 만들었다

엄청 복잡한 크롤러는 아니었어서 오래 걸리진 않았는데 삽질!을 했는데

[web_crawling] span안에 text 가져오기

 

코드 짜면서의 어려움에서 오는 깨달음이라기보다

해결하는 방법에서 깨달음을 얻음

• 이런저런 방법을 시도해보고 도무지 원하는 결과가 받아와지지 않아서 data 파트 팀원에게 도움을 요청했는데
• 전혀 생각하지 못한 코드가 빠져있어서 (맥북 설정 관련) 그것만 추가해주면 되는 코드였다
• 기본적인 개념이나, 가져야 할 베이스 구조 같은 걸 먼저 공부하고 시작한 게 아니고 일단 고 해서 필요한 코드들을 누적누적 짠 거였기 때문에 기초적인 세팅을 몰랐다

그래서 여기서 느낀점

> 시니어 개발자들은 이래서 있구나 / 도움을 받는 게 중요하구나

> 기본 구조정도는 알고 짜자 / 일단 고는 삽질의 시간을 늘린다

 

잘한 점은

> 일단 내가 시도해 볼 수 있는 방법은 최대한 해보고 '이런 방법을 해보았는데 안된다, 그리고 어떤 문제가 있는지' 정확하게 질문한 점

두루뭉실하게 코드 보내고 안나와요~ 혹은 그냥 에러 나요~ 가 아니라

' ~~~에러가 나는데 ~~걸 시도 했는데 원하는 ~~ 결과가 안나온다'

라고 질문을 하니 문제를 빠르게 파악해서 더 원활한 해결이 가능했다

사실 이건 전에 한 번 통으로 몇 번 물어보고 깨우쳐서 항상 질문 형식을 이런 식으로 잘 하고 있다

(이런 게 성장...)

 

그리고 data 분야와 관련하여 느낀 점

• 나는 데이터를 가져와서 '분석' 까지 하는 것에 대한 흥미는 딱히 없는 느낌?
• 이런 것까지 분석해??? 에서 이런 것까지 해야 구체적인 결과나 수치를 얻을 수 있는데
• 나는 그정도로 한 데이터에 대해 깊게 파고들고픈 원함이 없음
• 내가 원하는 결과만 얻고 끝내도 만족하는 느낌

 

4. BE - API 개발

Elasticsearch 연결해서 django로 검색엔진을 개발했다

 

그런데 정말정말 수많은 삽질을 했음

 

아쉬운 점

- 아무래도 api 개발을 해본적이 없으니까, 레퍼런스를 찾아봤을 때 검색엔진이라서 다들 django로 많이 연결해서 개발해서 나도 그대로 따라갔는데 좀 더 성능 좋은 개발 언어를 활용해 보면 좋겠다! 는 아쉬움 -> 추후 성능 개선을 위해서 다른 팀원분이  Go로 수정해주셨다. 그래서 나도 ... 그걸 미리 했더라면 하는 아쉬움

- 도커로 이미지 만들어서 연결에 대한 효율성을 높이고 팠는데, 정확히 어떤 시스템 구성으로 연결되어있는지 파악하지 못해서 단순한 연결로만 구축했다. 이건 너무너무 아쉽다!! 도커를 잘 활용하고 싶었는데 일단 빨리 연결해야되니까 빼버렸는데 근데 docker파일... 올라가 있긴 한데 아직도 정확한 연결에 대한 이해가 부족한 게 느껴진다.

(알면 분발해라... 공부해야지)

- 크롤러랑 마찬가지로 나는 django도 첨 써봐서 일단 고. 레퍼런스들을 굉장히 많이 참고해서 필요한 코드를 구성했는데 장고 각각의 파일들이 어떤 역할을 하는지 개발하면서 알아갔다.

• 장점: 개발을 진행하면서 파악하기 때문에 어떤 파일이 어떤 역할을 하는지 습득은 빨리 할 수 있음. 
• 단점: 어떤 역할인지 미리 알면 에러가 났을 때 어느 파일을 수정해야 하는지를 빨리 알 수 있는데 그걸 모르니까 어디서 어떤 코드를 어떻게 해결해야 하는지 찾는 게 너무 오래 걸림 ㅋㅋ 
• 얘도 마찬가지로 시스템 연결에 대한 이해가 부족한 상태로 시작해서 에러 해결할 때 더 헤맸다

 

그리고 API 개발하면서 전체적으로 느낀점

- BE 개발 나쁘지 않다. 

- 그리고 학교에서 배우는 코테 문제같은 알고리즘 문제나 매우 간단한 동작만 하는 프로그램 코드만 짜다가 실제 서비스에 활용되는 개발을 해보니까 훨씬 짜는 게 재밌고, 왜 사람들이 개발 배울 때 일단 서비스 만들어보라고 하는지 체감됐다. 삽질하면서 배우는 게 많다는 것도 있긴한데 흥미를 붙일 수 있는 가장 좋은 커리큘럼인 것 같다.

- 포스트맨이랑 로컬에서랑 쿼리 날려서 확인했었는데 도파민 뿜뿜 행위임. 원하는 결과가 나왔을 때의 희열...

 

 

5. FE 

대망의 프론트 ㅋㅋㅋ

내가 프론트를 가장 많이 맡게 됐는데,

아무래도 규모가 크지 않은 토이플젝의 경우는 프론트가 많을수록 좋다는 사실을 익히 알고 있기는 했으나

 

프로젝트 내부 이슈 사담을 하자면

원래 5명이었는데 프론트 담당이었던 팀원이 빠져서

프론트를 나와 다른 팀원이 도맡게 되었음

 

뭐 나는 플젝 시작할 때 내가 프론트를 하려나 싶기는 했는데 (전에 알고 있던 사실에 기반해서)

근데 이렇게 많이 맡게 될줄은 몰랐다 ^^;;

이런 기능들의 프론트를 구현했다

 

알게된 점

- yarn / npm 같이 안쓴다. 이런 패키지 라이브러리에 대한 이해가 없다보니 에러 서치하다가 설치해야된다고 뜨는거 그냥 npm install 하든 yarn add 하든 막 했는데 , 이러면 안되는 거였다. 패키지 꼬일 수도 있다함. 다행인지 아니면 원래 잘 안 그러는건지 실행할 때 문제는 없었다.

- typescript랑 javascript의 차이도 배웠다 (type지정)

 

전체적으로 느낀 점

- 나는 프론트는 안맞는구나

- 코딩이라는 걸 처음 알게 됐을 때 html을 사용해서 웹사이트 구축해보고 올려보는 걸 했을 때는 css 만지면서 옆에 바로바로 보이고 조절하는 게 나쁘지 않았는데 코드에서는 정말 사소한 순서나 옵션으로 너무 많이 바뀌고 자잘하게 조절을 많이 해줘야되니까(return에서 div 값 넣어줄 때 코드줄 순서에 따라서 바뀌는 것 같은...) 굉장히 답답했다

- 바로바로 결과물이 보이는 거에 대한 성취도 딱히 크지 않았던 것 같다(물론 내가 원하는대로 딱 나오면 기쁘지. 기쁜데, 백엔드 쿼리문 잘 받아올 때만큼 기쁘지 않음)(이런 사소한 내 감정도 재밌어하는 분야에 대한 내 적성과 관련이 분명 있으니 적어본다...)

- 주먹구구식 코딩을 한 건 맞는데 주먹구구식으로 돌아가는 게 느껴져서 맘에 안들었던 것 같다

- components를 어떻게 나누는지에 따라 코드 효율성이 달라지는 것 같다. 세분화를 잘 하는 게 중요하다는 것도 느낌

- 원하는 기능을 원하는 컴포넌트에 선택하면 리액트 코드를 짜주는 노코드 툴이 더욱 더 발전했으면 좋겠다는 생각을 많이 했다

 

리액트랑 js도 당연히 처음해봤고 기초 문법이나 구성에 대한 지식 없이 시작해서

내가 만들려는 기능에 대한 레퍼런스를 상당히 많이 찾아봤는데

 

• 검색 기능
  • react말고 그냥 js랑 html로 연결한 게 가장 원하는 거랑 비슷해서 react jsx로 변환해서 많이 참고했다

 

• 챗봇 기능
  • 미리 사람들이 만들어놓은 패키지가 되게 많았는데 커스텀하는 게 더 어려워서 그냥 짰다
  • 챗봇 코드는 내가 짠 부분이 정말 적다 FE 개발자분에게 도움을 몹시몹시 많이 받음
  • atom이랑 recoil을 사용해서 잘 구축해주셨다 

 

• 전체적인 css
  • css는 로컬에 뷰 띄워놓고 열심히 하나하나 조절하면서 만졌는데
  • 얘도 그래도 효율적으로 겹치는 css 들은 import하는 파일에 모아서 하면 좋겠다는 생각?
  • 근데 또 이렇게 하면 뷰마다 다른 요소들에 영향을 받아서 바뀌는 경우가 많았어서 나는 그냥 나눠서 짰다

 

프론트... 그래도 사랑하시죠?

• 아니요 ㅎㅎ
• 리액트 연결하는 게 백엔드 로직만큼 어렵게 느껴지진 않았는데  그 로직을 생각하는 게 알고리즘이랑 내가 느끼기엔 달라서 고뇌의... 희열이 내게는 느껴지지 않는 느낌?
  • 왜 그럴까...API 개발할 때는... 큰 로직을 구축하기 위해 함수들을 연결 연결해서 하는건데 리액트는 작은 로직을 여러개 만드는 차이인가?

 

 

6. Git

몰랐던 점

- FE 할 때 노코드툴로 프론트를 짜서 각 뷰마다 전체 폴더가 하나씩 있었다, 그래서 그걸 FE 레포지토리에 있는 브랜치에 통째로 올렸는데, 아니었다 하하

- 그 브랜치가 쌓여서 (겹쳐서) 메인으로 머지 해야되는거니까 필요한 src/components랑 css 등 그런 것들을 합쳐야되는 거잖음 pull 받아서 그런 것 추가해서 branch마다 고것들을 다르게 해서 올리는 거였다는 것...

 

느낀 점

- 깃에 대한 두려움이 너무 컸다.

- 하지만 pr날리고 git에 push하고 기본적인 과정에는 익숙해져서 두려움을 떨칠 수 있었다.

 

 

See : 느낀점

- 정성(커뮤니케이션, 개선할 점의 회고)

• KPT
  • Keep: 프로젝트에서 만족했고, 앞으로의 업무에서 지속하고 싶은 부분
    • 데일리 스크럼을 글로 정리하여 하루 스케줄을 관리한 점
    • 주간 회고를 통해 팀원들과 좋았던 점/개선할 점/공유하고 싶은 내용을 나눈 점
    • 새로운 기술에 대한 열린 태도, 배우려는 자세
    • 협업 툴을 체계적으로 활용한 것(노션, 슬랙)
  • Problem: 프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던
    • 레퍼런스 참고하면 시야가 좁혀져 있음
  • Try: Problem에 대한 해결 방식으로 다음 프로젝트에서 시도해 볼 점
    • 나중에 프로젝트 할 때는 시작 전에 미리 목표를 구체적으로 설정하기
    • 이슈 쉐어링을 더 잘 할 것! 공유하면 다른 팀원이 방향을 잡아주거나, 쉽게 해결해줄 수 있는 이슈들이 생각보다 많다
    • 구현된 코드를 이해 못하는 것 같아서 싹 지우고 다시 짜본 타팀원의 방식 -> 그 로직에 대한 구현을 아니까 더 코드를 잘 짜게 해줌

 

그리고 팀원들과 함께 회고를 진행하면서 전달받은

나의 잘한 점과 개선할 점!

 

잘한 점, 배울 점

• 새로운 기술, 스택을 배우고 찾아보며 적용하려는 태도
• 처음 배우는 것에 대한 두려움이 없는 태도
• 기술 이야기 공유하는 태도
• 모르는 것에 대해 자주 물어보고, 질문하는 태도
• 아무리 힘든 것이라도 해야지... 하고 해내는 태도, 언니들에게 의지하지 않고 자신의 역량을 최대한 발휘하려고 노력하는 태도
• 끈기와 정신력, 부드러운 어투

 

개선할 점

• 너무 자신이 끝까지 하려고 해 매몰비용이 심함
  • --> 다음 프로젝트에서는 이슈 쉐어링을 구체적으로 어떤 에러가 있는지 어떤 기능 구현에 어려움을 겪는 건지 자주 공유하고 도움을 요청하는 태도를 적용해 봐야겠다!

---

 

회고를 마치며...

많은 것을 했다고 프로젝트가 끝난 당장은 느꼈었는데,

돌아보니 체계가 잡히지 않고 시작하는 나의 개발은 코드에 대한 이해도와 전문성을 깊이 기르기에는 부족했던 것 같다.

다음 프로젝트에서는 좀 더 코딩 잘하는 팀원이 되고싶다! 

그리고 함께 한 팀원들이 정말정말 좋았다. 마냥 개발을 잘하는 것에 그치는 게 아니라 인간적으로 다들 너무나 감사한 팀원들이었다.

다같이 열정을 가지고 참여해서 잘 마무리할 수 있었던 프로젝트였다.

 

나의 첫 프로젝트 끝 :D