[개발 회고록] 2월 4주차

💭 1. 이번 주엔 어떤 일들이 있었고, 그 속에서 나는 어떤 것을 느꼈을까

2월 19일(일) : Atties 배포 전 날, 마지막 오류 수정

2월 20일(월) : Atties 운영 & 정식 배포 시작 | 홀랑 프로젝트

📜 chatGPT 활용법

참고 링크

1. 코드 분석 : what the following code doing?
2. 코드 작성
3. 버그 및 에러 찾기 : can you check if there are possible bug for the code below?
4. 테스트 케이스 작성 : write 5 test cases for the previous mthod in JUnit format
5. 개발 문서 작성 : write a document to explain the method

키야.. chatGPT를 얼마나 유용하게 써먹느냐가 개발 실력을 판가름할 날이 머지않은 것 같다. 뒤처지지 않게 chatGPT를 애용하도록 하자

📜 애자일 스터디

참고 링크

1. 각자 읽기 → 삼색 볼펜법
   1. 20분 읽고, 그 이상 1인당 1번 씩 연장(5,10,15분 단위로) 가능
2. 빨간색으로 줄친 곳 한 줄씩 소리 내어 읽음
   1. 진행자가 그에 합집합을 구함
3. 파랑색, 초록색도 동일하게 확인
4. 전체에 대해 빨> 파> 초를 둘러봄
5. 이렇게 하면 총합 3번 읽은 셈

너무 좋은 스터디 방식인 거 같다. 전에 책 스터디를 진행한 적이 있는데, 모이는 시간 없이 '각자 정리'하는 방식으로 했었는데 마지막에 흐지부지하게 끝이 났다. 다음번에는 위 방식처럼 해보면 스터디의 의미가 깊어질 것 같다.

📜 NEXTSTEP Clean code

참고 링크

1. 인자 2개 이상인 함수는 비권장
2. import 순서 : eslint sort import plugin 사용하기
3. 페어 프로그래밍 해보기. 배워가는게 정말 많을 것임

2월 21일(화)

11:00 AM | Atties 기획자, 디자이너 회의

- 기획자, 디자이너와 프로젝트 개발을 마무리한 이 시점부터 앞으로 어떻게 운영해 나갈 지에 대해 이야기를 나누었다. 오늘(22일 오전 00:31분)까지 75명의 유저가 접속하였다. 그중 작가 전환 횟수는 4회, 작품 등록 횟수는 0이다. 예상은 했지만, 이 정도의 수치일 줄은 몰랐다.

그래서, 이번주 금요일 쯤에 팀원들과 이 프로젝트를 여기서 끝낼지, 다른 기획으로 바꿔서 할지 이야기할 생각이다. 기획자, 디자이너와의 회의에서는 "이 완성도 높은 서비스를 버리기는 아쉽기에 기획을 바꿔서라도 해보자"라고 했지만, 생각해 보니 그게 말이나 쉽지 생각보다 쉽지 않을 거 같다. 변수명이며, 페이지며 모든 것들이 지금의 기획에 맞게 개발이 되었는데. 그리고 개발자 분들도 다들 이제 각자의 삶으로 다시 돌아가서 시간 투자를 길게 못하고(최악의 경우 나 혼자 작업해야 할 수도), 기획을 바꾼다고 해서 100% 성공한다는 보장이 없다. 그래서 그저 포트폴리오용으로 이쯤에서 그만두는 것도 괜찮은 수인 거 같다. 목요일에서 금요일 날 회의를 잡아서 한 번 팀원들과 이야기를 나눠봐야겠다.

 

8:00 PM | 벚꽃 오프닝 회의

약 1달 만에 벚꽃 오프닝 프로젝트 팀원과 이야기를 나눴다. 1월에 늦게 들어온 팀원인데, 불만이 많이 쌓였던 것 같다. 충분히 이해를 한다. 그분이 들어온 이후로 내가 바빠져서 프로젝트에 신경을 너무 못 쓴 거 같아 죄송할 따름이다. 일단, 지금까지 한 것들을 마무리를 어떻게든 지어야겠다. 그래서 오늘 클라이언트는 배포를 마친 상태이다. Netlify를 이용하니 깃헙 연결만 하니까 바로 배포가 되더라. 

