Why? What? How?

AWS DNA 2기 후기

가그린민트 — Fri, 18 Jun 2021 15:11:58 +0900

오랜만에 즐거운 시간이었다. 회사생활, 교육, 스터디 등을 통해 얻는 즐거움도 상당하지만, 이건 좀 뭔가 더 자극적이다.
얼마전 AWS DNA 모집 공고를 보았다. 지난 해 신청을 했다가 캘린더를 보고 취소 요청을 했었던터라, 올해는 바쁘더라도 신청을 해야겠다 마음 먹었다. 경쟁률이 상당하다고 들었고, 실제로 주변 지인들이 떨어졌지만 나는 붙었다. (왜지?! )

AWS DNA. Digital Native Architects의 줄임말로, 대략 AWS로 사고하고 문제를 해결하는 이들을 양성하기 위한 교육인듯 싶다. AWS의 기능은 빠르게 업데이트되는데 비해 현업 엔지니어는 수동적이다. 기존의 기술들로도 현재의 문제를 잘 해결해나가고 있고, 특정 기술에 lock-in 되는 것에 거부감을 느끼기 때문이다. 하지만 Public Cloud는 상당히 안정화되었고, 비즈니스 핵심 가치에 집중하기 위해서라도 관심사를 분리할 필요가 있다.

AWS DNA는 AWS를 통해 해결할 수 있는 문제들을 체험하게 해준다. 기술에 대한 깊이있는 학습을 전달하기 보다, Solutions Architect 분들이 설계한 시나리오대로 수행해본다. 목적의식이 분명하다면, 현업에서 적용할 것들을 생각해보고 테스트해보기 좋은 구성으로 짜여져있다. 즉, '너희는 비즈니스 로직에 집중해. AWS 위에서'라는 메시지가 곳곳에 스며있다.

과정은 대략 2달 정도 진행했다. 7개의 세션과 2번의 jam 대회가 있다.
> https://pages.awscloud.com/kr-aws-dna-online-reg.html

개인적으로 Network에 강점이 있다고 생각했는데, 2회차 세션은 또다른 인사이트를 주었다. TransitGateway 핵심 컨셉을 이해하고 실습해볼 수 있어서 좋았고, GSLB, Network Firewall 등 서비스를 알게 되었다.
4회차에 진행했던 실습을 바탕으로 사이드 프로젝트 배포 환경을 구성해보았다. 이번 실습 이후에 spinnaker documents를 보고 직접 구성한 후 부하테스트를 진행하며 리소스 관리도 해보고, 운영도 해보면서 k8s에 대한 이해도 조금 깊어졌다. 다른 세션들도 깊게 몰입해보고 적용해보고 싶었지만 병행하던 스터디와 강의 일정으로 시간을 내기가 어려웠다. 그리고 sagemaker는 기본 지식이 상당히 필요하다는 것을 확인할 수 있었다.

3팀이었다. 중간 집계에선 1등이었는데.. 허허

AWS DNA하면, jam 대회가 기억날 거 같다. jam 대회란 대략 10개 정도의 문제를 주고 팀이 공동으로 수행하는 방식이다. 문제상황은 네트워크, 배포, 보안 등 다양하다. 난이도에 따라 점수가 할당되어 있고, 힌트를 볼수록 차감되는 방식이다. 현황판이 있어 묘한 경쟁의식을 부추긴다. 가령, pem 키를 잃어버렸을 경우 등의 문제상황을 부여하고 각자 계정으로 접속하여 제한된 권한으로 문제가 주어진다. 문제를 해결하여 서버를 띄우면 특정 문자열을 얻을 수 있고 이를 정답으로 제출하면 점수를 얻는 방식으로 진행된다.
2번 모두 우리팀은 2등을 했는데 첫번째는 힌트를 아에 안보고 했던 것이 아쉬웠고, 두번째는 내가 너무 못했던 것이 여운이 남는다. 3~4년 전만해도 AWS를 꽤 안다고 생각했는데, 여전히 사용하던 것들만 사용하다보니 이렇게 되었나 싶다.

AWS DNA는 다양한 회사의, 다양한 경험을 한, 다양한 연차의 사람들이 모여 함께 학습하고 지식을 공유하고 문제를 해결해가는 과정이다.
전반적으로 구성이 참 알차다. 과정 중간중간 이벤트들도 재미있었고, 수강생들의 피드백을 받고 개선하는 모습들도 너무 좋다. 끝나고 받은 후드티도 고퀄이었다! ‍♂️ 몰입하지 못해서 너무 아쉬웠지만, 덕분에 무엇이 부족한지도 생각해볼 수 있는 시간이었다. AWS의 다양한 기술들을 실무 관점에서 생각하고 경험해보고 싶은 분들이라면 적극 추천한다.

2021년 상반기 회고

가그린민트 — Mon, 14 Jun 2021 15:02:03 +0900

이제는 멈춰버린 블로그. 회고를 통해 생존신고를 남겨본다.
2021년 상반기. 여전히 글또를 시작하지 않고 있다.
그리고 하반기에도 시작하지 않을 계획이다.
2주에 한번씩 글을 쓰기엔 시간이 부족하다.
이번 상반기엔 무얼 했던걸까

1. 외부 강의

https://edu.nextstep.camp/c/VI4PhjPA

인프라 공방

edu.nextstep.camp

인프라공방이 1기에 이어 2기도 순항 중이다. 1기 10명으로 시작하여 2분만에 마감되었다. 그리고 2기는 15명에 리뷰어 한명과 함께 하고 있다. 3기는 20명으로 진행할 계획이다. 과정을 진행하면서 강의도 다듬어지고 미션, 리뷰로 소통하며 내용도 풍부해진다. 우테캠 Pro도 1기에 이어 2기를 진행하고 있다. 올해 3기까지 할 계획인데 3기에는 프로젝트 미션도 추가할 계획이다. 우형의 기대치에 맞는 인재들이 영입되길 기대해본다. 그 외로 카카오 신입사원 교육, 캐치 토크 콘서트 등을 진행했다. 이제 조금 외부 강의가 익숙해졌다.

2. 우아한테크코스

https://woowacourse.github.io/

우아한테크코스

우아한테크코스에서 개발자들을 위해 디자인된 강의를 수강해보세요.

woowacourse.github.io

1) 운영
우아한테크코스도 이제 3기다. 올해는 프론트엔드 과정을 오픈했다. 인원은 총 78명으로 늘어났고 코치와 리뷰어들도 늘어났다. 점진적으로 사업이 확장되어감에 따라 소통비용들이 발생했고, 상반기는 이를 조정하는 시간들이 필요했다. 과정 내에서 학습로그, 모의 면접 등의 활동을 추가했고 K-Digital Training 사업을 운영했다. 전자의 경우, 크루들이 본인의 현재 수준을 파악하고 알고 있는 것을 자신의 용어로 표현하여 유의미했다는 피드백이 있었다. 후자의 경우, 우아한형제들로부터 경제적 자립을 일구고 크루들의 생활비 지원에 보탬이 되었다는데서 의미가 있다. KDT를 주도적으로 진행하면서 여러 협력부서, 정부기관들과의 소통비용이 컸지만 결과물을 만들어내서 개인적으로도 나름 의미가 있었다. 앞으로 우테코 사업을 확장하면서 여러가지 시도도 해볼 수 있으리라.
https://v.kakao.com/v/20210514110453693

우아한테크코스 방문한 이억원 차관

[서울=뉴시스]이억원 기획재정부 차관이 14일 청년인력양성과 관련해 서울 송파구 우아한테크코스를 방문, 간담회에서 발언하고 있다. (사진=기획재정부 제공) 2021.05.14. photo@newsis.com *재판매 및 D

v.kakao.com

2) 강의

https://www.youtube.com/watch?v=_DgpFbcGuAc

올해는 레벨1에 SQL 강의 영상을 제공하여 프론트엔드, 백엔드 크루 중 SQL이 약한 크루들이 스스로 학습할 수 있도록 가이드했다. 고마움을 적극적으로 표현했던 크루들과 우형 내 타 팀원분들 덕분에 나름 의미있었던 활동이었다. 레벨2에는 네트워크/인프라 강의 및 배포/협업 미션을 진행헀다. 백엔드 커리큘럼의 변화를 최소화하면서 자연스레 인프라 주제를 경험하여 프로젝트를 진행할 역량을 키우도록 구성했다. 하지만 여전히 강의 내용이 어렵다는 피드백이 있어 좀 더 개선해야겠다.

3) 멘토링
지난 해에 개인적인 일들로 크루들에게 몰입하지 못했다고 생각하여 올해는 데일리미팅부터 몇가지 시도를 했다. 그 외로도 오프라인으로 자주 마주하고 멘토링을 진행했고, 스터디도 몇개 참여하여 유대관계를 형성했다.

