itisjustK
코딩과 사람 사는 이야기
itisjustK
전체 방문자
오늘
어제
  • 분류 전체보기 (207)
    • 일이삼사오육칠팔구십일이삼사오육칠팔구십일이삼사오육칠.. (0)
    • Web (43)
      • html & css (9)
      • django & python (15)
      • java script (9)
    • iOS (51)
      • Swift (42)
      • SwiftUI (5)
    • CS (25)
      • 자료구조 (6)
      • 운영체제 (3)
      • 데이터베이스 (9)
      • 네트워크 (7)
    • PS (34)
      • 알고리즘 & 자료구조 (0)
    • Life (36)
    • Retrospective (15)
    • Book (1)

블로그 메뉴

  • 홈
  • 태그
  • 방명록

공지사항

인기 글

태그

  • mongodb
  • 킨디
  • 개발자
  • nosql
  • ios
  • 생활코딩 #이고잉 #HTML #코딩 #개발자
  • crud
  • 어플
  • SWIFT
  • 세그멘테이션
  • 독립서점
  • CoreData
  • AppleDevloperAcademy
  • POSTECH
  • 생활코딩
  • 연결리스트
  • binding
  • 점주
  • SwiftUI
  • CS

최근 댓글

최근 글

티스토리

hELLO · Designed By 정상우.
itisjustK

코딩과 사람 사는 이야기

[side project] alien-test : 외계인이 알려주는 나의 전생
Retrospective

[side project] alien-test : 외계인이 알려주는 나의 전생

2021. 9. 16. 22:23

http://alien-test.site

 

2학기 프로젝트 그리고 팀 빌딩

멋쟁이 사자처럼의 2학기는 프로젝트로 진행된다. 1학기때 배운 프로그래밍 개념을 토대로 서비스를 만들어보는 기간이다. 기간도 굉장히 길다. 2학기 내내 프로젝트를 진행하기 때문에 실질적인 서비스를 만들 수 있다. 

 

마음이 맞고 아이디어가 맞는 사람끼리 모여 팀 빌딩을 하였다. 나는 외국인에게 사투리를 알려주는 아이디어의 팀에 들어갔다. (내가 냈던 아이디어는 현실적으로 불가능한 사항이 많았다. 물론 의지를 가지고 도전할 수 있겠지만 현실적으로 남들이 이용하는 서비스를 만들어보자는 게 목표였다.) 그렇게 멋사 9기 4명 + 멋사 8기 출신의 운영진 1명. 총 5명이서 팀을 꾸리게 됐다.

 

사이드 프로젝트 ?!

운영진 출신의 친구가 프로젝트 개발에 들어가기 전 사이드 프로젝트를 하나 하고 가는 게 어떻냐는 의견을 냈다. 그 이유는 본 게임에 앞서 간단한 몸 풀기 정도의 서비스를 만들어보면서 전체적인 흐름을 맛 보고 들어가자는 취지였다. 협업에서의 github 사용법을 익히고, 피그마를 사용하고, 방학동안 잠시 휘발됐던 python, django 개념들을 다시 떠올릴 겸 해서 사이드 프로젝트를 하자는 것이었다. 

 

모두가 동의했고 우리는 각자 아이디어 1~3개씩 준비했다. 모두의 아이디어가 재밌었지만, 이 사이드 프로젝트의 목적은 '간단한 몸 풀기'였다. 본 게임에 들어갈 힘을 다 빼지 않으면서 개발 및 협업의 기능을 익히기에 가장 적당한 아이디어를 골랐는데, 요새 유행하는 mbti 검사처럼 테스트를 통해 결과를 도출하는 기획을 채택했다. 이름하여 '외계인이 알려주는 나의 전생'

노션에 각자의 아이디어를 기록했다

 

역할 분담

각자 원하는 역할을 얘기했다. 다행히도 백엔드 2명 프론트엔드 3명으로 적절히 나누어졌다. 나는 당연히 백엔드 포지션을 맡았다. 프론트엔드는 너무 어렵다. 백엔드는 그래도 정답이 있고 해결할 수 있다는 느낌이 강한데, 프론트엔드는 훌륭한 디자인을 위해 계속 노력해야 하기에 끝이 없는 것처럼 느껴졌다. 우리는 개발 기간을 최대 일주일로 잡고 개발 계획을 짰다.

대략의 개발 일정

 

백엔드 파트 : 테스트 로직 짜기 

