[개발 회고록] 3월 1주차

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

2월 26일(일) : 오늘은 Off

오늘은 개발 쉬는 날이당 ~

 

2월 27일(월) : 혼란의 날

📜 Atties, 앞으로의 방향은?

아띠즈는 이제 끝이 난 것 같다. 노션 칸반보드 팀원들 최근 접속일이 3일 전이고, 이제 더 이상 PR이 올라오지 않는다. 지난주 목요일 날 회의를 진행하여 앞으로 추가 구현할 기능들에 대해 이야기를 나누었다. 시간이 시간이고, 상황이 상황인지라 이제 다들 프로젝트에 신경 쓸 여유가 없는 것 같다. 나 또한 이번주 목요일부터 개강하면 프로젝트에 투자하기 벅찬 상황이 될 것이다. 프로젝트 기간인 8주 동안 불탔고, 이제는 불이 꺼지고 재만이 남아 있다. 불을 다시 살리려면 연탄(시간적 여유)과 라이터(새로운 시작)가 필요하지만 이제는 둘 다 없다. 이제는 놓아줄 때가 된 것 같다. 이제는, 놓아주자. 

앞으로 그럼 종료된 Atties프로젝트를 어떻게 할 것인가. 추가 기능 구현은 백엔드에서 먼저 구현해 주어야 프런트에서 구현 가능한 부분이다. 흠. 그렇다면 지금까지의 기능들에서 프런트엔드에서 보완할 수 있는 점들을 일단 보완하도록 하자. 그리고, 경매와 홍보를 주기적으로 하여 운영은 계속하도록 하자. 이 운영이 상당히 큰 도움이 될 것이다.

 

그저께 구름톤 네트워킹에 가서 강연을 들었다. 한 팀은 구름톤이 끝나고 창업지원팀의 지원을 받아서 서비스를 운영하고 있다는 내용의 강연이었다. 정말 인상 깊게 들어서 '나도 이번에 만든 프로젝트를 바탕으로 창업해 볼까?'라는 생각을 하여 찾아보았다. '서강대학교 캠퍼스타운 창업팀'지원서를 쓱 훑어보았는데, 와.. 만만치 않다. 채워야 할 칸들도 어마무시했고, 질문 하나하나가 어마무시했다. '과연 내가 할 수 있을까'라는 막연한 두려움이 몰아친다.. 이제 다음 주면 또 개강인데.

일단, 그냥.. 두렵다. 작성한다고 하면 나와 기획자 두 명이서 작성하게 될 텐데.. 막막하다. 내가 글을 막 잘 쓰는 편도 아닌데 이런 걸 쓸 수 있을까?

기획자, 디자이너, 개발자 모두 의지가 있는 것 같다. 좀 전에도 디자이너가 '기획자와 함께 만나서 앞으로 운영 어떻게 할지 이야기하는 게 어떻냐'라고 이야기했다. 다들 의지가 있어 보인다. 해보자, 운영해 보자. 이렇게 버리긴 너무 아까운 서비스이다.

 

📜 TIL : 애자일 방법론

참고

애자일 방법론 : 유연성, 협업 및 고객 Needs 충족을 강조하는 프로젝트 관리 기법

• 변화하는 요구사항과 Task의 우선순위에 따라 지속적인 피드백과 빠른 조정이 가능한 Sprint 방식으로 수행됨
• 고객의 요구사항을 충족하는 High Quality 제품을 제공하기 위해 커뮤니케이션, 팀워크, 지속적인 개선을 지향
• 기존의 순차적인 프로세스(Waterfall 방식)의 약점을 보완하기 위해 등장
• 작지만 빠른 성과 + 점진적인 Progress 창출을 강조

대표적인 Agile 방법론

1. 스크럼 방식

• 데일리 스크럼, 스프린트 기획/리뷰, 스프린트 회고 등  스크럼 행사를 통해 협업하는 Product Owner, Scrum Master, Developer Team의 3가지 역할로 구성
• 목표 : 최대한 짧은 시간 내 고객의 요구 사항을 충족하는 고품질의 제품 제공

