블로그

3주차 회고

일주일 간 학습했던 내용과 회고데브옵스 한방 정리스프린트2를 시작하기전에 전체적인 흐름과 연관관계를 알 수 있어서 좋았다!손쉽게 데브옵스 환경을 구축하는 방법강의와 네이버 카페를 보고 차근 차근 따라하니 할만했다. 카페를 보니 심지어 강의를 안 듣고 따라하는 사람도 있었는데 강사님이 댓글 다 달아주시는 것 보고 신기했다. 지식공유자라는 건 쉽지 않군요.배포를 시작하기 전에 반드시 알아야 할 것들실습이 없는 강의는 부담없이 들을 수 있지만 한편으로는 자꾸 기억이 희미해져서 다시 들어야겠다.Jenkins Pipeline (기초부터 Blue/Green 까지)지금까지 실습 따라하면서 어려움이 없었는데 여기서 좀 막혔다. connection refused 됐는데 docker ID인지 github ID인지 넣어서...잠결에 분명 해결한 것 같았지만 이미지 에러가 났고 아예 처음부터 다시 시도해봐야겠다.Helm과 Kustomize 비교하며 사용-1대부분 헬름을 쓴다고 해서 커스터마이즈는 안 배워도되려나 했는데 또 필요한 경우도 있다고 하니 열심히 따라함. 간단해서 오히려 좋아!  미션 관련미션을 해결하는 과정도커와 컨테이너d의 명령어 익히고 이미지 파일간 변환, 도커와 컨테이너d 이미지 사이즈 차이에 대한 이해미션 해결에 대한 간단한 회고도커와 컨테이너d 이미지 사이즈가 차이났을 때, 그 원인을 파악하는 3가지 단계가 좋았다. 그냥 바로 결론으로 진입하는 게 아니라 하나 하나 가정하고 확인하는 접근 방식이 좋았다. 나도 일을 할 때 그렇게 접근하고싶다. 다음주 학습 목표미뤄둔 복습 진행하기실습 중 잘 안된 부분 다시 시도블루 - 그린 배포 재도전
춘식

인프런 워밍업 클럽 4기 - DevOps 3주차 발자국

데브옵스 한방 정리, 손쉽게 데브옵스 환경을 구축하는 방법복습(내용 정리) - 링크 배포를 시작하기 전에 반드시 알아야 할 것들복습(내용 정리) - 링크 Jenkins Pipeline (기초부터 Blue/Green 까지)복습(내용 정리) - 링크 회고이번 주 강의에서는 데브옵스를 구성하는 핵심 요소들과 전체적인 흐름을 배우고, 그중 배포 관련 실습을 진행했다. 이 과정을 통해 개발자가 오직 개발에만 집중할 수 있는 환경을 만드는 것이 데브옵스의 중요한 역할임을 체감했고, 그 과정 자체가 더 흥미롭게 느껴졌다.또한 단순히 이론만 공부하는 것이 아니라, 계속 직접 테스트 환경을 구축하고 실습을 진행하다 보니 테스트에 대한 자신감도 생겼다. 환경 구성에 익숙해지면서, 앞으로 새로운 기술이나 툴을 접하더라도 빠르게 테스트해볼 수 있겠다는 확신이 들었다.
춘식

인프런 워밍업 클럽 4기 - DevOps 2주차 발자국

Application 기능으로 k8s 이해 - Probe, Configmap, secret, PV/PVC, Deployment복습(내용 정리) - 링크 Component 동작으로 k8s 이해 복습(내용 정리) - 링크 회고이번주 강의를 통해 쿠버네티스가 단순히 컨테이너를 띄우고 관리하는 도구가 아니라 서비스 안정성을 위해 얼마나 정교하게 설계된 시스템인지 깨달았다. 특히 각 오브젝트들이 단순히 역할만 나누어진게 아니라, 운영 자동화를 위해 유기적으로 연결되어 있다는 점이 인상 깊었다.그동안 쿠버네티스 오브젝트들의 개념은 알고 있었지만, 비슷한 기능을 수행하는 경우 정확히 어떤 차이가 있는지 자세히 알지 못했다. 이번 강의에서는 그 작은 차이와 실제 운영에서 자주 쓰이는 사례들을 볼 수 있어서 추상적인 개념이 아닌 구체적인 운영 시나리오 속에서 오브젝트들을 이해할 수 있었다.단순히 기능을 아는 것이 아니라 "왜 이 기능이 필요한가", 그리고 "어떤 상황에서 어떻게 써야 하는가"에 대한 감각이 생겼다는 점이다. 단순히 쿠버네티스를 쓰는 사람이 아니라, 쿠버네티스를 "잘" 쓰는 사람이 되기 위한 시작점에 서 있는 느낌이다. 앞으로는 단순히 YAML을 작성하는 게 아니라, 그 안에 담긴 의도와 운영 흐름까지 함께 고민하는 엔지니어가 되고 싶다.
Jenny

[워밍업 클럽 DevOps4기] 3주차

학습내용[복습]Section 8. Application 기능으로 k8s 이해Section 9. Application 기능으로 이해하기 - Configmap, SecretSection 10. Application 기능으로 k8s 이해 - PV/PVC, Deployment, Service, HPA [진도]Section9. Application 기능으로 k8s 이해 - Configmap, SecretSection 10. Application 기능으로 k8s 이해 - PV/PVC, Deployment, Service, HPASection 11. Component 동작으로 k8s 이해Section 13. 데브옵스 한방 정리 회고벌써 마지막주가 됐습니다.아직 배운 내용이 내것이라고 하기에는 부족한것 같습니다.우선 완주를 목표로 하고, 부족한 내용은 반복해서 보려고합니다.마지막까지 화이팅!

4주차 발자국 남기기

강의 수강일주일 동안 학습했던 내용을 요약해주세요.Helm과 Kustomize 비교하며 사용-2ArgoCD 빠르게 레벨업 1,2,3미션6 - Github 업데이트  일주일 간의 학습 내용에 대한 간단한 회고를 작성해 주세요.일주일 동안 스스로 칭찬하고 싶은 점, 아쉬웠던 점, 보완하고 싶은 점이 무엇인지 생각해 보세요.마지막 4주차 업무도 많았고, 복습에 미션에 할 내용은 많은데 조금 어려웠음ArgorCD의 고급기능?을 알게 되었다는 뿌듯함다음주에는 어떤 식으로 학습하겠다는 스스로의 목표를 세워봐도 좋아요.4주간 수업과 복습 미션에 대해 다시 정리하는 나만의 시간 계획을 작성 해 보아야 겠다미션미션을 해결하는 과정을 요약해 주세요. 강의 내용을 차근차근 따라하면 실습을 할 수 있었으나, 실제 미션 과정을 도움 없이 해보려고 하면 조금 난이도가 있었고, 이해 해야 하는 기능 들이 있어서 시간이 조금 걸렸음