끝 매듭을 안 맺고 이렇게 흐지부지 끝나버리면 지금까지의 벚꽃 오프닝 프로젝트에서 작업했던 것들이 물거품이 된다. 물론 배운 것이 하나도 없는 것은 아니지만, 결과물이 있어야지 그래도. 마무리는 지어보자. '아띠즈'는 끝났으니, 이제 벚꽃오프닝에 집중을 해보자 그래.

우선순위를 이제 바꿔보자. 

 

11:00 PM | 홀랑 회의 

디자인 관련해서 이야기할 것들이 있다 하여 급하게 회의를 가졌다. 가로 사이즈 450px에 맞게 구현을 했지만, 모바일은 아이폰 12 pro 기준 390px, 작은 것은 360px인 것도 있어서 두 줄로 보여 디자인이 다르게 보일 수 있기 때문이다. 그래서 결론은 폰트 사이즈를 줄이거나, 일정 사이즈보다 작아지면 다음 줄로 넘어가도록 하기로 결정하였다. 웹으로 모바일 화면에 맞게 구현하는 것이라 고려해야 할 사항들이 상당히 많은 것 같다. 배포를 오늘 하였고, 빠른 시일 내에 피그마에 구현된 대로 퍼블리싱을 해보고, 화면 사이즈에 맞는지 이야기 나누며 조정을 해야 할 것 같다.

 

yarn berry?

어제 팀원과 이야기하다가 팀원이 'yarn cache가 뭐예요?' 물었는데 대답을 못하였다. 내가 사용하고 있는 환경인 yarn berry의 기초지식인데도 대답을 못한 것에 내가 아직 많이 부족함을 느꼈다. 

 

2월 22일(수) : 테오의 스프린트 1일 차

10:00 AM | 홀랑 회의(배포 오류)

갑작스레 FE팀원과 회의를 하였다. 작업을 완료해서 PR을 올렸는데 배포가 안 되는 거다. 그래서, dev branch에서 변경사항 없이 PR을 올렸는데 그것 또한 배포가 안되는 것이다. 분명히 어제 PR을 닫았을 때는 잘 배포가 되었었다. 

무엇이 문제일까? 어제까지는 배포가 왜 잘 되었던 거지.

2시간 동안 팀원과 BoilerPlate에서 src, public, package.json제외한 모든 파일을 교체해보기도 하고 여러 방법을 시도해 봤는데 결국 실패했다. 안될 이유가 없는데. 내 생각에는 그저께 팀원이 npm i로 PR 올린 것이 화근이 되었던 것 같다. 그때 npm관련된 의존성이 프로젝트 어딘가에 설치된 것 같다. 그에 따라 설치되어 있던 package-lock.json을 삭제했는데, package.json에도 무언가가 추가된 것일까? 지금까지 손 못 본 package.json을 손 봐바야겠다. 그래도 계속 배포가 안된다면, src와 public폴더 제외한 모든 파일을 새로 설치하여 시도해 봐야지.

 

2:00 PM | 벚꽃 오프닝 회의(앞으로의 계획)

이 또한 약 1달 만에, 이번에는 기획자 제외한 모든 팀원들이 모여 회의를 진행했다. 백엔드 팀원도 이번 주 안에 배포를 해주신다고 하셨고, 프런트엔드 팀원과 작업할 것들을 분류하고 분배했다. 거의 끝났으니 조금만 더 힘내보자 ㅜㅜ. 결실은 맺어야지.

긴 개발 기간임에도 다들 열정이 여전히 남아있어 다행이라 생각하고, 너무 감사했다. 한편으로는 그동안 다른 프로젝트 하느라 신경을 못써서 죄송했다. 이제 다 왔으니, 조금만 힘내보자. 추가 기능 구현 없이, 지금까지의 기능까지만 종합하여 마무리를 짓자. 그 이후는 그때 가서 생각해 보자.