2. 칸반 보드

• 팀이 작업 흐름을 시각화하여 진행 중인 작업량을 제한

3. XP(Extream Programming) 방식

• 개발자, 고객 및 이해관계자 간의 협업의 중요성을 강조하는 SW
• 지속적인 테스트, 리팩토링 및 협업의 중요성 강조

4. Crystal 방식

• 변화하는 고객의 요구사항에 빠르게 대응하는 방식
• 지속적인 개선에 초점. 팀원은 정기적으로 자신의 업무 방식을 평가, 더 강력한 팀워크 -> 더 나은 프로젝트 결과로 이어짐

 

2월 28일(화)

📜 tailwind로 반응형 웹을 만들어보자

홀랑 프로젝트를 진행하는데, 맨 처음에는 모두 px을 사용하였다. px로 하니 뭔가 이상한 거다. 폰화면으로 볼 때랑 웹화면으로 볼 때랑 사이즈가 똑같다. 폰 화면에서 보면 글씨가 엄청 크게 보이는 것이다. 무언가 잘못된 걸 인지했지만, 일단 계속했다. 지난주 회의, 쟁이 '웹앱이면 반응형으로 해야 할 텐데 왜 rem 안 쓰고 px 쓰셨어요?'머리가 띵했다. 프로젝트 초반에, 이 점에 대해서 프런트엔드와 디자이너끼리 이야기할 때 논의 사항이 나왔다. 나도 rem으로 모두 교체해야 하나 생각하고 있었는데, 우리 프론트엔드 팀원이 '이미 px로 다 작업했는데 디자이너도 다 바꾸고 하면 힘드니 px로 계속해요'라고 해서 나도 그냥 px로 진행했다. 이때 내가 무조건 수용할 것이 아니라, 의문을 제기해서 고쳤어야 했다.

결국엔 px> rem변환기를 이용하여 px로 작업했던 것을 rem으로 교체해 주었다. VS Code 확장프로그램에 px to rem 프로그램이 있어 편하게 바꾸었다.

그런데 어제 또 이슈가 터졌다. 잼이 inner-height를 이용해서 최상위 컴포넌트에서 단위 지정을 해주면 모든 rem이 그 단위에 따른 다는 것이다. 맞아.. 그랬어. 이 걸 구름톤 때 잼 형이 다 담당해서 해줘서 나는 이러한 점들을 몰랐다. 같은 프로젝트인데도, 아는 것이 달랐다.

그에 관련된 토론의 현장.. https://github.com/swyg-goorm/client/pull/45

프런트엔드 팀원이 styled-component를 사용해서 px을 기존 px> rem 변환기를 이용한 변환(16px=1 rem)이 아닌, 10px=1 rem)으로 교체해서 PR을 올린 것이다. 내 입장에서는 너무 황당했다. 전에 16px=1 rem으로 하자 해서 모두 변환을 해놓았는데, 쟁 말의 말을 듣고, 쟁과의 논의만을 통해 모든 것을 바꿔버린 것이다. 그런데 또 팀원은 다른 작업을 해야 해서 더 이상 소통도 불가능한 상태였다. 말 그대로 답답했다. 

오늘 검색에 검색을 거듭하여 알아본 후 팀원과 이야기를 통해, styled-component를 이용하지 않고, global css에서 rem을 지정해주지 않는 방식으로 진행하기로 하였다.

px, rem 이런 기본적인 것들도 잊고 프로젝트를 진행하고 있었다니, 참 부끄러웠다. react-query, tailwind사용하면 뭐 해. css의 px과 rem의 차이점에 대해서도 명확히 모르는데. 오늘 한 번 더 기초부터 탄탄히 쌓는 것이 중요하다는 것을 느꼈다.

 

📜 창업? 내가 할 수 있을까