[인프런 워밍업 클럽 4기] DevOps 발자국 4주차

이번 주는 워밍업 클럽의 마지막 주차였다. 주요 내용은 Helm과 Kustomize 그리고 ArgoCD 내용이다. 모두다 배포를 자동화하기 위한 tool들이고 목적에 따라 사용하면 된다. Helm과 Kustomize는 다양한 배포환경에 맞게 배포 자동화하는 목적이고 ArgoCD는 Blue/Green, Canary 배포 같이 안전한 배포, 배포 자동화를 하는데 목적을 두고 있다. 이렇게 쿠버네티스 생태계에 대해서 실습을 통해 약간은 알게 될 수 있는 시간이었고, 앞으로 내가 필요하다면 이런 옵션을 사용하면 되겠구나라고 알게되었다는데 큰 의의를 두고 있다.  사실 진짜 운영에서 활용을 하게 된다면 이것보다 더 많은 지식이 필요하고, 환경 설정에서도 나의 환경에 맞게 커스텀하는 것들이 중요할 것이라 생각한다. 새로운 것을 배우다보면 사용법에 대한 내용은 어디서나 얻을 수 있지만 제대로 활용하는 방법에 대해서는 항상 의문이 생긴다. 이번 강의를 통해서 어떻게 제대로 활용할지에 대해 약간은 깨달았으니 앞으로 필요할때 고려할 옵션이 늘어서 기분 좋게 생각한다.  워밍업 클럽을 끝내면서 마지막 한마디어떤 강의를 구매하더라도 항상 완강은 힘들었는데 일프로님과 스터디를 통해 완강하고 미약하지만 복습하려고 노력한 시간들이 지나고나니 뿌듯하게 느껴졌습니다.
이상현

[인프런 워밍업 클럽 4기] DevOps 발자국 4주차

[ 강의 정보 ]강의명 : 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 [ 워밍업 클럽 4주차 회고 ]벌써 스터디의 마지막 주를 달리고 있다. 한 달이라는 시간안에 주어진 과정을 따라가는게 쉽지 않을 거라 생각했으나, 처음 결심한 대로 잘 따라가지 못한게 아쉬운 마음이 먼저 든다. 이번 주차에서는 Kustomize와 Helm을 통한 배포 구성 관리 및 Argo CD를 통한 배포 전략을 살펴보았는데, 현업에서도 동일한 기술들을 도입하려는 생각을 하고있어 주의깊게 강의를 보아야 겠다고 생각했다. 그리고 현재하고 있는 고민들이 강의에서도 나오는 것을 보고 적절한 Best Practice를 적용하는 것이 중요하겠구나 생각되었다. 한 달동안 쿠버네티스의 동작 흐름부터 CI/CD를 통한 배포 자동화까지 하나의 큰 흐름을 배워가는 과정을 통해, 단순히 쿠버네티스 개념에 대해 배우는 것뿐만 아니라 운영을 위해서는 부가적인 기술들의 동작도 깊게 알아야 겠다는 생각도 하게 되었다.이번 스터디를 통해 100프로 열심히 했다고는 차마 스스로에게 할 수 없지만.. 스터디를 하기 전보다는 조금이나마 나아졌지 않을까 생각한다. 끝까지 빠진 내용들을 복습하며 채워나가야 겠다. 스터디 이후에도 정리한 내용들을 되새기며 나의 것으로 만들어나갈 수 있게 노력 하자!

Devops･Kubernetes

전민재

워밍업 스터디 4주차

강의배운내용은 다시 반복할때 더 잘 정리해서 효과적으로 사용하겠습니다.수업 내용과 자료와 미션들로 동작 원리를 이해하는데 많은 도움이 된 것 같습니다.스스로에게 많이 아쉽운 점도 있지만 남은 부트캠프도 2달반 후회 없이 보낼 수 있게 교훈 삼겠습니다. 미션미션 5~6 수행 과정 링크https://www.notion.so/ingjeon/1-6-207242bfe32b80fea2aaebd074be92c9미션을 하고 보니 따라 하기 급급했는데 정리한 내용으로 되집어 봐여겠습니다.하지만 전체적인 흐름과 동작에 대해 잘 배운 느낌이여서 좋았습니다.    

데브옵스 · 인프라･발자국

징니

인프런 워밍업 클럽 4기 BE 스터디 2주차