'나에게 과하게 많은 프로젝트를 하고 있나'라는 의문이 될 때가 있다. 평균보다 많이 하고 있긴 하다. 그래도, 이제 하나는 끝이 났고, 하나는 끝났다. 거의 다 왔으니 앞으로 조금만 더 힘내보자. 

 

10:00 PM | 테오의 스프린트 

오늘은 테오의 스프린트를 진행했다. 순서는

1. 아이디에이션

2. 투표로 간추리기

테오 님이 각 아이디어마다 코멘트와, 이 부분은 어떻게 개선하고, 어떻게 이어나가면 좋을지 조언을 해주셨다. 너무너무 고맙고, 멋있었다.

3. 팀 짜기

4. Team Canvas

같은 아이디어를 선택한 사람끼리 팀이 매칭되었다. Team Canvas를 진행하는데 다들 너무 말이 없는 거다. 팀이 8명이었는데 2-3명 빼고는 말을 거의 안 했다. 사실 나도 말 안 하는 사람 중 한 명이었다. 나 때문에 힘들었을 거 안다. 나도 너무 미안하다.ㅜㅜ 

근데, 왜 이렇게 첫 말 꺼내는 게 쉽지가 않을까.. 실제였으면 보다 편하게 말했을 텐데, 온라인이다 보니 더 압박감이 드는 것 같다. 모두가 내 목소리에 집중할 것 같은..?

"첫마디가 쉽지, 그다음부터는 쉽다" "다들 텐션을 억지로 올리는 거다. 평소 그런 텐션이라 그런 건 절대 아니다."

말을 많이 하던 팀원들이 이야기해 준 말이다.

그리고, 한 팀원이 Team Canavs에 적어준 내용이다.

와, 너무 다 맞는 말이고, 내가 잘못된 것이 맞고, 고쳐야겠다는 생각을 한 번 더 느끼게 되었다. 고치자.. 이건 다른 게 아니라 틀린 거구나. 를 느꼈다.

팀과 평소에 필요한 말만, 프로젝트에 관련된 말만, 할 말만 했다. 잡담의 중요성을 느끼지 못했다. 잡담.. 앞으로 잡담을 즐겨해야겠다. 그리고, 텐션이 다들 원래 평소에 그렇게 높아서 높은 것이 아니다. 팀을 살리기 위해, 팀을 지속하기 위해 '노력'하는 거다. 그럼에도 나는 '노력'조차 하지 않았다.

앞으로는 '잡담'을 즐겨해야겠다. 그리고, 텐션을 '억지로' 올리자. 텐션 평소에 낮은 게 당연하다. 그러나, 사람과 사람이 만나기 위해서는, 분위기를 이끌어 나가기 위해서는 '올릴'필요가 있다. 연습하자. 부모님, 친구들, 팀원들과 대화할 때 하나하나씩 연습해 보는 거다. 

1. 텐션을 올리기 위해 최선을 다하자

2. 팀원 말 한마디에 한 마디씩 아무 말이라도 던지기

3. 잡담 습관화하기

 

2월 22일(수) : 테오의 스프린트 중도 하차

내가 너무 욕심이 많은 거 같다. 프로젝트 지금 하고 있는 게 3개나 되는데, 오늘 또 '테오의 스프린트'를 시작했다. 하루 2-3시간 싹만 밤에 투자하면 되는 줄 알았지만, 그전까지 해가야 할 것들도 있고, 하루 2-3시간 외에도 어느 정도 시간을 투자해야 할 것 같다. 그리고 투자한 만큼 배워가는 것이 많을 것이다. 그런데 나는 지금, 하고 있는 프로젝트가 너무 많다. 2개는 거의 끝나 가긴 하지만, 완전히 끝난 것이 절대 아니다. 그리고 1개는 이제 본격적으로 시작하려고 하고.

욕심 좀 줄이자. 테오의 스프린트는 오늘 양해를 구해서 하차하도록 해야겠다. 

오늘 사실, 밤 11시에 '홀랑'회의가 있었음에도 '테오의 스프린트'에 참여해야 해서 참여하지 못했다. 이건 내가 100번 잘못한 게 맞다. 내일 한 번 더 회의를 진행하기로 했다. 일단 그전까지 최대한 작업을 해놓고, 앞으로의 계획을 다시 세우기로 했으니 함께 잘 세워보며 의지를 다시 다져보도록 하자.