프론트엔드 파트가 개발을 시작하기 전 백엔드가 기본적인 로직과 틀을 짜놓아야 했다. 그래서 ㅈㅎ이랑(나랑 같이 백엔드 맡은 친구의 이름을 편의상 ㅈㅎ이라고 하겠다) 같이 테스트 로직과 알고리즘을 구현해야 했다. 처음에는 어떻게 구현해야 할지 감이 안잡혔기에 유튜브와 구글을 통해 로직을 파악하고자 하였다. 그러나 대부분 유료 강의들이 많았고, 다행히 로직에 대해 알려주는 무료 강의가 있어 그것을 참고하였다. 

 

우리의 로직은 이러했다. 전생을 알려주는 데에 외계 지수 개념을 이용하였다. 총 10개의 질문과 각 질문당 4개의 선택지로 구성하고, 각 선택지에 1점에서 10점 사이의 배점을 부여하였다. 10개의 모든 질문지를 선택하면 총점이 최소 10점에서 100점이 된다. 이 총점을 가져와서 if문을 통해 구간을 나누고 구간에 걸리는 결과 페이지를 띄우는 것이다.

 

models.py를 통해 질문과 답지와 배점을 담을 데이터를 구성하고 admin 페이지에서 등록해주었다. 질문 페이지를 하나 만들어서 모든 질문을 담고 10번 문항에서는 제출 버튼을 만들어 submit을 구현해주었다. 후에 프론트엔드 파트에서 js를 통해 페이징을 구현하여 사용자가 이용하기에는 한 페이지에 한 질문만 보이게 하였다. 이때 백엔드에서 ㅈㅎ이와 할 일을 나누었는데, ㅈㅎ이가 평일에 근로를 해서 먼저 로직을 짜주면 내가 다음날 실질적으로 구현하는 역할을 담당했다. 

 

ㅈㅎ이는 a 태그와 url을 통해서 views로 넘긴 뒤 점수를 합산?하는 로직을 짰는데, (사실 정확히 이해하지는 못했다) 내가 조금 수정했다. views.py에서 각 선택한 배점을 getlist를 통해 list에 담아주고 sum 함수를 통해 합산을 구하고 total_score에 넣어주었다. 하지만 문제가 생겼는데, 점수 합산이 안되고 결과 페이지에서 자꾸 total_score가 0이 되었다. 이 사이드 프로젝트에서 이것만 내내 고민하다가 하루를 쓴 것 같다. 결국에는 submit하는 과정에서 button이 아니라 input을 쓰니 합산이 되었다. 이 과정에서 내가 끊임없이 고민하고 마침내 구현을 성공했을 때의 쾌감을 느꼈고 그 순간이 머릿속에서 생생하다. 이때의 느낌을 글로 남기기도 하였다. (욕이 절로 나오기도 했다)

 

2021.09.03 - [코딩 공부 일지/django & python] - [Django] Form으로 checkbox의 value 전달을 위한 submit : button vs input

 

[Django] Form으로 checkbox의 value 전달을 위한 submit : button vs input

2학기 본격적인 프로젝트를 시작하기 전 다들 django를 상기시킬 겸 github으로 협업하는 것을 익힐 겸 간단한 사이드 프로젝트를 하기로 했다. 하지만 결코 간단하지가 않았다. 사실 그렇게 어려운

newwave.tistory.com

 

 

 

배포는 '배포 포기'의 줄임말

프론트엔드 파트까지 완성하고 배포할 시간이 다가왔다. 배포야 뭐 오타없이 자세한 블로그에 나와있는 대로만 하면 무사히 배포할 줄 알았다. 하지만 이는 굉장히 오만한 착각이었다. 우리는 aws를 이용해 배포를 하였는데 혹시 몰라 ㅈㅎ이와 나 둘 다 배포를 진행했다. 그러다 우리 로컬 파일에 계정의 인스턴스를 적어야하는 곳이 있었는데 그 곳까지 ㅈㅎ이가 먼저 진행해서 ㅈㅎ이 맥북으로 배포를 진행했다. 배포를 하는 과정이 굉장히 순탄치 못했다. ubuntu 문제, 인스턴스 문제, 보안 문제, url 문제, 권한 문제 등등 ... 이 과정에서 ㅈㅎ이가 정말 많은 수고를 해주었다. ㅈㅎ이가 혼자 집에서 배포를 열심히 해준 덕에 우리는 무사히 배포를 마칠 수 있었고, 도메인까지 사서 우리만의 테스트 페이지를 완성했다.

 

 

그래서 나는 무엇을 느꼈나

 

소통