💻 강의Readable Code: 읽기 좋은 코드를 작성하는 사고법 📚 학습주석주석이 많다는 것은 비즈니스의 요구사항을 코드에 잘 못 녹였다는 것코드를 설명하는 주석은 코드가 아닌 주석에 의존한 것주석에 의존하여 코드를 작성하면 적절하지 않은 추상화 레벨을 갖게 돼 낮은 품질의 코드가 만들어질 수 있다언제 주석을 사용해야 할까?후대에 전해야 할 의사 결정의 히스토리를 코드로 표현할 수 없을 때 상세한 설명이 필요하기 때문에 이때 주석이 필요하다 주석 작성주석을 작성할 때, 자주 변하는 정보는 지양한다코드가 변경되면 주석도 같이 업데이트 해야 하기 때문에 주석이 없는 코드보다 부정확한 주석이 달린 코드가 더 치명적이다좋은 주석최대한 코드에 녹여내고, 코드로 표현 못하는 정보를 전달해야 할 때 주석을 사용한다예외 검증 테스트 코드assertThatThrownByisInstanceOfhasMessageassertThatThrownBy(() -> cafeKiosk.add(americano, 0)) .isInstanceOf(IllegalArgumentException.class) .hasMessage("음료는 1잔 이상 주문하실 수 있습니다.");회고지금은 컨트롤러에만 주석을 남기거나 학습이 중점인 개인 프로젝트에만 주석을 남기는 편이다하지만 예전에 팀 프로젝트를 할 때는 코드마다 주석을 남겼고, 클린 코드에 관심을 가지게 되면서 코드를 최대한 간결하게 작성하려고 하는데, 주석을 남기는 게 맞는지 의문이 생겨 부트캠프 튜터님들과 알고 지내는 주니어 개발자 분들에게 질문을 드린 적이 있다튜터님들이 생각하시는 클린 코드는 학습 내용처럼 주석 없이 최대한 코드에 녹여내는 것이 클린 코드라고 하셨고, 주니어 개발자 사이에서는 의견이 각각 달랐다아무래도 주위에 미들이나 시니어 개발자 보다는 같은 주니어 개발자가 대부분이기 때문에 의문점이 생기면 학습을 통해 배우거나 나보다 경험이 많은 개발자 선배들에게 물어보는 것이 최고인 것 같다튜터님들께 질문을 드려 피드백을 받았다고 해도 주변 주니어 개발자 분들과 마주칠 일이 많다 보니 주석에 대한 혼란이 조금은 남아있었는데 학습을 통해 주석에 대한 의문점이 완전히 풀렸다 상황에 따라 다르겠지만, 내가 배운 내용에 대해 자신감을 가져야겠다아는 것이 힘이다! 🎯 미션리팩토링 한 단계마다, 그 이유를 설명할 수 있어야 한다회고리팩토링 전 코드를 처음 봤을 때, 되게 복잡해 보이고 리팩토링이 꼭 필요한 코드라고 생각했다내가 처음부터 작성한 코드가 아닌, 다른 사람의 코드를 내가 이해하고 리팩토링을 해야 된다는 것에서 어떻게 시작해야 할지 망설여지고 어려움을 느꼈다그리고 복잡한 코드를 보며 협업에서 클린 코드는 꼭 필요한 부분이라고 생각하였다일단은 어떻게 리팩토링을 해야 할지 도전하는 마음으로 시작하였지만, 어떤 흐름대로 구성해야 할지 감이 잘 잡히지 않았다기능 구현을 하는 것보다 클린 코드로 리팩토링 하는 것이 더 어려운 것 같다클린 코드를 잘하기 위해서는 많이 해보는 수밖에 없는 것 같다

백엔드

박승민

[워밍업 클럽 4기 BE] 4주차 발자국

강의강의명: [Practical Testing: 실용적인 테스트 가이드]학습 내용: 섹션7. ~ 마무리이번 주는 남은 강의를 마무리하고 워밍업 클럽의 학습 일정에 마침표를 찍는 날이다. Mock 객체와 앞으로 테스트를 작성하는 데 있어서 가져 가면 좋을 마인드 셋을 배울 수 있었다. Mock을 마주하는 자세가장 기본적인 Mock의 사용법부터 왜 사용하는지, 그리고 Mock을 어디까지 다룰 것인지에 관한 전반적인 부분을 얘기한다.외부 서비스의 API를 이용하거나 메일 전송과 같은 외부 네트워크를 타는 일련의 일들은 우리가 개발하는 과정 동안 계속 서비스를 붙여서 테스트하는 것도 비용이 발생하고, 외부 서비스에서 문제가 발생하는 것까지 우리가 제어할 수 없는 부분이다. 잘 작동할 거라는 믿음과 기대를 바탕으로 제어할 수 없는 부분 등을 Mock으로 대체하여 최대한 우리가 제어할 수 있는 부분에서 최선을 다하는 것이 옳다고 생각한다. 더 나은 테스트를 작성하기 위한 구체적인 조언테스트 간 독립성을 보장하자테스트는 별도의 실행 순서가 정해져 있지 않다. 그러므로 테스트 사이에는 순서가 무관하게 성공해야 하고 각각 독립적으로 실행되어야 한다.공유 변수를 통해서 상태를 변경하고 순서가 정해져 있어야 하며, 만약 중간에 테스트가 수정이 발생하면 나머지 모든 테스트에 수정이 발생하게 된다.Q. private 메서드의 테스트는?client 입장에서 공개 API만 알면 된다. 내부 기능까지 알 필요가 없다. 굳이 하지 않아도 공개 API 검증하면서 자연스럽게 검증될 것이기 때문에 할 필요도 없는 것이다.그렇다고 하더라도 테스트에 관한 생각이 자꾸 떠오른다면 이 메서드가 별도의 책임을 갖는 객체로써 분리해야 하는 것인가를 고민해 보자.Appendix학습 테스트잘 모르는 기능, 라이브러리, 프레임워크를 학습하기 위해 작성하는 테스트로 여러 테스트 케이스를 스스로 정의하고 검증하는 과정을 통해 구체적인 동작과 가능함을 학습이 가능하여 관련 문서만 읽는 것보다 재밌게 학습할 수 있다.Spring REST Docs테스트 코트를 통한 API 문서 자동화 도구로 API 명세를 문서로 만들고 외부에 제공함으로써 협업을 원활하게 한다.테스트를 통과해야 문서가 만들어지므로 신뢰도가 높고 프로덕션 코드에 비침투적이라는 장점이 존재하지만, 코드양이 많고, 초기 설정이 어렵다.vs. Swagger적용이 쉽고 문서에서 바로 API 호출을 수행해 볼 수 있다.하지만 프로덕션 코드에 침투적이며 테스트와 무관하므로 신뢰도가 떨어진다.미션마지막 미션은 총 두 개였다.Layered Architecture 구조 레이어별로 어떤 특징이 있고, 어떻게 테스트하면 좋을지 정리하는 미션과 테스트를 작성할 때 Mock에서 자주 사용하는 어노테이션의 차이를 한번 정리하고 테스트 내용을 살펴보고, 각 항목을 어떻게 배치할지 생각해 보는 미션이었다.이번 미션은 전부 '자신의 언어로 다시 한번 표현할 수 있는가?'가 핵심이라고 생각한다. 무언가를 단순히 배우는 것에서 그치는 것이 아닌 스스로 한 번 더 생각해 보면서 학습의 일련의 과정에서 내가 놓친 부분과 부족한 부분을 스스로 다시 돌아보고 채워나가는 과정을 통해 나를 더 단단하게 만들어 나가는 시간이었다. 회고총 4주에 걸쳐 클린 코드를 지칭하는 수많은 원칙과 조언과 테스트에 대한 많은 내용들을 배웠다.그중에서도 가장 기억 남는 두 가지는 아무래도 '왜 지켜야 하는가?'와 '은탄환이 아닌 도구에 불과하다'라는 것이다. 이 모든 것은 적재적소에 알맞게 사용하는 것이 중요하고, 우리는 이런 것들을 지키면서 일을 하는 개발자로 주어진 기한 내에 요구사항을 모두 만족하는 프로덕트를 개발하는 것이 가장 중요한 사항이다. 도구에 매몰되어 우리의 본분을 잊지 말자.그리고 가장 만족도가 높았던 시간은 코드 리뷰 시간이다.선배 개발자에게 직접 모르는 것을 물어보고 나의 코드를 리뷰 받는 기회가 흔치 않고, 다른 사람들의 코드도 보면서 여러 시야를 확인할 수 있었고 많은 것을 배울 수 있을 거로 생각했지만 생각한 것 이상으로 많은 것을 얻어갈 수 있어서 너무 만족했던 시간이다.마지막에는 하나의 프로젝트를 만들어가면서 실제 서비스와 비슷한 구조에서 테스트가 어떤 의미를 가지는지 배울 수 있었다.4주라는 기간 동안 혼자 학습하는 것이 아닌 다른 사람들과 함께 공통의 목표를 향해 달려가면서 중간중간 포기하고 싶어지는 순간에도 열심히 노력하는 주변을 보면서 다시 한번 마음을 다잡을 수 있었고 끝까지 안주할 수 있었다.

