index.json

[{"content":"Postgres 데이터베이스를 K8s 환경에서 배포하는 방법을 찾고 있다면 오픈소스로 공개된 Postgres Operator들을 고려해 볼 수 있다. Postgres 컨테이너 이미지를 기반으로 직접 배포해볼 수도 있지만, 오퍼레이터를 통해 여러 K8s 자원들의 배포 및 관리 자동화하여 operational cost를 줄일 수 있다. Zalando나 Crunchy Data사에서 제공하는 오퍼레이터는 failover 말고 라도 Connection Pool, 백업, 모니터링 등 다른 기능셋들도 제공하기 때문에 다른 Postgres Operator 비교 블로그 글에서도 추천의 대상으로 많이 꼽고 있다. 이번 블로그에서는 이 둘 오퍼레이터에 대해서 알아보고자 한다.\n들어가며 두 오퍼레이터의 차이점을 나눠서 알아보기 전에 앞서 알아두면 좋을 사전지식을 정리해두고자 한다. 먼저, 공통점을 살펴보자. 오퍼레이터가 관리하는 K8s 자원들이다. 크게 6개로 나눌수 있는데, Postgres 컨테이너 이미지로 Primary와 Standby Pod으로 배포되는 Statefulset, Connection Pool을 배포하기 위한 Deployment, Client가 DB에 접근 가능하도록 필요한 Service, Postgresql configuration 설정 정보 관리를 위한 ConfigMap과 접근 정보 관리를 위한 Secret, 마지막으로 Transaction log 등 데이터베이스 state를 관리하기 하기 위한 각종 정보를 저장하는 PVC와 PV가 존재한다.\nPostgres 컨테이너 이미지로는 물론 공식 이미지가 존재하지만, 요건에 따라 필요 기능들을 추가하여 재 패키징한 프로젝트들도 많다. Postgres HA 프레임워크 중 하나인 Patroni 프로젝트를 컨테이너화한 Spilo가 대표적이며, EnterpriseDB사에서는 PgBouncer를 패키징한 docker-pgbouncer와 Backup 기능을 위한 자체 솔루션 + PostGIS + PGAudit를 포함해 패키징한 docker-postgresql도 제공한다. Bitnami에서는 또 다른 Postgres HA 프레임워크인 repmgr를 포함해 패키징한 프로젝트인 bitnami-docker-postgresql-repmgr가 있다.\nFailover 다음으로 Postgres의 주요 기능들에 대해서 살펴보고자 한다. 첫번째로 Postgres HA 프레임워크이다. 우선 Postgres는 기본적으로 primary와 standby 사이에 WAL(Write Ahead Log) 기반으로 streaming replication을 지원한다. 하지만, 클러스터링 기능은 제공하지 않기 때문에 primary, standby 인스턴스 관리를 위한 솔루션이 필요하다. K8s 환경에서 DBaaS를 제공한다고 해도 node fail의 상황이나 primary pod 혹은 standby pod이 죽을 경우, (다른 node에) 새 pod이 생성되는 container orchestration은 되지만, DB를 정상적으로 사용할 수 있기 위해서 standby =\u0026gt; primary로 바꾸는 promotion, primary =\u0026gt; standby로 교체하는 demotion과 같은 custom logic을 직접 개발하거나 이미 개발된 Postgres HA framework 사용이 필수적이다.\n주로 사용되는 Postgres HA 솔루션으로는 Patroni, PAF(pacemaker + corosync), repmgr가 있다. 해당 블로그에서는 각각의 failover 시나리오에 대해서 테스트 결과가 잘 정리되어 있다. Zalando사와 Crunchy Data사에서 Patroni를 사용하고 있는 만큼 Patroni에 대해서는 밑에서 좀 더 자세히 알아보려고 한다.\nConnection pool 두번째로 Connection Pool 기능이다. Connection Pool은 Postgres client와 Postgres 서버 사이의 connection을 관리하여 connection을 재사용하고, 실제 사용하지 않는 Idle 상태 Connection 회수하여 Postgres 서버 오버헤드를 줄이기 위한 목적으로 사용하는 기능이다. 자주 언급되는 솔루션으로는 PgBouncer와 Pgpool-II이 있는데, Zalando사와 Crunchy Data사에서는 PgBouncer를 사용하고 있다. 그 둘의 대한 비교는 해당 블로그에서 자세하게 다루고 있다. LB 기능 지원이 Pgpool-II의 가장 큰 장점이지만, connection 큐잉과 다양한 pool 모드 지원 등 connection 자체에 대한 관리는 PgBouncer가 더 뛰어나다고 볼 수 있다. Pgpool-II이 지원하는 LB 기능은 읽기 요청인지 쓰기 요청인지 여부에 따라서 primary와 standby에 분산해서 처리할 수 있으며, 기본 PgBouncer에 위와 같은 LB 기능과 쿼리 rewrite 기능까지 추가한 프로젝트가 궁금하다면 awslabs의 pgbouncer-rr-patch를 참고하기 바란다.\nZalando Zalando Postgres Operator는 유럽 대형 쇼핑몰 회사인 Zalando에서 만들어서 사내에서 실 사용중인 것으로 알려진 오픈소스 오퍼레이터이다. Python 구현체인 Patroni를 컨테이너화한 Spilio 컨테이너 이미지를 사용하여 Postgres CR을 배포하고 Statefulset 등 여러 관련 k8s 리소스를 관리한다.\nZalando의 경우에는 kubebuilder나 controller-runtime을 사용하지 않고 client-go 등을 직접 사용해서 오퍼레이터를 개발했다. Patroni REST API를 호출하여 switchover가 이뤄지는데, node 상태에 따라서 patroni api를 호출하는 flow를 가진다.\n/cmd/main.go 부터 코드를 타고 가면,\nmain.go =\u0026gt; controller.go run() =\u0026gt; controller.go initController() =\u0026gt; controller.go initSharedInformers() =\u0026gt; node.go 에 이르게 된다.\nc.nodesInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{ \tAddFunc: c.nodeAdd, \tUpdateFunc: c.nodeUpdate, \tDeleteFunc: c.nodeDelete, }) func (c *Controller) nodeAdd(obj interface{}) { \tnode, ok := obj.(*v1.Node) \tif !ok { \treturn \t}  \tc.logger.Debugf(\u0026#34;new node has been added: %s (%s)\u0026#34;, util.NameFromMeta(node.ObjectMeta), node.Spec.ProviderID)  \t// check if the node became not ready while the operator was down (otherwise we would have caught it in nodeUpdate) \tif !c.nodeIsReady(node) { \tc.moveMasterPodsOffNode(node) \t} } node가 ready 상태가 아니라면 master pod(primary)를 옮기는데,\nnode.go moveMasterPodsOffNode() =\u0026gt; node.go attemptToMoveMasterPodsOffNode() =\u0026gt; pod.go MigrateMasterPod() =\u0026gt; cluster.go Switchover() =\u0026gt; patroni.go Switchover() 가 종착점이다.\nSwitchover는 현재 primary pod을 다른 candidate pod로 바꾸는 API이다.\n// Switchover by calling Patroni REST API func (p *Patroni) Switchover(master *v1.Pod, candidate string) error { \tbuf := \u0026amp;bytes.Buffer{} \terr := json.NewEncoder(buf).Encode(map[string]string{\u0026#34;leader\u0026#34;: master.Name, \u0026#34;member\u0026#34;: candidate}) \tif err != nil { \treturn fmt.Errorf(\u0026#34;could not encode json: %v\u0026#34;, err) \t} \tapiURLString, err := apiURL(master) \tif err != nil { \treturn err \t} \treturn p.httpPostOrPatch(http.MethodPost, apiURLString+failoverPath, buf) } Switchover와 달리 특정 pod 재기동이 필요한 상황에는 patroni.go에 정의된 Restart() 인터페이스에 따라 pod 재시작 시키는 patroni restart REST API를 호출하고 있다.\nEvent 종류가 Update 인지, Sync 인지에 따라서 호출 flow 중 조금의 차이가 있다.\n  main.go =\u0026gt; controller.go run() =\u0026gt; postgresql.go processClusterEventsQueue() =\u0026gt; postgresql.go processEvent() =\u0026gt; sync.go Sync() =\u0026gt; sync.go syncStatefulSet() =\u0026gt; sync.go restartInstance() =\u0026gt; patroni.go Restart()\n  main.go =\u0026gt; controller.go run() =\u0026gt; postgresql.go processClusterEventsQueue() =\u0026gt; postgresql.go processEvent() =\u0026gt; cluster.go Update() =\u0026gt; sync.go syncStatefulSet() =\u0026gt; sync.go restartInstance() =\u0026gt; patroni.go Restart()\n  모니터링 기능을 보면, Zalando의 경우에는 사내에서 모니터링을 위한 다른 솔루션을 사용하고 있기 때문에 Prometheus 연동을 위한 exporter pod 이나 별도의 배포 yaml을 제공하지 않는다. Repo 내에 issue에서 모니터링 관련 example yaml이 공유되고 operator에 대한 모니터링을 위한 pr이 있지만 기본적으로 Prometheus 연동를 위한 role, service 등 K8s 리소스와 PrometheusRule를 함께 고려하여 prometheus-postgres-exporter를 zalando-operator의 sidecar container로 배포해야한다.\nCrunchy Data Crunchy Data는 Postgres DB 관련 상용 솔루션 만드는 it 회사이다. Postgres Operator는 오픈소스 프로젝트이지만, 이를 유지보수하고 구축하는 공수는 상용 서비스로 제공하고 있어서 실 사용시에 Crunchy Data 오퍼레이터를 우선적으로 고려하기도 한다.\nCrunchy Data는 controller runtime을 기반으로 개발되어 kubebuilder나 operator-sdk 사용경험이 있다면 좀 더 쉽게 소스코드를 navigate 할 수 있다. Failover 기능을 implement한 방법 부터 알아보자면, Zalando 처럼 SwitchOver가 필요한 상황을 감지하여 자동 실행되는 로직은 아니다. Crunchy Data의 경우에는 해당 PR을 기반으로 SwitchOver가 필요한 경우에 Postgres CR spec 변경을 직접 해줘야 SwitchOver가 트리거 된다.\npkg/apis/postgres-operator.crunchydata.com/v1beta1/patroni_types.go에 아래와 같이 const가 설정 되어 있고, PatroniSwitchover.Type이 존재하지만\nPatroniSwitchoverTypeFailover = \u0026#34;Failover\u0026#34; PatroniSwitchoverTypeSwitchover = \u0026#34;Switchover\u0026#34; crunchy data 코드 내부에서는 PatroniSwitchover.Type을 셋팅해주는 부분이 없다. 하지만 해당 값이 설정 된 경우에는 patronictl cmd를 실행하여 switchover, 그리고 primary pod이 존재 하지 않는 경우나 candidate pod을 특정할 수 없는 경우에 failover가 실행된다.\nFailover 실행 플로우를 보면 아래와 같다.\ninternal/controller/postgrescluster/controller.go\n Reconcile() -\u0026gt; instance.go reconcileInstanceSets() -\u0026gt; rolloutInstance() -\u0026gt; api.go ChangePrimaryAndWait() Reconcile() -\u0026gt; patroni.go reconcilePatroniSwitchover() -\u0026gt; api.go SwitchoverAndWait() or FailoverAndWait()  internal/controller/postgrescluster/patroni.go의 reconcilePatroniSwitchover() 함수를 참고하면,\nif cluster.Spec.Patroni == nil || cluster.Spec.Patroni.Switchover == nil || \t!cluster.Spec.Patroni.Switchover.Enabled { \tcluster.Status.Patroni.Switchover = nil \treturn nil } Patroni 개체의 Switchover.Type 값에 따라서, SwitchoverAndWait() 혹은 FailoverAndWait()를 실행한다. SwitchoverAndWait()의 경우에는 ChangePrimaryAndWait()와 달리 primary pod와 이를 대신 할 candidate pod을 인자로 받으며, FailoverAndWait()은 primary pod이 존재하지 않는 경우로 candidate pod만 인자로 받는다.\nrolloutInstances()의 경우에는 pod 재배포가 필요한 경우 재배포 하면서, 해당 pod이 primary인 경우에 primary를 교체하는 ChangePrimaryAndWait() 함수를 호출한다. 이 경우에는 patroni가 현재 상태에서 가장 best candidate을 직접 선택하고 primary를 demote 시킨다.\nif primary \u0026amp;\u0026amp; len(instances.forCluster) \u0026gt; 1 { \tvar span trace.Span \tctx, span = r.Tracer.Start(ctx, \u0026#34;patroni-change-primary\u0026#34;) \tdefer span.End()  \tsuccess, err := patroni.Executor(exec).ChangePrimaryAndWait(ctx, pod.Name, \u0026#34;\u0026#34;) 모니터링 관련해서는 pgmonitor 라는 별도의 프로젝트가 존재한다. postgres 버전 별로 DB metric을 가져오기 위한 환경 설정 값들이 정의 되어 있으며, pgnodemx PostgreSQL extension을 사용하여 node의 OS 관련 metric을 sql 쿼리로 가져올 수 있다. CrunchyData Operator를 사용하면 cluster CR에 monitoring 사용 명시할 수 있는데, enable 된 경우 metric 수집 접근이 가능 하도록 pg_hba.conf 파일 설정 업데이트 및 기타 환경 설정과 필요한 SQL 쿼리를 실행해주기 때문에 편리하다. postgres exporter container는 따로 배포하지 않아도 되고, 모니터링 시스템만 배포해주면 된다. prometheus, grafana, alertmanager를 배포하는 yaml을 모아둔 샘플 프로젝트를 제공하기 때문에 해당 가이드를 참고하여 간단하게 배포 가능하다.\n$ kubectl apply -k kustomize/monitoring 마무리 결론적으로 fail over 자동화를 본다면 zalando가 모니터링 자동화 기능을 우선시 한다면 crunchy data operator를 사용을 고려해볼 수 있다. 하지만 둘 중 어떤 PostgreSQL 오픈소스 오퍼레이터를 선택하더라도 실 사용시 기능 추가가 필요할 가능성이 높다. Zalando operator를 fork해서 개발한 사례를 참고해보고 실제 공수를 잘 따져서 새로운 PostgreSQL 오퍼레이터를 개발하는 선택지도 고려해보자.\nReference  Comparing Kubernetes operators for PostgreSQL  CrunchyData Vs Zalando 참고 자료  https://github.com/CrunchyData/postgres-operator/issues/992 https://www.reddit.com/r/kubernetes/comments/fjm3vd/comparison_of_choices_to_run_dbspostgresql_crd_on/ https://news.ycombinator.com/item?id=28758162  ","permalink":"https://diglog.io/posts/postgres-operator/","summary":"Postgres 데이터베이스를 K8s 환경에서 배포하는 방법을 찾고 있다면 오픈소스로 공개된 Postgres Operator들을 고려해 볼 수 있다. Postgres 컨테이너 이미지를 기반으로 직접 배포해볼 수도 있지만, 오퍼레이터를 통해 여러 K8s 자원들의 배포 및 관리 자동화하여 operational cost를 줄일 수 있다. Zalando나 Crunchy Data사에서 제공하는 오퍼레이터는 failover 말고 라도 Connection Pool, 백업, 모니터링 등 다른 기능셋들도 제공하기 때문에 다른 Postgres Operator 비교 블로그 글에서도 추천의 대상으로 많이 꼽고 있다. 이번 블로그에서는 이 둘 오퍼레이터에 대해서 알아보고자 한다.","title":"Postgres Operator"},{"content":"함께 자라기 - 애자일로 가는 길은 개발자 블로그나 커뮤니티 내에서 좋은 평을 많이 봐서, 언젠간 읽어 봐야지 라고 벼르고 있었는데, 드디어 읽었다.\n작년부터인가 개인적으로 너무 정체 되어 있던 것 같아서 \u0026lsquo;성장\u0026rsquo;에 대해서 고민을 하지 않을 수 없었는데, 이 책은 그에 대한 고민에 대한 해답과 동기부여에 아주 적합한 책이었다. 여러 사례들과 저자의 인사이트를 모은 에세이 형태이다 보니 사실 목차 순서대로 읽지 않아도 되지만, 저자의 의도를 고스란히 느끼고자 원래 책을 순서대로 읽는 편이다 보니, 왜 앞서서 이러한 예시를 먼저 들었는지 알만한 부분들이 많았다. 개인적인 느낌으로는 유시민 작가님의 어떻게 살 것인가 와 상당히 유사하였는데, 커리어 빌딩과 관련해서 어떻게 살아야 전문가가 될 수 있는지 서술된 책으로 읽혔기 때문인 것 같다. 끝 부분에서는 애자일이란 무엇이고, 애자일의 도입을 위해서는 어떻게 해야하는지에 대한 해답이 서술되어 있지만, 책의 앞부분 부터 중후반까지는 \u0026lsquo;전문가란 누구인가?\u0026rsquo; 전문가의 역량과 특징, \u0026lsquo;어떻게 하면 전문가가 될 수 있는가\u0026rsquo; 이런 질문들에 대한 전문성 사례 연구 소개가 많기 때문에 조직 문화 연구나 팀빌딩에 관심이나 책임이 있는 사람, 전문가로 성장하고자하는 기로에 놓인 주니어를 대상으로 참 좋은 책이 아닐까 한다. 다만, 예시로 드는 사례들이 소프트웨어 개발과 관련이 많기 때문에 해당 직군 종사자들에게 좀 더 와닿을 수 있을 것 같다. 참고한 서적과 연구 논문들이 많다. 어떻게 살 것인가 읽고 나서 주석만 쫓아서 위시리스트에 몇십권의 책을 추가해 놓은 기억이 있는데, 이번에도 비슷하지 않을까 한다.\n뼈 때리는 문장들이 많아서 자기 반성을 겸하면서 읽었다. 키워드로 꼽자면 경력, 회고 (피드백), 인지 (mindfulness), 협력으로 나눌 수 있을 것 같다. 개인적으로 임팩트가 있었던 순으로 꼽자면 인지 \u0026gt; 협력 \u0026gt; 회고 \u0026gt; 경력 순이었다. 키워드 별로 가장 울림이 컸던 문장들을 꼽아봤다. 주기적으로 책갈피 해두듯 반복 해서 봐야겠다.\n인지  지속적으로 자신의 감정 상태를 살피면서 지금 지루한지 불안한지를 알아채고 만약 지루함이나 불안함을 느낀다면 앞의 네가지 전략을 적절히 사용해야 한다는 겁니다. (중략) 자기가 지금 어떤 상태인지 살피는 알아차림(mindfulness)이 꼭 필요합니다.\n mindfulness 라는 단어에 대한 너무 적절한 번역이 아니지 않나 라는 생각이 들었다.\n어렸을 때만해도 \u0026lsquo;너 자신을 알라\u0026rsquo;는 말이 왜 명언인지 이해되지 않을 만큼, 나는 나를 너무 잘 알고 있다고 생각했는데, 어느 순간 부터는 나를 잘 아는 것이 제일 어렵고 힘든 일이 되었다. 메타 인지 능력은 모든 도메인에 걸쳐서 가장 필요하고 중요한 능력 중 하나인데, 그 중요성을 잘 보여주는 연구 결과도 책에 많이 수록 되어 있었다. 가장 인상적이었던 대목은 아래와 같다.\n 피겨 스케이팅 선수들에 대한 연구인데요. 지역 대회 수준의 선수와 세계 대회 수준의 선수 두 그룹을 서로 비교해 봤습니다. 우선 하루 연습을 끝낸 후 간단한 설문을 통해 여러 가지를 물었습니다. 그 중 하나가 오늘 연습 중 트리플 악셀을 몇 번 정도 했다고 기억하는가 하는 질문입니다. 두 그룹의 응답에는 큰 차이는 없었습니다. 하지만 두 그룹의 실제 연습 장면을 몰래 녹화해서 국제 심판들에게 분석하게 한 결과는 차이가 있었습니다. 세계 대회 수준의 선수는 지역 대회 수준의 선수에 비해 몇 배 더 많은 트리플 악셀을 연습했습니다. 지역 대회 수준의 선수는 자신들이 이미 익숙하고 자신 있는 \u0026lsquo;예술적 표현\u0026rsquo; 등의 연습에 시간을 더 썼습니다. 그러고는 트리플 악셀을 많이 연습했다고 착각했습니다. (중략) 이 연구가 보여주듯 (중략) 자신이 어떤 연습을 얼마나 하는지에 대해 정확하게 인식하지 못하는 경우들이 있습니다. (중략) 안전지대 안에 머무르고, 지루함 속에서 자기 실력에 대해 안심하고, 그 상태에 익숙해진 것이지요.\n 위 연구가 본인의 능력 개발을 위한 자기 자신에 대한 인지에 대해서 말한다면, 상대방이 어떻게 받아들일지에 관한 메타 인지에 관한 내용도 좋았다. 인수인계나 가이드 문서 작성부터 주니어나 신입 개발자들을 교육하거나 리드하는 역할을 맡게 되었을 때 유념하면 많은 도움이될 것 같다.\n 의료계의 연구를 보면 전문가가 특정 수술법을 학생에게 가르칠 때, 의료적 지식, 무엇을 어떻게 해야 할지에 대한 행동 단계, 의사결정 단계 등 자신이 해당 과제를 수행할 때 사용하는 지식 중 70%는 가르치지 않는다는 분석이 거듭해 나왔습니다. 가르치는 능력을 인정받고 한 번 이상의 \u0026lsquo;탁월한 교사상\u0026rsquo;을 받은 사람임에도 그랬고, 되도록 단계나 지식을 빠짐없이 가르쳐 주라는 특별한 주문을 받았음에도 그러했습니다. 심지어는 수업이 끝나고 \u0026ldquo;혹시 빠트린 것이 있습니까\u0026rdquo; 하고 물은 후 그걸 추가해도 여전히 70% 정도는 빠트렸습니다. 그 기술을 성공적으로 해내기 위한 필요한 것의 30%만 가르쳐 놓고 자신은 다 가르쳤다고 생각하는 겁니다.\n 의료계 연구 관련해서 작가님의 설명으로부터 새롭게 알게된 흥미로운 사실이 있었는데, 바로 의료계에서 비 경력자가 수련을 거듭해서 성장해나가는 환경과 방식이 개발자들이 겪는 환경과 비슷하다는 것이었다. 전문가 연구 및 사례에서 흔히 쓰인다고 한다.\n메타인지를 높이는 방법 또한 간단하다. \u0026rsquo;think things through\u0026rsquo;, 그대로 직시하고 분석하는 것.\n 선생 입장에서는 자신에 대한 메타인지를 높이는 노력을 할 수 있습니다. \u0026ldquo;내가 이 문제를 해결할 때 어떤 과정을 거치는가\u0026quot;를 생각하며 자신의 머릿속을 관찰하고 질문을 던지고 분석하는 것이죠. 그리고 학생들이 이걸 배우면서 어떤 생각을 하는가를 직접 관찰하고 질문을 던지고 분석할 수 있을 겁니다. 메타분석에 따르면 선생이 인지적 작업 분석에 능숙한가 하는 것이 학생들의 학업성취도에 미치는 영향의 효과 크기가 자그마치 1.29나 됩니다. 이런 분석 능력이 뛰어난 선생이 잘 가르치는 사람이라는 이야기입니다.\n 협력  사람들은 협력이 중요하다고 합니다. 그래서 프로젝트를 할 때 협력적으로 하자고 합니다. 그러나 실제 모습을 들여다보면 초반에 일을 세밀하게 나누고 선을 긋습니다. 그리고 안녕이죠. 각자 진행하고 나중에 만나서 서로 합쳐봅니다. 그 속을 들여다보면 협력은 거의 없습니다.\n 프로젝트를 처음 시작할 때, 역할 분담하며 진행시켜 나갈 때 유념하면 좋을 것 같은 문장이다. 분담을 하더라도 주기적인 스크럼과 wip pr에 대한 점진적인 코드리뷰 등을 통해서 피드백의 주기가 빠르다면 그만큼 협력도 쉬워질 것이라는 생각이 들었다.\n협력에 관해서도 특히 흥미로웠던 연구들이 많았다.\n 한 연구에서는 경력이 있는 개발자들에게 특정 문제를 해결할 때 초보 개발자에게 해 줄 조언을 적어보라고 했습니다. 평균 7년 경력의 개발자들이었는데 뛰어난 개발자들은 약 70%가 동료와의 협력을 언급하는 반면, 실력이 그저 그런 개발자들은 20%도 안 되는 사람들만이 동료와의 협력을 언급했습니다.\n 협력과 실력을 이어주는 연결고리는 바로 oop를 배울 때 수 없이 들어봤을 법한 추상화에 있다.\n 둘이서 협력하면서 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 됩니다. 서로 다른 것들을 하나로 묶어야 하기 때문입니다. 반면 혼자서 작업할 경우에는 이런 추상화의 필요가 덜합니다.\n 협력의 과정에 있어서 추상화를 거친다고 미처 인지하지 못했는데\u0026hellip; 너무 맞는 말이다. 사실 어떤 문제가 있을 때 그 문제에 대해서 다른사람에게 설명하는 것 만으로, 혹은 설명하기 위해 과정을 그냥 적어보는 것 만으로 해결 방법이 보일 때도 있다. 그것이 바로 추상화의 힘!..\n그리고 또 인상적이었던 마지막 연구 결과는 공유 방법에 관한 실용적인 팁이다.\n 하나 공유나 최고 공유가 아마 우리가 흔히하는 공유 방식일 겁니다. 그런데 이 방식은 하고 나면 신뢰가 더 떨어집니다. (중략) 왜 이런 일이 생겼을까요? 하나 공유나 최고 고유의 경우 우리는 공유 자리에 기대감보다 불안감을 갖고 갈 겁니다. (중략) 반대로 복수 공유는 그런 불안감이 상대적으로 덜합니다. 또 부정적 피드백을 수용하려는 마음도 더 많죠. 여러 개를 준비했으니 그중 하나를 두고 뭐라고 해도 나에 대한 공격은 아닌 겁니다.\n 어떻게 보면 당연한 결과지만, 공유 할때는 한 개 보다는 2~3개의 솔루션을 준비해서 가자!\n회고  저는 뭔가 일이 끝나면 항상 회고라는 활동을 합니다. 연말에는 한해를 되돌아보고 반성하는 일 년 회고를 합니다. 내가 올해에 어떤 것을 했고, 어떤 것을 느꼈고, 어떤 교훈을 배웠는지 짚어봅니다. (중략) 자기계발이 왜 중요하다고 생각하냐면, 현재 나에게 무엇을 투자했느냐가 1년, 혹은 2년 후의 나를 결정한다고 느끼기 때문입니다. 예를 들어 올해 업무도 잘한 것 같고 사람들에게 인정을 받은 것 같다면 1~2년 전을 잘 되돌아봅니다. 아마 그때 열심히 자기투자를 했을 겁니다. 반대로 올해 읽은 책도 몇 권 없고 새로 얻은 통찰도 없다면 지금 당장은 별 문제없는 것 같지만 내년이나 내후년에는 분명 추락을 경험할 것입니다. (중략) 무서운 사실은 이게 축적이 되면 엄청난 차이를 만들 거라는 점이지요. 자기가 습득한 지식이나 능력은 복리로 이자가 붙기 때문입니다.\n 회고는 인지의 밑바탕이 된다. 제 3자의 눈으로 보듯 자기 자신을 있는 그대로 인지할 수 있다면 좋겠지만 대게 그건 어려운 일이기 마련이다. 편견에 사로잡혀 있을 수도 있고, 지나친 자신감이나 떨어진 자존감에 의해서 본인을 제대로 직시하고 있지 못하기 쉽다. 물론 때로는 묻고 따지지 지도 않고 일단 가는 전진이 필요한 상황도 있지만, 언젠가는 멈춰서서 자신의 선택을 돌이켜보는 시간이 오기 마련이다. 이때 적절한 피드백을 하고, 복기할 수 있다면 다음 성장을 위한 발판이 될 것이다. 서로 피드백을 하고 같이 복기할 수 있는 상대가 있다면 그건 엄청난 행운이겠지!\u0026hellip;\n 꾸준한 반복으로 달인이 되려면 적어도 실력을 개선하려는 동기가 있어야 하고, 구체적인 피드백을 적절한 시기에 받아야 한다고 말할 수 있겠습니다. 단순히 반복만 한다고 해서 달인이 될 수 없습니다. 특정 영역에서 자신의 실력을 향상시키고 싶은 사람이라면 혹시 그 일을 내가 양치질하듯이 수 십년을 단순히 반복해 온 것은 아닌지 반문해 보고, 내 일에서 매 양치질 직후 구강 거울이나 치면착색제의 역할을 하고 있는 것은 무엇인지, 없다면 어떻게 만들어낼지 고민해 보길 바랍니다.\n 비슷한 맥락의 문장인데, 빠른 피드백 사이클이 agile의 최대의 장점으로 제품 고도화나 revenue 증가에 가장 크게 영향을 미치지 않나한다. 물론 피드백이 부족한 환경에 놓여져 있다면, 스스로라도 자기 자신에 대해 인지하여 피드백 할 수 있길\n 수십 년 동안 한 가지 일을 하면서 전문가가 안 되는 비결이 있다면 타당성과 피드백이 부족한 환경에서 일하는 겁니다. 예컨대 복잡한 상황에서 뒤죽박죽으로 일하거나 오늘 실수한 것을 몇 달 뒤에 알거나 혹은 영영 모르거나 하는 환경이겠죠. 따라서 이 두 가지가 전문성의 요체라고 할 수 있겠습니다.\n 경력  경력 연차는 직무 성과와 얼마나 많은 상관성을 갖고 있었을까요? 또 학력과의 상관성은 얼마나 됐을까요? 경력 연차의 상관성은 0.18, 학력의 상관성은 0.10 입니다. 상관성이 0.20 이하면 사회 과학에서도 꽤나 약한 상관성이라고 말합니다. 관심사조차도 직무 성과와 상관성이 0.10이 되는 수준입니다.\n \u0026lsquo;잘하기 위해서 좋아하는 일을 하는 것이 필수조건이 아닌 것인가?\u0026rsquo;, \u0026lsquo;직무의 목적은 성과를 내기 위해서일 뿐인가\u0026rsquo;, \u0026lsquo;자아 실현을 위한 직업을 갖는 다면 그 성과를 어떻게 측정할 수 있을까\u0026rsquo;, \u0026lsquo;직무 성과와 가장 큰 상관관계를 갖는 항목은 무엇인가\u0026rsquo; 다소 충격적이면서도 위와 같이 이런 저런 정리 되지 않는 생각을 하게 만든 연구 결과였다.\n","permalink":"https://diglog.io/posts/%ED%95%A8%EA%BB%98-%EC%9E%90%EB%9D%BC%EA%B8%B0/","summary":"함께 자라기 - 애자일로 가는 길은 개발자 블로그나 커뮤니티 내에서 좋은 평을 많이 봐서, 언젠간 읽어 봐야지 라고 벼르고 있었는데, 드디어 읽었다.\n작년부터인가 개인적으로 너무 정체 되어 있던 것 같아서 \u0026lsquo;성장\u0026rsquo;에 대해서 고민을 하지 않을 수 없었는데, 이 책은 그에 대한 고민에 대한 해답과 동기부여에 아주 적합한 책이었다. 여러 사례들과 저자의 인사이트를 모은 에세이 형태이다 보니 사실 목차 순서대로 읽지 않아도 되지만, 저자의 의도를 고스란히 느끼고자 원래 책을 순서대로 읽는 편이다 보니, 왜 앞서서 이러한 예시를 먼저 들었는지 알만한 부분들이 많았다.","title":"함께 자라기"},{"content":"Hello World 👋 This blog is mainly for recording and sharing what I learned about software development in general. At this moment, most of drafts are written in Korean, but sometimes I\u0026rsquo;ll force myself to use English just so that I\u0026rsquo;m not loosing it completely. I used to live in Chitown 🏙️ . I\u0026rsquo;m based in South Korea 🇰🇷 since 2018.\nJust so you know, I\u0026rsquo;m very new to blogging. Depends on my interest and career, the main topic of this blog is subject to change.\nI\u0026rsquo;m _ _ _ 🙋‍♀️  a cloud researcher ☁️ working with Kubernetes  I\u0026rsquo;ve been _ _ _ 💻  developing K8s operators, RESTful APIs and web applications using Java, Go, Postgres, PHP and Linux  You can reach me via LinkedIn\n","permalink":"https://diglog.io/about/","summary":"about","title":"About Me"}]