3. 학습

AWS DNA, 엘레강트 오브젝트 스터디를 했고 둘다 유의미한 성장을 이뤄내지는 못했다. 뭐, 오랜만에 스트레칭한 정도랄까. 인프라공방을 준비하며 k8s 이해는 조금 깊어졌다. 프로그래밍 역량을 키워보고자 했으나, NEXTSTEP 개발도 의미있는 PR은 몇개 안되고 플젝을 진행했던 것도 없다. 그래서 하반기에 플젝을 하기위해 팀빌딩을 했고 현재까지는 순항중이다.

4. 성당

https://pf.kakao.com/_rtxjxjK

송파동성당 청년 연합회

송파동성당 청년연합회 카카오톡채널입니다.

pf.kakao.com

회장이 되었다. 코로나19로 활동하지 않는 청년들에 변화를 주기 위해 몇가지 시도를 하였다. 우선 매주 전례상 의미있는 영상, 메시지 등을 카카오 채널 메시지로 보내고 미사를 중계하고 있다. 말씀나눔, 회의 등을 비대면으로 진행했다. 수녀님이 오시고 부제님이 생기고 학사님도 두분 생겨서 축하식을 진행했다. 단톡방을 만들어 청년들과 코로나19 봉사를 함께 하고 있다. 사순시기에 매주 여러가지 활동들을 진행했고, 십자가의 길, 함께 기도문 만들기도 했다. 성삼일에 미사 복사 및 수난감실 성체조배를 했고 부활시기엔 성경쓰기를 하여 성당에 비치했다. 성가대 모임을 재개했고, 성서모임도 시작하여 매주 진행중이다. 청년 전례학교 초급을 안내하고, 성모성월 편지를 작성하여 성모의밤 행사에 참여했다. 서울대교구 본당임원 연수, 10지구 청년회의 등에 참여하여 우리가 진행하고 있는것들을 공유하고 하반기 일정을 계획했다. 어버이날 행사와 연합회 홍보겸 말씀캔디를 나누었다. (적다보니 많네;)
변화하지 않는 조직에 변화를 주기 위해서는 우선 나 혼자라도 시도해보고 관심있는 사람이 있으면 점진적으로 방안을 제시한다.
이 방법은 어디서든 효과가 있는듯하다. 아직 큰 변화가 있지는 않지만 지난해완 공기가 달라졌음을 느낀다. 상반기엔 기존 멤버들의 신앙 활동의 근력을 만들었다면 하반기엔 멤버를 늘리기 위해 몇가지 시도를 해볼 계획이다.

5. 결혼생활 그리고 일상

행복하다. 일상에 평화가 찾아왔고, 매우 안정적이다. 우리는 여러가지 면에서 건설적인 계획들을 세우고 실천 중이다. 함께 자라고 나아가고 있고 합리적인 결정들을 하고 있다. 이 소중한 시간들을 잘 키워가야겠다.

* 정리하면

올해 상반기도 교양, 운동, 프로그래밍은 역시나 뒷전이다.
Social Life는 오픈소스 활동과 커뮤니티 활동, 블로그 포스팅을 제외하곤 목표치를 달성했다.
Business도 대출상환이 힘들기는 했으나 그 외의 항목에서 의미있는 결정들을 할 수 있었다.
DevOps는 강의를 준비하며 역량을 약간 올렸으나, 우테코 서비스에 반영하지 않은 점은 다소 아쉽다. 쿠버네티스 환경으로 배포시 다른 팀원들이 트러블슈팅하기 어려울거란 판단이 서 도입하지 않았다. 다만 레벨2 제작근로를 통해 프론트엔드 크루들이 사용할 미션을 배포/운영해보았고, 크루들이 스크립트 등을 돌려가며 부하를 주었지만 안정적으로 운영하였다. 역시 사전 부하테스트는 운영자에게 심리적 안정감을 준다.
Health는 지난해와 비슷한 양상을 보인다. 의미가 있는 활동이라면, 지난해 술을 끊었고 올해 커피를 끊었다. 그리고 의도한 것은 아니지만 라면을 먹지 않고 있다. 하지만 그리고 역시나 운동이 필요하다.

따라서 하반기에는 Programming과 Backend에 리소스를 집중할 계획이다.
1. 사이드 프로젝트를 진행할 계획이다. 얼마전 다시 멘사 홈페이지 위원장을 맡았다. 이번에는 리뉴얼을 감행해볼 계획이다.
2. NEXTSTEP 플랫폼의 테스트 커버리지를 다시 높이고, 몇몇 packages를 리팩토링할 계획이다.
3. 하반기엔 Javascript를 다시 학습해볼 계획이다.
4. 인프라공방을 꾸준히 오픈할 계획이고 우테캠Pro 3기의 프로젝트 과정을 설계할 계획이다.
5. 와이프와 필라테스를 신청했고 꾸준히 할 계획이다.

상반기에 고생 많았고, 하반기에 다시 재밌는 것들 좀 해보자

2020년 회고

가그린민트 — Mon, 4 Jan 2021 14:40:40 +0900

2020년은 안식년이었다. 참 오랜만에 일상을 살아본 것 같다.

얼마전 회사에서는 하반기 본인 평가를, DevC에서 원격회고, 그리고 와이프와 새해 다짐 등을 하고 나서 이 내용을 바탕으로 2020년 회고를 작성해본다.

1. 결혼

자세한 내용은 링크를 참고해보시길

사랑하는 사람을 만나 3월에 연애를 시작하여 199일 째인 2020.10.10에 결혼을 했다. 결혼을 준비해가는 과정에서 158개의 Task를 수행했고, 그 과정에서 스드메 / 가전 / 가구 / 예단 / 예물 / 예복 / 청첩장 / 결혼식 등 지금까지 경험해보지 못했던 다양한 부분에서 결정을 해야 하는 순간들이 있었다. 덕분에 일상을 살아보는 계기가 되었고, 가족에 대해 생각해볼 수 있었다.

와이프를 만나고 가장 변화된 점이 건강에 대한 시각이다. 그동안에도 먹는 것을 소홀히하지는 않았지만 가족 구성원 모두가 영양소를 이해하고 따져가며 먹는터라, 덕분에 이해의 폭이 넓어졌다. 수면시간의 경우, 20대 이후로 평균 5시간 내외였는데 최근들어 7시간까지 늘어났다. 그리고 연애를 시작한 이후로 술을 끊었다. 때때로 거절하기 어려운 시점들도 있었지만, 아직까지는 일관되게 의사표시를 하고 있다.

두번째로 변화된 점은 소비 패턴이다. 기존에는 불필요한 물건을 하나 안사는 것이 10가지 혜택을 받는 것보다 낫다는 생각을 했었다. 물론 ~~(그 생각에는 지금도 크게 변함은 없다.)~~ 그러다보니 엔간하면 물건을 사지 않았는데, 생활하는데 필요한 가전이나 도구가 삶의 질과 생산성을 높인다는 것을 경험하는 한 해였던 거 같다. 추가적으로 전세집을 장만하고 나서 자산에 대한 시각이 바뀐 점도 꽤 유의미하다.

마지막으로 삶에 대한 시각이다. 어떻게 살아가야 하고, 어떻게 관계지어가야 할지, 좋은 영향을 주고 받았다. 덕분에 한동안 불안정했던 심리상태도 정리하는 한해가 되었고, 사회 초년생으로서의 5년을 정리해보는 시간을 가질 수 있었다.

2. 우아한테크코스

2019년도에 이어 우아한테크코스 2기를 진행했다. 개인적으로는 프로젝트, 정규직 전환, 온라인 강의, 외부 강의, K-Digital Training 등이 기억에 남는다.

강의 컨텐츠의 경우, Java8, SQL, 네트워크 등의 강의 컨텐츠 품질을 개선하였고, 유저 스토리 & 사용성, 서비스 구성하기, 배포 강의 및 프로젝트 미션 설계 등을 통해 올해 변화된 커리큘럼에서도 크루들이 프로젝트를 원활히 수행하도록 고민했던 점이 기억에 남는다. 그리고 안정적인 서비스를 구성하며 필요한 지식들(무중단 배포, 화면 응답 개선, 조회 성능 개선 등)을 정리하며 스터디와 강의를 진행했고, 이런 부분들이 우아한테크캠프 Pro 강의를 만드는데 많은 도움이 되었던거 같다. 추가적으로 소프트웨어 교육자 공개 설명회, 테크코스 강의, 사내 비개발자 대상 SQL & 제플린 강의, SSAFY 특강 및 인터뷰 등을 온라인 강의로 진행하고 면담을 진행하여 코로나19에 대응한 점이 유의미했다. 그리고 지난 1기의 공통적인 고민이었던 '현재 학습 수준 파악', '본인이 설계한 학습전략에 대한 불안감' 등을 해소하고자 로드맵을 작성하였고, 이를 토대로 멘토링을 진행한 결과 보다 직관적인 메시지를 줄 수 있었다고 생각한다.