인프런 워밍업 클럽 4기 DevOps - 4주차 발자국

이번 주 카테고리Helm과 Kustomize 비교하며 사용-2ArgoCD 빠르게 레벨업-1ArgoCD 빠르게 레벨업-2ArgoCD 빠르게 레벨업-3이번 주 회고이번 주는 다른 주차에 비해 학습 분량은 적었지만, 내용의 난이도는 훨씬 높았다. Helm과 Kustomize는 쿠버네티스 리소스를 템플릿화하거나 커스터마이징할 수 있는 도구로 알고 있었지만, 실제로 실습을 해보니 각 도구의 철학과 사용 방식이 달라 적응하는 데 시간이 걸렸다.ArgoCD는 GitOps라는 개념을 바탕으로 한 배포 도구로, 겉보기에는 UI도 잘 갖춰져 있어 쉬워 보였지만, 내부 구조와 동작 원리를 이해하려다 보니 예상보다 복잡했다. 특히, 실습을 따라 진행하면서 발생한 예상치 못한 동작이나 버그의 원인을 파악하는 과정은 단순히 기능을 익히는 수준을 넘어선 깊은 이해를 요구했다.이번 주는 "양보다 질"의 한 주였다. 적은 분량 속에 담긴 고밀도의 개념들을 소화하려다 보니 시간이 훨씬 더 많이 소요되었고, 단순히 따라하는 수준을 넘어서 각 도구의 역할, 차이점, 그리고 실전에서 어떻게 활용해야 할지를 끊임없이 고민하게 되었다.앞으로도 관련 문서와 다른 개발자들의 블로그, GitHub 예제들을 참고해 내용을 다듬고, 실습을 반복하면서 점점 더 깊이 있는 이해를 쌓아가야만 한다.

데브옵스 · 인프라･워밍업클럽4기･데브옵스

제어쟁이

임베디드 개발자 학습 로드맵 완벽 정리! (전기,전자,로봇,컴공 필수 시청)

안녕하세요. 네이버 블로그 ‘인사이드 임베디드’를 운영하고 있는 제어쟁이입니다! 😊 이번 영상에서는 임베디드 개발자가 되기 위해 꼭 거쳐야 학습 로드맵을 정리해봤습니다. 단순한 과목 나열이 아닌, 실제 실무에서 어떻게 쓰이는지까지 담았으니 전자·전기·로봇·컴공 전공자 분들이라면 꼭 끝까지 시청해주세요! ✔ 어떤 하드웨어 과목을 어떤 순서로 공부해야 하는지 ✔ C언어와 MCU는 어떻게 연결되는지 ✔ 제어공학과 DSP가 왜 중요한지 ✔ 실험 장비와 기록 습관까지 왜 실력 차이를 만드는지 이 영상 하나로 임베디드 학습의 전체 흐름을 잡으실 수 있습니다. https://www.youtube.com/watch?v=G8AYOJh9SYM

임베디드 · IoT･임베디드･전자공학･전기공학･로드맵

대학원 진학 고민하시는 분들께!

안녕하세요 제어쟁이입니다.유튜브와 블로그를 운영하면서 학생 분들, 사회 초년생 분들로부터 많은 질문을 받았습니다.그중에서도 특히 대학원 진학을 고민하시는 분들이 많더라구요. 결론부터 말씀드리면, 대학원은 여건이 된다면 무조건 진학하시길 추천드립니다. 특히 석사 과정은 가성비가 매우 훌륭하고, 박사 과정은 석사를 해보면서 자연스럽게 결정할 수 있을 거예요. 정말 현실적으로, 대학원을 선택할 때 고려해야 할 가이드를 제시해드리겠습니다.1. 학교 네임밸류2. 산학 과제, 국책 과제를 많이 하는가?3. 희망 대학원 랩실 졸업생들의 진로하나씩 설명드릴게요.1. 학교 네임밸류사실 이건 대한민국, 아니 전 세계적으로도 어쩔 수 없는 부분입니다. 여러분이 면접관 또는 인사 담당자라면, 서울의 S대 출신과 처음 들어보는 대학원 랩실 출신 중 누구를 더 선호하시겠어요? 현실은 냉정합니다. 네임밸류는 여전히 강력한 무기입니다.​2. 산학 과제, 국책 과제를 많이 하는가?랩실 홈페이지를 보면 어떤 회사들과 산학 과제 또는 국책 과제를 진행했는지 확인할 수 있습니다. 이러한 과제를 많이 한다는 건, 여러 기업과 함께 일할 기회가 많다는 뜻이고, 이는 취업에 매우 유리한 요소로 작용할 수 있습니다.​3. 희망 대학원 랩실 졸업생들의 진로랩실 졸업생들이 어디에 취업했는지는 대부분 홈페이지에 공개되어 있습니다. 그리고 졸업 후에는 선배들이 근무하는 기업이나 유사한 곳에 연결될 가능성이 매우 높습니다. 취업이 목표라면 반드시 확인해야 할 부분이죠.위의 세 가지는 꼭 깊이 고민해보시길 바랍니다..! 궁금한 점이나 추가 질문이 있으시면 언제든지 편하게 문의주세요 :)​

임베디드 · IoT･전기전자･전자공학･대학원･취업

박승민

[워밍업 클럽 4기 BE] 1주차 발자국