지난주에 끝난 Atties프로젝트의 기획자와 앞으로 경매 일정을 어떻게 할지, 그리고 운영을 어떻게 할 지에 대해 이야기를 나누었다. 그러던 중 창업을 하자는 이야기가 또 나왔다. 일단 지금 모집 중인 예비창업패키지를 지원해 보자는 이야기가 나왔다. 일단, 나와 기획자 두 명에서 이야기할 것이 아니라 팀원들 모두와 이야기해 보는 것이 중요하다고 생각했다. 그래서, 일단 팀원들에게 DM으로 '만약에 이 프로그램을 하게 된다면 할 의향이 있는지' 물었다. 그리고 어느 정도 인원이 추려지면 공지를 올려서 시간을 맞춰봐야겠다. 창업이라.. 정말 진귀한 경험이 될 것이다. 창업도 하고, 돈도 받고, 대표가 되는 것이다. 와우. 하고 싶다.

하나의 큰 제약사항이 있다. 다들 취준생이라는 점이다. 다들 취준생이어서 많은 시간을 투자할 여력이 없는 것이 현실이다. 흠 ,, 그리고 팀원 8명 중 2명은 이미 취업에 성공했다. 한 분은 이미 재직 중이시고, 한 분은 2주 후부터 근무 예정이라고 한다. 와우.. 취업 불경기라고들 하지만 취업할 사람들은 다들 취업하는구나. 이렇게 훌륭한 분들과 함께 프로젝트를 했었다니 참 영광이다.

 

3월 1일(수) 

📜 TIL : 자주 보는 개발 설계 패턴

참고

1. Factory Method : 인스턴스 생성 로직을 클라이언트에 노출하지 않고 인스턴스 생성 전용 클래스에서 인스턴스를 생성

2. Observer Pattern : 개체 간 다수 종속성을 정의하여 하나의 개체가 변경하면 모든 종속성이 자동으로 다른 객체들에게 통지되고 업데이트

3. Singleton Design Pattern : 클래스의 인스턴스화를 하나의 객체를 제한

4. Decorator Pattern : 객체에 추가 책임을 동적으로 부여. 기능 확장하기 위해 좀 더 유연한 대안 제공

 

📜 TIL : 개발자와 잡담

참고

잡담이 결국 개발 이야기로 바뀐다

• 잡담을 하다 보면 분위기도 풀리고, 가까워지면서 개발 공부는 얼마나 했는지, 개발 언어는 무엇을 사용하는지, 어떤 라이브러리가 좋은지 등등 이런 이야기들이 오고 간다.
• 그러다 시간이 지나 유대감이 좀 더 형성되면 서로 궁금한 것들을 물어보기 시작한다.
• 대화를 하며 크게 느끼는 게 '내가 머리로 이해하고 사용하는 것과 설명하는 것에는 큰 차이가 있다'는 것이다.

여러 생각들이 모이고 모여

• 많은 질문들과 생각들이 오긴다.

"저희 회사는 폴더 구조를 이렇게 해요. 다른 회사는 어때요?"

"요즘 타입스크립트를 공부 중인데 클래스 문법을 100프로 활용할 수 있네요!"

"회사에 프런트 개발자는 제가 처음이에요. 개발 환경은 어떻게 설정하시나요?"

"잘하는 프론트 개발자는 뭘까요? 무슨 일을 하나요?"

"일하는 방식이 비효율적인 것 같아요"

나를 알게 된다.

• 내가 아는 것을 설명해야 할 때도 있기에 나의 부족한 부분과 잘하는 부분을 알 수 있다. 즉, 내 현재 위치, 내 수준을 알 수 있다.
• 내가 잘하는 것을 아는 것은 여러 팀원들이 모여 하나의 목표를 바라보고 무엇을 해야 할지 고민하는 자리에서 내가 할 일을 빠르게 판단할 수 있다는 것을 의미한다.

팀원과 스터디를 할 때, 프로젝트를 할 때 그것에만 집중하지 말자. "잡담을 하자". 잡담을 해야 많은 이야기들이 오가고, 마침내 성장한다

 

📜 TIL : 코드 리뷰는 스포츠다

링크

• 코드리뷰 : 소프트웨어 개발에서 매우 중요한 역할 
  • 프로젝트 내 전체적인 코드 베이스의 품질을 일정 수준 이상으로 유지
  • 코드 작성 단계에서 미처 발견하지 못한 오류 검증