당분간, 프로젝트 마무리 하기 전까지는 "지금 하고 있는" 프로젝트에 최선을 다해야겠다.

 

2월 23일(목) 

10:00 AM | Atties : 앞으로의 계획

금일 회의 내용이다. "8주짜리 프로젝트에서 끝나면, 그저 8주 짜리 사이드 프로젝트에서 끝나게 된다. 그러나, 그 이상을 계속 운영 및 유지/보수한다면 그 이상 규모의 프로젝트가 될 수 있다"는 취지로 오늘 회의를 열어 보았다. 정해진 프로젝트 기간(8주)이 지났음에도 모든 사정이 생긴 한 분 제외한 여섯 명의 팀원이 모두 모여주었다. 

그리고 앞으로 구현할 추가 기능들을 다 같이 작성해 보았다. 지난 8주처럼 타이트하게 할 수는 없지만, 차차 기능 하나하나씩 구현해 나가다 보면 오류도 없고, 속도도 개선된 완성된 서비스에 다가갈 수 있지 않을까?

 

11:30 AM | 홀랑 : Netlify의 오류

어제 서버 배포가 안되었다. 그저께만 해도 잘 되던 버전도 배포가 안 되는 거다. 그래서 '이게 뭐지'싶었는데, 혹시나 싶었던 것이 맞았다. Netlify의 오류였다. 오늘 다시 깃헙을 보니 어제 올린 PR이 배포가 되어 있는 것이다. 그래서 팀원과 긴급하게 회의를 해서 추가적으로 앞으로의 계획을 세웠다.

 

5:00 PM | 홀랑 : 추가 회의

어제 '테오의 스프린트'참석하느라 회의 참여를 못했다. 어제는 프런트엔드 팀원이 모두 빠져서 오늘 다시 진행하였다. 팀원들에게 너무나 미안하고 고마웠다. 앞으로 더더욱 열심히 해야지. 오늘 정한 개발 기간에 맞게 개발을 좀 더 서둘러 봐야겠다.

기존 일정보다 모두 1주 앞당겨졌다. 기존 일정은 테스트가 없었어서, 이렇게 진행하는 게 맞는 거 같다. 사실, 페이지가 그렇게 많지 않아서 하루 이틀만 타이트하게 수행하면 충분히 가능한 부분이다. 금, 일요일에 힘들게 진행해 보자!

 

9:00 PM | 벚꽃오프닝 잠깐 회의

회원가입에서 500 오류가 떠서 팀원과 회의를 진행했다. 변수 하나가 빠진 것이었다. 나는 그런데 그러한 변수가 생긴지도 모르고 있었다. 소통이 너무 안되고 있었다는 것을 느꼈다. 앞으로는 소통을 더 활발히 해야겠다. PR확인도 대충대충 하지 말고!

 

2월 24일(금)

📜 안될 때는 천천히

어제부터 Swiper라이브러리를 사용하려는데 자꾸 화면에 잠깐 띄어지더니 사라지는 현상이 반복되었다. 어제 30분, 오늘 오전에 이것만 약 2시간은 붙잡고 있었다. 이번 프로젝트에서 처음 쓴 라이브러리를 제거해 보기도, 이전 프로젝트를 가져와 복사 및 붙여 넣기 해보기도, 다른 라이브러리(React-slick)를 도입해보기도 해 봤는데 다 안되는 거다. 머리가 아파왔다. '우리 프로젝트가 문제인가? 왜?'

마지막에, 'test'페이지를 만들어서 Swiper를 넣으니 되는거다. "유레카"를 외쳤다. 다른 페이지와 현재 이 페이지의 차이점은 바로, '상위 태그'였다. 그래서 확인해 본 결과, 최상단 태그에 'items-center'가 잡혀 있었다. 이걸 자식 태그가 상속받아서 적용되어 오류가 발생했던 것이다. 