강의강의명: [Readable Code: 읽기 좋은 코드를 작성하는 사고법]학습 내용: 섹션1. ~ 섹션5클린 코드를 지칭하는 수많은 원칙과 조언들이 존재한다. 강의를 통해서 이러한 원칙과 조언만을 배울 뿐만 아니라 “왜 지켜야 하는가?”를 배울 수 있는 시간이었다. 그중에서도 가장 기억에 남는 부분은 다음과 같다.사고의 depth 줄이기중첩 분기(반복) 문에서 depth를 줄인다는 것이 "무조건 1 depth로 만들어라."가 아닌 추상화를 통한 사고 과정의 depth를 줄이는 것이 목적이라는 것이다. 무작정 depth를 줄이는 것을 주목적으로 삼으면 오히려 복잡도가 높아져 혼선을 줄 수 있다.getter와 setter를 대하는 자세예전에는 나는 객체를 생성하는 동시에 항상 getter와 setter를 만들어 사용했었다. 그저 편하다는 이유 하나만으로이번 강의를 통해서 그동안 나의 방식이 가져올 수 있는 문제점을 배우고 고칠 기회를 얻었다.setter가 필요하다면 set 대신 update처럼 의도를 드러내는 네이밍을 선정getter를 사용하려고 한다면 외부에서 데이터를 왜 필요로 하는지 생각해 보고 객체에 물어볼 수 있지 않을까?SOLID객체 지향을 학습하면서 설계의 5원칙이라고 하면서 그냥 외우던 것을 실제 코드로 어떻게 녹이는지, 어떤 상황에 위배되고 문제가 발생할 수 있는지 학습할 수 있는 이번 주 학습 내용 중 가장 기억에 남는 부분이다.차주 학습 계획중간중간 기록하여 이해되지 않은 부분을 다시 찾아보고 하느라 강의 시간만 보고 계획을 세워 기존 계획보다 많은 시간을 소모하게 된 부분이 아쉬웠다. 실습 부분이 강의를 수강하면서 같이 진행하여 강의를 더욱 재밌게 수강하였다. 하지만 강의 내용을 온전히 나의 것으로 습득했는가에 대한 의문과 아쉬움이 남는 한 주였다. 앞으로 강의 수강 계획을 강의 시간보다 여유 있게 계획하여 일정을 여유 있게 소화하도록 보완해 나갈 계획이다. 또한, 차주부터 실습 부분은 강의 없이 스스로 진행해 보는 시간을 마련해 볼 계획이다.미션이번 주는 총 두 가지 미션을 진행했다. 첫 번째로 우리가 일상에 자연스럽게 녹아있는 추상을 구체화해 보는 미션으로 둘째로 SOLID를 스스로 정리해 보는 시간을 갖는 것과, 예제 코드를 리팩터링하여 추상화하는 미션이었다. 스스로 정리해 보는 시간은 단순히 무언가를 배운다는 것에 그치지 않고 한 번 더 생각하고 정리할 수 있는 시간이 그동안 나에게 얼마나 부족했고 중요한 순간인지를 알려주는 소중한 기회였다. 또한, 리팩터링 미션은 추상화 레벨, 그리고 메서드의 좋은 이름, 도메인 관점에서 바라보는 방식 등 코드를 다양한 시각에서 바라볼 수 있는 미션이었다.
징니

인프런 워밍업 클럽 4기 BE 스터디 3주차

💻 강의Practical Testing: 실용적인 테스트 가이드 📚 학습통합 테스트여러 모듈이 협력하는 기능을 통합적으로 검증단위 테스트만으로는 기능 전체의 신뢰성을 보장할 수 없음ORMObject-Relational MappingJPAJava 진영의 ORM 기술 표준인터페이스여러 구현체가 있지만, 보통 Hibernate를 많이 사용자동으로 CRUD SQL을 생성하고 실행, 여러 부가 기능들을 제공ORM이 생성해주는 쿼리를 사용하고 있기 때문에 어떤 식으로 쿼리가 생성되고 실행되는지 명확한 이해 필요Spring 진영에서는 JPA를 한번 더 추상화한 Spring Data JPA 제공보통 QueryDSL과 조합하여 많이 사용타입 체크동적 쿼리회고

백엔드

워밍업 클럽 4기 DevOps - 4주차 발자국

강의명 : 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2스터디 기간 동안은 생각보다 시간이 빨리 흘러간 것 같다이 강의는 반 년 전부터 들어야지 생각만 하고 계속 미뤄왔던 터라 스터디로 함께 듣는다고 해도 끝까지 따라갈 수 있을지 자신이 없었지만막상 4주가 지나고 나니 시간이 어떻게 흘렀는지도 모를 정도로 빠르게 지나 무사히 완주를 했다혼자 들을 땐 하나 막히면 그냥 미뤄버리게 되는데이번에는 팀원들에게 피해를 주고 싶지 않아서라도 매일 일정에 맞춰 강의를 듣고 미션을 수행하려 노력해봤다도장 깨기 하듯 하루하루 채워나간 덕분에 밀린 일정 없이 끝까지 따라올 수 있었고함께 꾸준히 참여해주신 팀원분께도 박수를 보내고 싶다처음 접하는 개념들도 많았고 실습이나 미션은 생각보다 시간이 오래걸리기도 했지만그래도 꾸준히 학습하고 정리해둔 페이지를 다시보면서 점점 익숙해졌다완벽하게 내 것으로 만들었다고는 말할 수 없지만 적어도 이게 어떻게 이어지는지 정도는 파악할 정도는 된 것 같다앞으로도 복습 페이지를 자주 들여다보며 반복학습으로 더 익숙해지도록 공부해봐야겠다매일 아침 팀별로 신경도 많이 써주시고카페의 자료실 볼 때마다 느끼는 거지만 정성스럽게 올려주신 글들 덕분에하나하나 따라해보면서 여기까지 올 수 있었습니다 감사합니다 일프로님 🥹완강하신 분들 모두 수고 많으셨습니다!

인프런 워밍업 클럽 4주차 회고 - 발자국

차주 목표미션을 진행 함에따라, 실수나 빠지는 부분이 있는 듯하여 천천히 다시 되새기는 시간을 가져야겠다.아직 따라가지 못한 강의에 대한 학습을 진행해야겠다.회고록 이번에 컨테이너부터 시작해 쿠버네티스, 그리고 CI/CD까지 전반적인 내용을 공부할 수 있어 좋았으나,아직 내 지식으로 체화 되지 않음을 느낀다. 조금더 복습을 진행해야겠고 다음에는 이 다음 단계를 밟는것을 목표로 이번달 남은 시간을 보내야겠다.