2020년엔 ssafy 채용박람회 참여(상/하반기), 사내 SQL 강의, 우테캠 Pro, 카카오 신입사원 교육 및 그 외 몇가지 외부 강의가 있었다. 올해 미뤄뒀던 개인 강의도 오픈할 계획이고 몇몇 강의 컨텐츠도 만들어둘 계획이다. 올해는 지난해 아쉬웠던 온라인 강의에 좀 더 익숙해지는 한해가 되길 바래본다.

K-Digital Training은 고용노동부와 진행하는 사업이다. 우형이 언제까지 교육에 투자할까, 교육을 확대하기 위한 예산을 얼마나 확보할 수 있을까 고민하기보다 우리가 먼저 안정적인 상황을 만들어보자는 생각에 시작했다. 생각보다 이것저것 해야할 일들이 많았지만, 나름 재미요소도 있다. 앞으로 확대되어 NHN Next와 같은 사례로 남지 않길 바래본다.

크리스마스별이 뜨던 날, 물의 정원에서

2021년에는..

1. 올 한해는 Nextstep 플랫폼 개선, 팀 내에서 사용할 몇가지 도구 개발 등 프로그래밍에 집중할 계획이다. 최근 SwiftUI를 시작했는데, 올해 와이프와 함께 앱 런칭도 해보려고 한다.

2. 강의는 개인 강의 (Service TMT)를 3번정도 오픈할 계획이고 그 외로 사내 SQL 강의와 네트워크/CS 관련 영상을 만들어볼 계획이다. 그 외로 테크세미나, 기술 블로그 포스팅 등의 지식 공유도 욕심내보고 있다.

3. 결혼 준비를 하면서 체중이 많이 늘었다. 70kg까지 다이어트를 하는 것이 목표이고, 작년에 이어 올해도 요가를 틈틈히 하려고 한다. 먹는 것은 지금과 같이 유지해가도 좋을 듯하고, 피부관리에 좀 더 신경을 쓸 계획이다.

4. 성당에서 전례단장을 시작으로 2021년엔 청년회장까지 하게 되었다. 코로나19로 종교의 위치가 더욱 어려워진 시기에 선한 영향력이 미치도록 올 한해도 노력해보려고 한다.

2020년 상반기 회고

가그린민트 — Sun, 5 Jul 2020 15:46:29 +0900

이번 상반기 회고는 하지 말까하다가 그래도 기록으로 남겨두는 것이 좋을 거 같아 작성해본다.

총평을 하자면, 하나의 큰 변화가 있었고 그 외 대체적으로 망했다.
행복하고 뜻 깊은 시간은 분명했으나, 이렇게 오래 지속되기는 힘들거라 생각한다. 그 이유에 대해서 이야기해본다.

우선 상반기 나의 목표는, MySQL 내실을 다지고 컨텐츠로 만들어 외부 강의를 하는 것이었다.
그렇게 시스템 아키텍처의 한 부분씩 준비를 하여 자신이 원하는 시스템 디자인에 필요한 부분들을 취합해서 들을 수 있는 커리큘럼을 만들고 싶었다. 하지만 공부도 안했고, 강의 준비도 안했다. 놀았기 때문이다. 놀아도 너무 놀았다
1월에 시작했던 안식월이 지금까지 계속 될 줄이야..

4기에 작성했던 글또 글도 보면, 쿠버네티스 네트워킹은 이미 어느정도 정리해뒀던 주제였고 이마저도 쓰다 말았다. 일급컬렉션과 불변객체 관련 주제는 의미가 있는 주제들이기는 하나, 이미 알고 있는 내용들을 정리한 것으로 작성하는데 20분도 안걸렸다. (개인적인 성장에는 별 도움이 되지 않았다) User Story와 Usability는 강의 준비하는 과정에서 개발자 외의 시각을 엿볼 수 있어서 나름 의미있는 시간이기는 했다. 하지만 전반적으로 글또 매 기수마다 하나의 주제를 시리즈로 작성했던 것을 반추해보면, 이번 4기에는 학습이 제대로 이루어지지 않았음을 반증한다.

상반기에 나름 목표로 두었던 로드맵도 야심차게 망했다. 테크코스 1기 크루 2명과 함께 사이드 프로젝트로 진행했고 반복주기를 나누어서도 해보고 오프라인 미팅을 가져보기도 하고, 이슈 관리나 리뷰 등도 진행해보았지만, 동기부여를 주지 못했고 몇차례 싸이클을 돌다 멈춰버렸다. 무엇보다도 내가 몰입하지 못했던 것이 가장 큰 이유겠다. 우선은 전반의 컨셉을 정리하고 앞으로 컨텐츠를 어떤 방식으로 채워갈지 가이드라인을 잡은 정도에서 첫번째 반복주기를 마무리짓기로 했다.

테크코스 역시 아쉬움이 많이 남는다. 레벨1, 레벨2 조별 크루들과의 관계도 아쉬움이 많았고 무엇보다 코드리뷰를 진행하지 않으니 크루들의 상태가 어떤지 알기가 어려웠다. 물론 개개인 면담을 통해서 관계를 형성해간 크루들도 있었으나, 코로나 등의 이슈로 작년과는 다른 분위기가 뭇내 아쉽다. 내부 강의는 그런대로 만족스럽다. java8 lambda, SQL, 배포, 유저스토리 등의 강의를 하였는데, 강의 컨텐츠는 지난해보다 다소 개선되었다고 생각한다. 그 외로도 내부 채용을 위해 진행한 교육자 경험기를 시작으로 유저스토리 강의와 SSAFY 특강까지 유튜브 실시간 스트리밍으로 진행해보았는데, SSAFY에서 좋은 피드백을 받아 나름 유의미한 시간이었다. 그런 여러가지 이유들로 외부 강의를 처음부터 온라인으로 여는 것을 고려중이다.

플랫폼 개발 역시 너무 아쉬운 부분이 많다. 상반기에 내가 작업한 부분은 경악할만한 수준이라, 갑자기 현타가..

상반기에 유의미한 결과로는, 정규직 전환(우형은 전환 개념이 없어서 다시 채용프로세스를 밟아야 했다.), 강의 컨텐츠의 품질을 높인 것, 유튜브 강의를 경험해본 것 정도이고 추가적으로 소규모의 개발팀을 운영해본 부분(근로장학생)과 어쨋든 로드맵을 작성해본 것 정도겠다. 특히 근로장학생들에게 처음에 어떤 프로젝트를 맡길지 애매했었는데, 내가 만든 토이프로젝트(슬랙 채널 아카이빙 서비스)를 기반으로 크루들이 작업을 점진적으로 진행하며 소통하는 것을 보고 이런 형태의 교육도 좀 더 세밀하게 설계해보아야겠다는 생각을 하게 되었다.

사실 이번 상반기가 이렇게 부진한 것은, 연애를 시작했기 때문이다. 처음 하는 연애라 모든 것이 도전거리였고, 이제 100일이 지난 시점에 프로포즈를 하기까지 많은 일들이 있었다. 99일 뒤 결혼을 앞둔 시점에 청첩장과 예복, 이사를 제외한 대부분의 준비가 이루어질 수 있었던 것도, 그리고 이렇게 복에 겨운 시간을 보낼 수 있었던 것도 정말 여러모로 감사할 일이다. 그리고 연인과 함께 하면서 그동안 소홀히했던 일상이라던가 건강 등을 돌아보는 계기가 되었다.

하지만 지속가능한 건강한 삶을 위해서는 균형감있는 성장이 필요하다고 생각한다. 결혼 준비가 막바지에 다른 시점이라, 7월 중으로는 외부 강의에 박차를 가해 마무리 짓고(개인 연차도 이 기회에 많이 소진할 계획이다), 8월에 5명 정도를 대상으로 스터디를 진행해볼까 한다. (10월에 결혼이라) 11 ~ 12월 경에 외부 강의를 여는 것을 목표로 하고 있다. 이래저래 아쉬운 점이 많은 상반기지만, 앞으로 더 길고 멀리가기 위한 전환점이라 생각하고 Nextstep을 준비하고자 한다.

User Story와 Usability

가그린민트 — Sun, 7 Jun 2020 16:17:35 +0900