• 코드리뷰가 불편한 이유 3가지
  1. 자신의 코드가 비판을 받을 것에 대한 불안감
  2. 타인의 코드를 비판하는 것에 대한 불편함
  3. 코드리뷰에 소요되는 시간
• 코드 리뷰어와 리뷰이는 펜싱 경기에서 공격수와 수비수에 유사

리뷰이의 방어

: 약점을 노출하지 않아야 함

• 코드 컨벤션이 잘 지켜졌는지
• 논리적인 오류나 오타가 없는지
• 반복적인 작업을 하다 누락한 부분이 없는지
• 이전 PR에서 지적된 실수를 다시 한 번 반복하고 있지 않은지
• 사용이 권장되지 않는(deprecated) 구식 기능을 사용하고 있는지
• 코드의 시간 복잡도를 낮출 수 있는지
• 성능상 최적화 가능한 부분이 더 남아있지 않은지

+ 리뷰어가 미리 궁금해할 수 있는 부분까지 고려해 설명을 남김으로써 공격의 기회조차 주지 않는 것

선택에 대한 근거를 어느 정도 기억해 두는 것이 좋음 -> PR 본문, 커밋 메시지, 주석을 통해 남겨두기

& 스크린숏, 영상, 다이어그램을 쓸 수도 있음

선택에 대한 근거

• 변수나 함수에 왜 그러한 네이밍을 사용했는지
• 외부 프로젝트를 참고할 때, 어떤 점을 우선적으로 참고했는지
• 참고한 레퍼런스가 공신력이 있는지
• 선택한 라이브러리가 다른 라이브러리와 비교했을 때 어떤 장점이 있는지
• 내가 지금 수정하고 있는 코드에 대해서 기존에 논의된 히스토리가 있는지
• 만약 도움이 필요하다면, 지금까지 어떤 방법으로 디버깅을 시도했는지

리뷰어의 공격

: 상대방이 미처 고려하지 못한 약점을 찾아 공략

• 누락한 로직이나 오타, 오류가 있는지
• 기존 코드보다 더 나은 네이밍, 로직을 제안할 수 있는지
• 참고한 레퍼런스가 믿을 수 있는지
• 리뷰이가 선택에 대한 충분한 근거를 남기지 않은 부분이 있는지

만약에 리뷰어의 지식이 부족해 코드 리뷰를 하기 어려운 경우라면?

• 리뷰어가 리뷰이의 코드를 이애하기 위해 어떠한 노력을 했는지 자세하기 알려주기
  • "해당 부분의 코드가 이해가 안 되어서 찾아봣는데, 저희 프로젝트에서는 이러이러한 용도로 쓰고 있군요"
• 노력을 했음에도 이해가 안되면 직접 질문하기

리뷰어와 리뷰이의 예의

• 리뷰어는 코드의 문제점을 찾아냄과 동시에 친절하고 예의를 갖추며 텐션을 높이기 위해 의도적으로 노력해야 함
• 코드리뷰에서는 코드와 나를 분리하여 생각하는 것이 중요
• 정답이 없는 논쟁 -> 팀원 간의 합의된 규칙을 레퍼런스로 참조하여 대화를 진행 

 

3월 2일(목)

📜 TIL : 코드리뷰 in 뱅크샐러드 개발 문화

참고

Github과 비동기 커뮤니케이션

• 동기 커뮤니케이션(실시간 커뮤니케이션. ex 전화, 회의)에 반대되는 개념으로 '요청에 실시간으로 응답하거나, 응답을 요구하지 않는 커뮤니케이션'
• Jira, Slack, 메일

작은 PR 규칙

• 작은 PR 규칙 : 1개의 PR은 1,000라인을 넘을 수 없다
  • 고객 임팩트를 내는 부분에 있어 병목이 되지 않기 위해
• PR, Commit의 단위는 최소의 기능 단위로 세분화
• 테스트 코드는 제한 x