데브옵스 · 인프라･devops･k8s

ddd

[워밍업 클럽 4기: DevOps] 4주차 회고

[4주차에 접어들면서]마지막 주차였는데요!현재 업무에서 일이 너무 많아서 강의도 못듣고 복습도 못해서 너무 아쉬웠습니다.차주에 최대한 따라가면서 밀린 강의와 복습을 최대한 진행하고 싶습니다! [팀 스터디 소감]사다리타기를 통해 리더로 뽑혔는데 개인 업무가 바빠져서 팀 리더로서 다른 팀원들을 챙기거나 독려하지 못해서 아쉬운 마음이 컸습니다.조금 더 이끌고 도와주면서 했어야 하는데 팀원들한테 미안한 마음이 크네요그래도 이런 스터디 기회를 마련해주시고 고생하신 일프로님과 인프런 측에 고맙다고 말하고 싶습니다 
ddd 22일 전

워밍업 클럽 4기 DevOps - 4주차 발자국

[발자국]"쿠버네티스 어나더 클래스 ( 지상편 ) - Sprint 1, 2" 강의 4주차를 듣고 정리하는 발자국 입니다.강의 내용섹션 18( 6~9 ) Helm과 Kustomize 비교하며 사용섹션 19( 1~4 ) ArgoCD 빠르게 레벨업-1섹션 19( 5~6 ) ArgoCD 빠르게 레벨업-2섹션 19( 7~8 ) ArgoCD 빠르게 레벨업-3 회고벌써 스터디의 마지막 발자국을 남기는 시간이 되었다.1달이라는 시간이 정말 눈 깜짝할 새에 지나간 것 같다.이번 스터디를 통해 처음 접했던 컨테이너부터 시작해 쿠버네티스, 그리고 CI/CD까지각각의 개념을 순차적으로 배우고 실습해볼 수 있어서 정말 값진 시간이였다.무엇보다 포기하지 않고 꾸준히 달려온 내 모습이 스스로도 대견하게 느껴진다.사실 혼자였다면 중간에 지치거나 놓쳐버렸을지도 모른다.하지만 팀원들과 함께 했기에 끝까지 완주할 수 있었고, 그 과정에서 더 노력할 수 있었다.앞으로도 이 경험을 발판 삼아, 협업 속에서 서로에게 긍정적인 영향을 주고받는'Win-Win' 관계를 만들어갈 수 있는 사람이 되고 싶다. 그리고 마지막으로,좋은 강의를 통해 꾸준히 신경 써주시고 항상 성실하게 이끌어주신 일프로 강사님께도 진심으로 감사드립니다. 🙇‍♂덕분에 어렵게만 느껴졌던 기술들을 흥미롭게 배우고, 끝까지 완주할 수 있었습니다.

데브옵스 · 인프라･일프로･쿠버네티스

워밍업 클럽 4기 BE 클린코드&테스트 4주 차 발자국

@Mock, @Spy, @InjectMocks 등 테스트 코드에서 자주 사용되는 어노테이션에 대해서 학습했습니다.Given-When-Then 스타일을 지원하는 BDDMockito와테스트 철학과 관련된 Mockist, Classcist에 대해서 알게 됐습니다.명확한 주제 명시, Test Fixture, @ParameterizedTest, @DynamicTest 등 더 나은 테스트 작성을 위한 방법을 공부했습니다. 이를 토대로 이번 주 미션에서 각 테스트 레이어의 역할과 테스트 방법에 대해 정리했고Mockito의 주요 어노테이션과 스프링 환경과 순수 자바 환경에서의 테스트의 차이 및공통 환경을 고려한 객체 생성 및 동작 배치에 대한 미션을 수행했습니다 그간 테스트에 대해서 학습한 내용들이 정리가 되는 한 주였다고 생각합니다.또한 테스트 주도 개발은 답답하고 하기 싫다는 생각이 앞섰는데 멀리 가기 위한 지름길이라고 깨달았습니다.'잘 되냐 안 되냐'도 중요하지만 작성한 코드의 구조와 의존성을 확인하고맞는 설계로 진행해 나아가고 있는지 확인할 수 있다고 느꼈기 때문입니다.단순히 기술을 배운 것이 아닌 좋은 코드를 만들기 위한 시야와 기준이 생긴 것 같습니다.테스트를 돌리는 것에 의미를 두는 게 아닌 테스트를 통해 코드의 문제를 읽는 눈을 갖고더 나은 코드를 작성하는 실력을 기르고 싶다는 마음이 더 커진, 의미 있는 4주를 보냈던 것 같습니다.
kailis