우아한 테크코스 레벨3와 레벨4의 커리큘럼을 바꾸면서, 크루들에게 프로젝트 준비를 위한 시간이 주어졌다. 기획서를 작성하고 프로젝트를 준비하는데에 앞서 어떤 메시지를 주면 좋을지 고민이 시작되었다. 그러다 문득 User Story를 작성해보는 것도 좋겠다는 생각이 들어 강의와 실습 컨텐츠를 만들어보았다. 이 자료는 인간중심 UX 디자인과 사용자를 생각하게 하지마를 참고하여 만들었다.

User Story는 사용자 상을 제작하고, 사용자의 시나리오를 작성한 후 요구사항으로 도출된다. 아래에서는 http://edu.nextstep.camp/ 을 가상으로 작성해보았다. 요구사항을 도출하기까지 사용되는 In-Depth Interview와 사용성을 위해 진행하는 Usability Test를 비교해 보는 것도 좋을거라 생각한다.

‍ ‍ ‍ 1. 사용자

실용주의가 없는 장인정신은 장인정신이 아니다. 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족이다. 품질은 물론이고 시간과 비용도 고객 만족을 위한 구성요소다. 고객에게 가치를 전달할 수 없다면 잘 작성된 코드라고 할 수 없다. by 소프트웨어 장인

기사에서 시사하듯, 소프트웨어(혹은 서비스)는 사용자를 중심에 두어야 한다.

1) 잠재 사용자 파악하기

(1) 사용자 리서치

사용자가 이미 경험한 것들(어떤 인식/태도를 가지고 있는지)를 파악하면 사용자 스토리가 도출된다.
유사한 서비스를 사용하는 사용자를 대상으로 리서치를 한다.

a. 그럴듯한 사용자 역할 찾기

제품	예상 역할
교육 서비스	강사, 학생, 강의 컨텐츠를 관리하는 사람, 시스템 관리자 등
구매 서비스	판매자, 구매자, 주문 요청을 처리하는 사람, 배송받는 사람, 시스템 관리자 등
이메일 서비스	이메일 계정 소유자, 외부 이메일 수취인, 시스템 관리자 등

b. 인터뷰 주제

* 작업을 이해하는 것도 중요하지만, 왜 그 작업이 존재하는지 이해해야 한다.

- 작업 빈도와 우선순위

일반적으로 어떤 일을 가장 먼저 합니까? 그 이유는?
어떤 일을 가능한 미룹니까?
어떤 일들이 시간을 낭비하게 만듭니까?
단지 한두가지 일을 할 수 있는 시간이 더 생긴다면, 무엇을 하겠습니까?
왜 그 업무에 더 많은 시간을 투자합니까?

- 현재 제품의 역할

제품을 얼마나 자주 이용합니까?
현재의 제품을 어디에 가장 많이 이용합니까?
어떻게 이용하는지 보여주실 수 있을까요?
이 도구를 사용하기 전에 어떤 다른 도구들을 이용합니까?
어떤 도구와 함께 제품을 사용합니까?
이 제품을 사용한 후에 어떤 도구를 사용합니까?
동일 작업에서 사용한 다른 도구와 이 제 품을 어떻게 비교할 수 있을까요?

c. 인터뷰하기

참가자들에게 보여달라고 요청하라
유도 질문을 하지 마라
인터뷰 참가자에게 해결책에 대해 묻지 마라
인터뷰 도중 문제를 해결하려고 하지 마라
무엇이 좋은 경험을 만들까요? (목적에 대해 직접적으로 질문하면, 유용한 답변을 얻지 못한다.)

* 멘탈 모델 객체와 속성

멘탈모델은 사용자의 기존 경험, 인식 등으로 형성되며, 시스템의 개념구조와 동작이 사용자의 멘탈모델과 일치하면, 대개 시스템은 사용하기 쉽다.

멘탈모델	객체속성
이메일 메시지	- 누가 보냈는지 - 누가 메시지를 받는지 - 언제 보냈는지 - 무엇에 관한 것인지 - 어떤 첨부물이 있는지 - 상대방이 어떤 행동을 하였는지(전달, 답장 등) - 얼마나 급한 행동인지
연락처	- 어떻게 그들에게 연락할 수 있는지 - 어디서 일하는지

d. 다른 자료들 활용하기

기존 설문조사를 활용하거나 기존 서비스를 벤치마킹하는 것도 좋다. 추가적으로, 웹 로그 등의 데이터는 어디에 문제가 있을 수 있는지 파악하는데 유용하지만 왜 그 문제가 발생하는지 설명하지 못한다.

(2) 데이터 이해하기

모델링의 요점은 데이터를 이해할 수 있게 다듬어서 리서치 내용을 충분히 이해한 상태에서 의사결정을 내릴 수 있게 돕는 것이다.

개별 데이터	아이디어
- 씨유는 일주일에 최소 한 번 수강생들에게 독려 메일을 보낸다. - 포비는 수업 대기신청한 사람들에게 이메일을 보낸다.	이메일 보내기
- 준은 수강생들이 프론트엔드 미션을 잘 소화하도록 며칠에 한번씩 강의 컨텐츠를 올린다	웹 사이트에 교육 컨텐츠 올리기
- 제이슨은 DDD 교육 컨텐츠를 판매한다.	웹 사이트에 상품 컨텐츠 올리기
- 소니는 2일에 한번은 리뷰 요청을 한다	웹 사이트를 통해 코드리뷰 요청하기

2) Persona 작성하기

Persona란, 잠재 사용자들의 다양한 목적과 관찰된 행동 패턴을 응집시켜 놓은 원형이다.
따라서, Persona를 통해 제품을 정의, 디자인할 수 있다. Persona를 통해 형성된 공통된 '사용자'를 생각하면서 작업을 진행한다.

(1) 패턴 분석하기

행동 변수란 인터뷰 참가자들간 차이가 있는 행동 및 사고방식들을 의미한다.
모집단이라고 믿는 대상과 비교하지 말고 각 인터뷰 참가자들끼리 비교하면서 배치한다.
자주 함께 보이는 사람들을 동그라미 쳐둔다.

강의 경험이 많은 강사	강의 경험이 적은 강사	수강생	리뷰어
- 기존 교육 컨텐츠를 판매 - 빈번하지 않은 독려 메일 - 수강생과 자주 이야기 하지 않음 ...	- 교육 컨텐츠 작성에 많은 시간 할애 - 수강생과의 관계에 집중 - 리뷰어와 어느 정도 자주 이야기함 ...	- 프로그래밍 학습에 많은 시간 할애 ...	...

(2) 목적 정의하기

각 목적은 동사로 작성한다.

강사	수강생	리뷰어
- 자기 브랜딩을 하고 싶다 - 강의를 판매하고 싶다 - 리뷰어 품질관리를 하고 싶다	- 프로그래밍 실력을 높이고 싶다 - CS를 학습하고 싶다 - 나의 학습 상태를 확인하고 싶다	- 수강생들과 소통하고 싶다 - 코드리뷰 품질을 높이고 싶다

특이점을 명확히 한다.
Persona간 우선순위를 정한다.

(3) 개별 Persona 설명하기

러너

- 28세
- 3년차 백엔드 개발자
- SI업체
- 비전공
- Mac 사용

현재 수강중인 수업: ATDD
- 수강한 이유 : 인수테스트 역량을 키우기 위해
- 이전에 들었던 수업 : Clean Code
- 이전 수업의 미션 완료율 : 100%
- 리뷰 요청 주기 : 평균 2일에 한번
- 평균 수업료: 77만원
- 수강대기 신청 이유 : 다음 강의를 바로 신청하고 싶었음
- 신청 전 방문 횟수 : 3회

Needs
- 프로그래밍 역량을 키우고 싶다.
- 수강 후 이직 멘토링을 받고 싶다.

Customer Job
- 프로그래밍 역량을 키워서 원하는 곳으로 이직을 할 수 있다

2. 유저 스토리 도출하기

1) 시나리오 제작하기

시나리오는 Persona 관점에서 기술한다. Persona에 의한 행동의 결과로서 Persona와 시스템 사이의 인터렉션을 묘사한다.

제품	페르소나	시나리오
이메일 시스템	강사	- 개강 알림 메일 보내기 - 독려 메일 보내기
이메일 시스템	수강생	- 질문 메일 보내기 - 수료증 요청하기 - 멘토링 신청하기
구매 플랫폼	구매자	- 구매요청

정황 시나리오는 버스를 타기 위해 현금을 인출해야 하는 '맥락', 카메라 메모리가 가득 찼기 때문에 업로드해야 하는 '니즈', 구매 요청 접수증 등 '특정 계기'로 시작한다. 정황 시나리오에서 해결안을 미리 제공하지 않아야 한다.