소통, 소통, 소통, 소통, 소통 ... 10번 100번 강조해도 중요한 말이다. 어쨌든 서비스를 만들고 개발하는 과정에서 여러 사람이 각자 맡은 바를 할 수 밖에 없고, 이 과정에서 서로 얼마나 했는지, 어떤 생각으로 하는지, 무엇을 할 건지, 어디가 이상이 있는지, 우리는 또 뭘 해야 하는지 등을 알기 위해 소통을 해야 한다. 소통은 원활한 협업을 가능케하는 능력이다. 우리 팀의 목표까지 얼마나 남았고 각자 어느 위치까지 도달했고 무엇을 도와야 하며 당장 지금 뭘 해야 우리 팀이 앞으로 나아가는지를 알기 위해 소통을 잘 해야 한다. 그리고 이 소통을 잘 하기 위해 github과 피그마를 쓰는 것이다. 우리는 소통을 잘 했는가? 만약 부족한 점이 있었다면 어디가 부족했고 이를 보완하기 위해 무엇을 해야 하는가? 

 

탄탄한 기획

개발을 시작하기 앞서 기획이 탄탄해야 함을 느꼈다. 우리는 우리의 기획이 탄탄한 상황에서 시작한 게 아니었다. 시간이 촉박했던 것도 있었고 기획 플로우와 디자인 와이어프레임이 정해지기도 전에 개발에 들어갔다. 이때문에 중간에 방향이 틀어진 부분도 있다. 기반을 잘 다지지 못한 상황에서 개발에 들어가니 각자 개발 방향이 조금씩 달랐고 약간의 시간 낭비도 있을 뻔했다. 그리고 '우리 팀의 구성원 모두가 나와 같은 이미지를 그리면서 개발을 하는가'에 대한 의문도 들었다. 이런 오해를 방지하기 위해 기획을 탄탄히 해야 하고, 기능적으로는 직관적인 이해를 위해 피그마를 통해 기획 플로우와 디자인 와이어프레임을 먼저 만들고 개발을 시작해야겠다.

 

클린 코드

솔직해져보자. 내 코드가 깨끗한가? 가독성이 좋은가? 몇 달 뒤에 이 코드를 수정하기 위해 코드 창을 봤을 때 이해하기 쉬운가? 전혀 아니다. 죽었다 깨어나도 아니다. 나는 그저 어떻게든 이 서비스가 돌아가기만 하면 된다는 생각으로 코드를 짰다. 그러면 클린 코드가 무엇인가? 그래, 이 전에 가독성이 좋은 코드란 어떤 코든가? 이 궁금증을 해소하기 위해서는 클린 코드에 관한 책을 읽어야겠다. 개발의 속도가 붙으려면 처음부터 시간이 걸리더라도 클린 코드를 작성하는 것이 좋다고 한다. 사이드 프로젝트여서 망정이지, 만약에 몇 달간 진행되는 프로젝트에서 내 코드가 너무 더러워서 남은 물론이고 나조차도 며칠 뒤에 보면 알아먹을 수 없는 코드라면 무슨 사단이 나겠는가? 생각만 해도 끔찍하다. 다음 프로젝트때는 돌아가는 것은 물론이고 클린한 코드를 짜기 위해 노력하자. 이를 수행하기 위해 일주일마다 코드 리뷰하는 것도 좋은 방법 중에 하나다.

 

 

 

어쨌거나 저쨌거나 느낀 것이 하나라도 있는 사이드 프로젝트였다. 처음으로 누군가에게 '내가 만든 사이트야'라고 링크를 보낼 수 있는 사이트이기도 하다. 사이드 프로젝트를 먼저 해보자는 그 친구에게 정말 감사하다. 선견지명 오졌다리 오졌다. 

 

우리 팀의 이름인 '저잣거리를 떠도는 개'  영어론 DIS (doggies in the street)

 

 

 

 

저작자표시 (새창열림)

'Retrospective' 카테고리의 다른 글

독립서점 플랫폼 어플 '킨디' 제작 일지 (4) - 개발 시작 (Feat. 애자일, 스크럼, 칸반, PR 문화, 플래닝 포커)  (0) 2022.10.29
독립서점 플랫폼 어플 '킨디' 제작 일지 (3) - 기획 과정 (Feat. 유저 리서치, 페인 포인트)  (0) 2022.10.09
그간 일들을 정리하며  (0) 2022.05.05
Apple Developer Academy 합격 후기 (1) CV, Portfolio  (0) 2022.02.10
[Toy Project] Mily World  (0) 2021.07.01
    'Retrospective' 카테고리의 다른 글
    • 독립서점 플랫폼 어플 '킨디' 제작 일지 (3) - 기획 과정 (Feat. 유저 리서치, 페인 포인트)
    • 그간 일들을 정리하며
    • Apple Developer Academy 합격 후기 (1) CV, Portfolio
    • [Toy Project] Mily World
    itisjustK
    itisjustK

    티스토리툴바