[발자국 4주차] 문어야 문어야 뭐하니

  문어야 문어야 뭐하니   해당 글은 인프런 워밍업 클럽 스터디 4기 - DevOps (쿠버네티스)를 진행하며 깊게 고민해 보려고 한 내용을 담습니다. 개괄적 정리보다 아는 것과의 비교를 통한 이해를 추구합니다.  또 Jenkins 파이프라인이 실패했다. 빌드는 성공했는데 배포 단계에서 타임아웃. kubectl로 수동 배포를 시도하니 이번엔 yaml 문법 에러다. 그런데 오늘부터 우리(?) 집에는 문어가 산다. 이 문어는 상당히 똑똑해서, 우리가 작업하고 싶어하는 배포들을 보다 단순하게 처리할 수 있도록 해 줄 것이다. 우리의 Jenkins가 못해먹겠다는 일을, 조금 더 덜어 보러 가 보자.  ArgoCD? 우리의 문어, ArgoCD는 쿠버네티스 환경에서 GitOps 방식으로 애플리케이션을 배포해주는 도구다.Git 저장소를 지속적으로 모니터링하다가 변경사항이 생기면 자동으로 쿠버네티스에 배포해준다. 왜 ArgoCD일까? 궁금해서 찾아 보았더니. 그리스 신화에서 이아손과 아르고 선원들이 황금양털을 찾으러 탔던 배가 '아르고호(Argo)'란다. 험난한 바다를 항해해서 목적지에 도달하는 것처럼, ArgoCD도 복잡한 배포 과정을 자동으로 항해해서 원하는 상태로 애플리케이션을 배포해준다는 의미인 것 같다. Git이라는 나침반만 있으면 알아서 목적지까지 데려다준다니, 나름 꽤 적절한 네이밍 아닌가.  배포 진화의 4단계 강사님이 정리해주신 배포 레벨별 진화 과정이 명확했다. Level 1: Jenkins UI에서 클릭 몇 번으로 해결. 편하지만 파이프라인 설정이 UI에만 저장되어 변경 이력 추적이 안 된다.Level 2: Jenkinsfile로 파이프라인을 코드화. 이제 Git으로 관리할 수 있다. 하지만 여전히 Jenkins가 kubectl을 실행해서 직접 배포한다.Level 3: Helm이나 Kustomize로 YAML 템플릿화. 개발/스테이징/운영 환경별로 다른 설정을 쉽게 관리할 수 있다. 그래도 배포 트리거는 수동이다.Level 4: ArgoCD로 GitOps 완성. Git 변경 → 자동 배포, Blue/Green이나 Canary 같은 고급 배포 전략도 지원.  중요한 건 Level 3까지도 충분히 서비스 운영이 가능하다는 점이다. ArgoCD는 더 나은 선택지지, 반드시 필요한 건 아니다. 하지만 나는 ArgoCD를 도입해야만 한다. 사실 내가 할 건 아니다. 회사에서 쓰고 있다. 그럼 알아야지. (ㅋㅋ ㅠㅠ)  Git이 진실의 원천이 되는 순간 이전 버전에서 알려주신 바로는 Jenkins에서 모든 걸 처리했다. 소스 빌드, 이미지 생성, 쿠버네티스 배포까지. 그런데 ArgoCD 아키텍처를 보니 접근 방식이 완전히 달랐다. Repo Server가 3분마다 Git 저장소를 확인한다. YAML 파일이 바뀌었나? 새로운 커밋이 있나?Application Controller가 현재 쿠버네티스 상태를 읽어온다. 그리고 Git의 내용과 비교한다.다르면? 자동으로 동기화한다. 이게 핵심이었다. Jenkins는 "배포하라"고 명령하는 방식이라면,ArgoCD는 "현재 상태가 원하는 상태와 같은가?"를 지속적으로 확인하는 방식이다. 일종의 Polling이지만, 권한을 더 이상 신경쓰지 않아도 된다는 의존 관계 해소가 가능하다.결과적으로 이제 Jenkins에서는 kubectl 권한을 관리할 필요가 없어진다.Pod에 대한 다른 모니터링 관리 툴 필요성도 줄어든다. 보안 측면에서도 좋고, 역할 분리도 명확해진다. 그런데 가장 흥미로웠던 건 Image Updater였다.  Image Updater, 드디어 찾은 진짜 자동화?  기존에는 이랬다. 개발자가 코드 푸시Jenkins가 빌드하고 이미지 생성Jenkins가 YAML 파일의 이미지 태그를 수정하는 스크립트 실행수정된 YAML을 Git에 푸시ArgoCD가 변경사항 감지해서 배포 이제 Image Updater를 쓰면. 개발자가 코드 푸시Jenkins가 빌드하고 이미지를 Docker Hub에 업로드Image Updater가 새 이미지 감지자동으로 Git의 YAML 파일 수정ArgoCD가 변경사항 감지해서 배포 개발자는 코드만 푸시하면 끝이다. Jenkins 파이프라인에서 복잡한 YAML 수정 로직을 짤 필요가 없다. 단, 제약이 있다. Helm이나 Kustomize로 배포해야만 동작한다. 내부적으로 --set image.tag 옵션을 사용하기 때문이다. update-strategy 설정도 중요하다. semver로 하면 버전 규칙에 맞는 최신 버전으로, latest로 하면 가장 최근 이미지로 업데이트된다.  Sync Policy, 자동화의 양날의 검 Manual vs Auto Sync Auto Sync. 좋아 보이지만 너무 무서운 단어가 아닌가? 난 서버에서 자동은 늘 무섭다.(;; 물론 요즘 선배님들의 자동화는 나의 매뉴얼보다 훨씬 낫다고 생각하지만..) 그래도 역시 강사님 설명을 들으니 함정이 있었다.Auto Sync + Self Heal 조합을 켜두면, 쿠버네티스에서 직접 수정한 내용이 모두 무시된다.HPA로 replica가 늘어나도 Git에 정의된 숫자로 다시 줄어든다. Sync Options Sync Options에서도 유사한 상황이 발생할 수 있다. AUTO-CREATE-NAMESPACE: 편리하지만 오타로 잘못된 네임스페이스가 생성될 수도 있다PRUNE RESOURCES: Git에서 삭제된 리소스를 쿠버네티스에서도 삭제하는데, 실수로 파일을 지웠을 때 운영 중인 서비스가 날아갈 수 있다 결국 환경별로 다르게 설정해야 한다. 개발 환경에서는 Auto Sync로 빠른 피드백을, 운영 환경에서는 Manual Sync로 안정성을 택하는 식으로. 오, 어쩐지 H2 같다. 정확한 타입 제한은 운영 DB에서만 처리할 때도 있으니까.  컴포넌트들의 역할 분담 이제 우리 집 문어를 뜯어 보자. ArgoCD 아키텍처를 보면 각 컴포넌트가 명확한 역할을 가지고 있다. Server: Web UI와 API 제공. 우리가 보는 대시보드가 여기서 나온다.Repo Server: Git 저장소와 소통. YAML 파일을 다운받아서 실제 배포할 매니페스트로 변환한다.Application Controller: 핵심 로직. 쿠버네티스 현재 상태와 Git의 desired state를 비교해서 동기화를 결정한다.Dex: SSO 연동. 회사에서 쓰는 LDAP이나 OAuth 프로바이더와 연결할 수 있다.Redis: 캐시 역할. Git과 쿠버네티스 API 호출을 줄여서 성능을 향상시킨다.Notification: 배포 결과를 Slack이나 이메일로 알려준다. 특히 ApplicationSet Controller가 인상적이었다. 개발/스테이징/운영 환경을 각각 다른 ArgoCD Application으로 만들 필요 없이, 하나의 템플릿으로 여러 환경을 관리할 수 있다고 해서.  Directory vs Helm vs Kustomize ArgoCD에서 지원하는 세 가지 배포 방식. Directory 방식그냥 YAML 파일들을 kubectl apply 하는 것과 같다가장 간단하고 직관적이다하지만 Image Updater를 쓸 수 없다. 이미지 태그를 동적으로 바꿀 방법이 없기 때문이다 Helm 방식:values.yaml에서 환경별 설정을 관리한다Image Updater가 values.yaml의 이미지 태그를 자동으로 수정해준다템플릿 문법이 복잡할 수 있지만, 기능이 가장 풍부하다 Kustomize 방식base 디렉토리에 공통 설정, overlay 디렉토리에 환경별 차이점을 둔다Helm보다 가볍고 배우기 쉽다Image Updater도 지원하지만 Helm만큼 유연하지는 않다 결론적으로, 단순한 서비스라면 Directory도 충분하다.하지만 Image Updater로 자동화를 원하거나 멀티 환경 관리가 필요하다면 Helm이나 Kustomize를 써야 한다. 하지만 우리는 직전 강의에서 Helm의 태깅과 다양성이 필요하다는 이야기를 들었다. 간단한 프로젝트에서는 Kustomize이 괜찮겠지만, 어쩐지 Kustomize를 사용할 프로젝트에서 k8s를 사용하는 것은 오버엔지니어링일지도 모른다는 생각이 들기도 한다. 유사한 관점은 ArgoCD에서도 이어진다.  그래서, 정말 필요한가?  Level 3으로도 충분히 잘 돌아가는 환경이라면 굳이 ArgoCD를 도입할 필요가 있을까? 강사님 말씀처럼 "유지보수 부담"도 생긴다. ArgoCD 자체도 쿠버네티스 위에서 돌아가는 애플리케이션이니까. 하지만 다음과 같은 상황이라면 도입을 고려해볼 만하다. Blue/Green, Canary 배포가 필요한 서비스멀티 클러스터 환경 관리Image Updater로 완전 자동화를 원하는 경우배포 과정에서 사람의 개입을 최소화하고 싶은 경우Git 기반으로 모든 배포 히스토리를 추적하고 싶은 경우  결국 '현재 내 상황에서 어떤 문제를 해결하고 싶은가'가 기준이 되어야 한다. Spring Boot 환경에서는 특히 Image Updater의 장점이 클 것이다.코드 변경 → 자동 빌드 → 자동 배포까지 완전히 세팅을 통해 자동화할 수 있으니까.  마무리하며 "나 이제... ArgoCD 쓸 수 있냐?" 음, 편리해졌다. 동시에 복잡성도 조금은 생긴다. Git에 푸시하면 알아서 배포되고, UI 대시보드에서 상태를 실시간으로 확인할 수 있고, 문제가 생기면 이전 버전으로 쉽게 롤백할 수 있다. 하지만 쉬워진 만큼 더 신중해져야 할 부분도 있다. Sync Policy 설정, Image Updater 전략, 멀티 클러스터 관리 등. 결국 도구는 도구일 뿐이고, 어떻게 쓰느냐가 중요하다. 그래도 한 가지는 확실하다. GitOps라는 개념을 제대로 구현해보고 싶다면, ArgoCD만큼 완성도 높은 도구는 찾기 어려울 것 같다. 이번에 강의를 마무리하면서 적용 시점이 다가오고 있어서 회사에서 다시금 ArgoCD를 접속했는데, 권한이 빠졌는지 대시보드가 뜨지 않고 회색 창이 떴다. SSO가 LDAP에서 키클락으로 바뀌어서 그럴 거라고 생각했다. 강의에도 그 부분이 나왔었다. 그리고 GitLab에 아키 팀이 설정해 둔 Helm 세팅에 대한 옵션을 봤다. 원래는 Helm이 무슨 역할을 하는지도 정확하게 알지 못해, 분명히 위키와 옵션을 봤음에도 기억하지 못했었다. 이제 옵션을 이해할 수 있다. 왜 이걸 쓰는지 알고 있다. 나는 이제 제법 K8S를 겁내지 않을 수 있겠구나. 4주 간의 여정을 즐겁게 마무리하면서, 앞으로의 Sprint 3에 대한 욕심도 생기고 있다. 멀게만 느껴졌던 DevOps, 이번 인프런 워밍업 클럽을 토대로 조금 더 가까워진 것 같다.  