러너는 다음 주에 모집 예정인 ATDD와 DDD 수업들의 알림 메시지를 받았다. 반복적인 유지보수 업무에 지친 그는 이직 준비를 위해 Nextstep에 접속했다. 홈페이지에서 각 과정에 대한 정보들을 확인한 후 수료생들의 미션에 대한 코드리뷰를 확인했다. 그는 브라운 강사에게 이번 ATDD 과정을 수강하려면 어느정도 역량이 필요한지 메시지를 보냈다. 얼마후 워니 강사에게 이전에 요청했던 이력서 피드백을 받았다.

2) 시나리오에서 요구사항 도출하기

시나리오	요구사항
러너는 다음 주에 모집 예정인 ATDD와 DDD 수업들의 알림 메시지를 받았다. 반복적인 유지보수 업무에 지친 그는 이직 준비를 위해 Nextstep에 접속했다.	- 개강 알림 메시지를 보낼 수 있어야 한다. - 메일에서 과정페이지로 접속할 수 있어야 한다.
홈페이지에서 각 과정에 대한 정보들을 확인한 후 수료생들의 미션에 대한 코드리뷰를 확인했다.	- 과정 목표, 커리큘럼, 수강생 리뷰 등을 한 화면에 보여줄 수 있어야 한다. - 코드 리뷰를 볼 수 있어야 한다.
그는 브라운 강사에게 이번 ATDD 과정을 수강하려면 어느정도 역량이 필요한지 메시지를 보냈다.	- 강사에게 메시지를 보낼 수 있어야 한다 - 강사는 메시지에 대한 알림을 받을 수 있어야 한다.
얼마후 워니 강사에게 이전에 요청했던 이력서 피드백을 받았다.	- 강사는 이력서 피드백을 등록할 수 있어야 한다. - 수강생은 피드백이 완료되면 알림을 받을 수 있어야 한다.

3. 사용자를 고민에 빠뜨리지 마라

누구나(평범한 능력과 경험을 가진 사람)이 어려움없이 사용법을 알 수 있어야 하며, 투입한 수고에 비해 얻은 가치가 커야 한다.

1) 아래 질문에 답해보자

유용성 : 사람들이 필요로 하는 일을 하는가?
학습 용이성 : 사람들이 사용법을 알아볼 수 있는가?
기억 용이성 : 사용할 때마다 사용법을 다시 익혀야 하는가?
유효성 : 맡은 임무를 완수하는가?
효율성 : 작업을 수행하는데 드는 시간과 노력의 양은 합리적인 수준인가?
호감도 : 사람들이 이것을 갖고 싶어하겠는가?
재미 : 사용할 때 즐겁거나 재미있다고 느끼는가?

2) 우리가 실제로 웹을 사용하는 방법

사용자는 웹 페이지를 읽지 않는다. 훑어본다. 한번에 여러 개를 만들어서 잘 보여주고 싶다는 욕망을 버려라.
사용자는 최선의 선택을 하지 않는다. 최소 조건만 충족되면 만족한다.
- 사용자는 보통 시간에 쫓긴다.
- 추측이 틀렸을 때 발생하는 불이익이 별로 없다.
- 선택지를 비교하더라도 결과가 나아지리라는 보장이 없다.
사용자는 작동방식까지 이해하려 하지 않는다. 적당히 임기응변한다.

3) 심각한 문제

여러번 생각을 하게 되면 피로도가 쌓여서 이탈하게 된다.

a. Usability Test

사용성 테스트란, 고객이 우리가 제공하고자 하는 서비스의 구조와 기능을 의도한 대로 인지, 이해, 예측, 실행 할 수 있는가를 확인하기 위한 리서치 방법론 중 하나이다. 참여자에게 특정 과제를 부여한 뒤 관찰을 통해 사용성의 문제점을 발견하는 방법이다.

즉, 사용성 테스트는 사람에 대해 알아보는 것이 아니라, 인터페이스에 대해 문제없이 사용할 수 있는지를 확인하는 것으로 의견이나 과거 사용 경험 등을 묻지 않는다.

* 얼마나 진행해야 할까

* UT를 통해 알 수 있는 것

이 기능을 발견할 수 있는지
이 기능은 사용할 수 있는지
이 Task를 쉽게 완료할 수 있는지
정보를 쉽게 이해할 수 있는지
사용자가 필요한 모든 정보를 얻을 수 있는지

* UT를 통해 알 수 없는 것

사용자에게 앱이 유용한지
어떤 다른 기능을 추가하면 좋은지

유용성 조사에서 선호도를 요구하는 것은 함정이 될 수 있다. (한 사람에게 A/B테스트하지 마라)

4) 호감에 영향을 주는 요인들

a. 부정적인 요인

사용자가 원하는 정보 숨겨두기
사용자를 귀찮게 하기. 전화번호 사이에 (-), 카드번호 공백 등을 사용자에게 넣으라고 강요하지마라
필요하지도 않은 정보 물어보기
가식적인 표현으로 사용자 기만하기
홍보용 장치로 작업 방해하기
아마추어 수준의 사이트 제작

b. 긍정적인 요인

사용자가 가장 많이 하는 활동을 찾아 명확하게 드러내줘라
사용자가 알고자 하는 정보를 공개하라
궁금해할 만한 내용을 예측하고 미리 답을 제시해라
오류가 발생했을 때 쉽게 회복할 수 있게 하라
해결하지 못한 문제가 있을 때는 사과하라

불변객체란

가그린민트 — Sun, 12 Apr 2020 11:07:30 +0900

https://edu.nextstep.camp/c/8fWRxNWU/

클린코드를 위한 TDD, 리팩토링 with Java

edu.nextstep.camp

일급컬렉션 피드백에 이어, 많이 하는 피드백이 불변객체를 작성하라는 것이다.

Effective Java에서는 '변경 가능성을 최소화하라'는 챕터를 통해 불변 객체를 소개한다. '불변 객체'는 인스턴스 생성 이후 내부 인스턴스 변수들을 수정할 수 없어야 한다. 이에 근본적으로 Thread-safe하므로 동기화 작업을 할 필요 없어 오류 가능성이 적고 실패 원자성을 제공한다.

불변 객체를 작성하기 위해 Effective Java에서는 아래의 규칙을 소개한다.

- 객체의 상태를 변경하는 메서드를 제공하지 않는다. 즉, setter 메서드 등을 통해 인스턴스 변수의 값을 변경하는 메서드를 작성하지 않아야 한다.

- 클래스를 확장할 수 없도록 한다. 그리하여 하위 클래스에서 의도치 않게 인스턴스 변수를 변경하는 것을 막아야 한다. 정적 팩토리 메서드를 작성한다면 생성자를 private으로 작성하기에 다른 패키지에서 이 클래스를 확장하는 것이 불가능해진다. 그 외에도 final class로 선언하고 모든 멤버 필드를 final로 적옹하여 상속을 막을 수 있다.

- 모든 필드를 final로 선언한다. java에서 final 예약어는 해당 객체를 가리키는 포인터를 바꿀 수 없게하는 의미를 까지지만, 코드 작성자의 의도를 명확히 드러내는 것만으로도 유의미하다.

- 모든 필드를 private으로 선언하여 직접 멤버 필드에 접근하는 것을 막을 수 있다.

- 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다. 즉, 외부에 인스턴스 변수를 반환할 경우 (getter 등에서) 방어적 복사본을 만들어야 한다. - 관련 링크

이 포스팅은, Collections 라이브러리의 unmodifiableList API를 어떻게 활용하는 것이 좋을지 피드백하다 작성하게 되었다. unmodifiableList 는 List에 read-only 상태로 접근 가능하도록 하며, List에 수정을 가하려고 할 경우 UnsupportedOperationException를 반환하도록 한다. - 관련 링크

final class ImmutableCart<T> {
    private final List<T> items;
    public ImmutableCart(final List<T> items) {
        this.items = Collections.unmodifiableList(items);
    }
    public List<T> getItems() {
        return new ArrayList(items);
    }
}

unmodifiableList를 생성자에서 사용하여 전달받은 값을 방어적 복사하고, getter에서 객체를 생성해서 반환하는 것도 좋은 전략이라고 생각한다. final 예약어를 사용하였으므로 값을 재할당할 수 없으며, unmodifiableList는 값을 수정할 시에 예외를 발생시키므로 Item을 교체하지 못한다는 의미가 분명해질 수 있다. 이에 내부에서 값을 재정의하는 메서드를 작성하는 것을 방지하는 효과를 가져온다.

getter에서도 unmodifiableList를 사용할 경우 Deep Copy가 되지 않는다는 점이 우려가 있지만, Item이 Value Object로 작성하여 불변성을 보장할 경우 속성을 변경할 수 없고 Collection에 직접 Item을 교체하는 api를 제공하지 않으므로 불변을 보장할 수는 있다. 다만, 이 경우 외부 사용자 측면에서는 기대하지 않은 예외 (unsupportedoperationexception)에 직면하여 좋지 못한 경험을 준다는 단점이 있으며, unmodifiableList은 비즈니스 로직을 읽어내는데 저해된다는 주장도 있다.

