본문 바로가기

분류 전체보기

 (23)
gfs 보호되어 있는 글입니다.
모헤윰 mo:heyum - 프로젝트 회고 부스트캠프의 최종 팀 프로젝트로 나는 모헤윰이라는 SNS를 만들었다. 결과물은 꽤 괜찮다. [여기]에 간단한 시연 영상이 있다. 사실 팀 구인을 하던 때부터 나는 무엇을 만드는지는 크게 중요하지 않았다. 여태까지의 학습 스프린트로 이미 개발이라는 과정은 어느정도 감을 익혔고, 내가 성장함에 따라 이 과정에서 사용하는 기술만 조금씩 변화할 뿐이라고 생각했다. 따라서 내가 팀 프로젝트에서 가장 중요하게 생각했던 포인트는 협업이었다. 오랜만에 진지한 글을 써보려고 한다. 주제는 모헤윰 협업 회고 정도가 될 것 같다. 첫 협업이라 아쉬운 부분이 많았어서 문제점만을 적었지만 모헤윰은 절대 실패한 프로젝트가 아니다. 모헤윰은 유저의 가입 → 서비스 이용 → 탈퇴까지 완전한 유저 시나리오를 구현하였으며, 컨테이너화를..
12월의 세 번째 회고 (Final 6/6) 이거 왜 끝나는거냐 ㄹㅇ 버그아님? 누가 빨리 고쳐 ※ 이 글은 마크다운을 지원하는 SNS, 모헤윰에서도 볼 수 있습니다. [링크] 나는 얼마나 달라졌을까? 마스터 클래스에서 마스터님이 부스트캠프 전과 후의 내가 어떻게 다른지 비교해 보라는 이야기를 하셨다. 글쎄.. 뭔가 변한 게 있을까? 이것에 대한 내용을 몇 번 씩 쓰고 지우길 반복했다. 분명 많이 변한 것 같은데 말로 표현이 잘 안 된다. 가장 확실하게 이야기 할 수 있는 변화는, 주변 친구들이 사람이 많이 밝아 졌단다. 뭔가 정량적으로 말할 수 있는 변화가 더 있을까? 그냥 원래는 공부 하는 법을 몰랐는데 부캠이 아니라면 평생 말도 못 섞었을 훌륭하신 분들과 함께 공부하면서 어떻게 공부를 해야 좋을지 조금은 알게 되었다. 챌린지 첫 조에서 만난 ..
12월의 두 번째 회고 (Final 5/6) 아니 날씨 비정상적으로 추운 버그 좀 수정해!!!!!!!!! 바빠도 팬미팅은 가야지 누군가 후기를 꼭 쓰라고 해서 쓰려다가 말았는데 저번 주에 아주 큰 일이 있었다. 마스터님이 저녁밥 모임을 개최하셨다. 헉.. 헉..! 순간적으로 엄청난 속도로 머리를 굴렸다. 서울 서쪽에서 금요일 저녁을 먹으려면 언제 미리 가서 어떻게 있어야 하지? 모르겠다. 서울 서쪽이나 동쪽이나 다 서울인데 못 갈 곳이 어딨겠어 하고 그냥 신청은 해버리고, 잊어버렸다. 왜냐면 잊어버리면 당첨이 되기 때문이다. 금요일은 하루 종일 줌으로 이야기를 해야 하는 날이어서, 아무 카페에서 노트북 펴고 있기는 조금 어려웠다. 급하게 스터디 카페를 찾았고 운 좋게도 아주 싼 가격에 자리를 빌릴 수 있었다. 스터디 카페를 처음 가보는 거였는데, ..
12월의 첫 번째 회고 (Final 4/6) 벌써 부캠이 끝나간다는 느낌을 받았다. 2주 남았다.. 이제 다들 취업 이야기를 하는데 나는 사실 '부캠이 끝나고 사회에 나가는' 상황에 대해 생각해 본 적이 없다. 어쩌면 좋지? 나를 돈 주고 쓰는 기업이 있다고? 그거 사기 아니냐..? 결전을 준비하는 주인공(아닙니다) 부캠은 풀스택 개발자를 키우는 곳이다. 언젠가 회고에서 아 이거 해줘 하고 자고 일어나면 모락모락 김이나는 백엔드가 쪄서 나왔으면 좋겠다~ 이런 소리를 한 적이 있었는데 사실 그러면 안된다. 모두가 백엔드, 프론드엔드 가리지 않고 역량을 쌓을 기회가 있어야 한다고 생각해서, 우리 팀은 매 주 FE, BE 작업 인원을 한 명씩 교환하면서 프로젝트를 진행하는 룰이 있다. 팀에서 느릿느릿 티스푼공사를 하는 나를 배려해 나는 3주차에 백엔드에..
11월의 마지막 회고(Final 3/6) ㄴ..나는 왜..왜이렇게 ㅁ..말을 ㅂ..버벅여 일주일이 너무 정신 없어서 월요일에 뭐가 있었는지 기억이 안나네 확장성을 고려한 설계 vs 주제넘는 욕심 팀원들의 깊은 배려 끝에 나는 이번 주에 거의 온전히 에디터 구현에 집중할 수 있었다. 이전부터 너무 고대해왔던 일이라 너무 신났는데, 역시 내가 하는 모든 코딩이 그렇듯 일이 술술 풀리지는 않았다. 에디터를 직접 구현하기 위해 div 태그에 contenteditable 속성을 넣어서 구현했는데, 굳이 input이나 textarea를 쓰지 않은 이유는 혹시 나중에 syntax highlighting을 구현할 기회가 있을까? 하는 생각에서였다. textarea가 지젼 못생겼다는 부차적인 이유도 있었지만.. 하지만 그 댓가가 너무 컸다. 우선 input, ..
11월의 두 번째 회고 (Final 2/6) 일주일 고작 7일로 설계한 사람 누구야 당장 개선해 안그러면 나 진짜로 죽어 삐걱삐걱삐걱삐걱삐걱삐걱 기다리고 기다리던 개발주간이다. 너무 고통스러운 기획과 디자인을 버티며 이 날 만을 기다려왔는데.. 온 사방에서 문제가 터졌다. 나름 코딩하면서 겪을만한 코딩 스타일의 차이를 대부분 그라운드 룰로 잡았다고 생각했는데, 우리가 대체 뭘 정했나 싶을 정도로 문제가 많았다. 이미 정해서 정한 대로 이행한 부분도 막상 해 보니 이건 좀 아닌듯? 하고 수정을 반복했고, 그 과정에서 너무나도 당연하게 지저분한 레포지토리가 되어버렸다. 우선 백로그 단위 자체를 너무 잘못 짰나 싶은 생각이 들었다. 하나의 백로그를 여러 개의 이슈로 분할해야 하는 때도 있었고, 그렇게 분할한 각각의 이슈도 task 크기가 천차만별로 달랐..
Redux vs Recoil 사용해 봅시다 팀 프로젝트 학습정리를 위해 노션에서 작성해서 존댓말인데, 티스토리로 옮기니까 아주 골치가 아프다. 원본 링크가 있는데 여기서 보면 조금 더 보기 편하대요..! 🤷 TL;DR Redux는 안정적이지만, 선언과 사용이 복잡하다. Recoil은 사용이 매우 쉽지만 정식 버전이 없다. 프로젝트 규모에 따라 마음에 드는 라이브러리를 선택하자 🚪서론 우리는 React를 사용할 때 보통 useState를 통해 상태를 관리합니다. useState는 정말 섹시하지만, 한 가지 너무 큰 단점이 있습니다. 바로 컴포넌트끼리 데이터를 주고받는 데 사용하기가 힘들다는 점입니다. 그 일을 하기 위해 등장한 것이 바로 상태 관리 라이브러리입니다. 상태 관리 라이브러리의 필요성에 대해 공감하지 못하는 분들을 위해 짧은 예시를 마련..

티스토리툴바