오늘 이러한 착오를 절대 '시간 낭비'라 생각하지 않는다. 이런 오류들을 겪으며 배워 가는 것이다. 이런 오류들을 해결해 보며 노하우가 쌓이며 점점 '이런 상황에서는 이렇게 해결해야지'라는 대처 능력이 생기게 된다. 오늘 참 좋은 걸 배웠다고 생각한다. 오류가 났을 때는 다른 페이지, 혹은 다른 프로젝트에서도 동일 현상이 나타나는지 확인하자. 나타난다면 그 둘의 공통점이 무엇인지, 나타나지 않는다면 그 둘의 차이점은 무엇인지 생각해 보자. 어떤 문제든 해결할 수 있을 것이다.

 

📜 3D라이브러리 도입

이번에 하는 홀랑 프로젝트에서 3D이미지를 사용할 일이 생겨서 'three'라이브러리를 처음 써봤다. 처음 써봤는데, 생각했던 것보다 너무 단순하고 쉬웠다. 우리 팀원 중 한 명인 쟁이 바로 프로젝트에 적용할 수 있게 코드를 다 짜셔 준 것이다. 너무 고마웠다. 그런데, 우리 프로젝트에 적용이 바로 되지 않았다. 분명히 같은 모듈을 설치해서 똑같이 적용해 봤는데 안 되었다. 그래서 '왜 안 되지, 왜 안 되지' 고민하던 중, 결국 인터넷 검색을 했다. 오픈소스도 많아서 참고하는데 어렵지 않았다. 일단, 참고한 블로그에서 기본 틀부터 내 프로젝트에 도입해 보았다. 너무너무 쉬운 거다. 그냥 설치하고, 코드를 복사 및 붙여 넣기 하면 된다. 그럼 일단 베이스는 끝났다. 거기다가 내 입맛에 맞게 손 보면 된다. 내 이미지를 넣고 싶으면 넣으면 되고, 디자인을 수정하고 싶으면 수정 하면 된다. 

라이브러리를 내 프로젝트에 적용을 시킨 다음, 쟁이 만들어준 코드를 복사 및 붙여 넣기 했다. 그러니 된 것이다 ! 보니깐, 라이브러리에 차이가 있었따. 우리 둘의 차이점은 쟁은 'react-three-fiber'와 'drei'였고, 내가 사용한 '@react-three/fiber'와 '@react-three/drei'였다. '@'가 붙고 안붙고의 차이와 'react'가 붙고의 차이를 나는 아직도 모른다. 이런 기본 적인 것들도 모르고 코딩을 해왔다니. 이 참에 이러한 것들의 차이를 공부해야겠다.

 

이러한 오류들을 겪으며 라이브러리를 몇 번을 삭제했다가, 설치하고, 버전을 바꿔보기도 했다. 이런 적은 처음이다. 라이브러리를 한 번 설치하면 쭉 사용하기만 했지, 삭제하거나 변경한 적은 없었다. 전혀 어렵지 않다는 것을 느꼈고, 라이브러리 삭제 및 수정에 대한 거부감이 사라졌다. 그리고, 새로운 라이브러리에 대한 거부감이 모두 사라졌다. 

라이브러리 도입하는 법)

1. 설치한다

2. 코드를 복사 붙혀넣기 한다.

3. 입맛에 맞게 손본다

이게 전부다. 앞으로 다양하고 유용한 라이브러리를 많이 접해보도록 하자. ㅎㅎ

오늘 작업한 것들 ㅎㅎ

📜 Three Library

참고

• 웹 브라우저에서 3차원 컴퓨터 그래픽스 애니메이션 응용을 만들고 표현하기 위해 사용되는 자바스크립트 라이브러리이자 API
• Renderer , Scene , Camera 라는 핵심 객체들로 이루어짐
  • Renderer:  Scene과 Camera의 객체를 넘겨받아 카메라 안의 3D 씬의 일부를 2D 이미지로 렌더링
  • Scene : 다수의 Mesh , Light , group , Object3D가 트리구조로 쌓여있음
    • Mesh : 어떠한 Material 안에 하나의 geomatry를 그리는 객체인데, geometry는 기하학 객체의 정점 데이터라고 한다. 구, 정육면체, 면, 사람, 강아지 등등 다양한 것이 될수 있다. Three.js내에 기본적으로 built-in 되어있는 객체도 존재한다.
    • Material : 기하학 객체를 그리는데 사용하는 표면 속성으로, 색이나 밝기 등을 지정할 수 있다고 한다.
  • Camera : Scene 안에 포함할 수도 있고, 밖에 둘 수도 있다.