추가적으로, 위키에서는 불변객체 작성시에 생성자에서는 방어적 복사 후 Collection 요소들의 타입 검사까지 진행하며, getter에서는 내부 필드의 방어적 복사를 수행하도록 가이드 한다.

결국, 불변객체를 어떻게 작성할 지는 답이 있는 영역이라기보다는, 팀 컨벤션으로 조율해갈 문제라고 생각한다. Effective Java에서 가이드하는 불변성을 보장하는 범위에서 어떻게 구현할지 합당한 논리만 견지하시면 좋다고 생각한다.

일급컬렉션에 대하여

가그린민트 — Mon, 30 Mar 2020 03:03:39 +0900

https://edu.nextstep.camp/c/8fWRxNWU/

클린코드를 위한 TDD, 리팩토링 with Java

edu.nextstep.camp

TDD, 클린코드 코드리뷰를 하다보면 '원시값과 문자열을 포장하라', '일급콜렉션을 쓴다'와 같은 피드백을 주곤한다. Wrapper Class를 작성하는 데에는 어려움이 없지만, 일급콜렉션을 학습하는 과정에서 보통 동욱님의 블로그를 접하는데 두번째 특징인 '불변성'으로 인해 혼란을 겪는다.
객체지향 생활체조에 제시된 일급콜렉션(First Class Collection)은 일급 시민(First Class Citizen)을 연상시킨다. 그리고 일급시민은 함수형 프로그래밍과 더불어 불변객체를 연상시킨다. 우선 일급시민은 무엇이고, 불변객체는 무엇일까?

일급시민은 1) 변수나 데이타에 할당 할 수 있고, 2) 객체의 인자로 넘길 수 있으며, 3) 객체의 리턴값으로 리턴 할수 있어야 한다. 자바는 1.8부터 동작을 파라미터화하여 전달할 수 있게 되었다.

1
2
3

getNumber(elm);
Function result = getResult();
List list = Arrays.asList(elm, result);

그렇다면, 불변객체는 무엇일까?
1) 객체를 변경하는 메소드를 제공하지 않는다.
2) 재정의할 수 있는 메소드를 제공하지 않는다.
3) 모든 필드를 final로 만든다.
4) 모든 필드를 private으로 만든다.
5) 가변 객체를 참조하는 필드는 배타적으로 접근해야 한다

즉, 객체의 상태를 바꿀 수는 없으므로 새로운 상태로 변경해야 할 경우 새로운 불변 객체를 만들어 기존의 불변 객체를 대체 시켜야 한다. 이를 통해 불변객체는 Side-effect 및 동시성 이슈에 노출되지 않는다. 따라서 함수형 프로그래밍에서 Side-effect를 발생시키지 않기 위해 불변객체를 사용하는 것이지, 일급시민의 특징이 불변성을 보장하는 것은 아니다.

그렇다면, 일급콜렉션은 무엇일까?
소트웍스 앤솔리지 설명을 토대로 보면, 우선 동욱님 블로그에서 설명하듯 '비지니스에 종속적인 자료구조', '상태와 행위를 한 곳에서 관리', '이름이 있는 컬렉션'의 특성을 가지고 있다. 이에 '원시값과 문자열을 포장하라'의 연장선상에서 자신만의 자료구조를 만들라는 의미에서 가이드를 한다고 이해하고 있다. 따라서 불변성을 반드시 보장해야 하는지는 알 수 없다. 물론 불변성을 지향할 경우 Side-effect는 발생하지 않겠지만, Collection 요소가 추가될 때마다 Collection을 새로 생성하는 등의 비효율성이 발생한다.

추가적으로, Collection이 불변성을 가질 수 있기 위해서는 어떻게 구현해야할까?
java에서 final 예약어는 해당 객체를 가리키는 포인터를 바꿀 수 없게하는 의미이다. 따라서 1) primitive type의 경우 불변이다. 2) reference type의 경우 값의 재할당은 안되지만, 속성을 변경하는 것은 가능하다. 이에 reference type을 불변으로 구현하기 위해서는 새로운 객체를 생성하여 반환하여야 한다. - [참고링크]

보통 일급컬렉션을 구현할 때 Collections.unmodifiableList를 활용한다. 이 경우 일급컬렉션이 속성으로 가지고 있는 Collection 값이 외부에 노출될 경우 값의 변경/추가/삭제는 불가하기에 불변성을 띄는 것으로 오해할 수 있다. 하지만 Collection에 담겨있는 Item의 속성은 변경이 가능하다. 따라서 Collections.unmodifiableList(new ArrayList<>(값))으로 한번 더 감싸 불변객체를 작성하거나, 값.stream().map(값의아이템::Clone).collect(toList()) 등과 같이 깊은 복사를 하여야 한다.

Kubernetes Networking #1

가그린민트 — Sun, 15 Mar 2020 16:23:30 +0900

이번 포스팅에서는 Kubernetes in Action, 매니징 쿠버네티스 을 활용하였습니다.

이 포스팅과 더불어 한우형님의 블로그, Rancher Labs 자료 등을 함께 보시면 더 좋습니다.

1. 기본적인 특징

* 네트워크 구성방식과 관계없이 파드간의 통신

- 모든 Pods는 다른 Pod와 NAT(Network Address Translation)을 사용하지 않고 통신할 수 있다.

- 모든 Nodes는 NAT를 사용하지 않고 모든 Pods와 통신할 수 있다.

2. Container-to-Container Networking

* NET namespace가 외부와 통신하는 방식

veth interface를 이용하여 두 개의 interface가 Pair를 맺은 후, 한쪽 Interface에 패킷이 들어오면 자신에게 연결된 다른 네트워크 인터페이스로 패킷을 보내주는 식으로 동작한다.

즉, container가 생성되면, 이 pair interface 의 한 쪽은 container 내부 namespace에 할당(eth0)되며, 나머지 하나는 vethXXXX 라는 이름으로 docker0 bridge에 binding된다. docker0는 docker 실행시 자동으로 생성되는 가상 브릿지로 Container는 외부와 통신할 때 docker0 브릿지를 거쳐 통신을 하며, docker0 브릿지에 할당된 IP 대역에 맞춰 컨테이너 IP가 할당된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

$ brctl show docker0
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02422a674d39       no              veth6bb114e
                                                        veth9517b99
                                                        vetha06291d
                                                        vethaf42c95
$ ip link ls
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 02:42:ac:11:00:0f brd ff:ff:ff:ff:ff:ff
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:2a:67:4d:39 brd ff:ff:ff:ff:ff:ff
7: vetha06291d@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
    link/ether 5a:0d:71:6c:7d:2f brd ff:ff:ff:ff:ff:ff link-netnsid 1
 
 
$ ethtool -S vetha06291d
NIC statistics:
     peer_ifindex: 6
 
$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
11f19f488ad3        bridge              bridge              local
0e4b12c5d30e        host                host                local
f2d26841d49a        none                null                local
 
 
$ docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "11f19f488ad3e93c199ceb1e9b22b9541a4777fe4916f1c7b379e93773ce26cf",
        "Created": "2019-11-28T06:15:22.406695801Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.1/24",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "09e556688ac65de82dbc4b08fe442853bbd3d2a2418e6564d9feb1677edf712e": {
                "Name": "k8s_POD_kubernetes-bootcamp-5b48cfdcbd-qzcsm_default_00dbb354-dc17-469c-a586-d5bd4d8158a9_0",
                "EndpointID": "7b8a3c0f47db0c39673fc1e5a82610cd094f3669d4b210f2c76796dfa2525222",
                "MacAddress": "02:42:ac:12:00:04",
                "IPv4Address": "172.18.0.4/24",
                "IPv6Address": ""
            },
 
$ docker ps -a
CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS               NAMES
09e556688ac6        k8s.gcr.io/pause:3.1   "/pause"                 About an hour ago   Up About an hour                        k8s_POD_kubernetes-bootcamp-5b48cfdcbd-qzcsm_default_00dbb354-dc17-469c-a586-d5bd4d8158a9_0

Kubernetes의 경우 실제 동작하는 컨테이너 외에도 pause 컨테이너가 생성되는 것을 확인할 수 있다. pause 명령으로 실행된 Container는 실제로도 쿠버네티스가 SIGTERM 명령을 내리기 전까지는 아무것도 하지 않고 Sleep 상태로 존재한다.

pause container의 역할을 파악하기 위해서는, 우선 Container network 방식 중 container 방식을 이해할 필요가 있다. [자세한건 여기]

Kubernetes는 Pod 내에서 컨테이너 생성시 Bridge 모드가 아닌 Container모드로 띄우는데, Container 모드는 아래와 같이 다른 컨테이너를 지정하여 띄울 수 있어 지정한 Container간 네트워크를 공유하는 형태로 생성할 수 있다.