커뮤니케이션 비용을 줄이기 위한 Pn룰 

1. P1 : 꼭 반영해주세요(Request changes)
   • 중대한 오류. 리뷰어를 설득할 수 있어야 함
2. P2 : 적극적으로 고려해주세요(Request changes)
   
   • 수용할 수 없는 상황이라면 적합한 의견을 들어 토론
3. P3 : 웬만하면 반영해주세요(Comment)
   • 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나, 다음에 반영할 계획을 명시적으로 (Jira 티켓 등) 표현
4. P4 : 반영해도 좋고 넘어가도 좋습니다(Approve)
   • 아무런 의견 달지 않아도 됨. 해당 의견을 반영해도 좋을 지 고민 정도면 충분
5. P5 : 그냥 사소한 의견입니다(Approve)
   • 아무런 의견 달지 않아도 됨

리뷰 우선순위 판단을 돕는 D-n룰

1. D-0 : 긴급한 수정사항으로 바로 리뷰해주세요
2. D-N : Working Day를 기준으로 N일 이내에 리뷰해주세요
   • D-2 : 가장 많이 사용
   • D-3~5 : 중요도가 낮거나 일정이 여유 있는 경우 

📜 TIL : 코어 자바스크립트 스터디 회고

참고

1. 벌금

2. 책 스터디 -> 날짜별 읽는 챕터와 대략적인 진행 시간을 확실하게 적어두기

진행 방식 : 삼생볼펜 공부법 

• 시간제한을 두고 하는 것이 굉장히 중요
• 오늘 배운 내용을 다함께 정리하며 마무리

문서화 : 출석부 & 그날그날 내용 정리

매끄러운 진행 : 시작하기 전에 아이스브레이킹 & 약간의 잡담

결론

1. 책 스터디 -> 삼색볼펜 도입해 보기

2. 스터디 시작 전, 아이스브레이킹 & 잡담으로 워밍업

3. 매일매일 출석부와 배운 내용 문서화

 

📜 창업에 대한 마음은 일단 접어두자

최근 들어 창업에 대해 고민을 많이 했다. 나 스스로에게 '왜 창업을 하고 싶은가'라고 몇 번 물었지만, '취업을 위해'라는 대답으로 귀결되었다. 취업을 위해 창업을 한다라.. 참 역설적인 이야기이다. 나는 사실 창업이 아니라, 취업이 하고 싶었던 것이다. 

Atties 기획자 분이 '예비창업패키지' 이야기를 하며 팀원들과 다 같이 모여해 보는 것이 어떻겠느냐는 제안을 하였다. 나도 이 이야기에 창업을 한다면 상당히 '좋은 소재거리'가 될 생각에 좋다고 했다. 팀원들에게 1대 1 메시지를 보내 관심이 있는지 물어보았을 때는 다들 호의적인 반응이었다. 그러나 오프라인으로 회의를 진행하기 위해 약속을 잡으려 하자 다들 일이 있다고, 바쁘다는 말만 남기며 회피했다. 창업을 하기로 마음먹었을 때 우려했던 점이었다. 팀원들이 전부 취준생이라는 점이었다. 개발 공부하고 회사 지원서 넣느라 바빠죽겠는데 거기다가 생뚱맞게 창업을 한다고? 말이 안 되는 이야기이다. 

기획자도 디자이너도 처음에는 '앞으로의 운영', '창업'에 대한 이야기를 꺼냈지만 마지막은 '취준생이라서 확답을 못주겠다'는 이야기로 끝이 났다. 나도 사실 그렇게 창업이 하고 싶다는 생각이 큰 것도 아니고, 이번에 한 프로젝트의 소재(예술품)가 내 관심 소재도, 전문 분야도 아니다.

여기서 창업에 대한 마음은 접자. 일단, 개발에 집중하자.

개발자가 되어 살다가 참신한 소재 혹은 좋은 아이디어가 떠오르면, 그때 해도 늦지 않다.

 

3월 3일(금)

📜 인턴에 지원해 보자