패키지 : three, @react-three/fiber, @react-three-drei

정육면체를 구현한 코드

import {OrbitControls} from '@react-three/drei';    

const Cube = () => {
    return(
    <div className="App">
      <Canvas>
        <OrbitControls/>
        <ambientLight intensity={0.5}/>
        <spotLight position={[10, 15, 10]} angle={0.3}/>
        <Mesh position={[0,0,0]}>
          <boxBufferGeometry attatch="geometry" />
          <meshLambertMaterial attatch="material" color="orange" />
        </Mesh>
      </Canvas>
    </div>
  );
};

 

 

📜 버전

Package : Major.Minor.Patch

• Major : 대규모 업데이트, 이전 버전과 호환 x
• Minor : 소규모 업데이트, 이전 버전과 호환 o. 기능 추가
• Patch : 버그 수정

📜 package.json

참고

• 숫자 : 무조건 명시된 숫자와 동일한 버전을 설치
• 부동호(>,>=,<=,<) : 해당 부등호 범위에 일치
• x : 숫자 대신 사용하여서, 어떤 숫자든 괜찮다
• lates : 가장 최신 버전을 설치하라
• ~ : 항상 최신 Patch 버전의 종속성 변경 허용
  • ex) ~1.3.2 : 1.3.8은 허용하지만 1.4.0은 허용 x
• ^ : 항상 최신 Minor 버전의 종속성 변경 허용. ~보다 여유 있음, 기본값
  • ex) ^1.4.2 : 1.5.2는 허용하지만 2.0.0은 허용 x
• devDependencies : development dependencies의 약자, 개발 모드 일 때만 의존
  • 실제로 배포할 때는 필요 없는 테스트 도구나 웹팩, 바벨같은 것들을 넣어둠
• peerDependencies : 직접 require은 하지 않지만, 호환되는 패키지의 목록
  • 주로 자기가 어떤 패키지의 플로그인 같은 개발할 때 사용

 

📜 yarn vs npm

yarn : npm(Node Package Manager)보다 속도, 안정성, 보완성을 개선시킴

참고

• 속도 : 패키지 데이터를 캐시하여 중복된 데이터를 다운로드 x, 캐시에 저장된 파일을 활용
• 안정성/보완성 : yarn.lock을 통해 모든 디바이스에 같은 패키지를 설치하는 것 보장

명령어

• yarn init
• yarn / yarn install
• yarn add package
• yarn global add package : 글로벌로 설치(로컬의 다른 프로젝트도 이 패키지 사용 가능)
• yarn remove
• yarn upgrade : 설치한 패키지들 업데이트
• npm dedupe : 중복 설치된 패키지 정리

 

📜 ngrok

ngrok ; 로컬 컴퓨터의 개발 환경을 인터넷으로 공유해 주는 툴

• 개발용 로컬 호스트를 tunneling을 통해 외부에서 연결

1. ngrok 설치 : yarn add ngrok