1

$ docker run --net=container:{container_id} -d {image_name}

즉, 각 Container의 IP가 같으므로 외부에서 같은 IP로 접근하며, Container들은 서로 같은 port를 사용하는 것은 불가능하다.

pause 컨테이너는 pod의 컨테이너들이 namespace를 공유하여 컨테이너 간에는 localhost로 통신할 수 있게 한다. (IPC 통신도 가능)

그리고 Pod에서 init process 역할을 하여 좀비 프로세스를 거둬들이는 기능도 수행한다. [자세한건 여기]

3. Pod-to-Pod Networking

CNI(Container Network Interface) plug in은 Virtual device (switch, router, tunnel 등)을 생성하는 등 Kubernetes의 가상 네트워크를 구성한다. 구체적으로는, 1) veth pair를 만들어 pod와 가상 네트워크를 연결, 2) pod의 routing table을 설정(IPAM), 3) Proxy ARP 기능 등을 수행한다.

1) intra node

Pod에서 실행되는 컨테이너는 Pod의 네트워크 네임스페이스를 사용한다. Container 관점에서 Pod는 하나의 네트워크 인터페이스를 가지고 있는 물리 머신으로 보인다. 각 Container의 localhost는 Pod를 통해 노드의 물리적 네트워크 인터페이스(예: root의 eth0)에 연결된다. 하나의 Node안에서 Pod간의 통신은 동일 네트워크 대역대에 있으므로 ARP을 사용하여 이루어진다.

2) inter node

다른 Node간의 통신의 경우, 다른 네트워크 대역대(IPAM에 의해 네트워크 대역을 나누므로 Pod들은 고유의 IP를 가질 수 있게 되는 것이다. [Calito의 IP할당] 그렇지 않을 경우 아래와 같이 docker0 IP가 중복일 수 있다.)이므로 Default Gateway인 root의 eth0을 통해 외부로 패킷을 송신한다. (즉, OSI 7 Layer상 3계층 이상의 통신이 이루어진다)

Kubernetes는 이처럼 각 Node의 Bridge가 서로 겹치지 않게 주소 대역을 할당한 수 routing table을 작성한다. 이렇게 Virtual Network Interface와 Bridge, Routing Rule의 조합을 일컬어 overlay network라 한다.

/24 범위의 노드에서는 256개가 아닌 최대 110개의 Pod를 실행할 수 있다. 이렇게 하면 여유가 생겨서 지정된 노드의 Pod IP 범위에 일시적으로 IP 주소가 없어서 Pod를 예약하지 못하는 상황이 발생하지 않는다. /24보다 작은 범위의 경우 약 절반의 Pod를 해당 범위의 IP 주소로 예약할 수 있다. 물론 노드당 CIDR 범위를 줄여 IP 주소할당을 최적화하여 더 많은 클러스터를 생성할 수도 있다.

오리뎅이님의 쿠버네티스 네트워킹 장표 중 일부

2편에서 'Pod-to-Service', 'Internet-to-Service' Networking이 이어집니다

글또 4기 다짐글

가그린민트 — Sun, 1 Mar 2020 23:56:36 +0900

벌써 2기, 3기에 이어 4기이다.

이제 1년이 지났다고 생각할 수도 있지만 상황이 많이도 변했다. 2기 시작할 무렵에는 다른 회사에 있었고, 백엔드 개발자 내지 데이터 엔지니어로 반년 정도 일을 한 상태였고, 개발자 행사나 모임에 이제 막 발을 들이는 시기. 모든 게 아직은 많이 낯설던 때였던 거 같다. 3기를 시작할 무렵에는 테크코스며 이런저런 행사며 스터디들로 정신이 없다가 그렇게 한 해를 마무리하고 4기를 시작할 즈음이 되었다.

사실 올해 1월부터는 계속 쉬고 있다. 굳이 갭이어를 두지 않아도 되겠다고 느낄 정도로 1월에는 팀 전체가 안식월을 보냈고, 2월에 어떻게 일을 시작하나 싶더니 코로나 이슈로 모든 일정이 미루어졌다. 그렇게 나태해질 즈음 글또가 적절한 균형감을 줄 수 있게 된 거 같아 다행이다.

나름의 다짐이라면,

이번 글또에서의 목표는 꾸준하게 글을 포스팅하는 것이다. (언제는 아니었겠느냐마는..) 이번 상반기에는 많은 욕심을 내지 않기로 하였다. 우선 작년에 작성하다만 쿠버네티스 네트워크를 포스팅한 후, MySQL 다시 공부하기를 주제로 장애 시 응급처치 방법 및 성능 개선 대상 식별, 인덱싱 + 실행계획, SQL 성능 개선, 캐시와 배치 처리, 트랜잭션, 백업 및 복구 전략 등의 목차로 포스팅할 계획이다. 그 외의 주제는 학습하다 인사이트를 얻을 경우 정리해서 포스팅하는 정도로 마무리할까 한다. ~~(글또는 경험상 하나의 스터디 주제를 메인으로 글을 쓸 때 효과가 가장 좋았던 거 같다.)~~

지속성장하기 위해서 글또는 너무 매력적인,

늘 하는 이야기이지만, 학습이란, 배우고 익힌다는 의미로 생각하고 있고, 교육은 지식 및 기술을 가르치고 길러낸다는 맥락으로 이해하고 있다. 익히는 과정에서 일정 산출물을 내는 작업은 분명한 목표를 산정함으로써 동기부여를 일으키는 한편, 인출 과정을 거치면서 장기기억으로 변환되기도 한다. 그리고 그것을 교육하면서, 교육한 대상과 공동학습을 하게 되고 한 단계 더 성장한다고 생각한다. 무엇보다 산출물을 공유하면서 개개인은 학습한 내용을 정제하는 한편 공유문화를 확산하여 지식의 선순환 구조를 가져갈 수 있다고 생각한다.

그런 맥락에서 올 상반기에는 글또 외에 몇 가지 목표가 있다. 우선은, 백엔드 개발자를 위한 로드맵의 완성도를 높여가는 것이다. 1기 크루들, 그리고 더 나아가 다양한 개발자들과 함께 만들어가려면 어떤 단계로 진행해갈지 고민 중이다. 많은 형태로 개발자 로드맵들이 제시되지만, 너무 추상화된 부분도 많고 범위도 넓어서 로드맵이 정작 필요한 주니어 개발자들에게는 다소 접근하기 어렵다는 느낌을 많이 받았다. 그런 맥락에서 지난 테크코스 1기를 돌아보며 뼈대를 작성해보았다. 앞으로 어떤 형태로 발전해나갈지 기대하는 부분이다.

https://github.com/woowacourse/roadmap

woowacourse/roadmap

Contribute to woowacourse/roadmap development by creating an account on GitHub.

github.com

둘째로는 외부 강의이다. 이번에 사내 비 개발자들을 대상으로 SQL 강의를 하게 되었다. 그리고 같은 주제로 외부로도 오픈하려 한다. 이전 회사에서도 느꼈었는데, 자신이 하는 일에 Ownership을 강하게 가진 사람일수록 성장 욕구가 강한 경향이 있는 것 같다. 개발 문화를 개발자에 국한한 것이 아닌 조직문화의 관점에서 바라볼 때, 이번 상반기 나의 활동으로 비 개발자와 개발자 간의 소통에 개선이 된다면, 좋은 개발 문화에 나름의 형태로 Contribution 하는 것이지 않을까 하는 생각이다.

https://edu.nextstep.camp/c/VulQIb2a

SQL 넘어 제플린으로

${lecture.title} ${lesson.title} 현재 수업이 준비중입니다.

edu.nextstep.camp

최근의 나태해진 나 자신을 다시 가다듬고 주기적으로 글을 써가며 올해도 조금은 성장해보길 고대해본다. 그리고 역시나, 글또를 통해 새롭게 알아가게 될 사람들과 그들에게서 받을 영감이 너무나 기대된다.

200 vs 404

가그린민트 — Wed, 12 Feb 2020 03:17:46 +0900

ATDD 강의 코드리뷰 중 이런 질문을 받았다. 질문의 요지는, /stations/{id} 혹은 /stations?name={name} 등과 같은 요청에 해당하는 데이터가 없을 경우, 어떤 응답코드가 적절한가이다.

HTTP Status Code에 대해서는 나름대로 기준을 세웠던지라 별다른 고민은 없었는데, 팀원과 이야기 중에 생각이 다른 부분이 있어 다른 리뷰어들과도 이야기를 나누어보았다. 이 내용을 정리하고 공유하고 또 다른 의견들을 듣는 것도 좋을 거 같아 포스팅해본다.