인턴, 3학년 때 하려고 했다. 그러나 내가 지금 보고 있는 것은? 개발 동아리뿐이다. 지난 CMC, DND동아리를 비록 떨어졌지만, 지원하며 내가 어떤 점이 부족하고, 어떤 점을 채워야 하는지 배울 수 있는 좋은 경험이 되었다. 다수의 프로젝트 경험이 있고, 프로젝트를 운영해본 경험이 있는 나는 이제 인턴에 지원할 실력이 된 듯 하다. 인턴으로써 어떤 점이 부족하고, 앞으로 어떤 부분을 채워야 할 지 배울 수 있는 좋은 경험이 될 것이다. 그러니 '아, 떨어질 거 같은데. 내가 과연 될까?'라는 걱정 하지 말고 일단 지원해 보자. 

아까 우리 학교 출신 프런트엔드 개발자 '워니'님의 유튜브 영상을 봤다. "개발 경험을 쌓으면서 돈도 벌고 1석 2조". 와.. 머리를 띵 맞은 거 같았다. 내가 하고 있는 이 사이드 프로젝트를 회사에서 돈 받아가면서, 혹은 외주 받아서 돈 받으면서 한다고? 너무 최고의 조건이다. 지원해 보자, 지원할 동기가 충분히 생겼다.

동문의 프런트엔드 개발자가 상당히 의지가 되는 거 같다. 대학의 한계로 못할 거 같다는 걱정이 들 때마다 이 분들을 떠올린다. 대표적으로 워니 님과 임효성 님이 있다.

'지원서를 써볼까'라는 생각을 할 때마다 '내가 과연 학기와 인턴을 병행할 수 있을까'라는 의문이 든다. 사실상 불가능하긴 하다. 아직 아닌가.. 올해 여름방학 인턴을 노려볼까. 혹은 가볍게 할 수 있는 동아리를 노려볼까. 그게 맞는 거 같다. 1차 목표로, 다음 주부터 모집할 동아리에 가입하는 것으로 하자.

 

3월 4일(토)

📜 TIL : CS지식 - SaaS

한 줄 정리

• SaaS : 구글 미트, 웹사이트 노션처럼 별도의 설치 없이 웹에서 직접 사용할 수 있는 서비스
• Cookie vs Session
  • Cookie : 클라이언트에 저장하며, 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일. ex) 자동완성(id,pw,검색기록)
  • Session : 서버에 저장하며, 웹 브라우저를 닫으면 사라짐
• 스토리지 : BE가 이미지, 비디오, 음악, 문서를 가져오는 곳
• 프로그램 > 프로세스 > 스레드
  • 프로그램 : 파일이 젖아 장치에 저장되어 있지만 메모리에는 올라가지 않은 정적인 상태
  • 프로세스 : OS로부터 자원을 할당받은 작업의 단위
  • 스레드 : 프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위
• URL : scheme + Host + port + Path
• URI : URL + query string + Fragment

앞으로 TIL 필기는 노션에 할 것 같다. 그 주에 혹은 그 날에 무엇을 배웠는지 회고를 하기 위해 캡처하는 방식으로 TIL을  블로그에 작성은 계속 할 것이다. 복사-붙혀넣기 하기에는 노션과 Tistory블로그가 작성 형식이 다르고, 내가 한 번 더 손 봐야 하는 번거로움이 생긴다. 그래서 캡처로 올릴 것이다.

오랜만에 CS지식을 공부하는데, 재밌더라. 흥미롭더라. 이럴 때마다 내가 정말 개발자랑 맞다는 생각이 든다. 끊임없이 배우는 것이 지겹다기보다는 흥미롭고 매번 새롭다. 이 흥미가 끊기지 않아야 할 텐데. 그러기 위해서는 개발을 지겹게 만들지 않는 것이 중요할 것 같다.

 

 

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

일 

나는 항상 새로운 것을 시도했고, 배우고, 지식을 공유하고, 커뮤니티 활동에 적극적인 사람을 원했다.