2. 서버 실행 : ngrok http 3000 (3000 포트에서 서버가 실행 중이라면

 

📜 FE 클린코드 - 반복문 회피

1. for < map, filter, some, every..

2. 에러 발생 시 반복을 멈출 수 없는 forEach보다는 for of 권장

 

📜 JS 프로처럼 쓰는 법

참고

1. nullish coalescing operator  :??

# nullish : 확실하게 null이거나 undefined이다

A?? B ; A값이 있다면 A, 없다면(null or undefined) B

 

2. logical OR operator : ||

A || B ; A값이 falsy인 경우에만(undefined, null, false,0,-0, NaN, '') 오른쪽 코드가 실행

 

3. object desctructing : {a, b} = obj

4. spread syntax :... array

5. optional chaining :?.

const title = person.job?.title??'No Job Yet';
// person.job이 있고 person.job.title이 있다면 그대로 사용 | 둘 중 하나라도 없다면 'No Job Yet'

 

 

2월 25일(토) : 구름톤 네트워킹

📜 html-to-image (참고)

📜 카카오톡 공유하기 (참고)

오늘 처음으로 위의 2개를 프로젝트에 직접 사용해 보았다. 각각 30분 컷 났다. 쉽더라.. 오픈소스가 이렇게 쉬울 줄이야. 요즘 이렇게 새로운 라이브러리와 오픈 API를 사용하는 게 너무나 즐겁고 흥미롭다. 하는 내내 지겹다는 생각보다는 '흥미롭다'라는 생각이 내 머릿속을 가득 채웠다. html to image는 너무나 쉬워서 막힌 부분이 없고, 카카오톡 공유하기는 env파일을 사용하는데에서 10분 정도 막혔다. env파일명을 내 마음대로 할 수 있는 줄 알았더니, 그게 아니었다. 변수명의 가장 앞부분을 NEXT_PUBLIC_API_이거로 시작해야 되더라.

정말, 개발의 세계는 무한하다는 것을 오늘 또 느꼈다. 계속해서 배우자, 지속적으로 성장하자.

오늘은 구름톤 네트워킹을 다녀왔다. 벌써 구름톤이 끝난지도 어느덧 3개월이 지났다. '프론트엔드'를 주제로 멘토와 다른 기수 멤버들과 이야기를 나누는 시간이 있었는데 "대체불가제가 되어야 하는가, 되면 안되는가"라는 심오한 주제가 나왔다. 너무나도 다들 말을 잘하셔서 나는 낄래야 낄 수가 없었다. 대화에 끼고 싶었지만, 이러한 주제에 대해서 생각해본 적이 없고 이렇게 심오한 주제에 대해 토론해본 적이 없었다. 이래서 책을 많이 읽고, 대화를 많이 해봐야 하나보다. 내가 두려워서 하지 못한 것도 맞지만, 해본 적이 없기에 못한 것도 있다. 한 번 더 '책을 많이 읽어야지'와 '심오한 주제에 대해서도 나눠봐야겠다'라는 생각을 하게 되었다.

강연도 듣고, 케이터링 식사도 하고, 멘토들과 다른 기수 멤버들과 다양한 이야기를 나누었다.

강연 중에 가장 인상 깊게 본 것은 "내 돈 안들이고 창업하기"였다. 2기 팀이었는데, 구름톤에서 만든 프로젝트를 끝나고도 계속 개발해서 창업지원금을 받으면서 창업을 했다는 거다. 너무나도 놀라웠다. 3박 4일이라는 짧은 시간 동안 만든 프로젝트를 살려서 창업까지 이어서 할 생각을 하고, 그걸 실천으로 옮기다니 너무나도 멋있었다. 마침 최근에 마무리 한 프로젝트를 어떻게 유지 및 보수를 할까 고민하던 찰나였는데, 반가운 이야기였다. "창업이다, 이거다"라는 생각을 했다. 발표하신 분과 함께 대화를 나누고 싶었지만, 네트워킹 때 찾지 못해서 대화를 나누지 못해  아쉬웠다.  

단백질만 챙겨먹귀,,ㅎ

 

너무나도 많은 것을 느끼고, 배울 수 있는 시간이었다. 이러한 자리와 시간을 만들어주셔서 구름과 카카오에게 감사합니다 :)

 

📚 2. 이번주의 개발 독서 : 소프트웨어 장인의 태도

일 

• 주기적으로 도끼날을 가는 시간은 낭비가 아니다. 그것이 바로 시간을 절약하고 끊임없이 빨리 움직일 수 있는 최선의 방법이다.
  • 맞아. 도끼날을 가는 시간은 절대 낭비가 아니다. 갈지 않은 도끼날로 10번 쳐야 끊어지는 나무를 간 나무로 1번 치면 끊어진다.
  • 그것처럼, 개발도 내 개발 실력을 갈고닦고, 아는 것이 풍부해지면 훨씬 더 간결하고 깔끔한 코드를 만들 수 있음을 기억하자.

화