우선, 200이 적절하다는 주장을 살펴보자.

HTTP에서 이야기하는 resource 라는 개념을 서버 데이터와 엮지 않고 온전히 URI 라고 보아야 한다. 즉, 서버의 데이터 없음을 HTTP resource와 엮지 않아야 한다는 것으로, 위의 경우에는 빈값의 200 응답을 해야 한다는 것이다.

다만, DELETE 메서드에서 없는 데이터를 삭제하려고 했을 때 이 요청은 400 에러로 처리하여야 하는데, 이는 서버에서 요청이 수용되었으나 클라이언트의 요청이 잘못되었음을 의미하기 때문이다. 이렇게 리소스와 데이터 자원을 분리하는 이유는 명확함을 강조하기 위함이다.

그리고 REST를 지향하는 API에서도, 삭제를 실행 했을 때 그 데이터가 삭제 가능한 상황을 단순하게 데이터가 존재한다고 판단하지 않는다. 그 데이터에 얽혀있는 비지니스적인 요소에 따라 요청 클라이언트에게 데이터가 없다고 밝혀야 할 수도 있고, 삭제가 불가능하다고 밝혀야 할 때도 있다.

가령, 주문을 실행한다고 했을 때 주문이 실행 불가능한 여러가지 경우가 있다. 재고가 떨어져서, 혹은 판매자가 폐업한 경우 등의 상황에서 404, 400, 500 에러는 적절치 않다. 리소스 수용이 정상적으로 이루어졌고, 요청한 데이터에도 이상이 없고(클라이언트에게 책임이 없고), 서버에서 비정상적이고 식별 불가한 에러를 발생한 것도 아니므로 200 응답을 주는 것이 적절해 보인다. 다만 클라이언트에서 식별에 대한 응답을 하기 위해 요청은 성공했지만 주문에는 실패했다는 의미로 내부적으로 관리되는 상태 코드를 응답 body 에 명시하도록 한다. 이러한 사용은 실제 서버에 이상이 있는지, 클라이언트가 잘못된 요청을 하는지에 대한 구분을 명확히 함으로써 장애시 트래킹 포인트를 좁히는데에도 큰 역할을 한다.

즉, 조회시 없을 때는 200, PUT/DELETE의 경우 상황에 따라 (데이터가 있어야하는데 없는 경우) 4xx, 아니면 200에 응답 body에 별도로 메시지나 정책적으로 만든 상태코드를 담아서 보내는 것이 적절하다는 주장이다.

위의 주장은 현재 국내 몇 군데 규모있는 회사 개발자들의 의견이었고, 나 역시 그렇게 생각하고 있었다. 그래서 확인차 몇군데 둘러보니 실제로 그렇게 운영되고 있다.

> 쿠팡 404 페이지 : https://www.coupang.com/vp/productsasdsasd
> 쿠팡 200 페이지 : https://www.coupang.com/vp/products/1229153213123123124124

https://luckyyowu.tistory.com/377

HTTP 404 Status Code 에 대한 고찰

뭐가 문제였나 필자는 현재 HMR(가정간편식) 커머스를 다루는 모 스타트업에서 백엔드 개발자로 재직 중이다. 말이 백엔드지 최근 변화되고 있는 트렌드에 맞춰 열심히 API 작성 셔틀을 하고 있다. API 개발에 주..

luckyyowu.tistory.com

위의 내용만 보면 200이 타당한 듯 보인다. 하지만 404 의견을 듣고 자료를 찾아보니 이거 역시 만만치가 않다.

우선, 404 NOT FOUND가 적절하다는 입장은, https://tools.ietf.org/html/rfc7231 에 근거를 두었다.

## 200 status code

1
2
3
4
5

The 200 (OK) status code indicates that the request has succeeded. 
The payload sent in a 200 response depends on the request method.
 
 
GET a representation of the target resource;

200은 요청이 성공했음을 나타내며 페이로드로 해당 resouce의 representation이 응답된다.

1
2

Aside from responses to CONNECT, a 200 response always has a payload, though an origin server MAY generate a payload body of zero length. 
If no payload is desired, an origin server ought to send 204 (No Content) instead.

200은 항상 payload를 가지고 있어야 하고 응답이 없는 경우 204를 보내주어야 한다.

## 204 status code

1

The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.

204는 요청을 성공적으로 이행하고 응답 페이로드에 추가적으로 보낼 컨텐츠가 없는 경우를 나타낸다.

1

For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource.

예를 들면, 추가적으로 보낼 컨텐츠가 없는 경우란 PUT 요청을 받고, ETag Header 필드를 포함하여 contents에 보낼 필요가 없을 때를 말한다. 즉, 204 응답은 타겟 리소스에 성공적으로 적용되었음을 나타내며, 암시적으로 useragent가 횡단(접근)할 필요가 없음을 나타낸다.

## 404 status code

1

The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

404 응답은 서버가 타겟 리소스의 representation을 찾지 못하였거나 존재한다는 것을 드러내려고 하지 않음을 나타낸다.

즉, HTTP 요청의 대상이 리소스임을 생각해 본다면

The target of an HTTP request is called a "resource"

서버가 정상적으로 동작함의 여부가 아니라 요청한 리소스가 정상적으로 응답이 오는가에 따라서 응답 코드를 판단해야 한다고 생각하다는 것으로, rfc7231문서에 정의된 Response Status Code 중 200과 204 두 상태 코드 모두 uri가 가리키는 resource가 존재하지 않는 경우의 상태를 나타내기는 어렵다는 주장이며, 404 상태 코드가 보다 명확하다는 입장이었다.

추가적으로, ResponseEntity 구현체를 보면 Body에 null을 넘겨줄 경우 notFound()를 리턴하도록 정적 팩토리 메서드를 작성했음을 확인할 수 있다.

1
2
3
4

    public static <T> ResponseEntity<T> of(Optional<T> body) {
        Assert.notNull(body, "Body must not be null");
        return body.map(ResponseEntity::ok).orElse(notFound().build());
    }

그리고 HTTP 완벽가이드를 보면, Not Found에 대해 이런 설명이 있다.

"서버가 요청한 URL을 찾을 수 없음을 알려주기 위해 사용한다. 종종, 클라이언트 애플리케이션이 사용자에게 보여주기 위한 엔터티가 포함된다."

그리고 트위터의 status code 정의를 보면, "The URI requested is invalid or the resource requested, such as a user, does not exist." 라고 가이드 하고 있다.

https://developer.twitter.com/en/docs/basics/response-codes

Response codes

The standard Twitter API returns HTTP status codes in addition to JSON-based error codes and messages.

developer.twitter.com

아래의 링크도 같이 확인해보자.

https://softwareengineering.stackexchange.com/questions/203492/when-to-use-http-status-code-404-in-an-api

When to use HTTP status code 404 in an API

I am working on a project and after arguing with people at work for about more than a hour. I decided to know what people on stack-exchange might say. We're writing an API for a system, there is a...

softwareengineering.stackexchange.com

https://medium.com/@laeshiny/get-요청-시-데이터가-없으면-200-or-404-4ab7430084af

Get 요청 시 데이터가 없으면 200 or 404 ?

아래와 같은 URL을 Get Method로 호출했다고 가정하겠습니다

medium.com

~~(위 포스팅의 저자분은 이제 200으로 보내신다는 이야기를 듣기는 했다만..)~~

사실 우리와 비슷한 논쟁이 stackoverflow에 이미 있었기는 하다.

https://stackoverflow.com/questions/11746894/what-is-the-proper-rest-response-code-for-a-valid-request-but-an-empty-data

What is the proper REST response code for a valid request but an empty data?

For example you run a GET request for users/9 but there is no user with id #9. Which is the best response code? 200 OK 202 Accepted 204 No Content 400 Bad Request 404 Not Found

stackoverflow.com

위의 stackoverflow 답글 중에 query string의 경우 빈 배열로 리턴해야 한다는 의견도 있지만, 나는 query string도 url의 한 파트라고 보기에 이는 반대한다. (https://en.wikipedia.org/wiki/Query_string)

이쯤되니 상태코드도 팀 컨벤션처럼 생각해야 하나, 아니면 이것도 글로벌 기준과 국내 실무와의 괴리 정도로 보면 되는 것인가하는 생각도 든다. 이런 이야기들을 하고 있으니 옆에서 "그냥 규원님께 물어봐. " 하는 의견도 있었다. ~~(사실 이 포스팅을 해야겠다는 생각이 들었던 시점도.. )~~

다른 분들은 어떻게들 생각하시는지, 어떻게들 하고 계신지 궁금하여 포스팅해본다.

이 포스팅에 답글이나, 페북에 댓글이 달리면 추가로 본문을 수정해볼까 합니다.