• 나 또한 그런 사람이 되자. 항상 새로운 것을 시도하고, 배우고, 지식을 공유학, 커뮤니티 활동에 적극적인, 그런 사람이 되자.
• 이 중 내가 개장 부족하며 채우고 싶은 것은 커뮤니티 활동에 적극적인 부분인 것 같다. 일단 지금 하고 있는 프로젝트에서 가장 적극적인 사람이 되려고 노력하고, 커뮤니티 활동에도 적극적으로 참여하도록 하자.

목 

열정을 나타내는 것

1. Github 계정 : 지금처럼만 하면 됨. 1일 1커밋을 실천 중이다. 아주 굿.
2. 블로그 : 지금처럼만 하면 됨
3. 오픈 소스 활동 : 어떻게 하는지 찾아보기. 글, 유튜브 영상좀 찾아봐야지
4. 기술 커뮤니티나 사용자 그룹 활동 내역 : Okky? 링크도인?
5. 사이드 프로젝트 내용 : 잘하고 있음
6. 트위터 계정 : @gueit214, 새로 만든 트위터 계정이다. 프론트엔드 트위터도 자주 검색해보며 다양한 최신 정보 얻어보자
7. 좋아하는 기술서적 목록 : 서적을 다 읽고, 그 서적을 통해 어떤 점을 배웠는지 개발 서적은 개발 블로그에, 인문 서적은 일상 블로그에 적도록 하자. 그리고, 나만의 "책 후기 한 줄"을 적고, 닳도록 외우자. 그러면 내 책이 될 것이다.
8. 참석했거나 발표했던 컨퍼런스 : 컨퍼런스가 있다면 주저 하지 않고 참석하자. '내가 가서 뭔 말을 할 수 있을까?'걱정에 참여를 꺼려했던 적이 여럿 있었다. 내가 아직 제대로 된 컨퍼런스에 참여 해본 적이 없어서 생기는 당연한 현상이고, 컨퍼런스에 참여하며 배우는 것이다. 전부 경험이다.

금 

소프트웨어 장인은

1. 다른 사람에게 무엇을 하라고 명령하는 대신 다른 개발자들과 함께 앉아 페어 프로그래밍을 하면서 그들의 지식과 경험 열정을 나눈다.

2. 항상 소프트웨어에 대해서 이야기하고 자신의 자기 계발 활동을 다른 사람들과 공유하려 한다.

3. 방향을 제시하고 변화를 이끄는 데 두려움이 없다.

• 나 또한 내가 속한 팀에서 소프트웨어 장인이 되려 노력하자.

---

😊 3. 이번주를 돌아보며

🎖️ 이번 주 이룬 성과는?

1. 창업이라는 세계를 알아보았다. 창업 세계라는 계단에 올라가진 않았지만, 창업이라는 것이 어떤 거구나, 어떤 것들을 준비해야 하는 구나 알게 되었다. 아직 창업 할 여유는 없지만, 언젠가 시도해 볼 만한 충분한 가치가 있다고 생각한다.

2. 노션에서 내버려두고 있던 '개발 Memo'페이지를 활성화 시킴. 이 페이지를 모두가 들어와서 '이 사람은 이런 식으로 문서화 시키는구나' 느낄 수 있게, 떳떳하게 공개할 수 있게 깔끔하고 정확하게 작성하도록 하자.

3. TIL을 블로그에도 활성화 : 노션에 1번, 블로그에 TIL을 적으며 한 번 더 머리에 상기시켜주고 참 좋은 거 같다. 앞으로도 쭉 해야지.

4. 개발 관련된 것 뿐 아니라, 스터디 방식, 팀 문화에 대해 공부

 

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

x

 

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

1. 노션 '개발 Memo'에 필기 > 그 날 혹은 밀렸다면 그 주 마지막에 TIL로 블로그에 작성하기

2. 학업에도 집중하지만, 한 편으로는 지금 마무리 중인 프로젝트에도 놓치지 않고 집중하기

3. 다음 주부터 모집하게 될 동아리에 '꼭 붙는다'는 마인드로 지원서 열심히 작성하기

4. 새로온 책, '자바스크립트 코딩의 기술' 열심히 읽기