• 리팩토링 : 엉망인 코드가 많을수록 엉망인 코드가 늘어나는 속도가 빨라진다. 이것 든 '깨진 유리창 법칙'으로도 알려져 있다. 지저분하고 엉망인 애플리케이션은 개발자들을 느리게 만들고 그로 인해 비즈니스도 느려진다.
  • 빨리 개발을 해야겠다고 변수 선언도 대충 하고, 하드코딩을 많이 해서 코드를 작성한 적이 있다. 작업이 적을 때는 문제가 없었는데 작업이 쌓이고 쌓이니, 그게 터지더라. 코드가 너무 길어서 건드리기 무서울 정도가 된 것이다. 처음부터 뿌리부터 곧게 내리고 줄기를 탄탄하게 지어야 좋은 열매가 열리는 법임을 기억하자.

목

• 어디로 가고 싶은지 커리어의 방향을 확신할 수 없을 때는 모든 문을 열어보기 시작해야 한다.
  1. 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고, 기술적 지식을 확장한다. 예를 들어 새로운 프로그램이 언어나 기술들을 배운다. => 항상 공부하던 JS, React로부터 벗어나 요즘 유행하는 스벨트, Vite도 한번 배워보자. 좋은 경험이 될 것이다.
  2. 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다. => 우리 지역 프런트엔드 개발자 커뮤니티가 있을까. 여유 있을 때 찾아봐야지
  3. 다른 개발자, 비즈니스맨들과 교류한다. => 이번 주에 있을 구름톤 네트워킹! 그리고, 개발 동아리에 가입해야 한다.
  4. 새롭게 배운 것, 지금 하고 있는 것들에 대해 블로깅 한다. => 굿. 잘하고 있다. 

금 

• ... 이어서
  1. 오픈 소스 프로젝트에 참여한다. => 이것도 한 번 알아봐야지. 시간 나면 해보자
  2. 프로젝트를 만들고 공개한다. => 굿. 잘하고 있다.
  3. 콘퍼런스에 참석한다. => 조금만 여유 생기면 콘퍼런스도 참석하자
  4. 콘퍼런스에서 연사로 나선다 => 아직 그럴 정도의 실력이..

---

😊 3. 이번주를 돌아보며

🎖️ 이번 주 이룬 성과는?

1. 다양한 라이브러리의 사용 및 도입

• 이번 주는 three, html-to-image, kakao API 등 다양한 API를 처음 써보았다. 이렇게 사용하기 쉽게 오픈소스와 자료가 많은 것을 알게 되었다. 앞으로 이런 새로운 라이브러리, 툴에 대해 거부감을 전혀 갖지 않아야겠다.

2. 선택과 집중

• 이번주 수요일부터 진행 예정이었던 '테오의 스프린트'. 아쉽지만, 팀원들에게는 정말 죄송하지만 지금 하고 있는 프로젝트들에 집중하기 위해 그만두었다. 잘한 선택이었던 것 같다. 아니, 애초에 신청을 하지 않고 팀을 짜지 않았어야 최선의 선택이긴 했다. 그래도 하루의 체험을 했고, 그동안 느낀 점들이 많았기에 좋은 경험이었다고 생각한다.

❤️‍🔥 이번 주의 아쉬움은?

x : 이번 주도 최선의 1주일을 살았던 것 같다.

🏃‍♂️ 다음 주의 목표는?

1. 지금 하고 있는 프로젝트 마무리 잘 끝내기

2. 다음 주는 개강주이다. 개강을 위한 준비를 하자. 

1. 강의평 보며 강의 별 학습법 정리
2. 각 과목 별 노션 페이지 만들기

3. 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고, 기술적 지식을 확장한다. 예를 들어 새로운 프로그램이 언어나 기술들을 배운다

4. 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다. 

5. 오픈 소스 프로젝트에 참여한다. 

회의 할 때)

1. 텐션을 올리기 위해 최선을 다하자. "텐션은 타고난 게 아니라 노력하는 것이다"

2. 팀원 말 한마디에 한 마디씩 아무 말이라도 던지기

3. 잡담 습관화하기. "잡담이 있어야 어떤 의견도 편하게 주고받을 수 있는 문화가 형성된다"