dohi

워밍업 클럽 4기 - 백엔드 4주차 회고

4주차 회고강의수강Mock을 마주하는 자세Mockito로 Stubbing하기Test Double@Mock, @Spy, InjectMocksBDDMockitoClassicist VS Mockist키워드 정리더 나은 테스트를 작성하기 위한 구체적 조언한 문단에 한 주제완벽하게 제어하기테스트 환경의 독립성 보장하자테스트 간 독립성을 보장하자한 눈에 들어오는 Test Fixture 구성Text Fixture 클렌징@ParameterizedTest@DynamicTest 테스트 수행도 비용이다. 환경 통합하기Q&A키워드정리 Appendix학습 테스트Spring REST DocsOutro테스트를 작성하는 마음가짐미션Day 16https://www.inflearn.com/blogs/11176Day 18https://inf.run/S7UnS 회고이번 너무 많고 좋은정보가 있어 직접적인 강의에 대한 모든 흐름이 느껴져서회고에 자세하게 적어보려합니다.저에게 테스트는 귀찮지만 한번 만들어놓으면 계속쓰는 도구 그이상그이하가 아니였습니다.테스트 코드를 배우고 아 테스트과정에서 계속반복되면 이게 문제겠구나(메일보내기 및 알람보내기)아! 이건 테스트는 한번만해도되는데그런관점을 배우게 되었고테스트 코드를 오히려 설계할때 어떤 관점과 어떤 중요한점 마음가짐을 더알려주는 강의였습니다.사실 사수에게 배울 수 없는 관점을 더 알려주셨고실제 라이브에서도 저런생각을 하면서 코드를 짜는구나제 코드를 바라보면서 문제점과 부족한 점이 점점 보이기 시작했습니다.사실 코드에는 정답이 없다고는 하지만맨날 제가 보기 좋은 코드만 짠 것같았고테스트를 작성하면서 실제 배운관점을 프로젝트에 적용하면서 도움이되었습니다.이번에 한이유는 실제로 사용하고 바로바로 배우기위해서 시작한거였는데많은 관점을 배웠고 실제 프로젝트에서도 적용하면서 도움이 많이 되었습니다.그동안에 매번 다보기전에 정리만 하고 마무리 안보고 다음강의로 넘어가느라 빠르게 넘어간것들 다시 정리해야겠어요지하철에서 보고 영감받으면 정리하고 넘어가고 하다보니 넘어간게 엄청많았더라고요 핫그만큼 강의 사이사이에 엄청 중요한게 많고 영감이 많아서 늘 도움이 된게 많았어요 감사합니다 일단 다봤지만 체크가안된건 오늘 쓰윽 마지막까지 봐야겠어요

백엔드･백엔드･워밍업클럽4기･워밍업클럽

채널톡 아이콘