Project Euler 문제를 풀면서 수학적인 사고와 새로운 프로그래밍 언어를 학습하고 익혀갔습니다. 수학문제를 푸는 것을 좋아하고 평소에 알고리즘 문제를 푸는 것을 좋아했기에 적합한 난이도 였습니다. 초반에 나온 문제들은 수학적으로 많은 사고를 요구하지 않습니다. 그래서 새로운 언어를 익힐 때 ‘어떤 예제를 짜볼까’ 고민을 많이 하게 되는데, 개인적으로 여기에 나오는 문제들이 그러한 고민을 많이 해소해주었습니다.

Solution

아직 문법적으로 미숙한 상태에서 풀어가기에 부족한 점이 많이 보일 수 있습니다. 좀 더 개선할 수 있는 부분이 보이면 이글의 댓글이나, 링크에 있는 github issue에 올려주시면 감사합니다 🙂

Project Euler Solutions

development

2019/08/19

1. Makefile에 help 타겟 추가

help: @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}'

2. help 에 노출하고 싶은 곳에 설명추가

##으로 해당 타겟에 대한 설명추가

prod-deploy: ## Deploy Production dep deploy production -v -p

완료된 파일

Makefile

help: @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' prod-deploy: ## Deploy Production dep deploy production -v -p prod-rollback: ## Rollback Production dep rollback production -v -p prod-unlock: ## Unlock Production dep deploy:unlock production -v

결과

ryan@macbook:~/deployer$ make help prod-deploy Deploy Production prod-rollback Rollback Production prod-unlock Unlock Production

Makefile에서 help target 추가하는 법

development

2018/04/24

1. “/etc/munin/plugin-conf.d/munin-node” 내용 확인

... [mysql*] user root env.mysqlopts --defaults-file=/etc/mysql/debian.cnf #env.mysqluser debian-sys-maint env.mysqluser root env.mysqlconnection DBI:mysql:mysql;mysql_read_default_file=/etc/mysql/debian.cnf ...

해당 내용을 통해 /etc/mysql/debian.cnf을 이용해 접속한다는 것을 확인 가능하다.

2. “/etc/mysql/debian.cnf” 에서 접속정보(user, password) 변경

# Automatically generated for Debian scripts. DO NOT TOUCH! [client] host = localhost #user = {$sys_maint_user} #password = {$sys_maint_password} user = {$user} password = {$password} socket = /var/run/mysqld/mysqld.sock [mysql_upgrade] host = localhost #user = {$sys_maint_user} #password = {$sys_maint_password} socket = /var/run/mysqld/mysqld.sock basedir = /usr

3. munin 플러그인 설정 명령어 확인

4. munin-node 재시작

# sudo service munin-node restart // 재시작 후 munin 그래프가 생성이 안될시에 아예 stop 후 start 시도 # sudo service munin-node stop # sleep 5 # sudo service munin-node start

참고

http://munin-monitoring.org/wiki/munin-node-configure

Munin에서 mysql plugin 세팅방법

development

development>DB

2018/04/11

terraform을 이용해서 인프라를 관리하다가 보면 노출되면 안되는 값을 코드로 작성해야 될 상황이 생긴다. 예를 들어, terraform으로 RDS를 생성할 때 마스터의 비밀번호가 한 예이다. terraform을 아래와 같이 작성해 버리면 해당 코드나 관련 저장소를 볼 수 있는 모두가 DB의 마스터 비밀번호를 알게되서 보안상 취약하게 된다

resource "aws_db_instance" "db-sample" { ... password = "master-password123!" ... }

그래서 이를 해결하기 위해 AWS에서 제공하는 KMS를 통해 비밀번호를 암호화하는 방법을 공유하고자 한다.

1. KMS Key 생성

KMS 암호화를 하는데 사용될 key를 생성해야 한다. AWS 공식문서를 따라하면 쉽게 만들수 있다.

2. 비밀번호를 암호화

터미널창을 열고 아래 비밀번호를 별도 파일로 만들어둔다.

$ echo -n 'master-password123!' > plaintext-password

그리고 아래 명령어를 실행한다. 이때 $key_id는 1번에서 KMS key를 생성하고 나서 생성된 key의 id를 넣어줘야 한다. 혹시 터미널에 AWS CLI 구성이 안되어 있으면 여기를 참고하기 바란다.

$ aws kms encrypt \ --key-id $key_id \ --plaintext fileb://plaintext-password \ --output text --query CiphertextBlob

실행하고 나면 아래와 같이 암호화된 문구가 출력이 된다.

$ aws kms encrypt \ --key-id $key_id \ --plaintext fileb://plaintext-password \ --output text --query CiphertextBlob AQICAHi1tzJHZQT30hQmf3yueEfl/t9tZ2L+7jqr6IcHddQEV1guYe/AlotboEYBuPA

이것을 terraform에에 아래와 같이 추가하여 세팅해주면 끝난다.

data "aws_kms_secret" "db" { secret { name = "master_password" payload = "AQICAHi1tzJHZQT30hQmf3yueEfl/t9tZ2L+7jqr6IcHddQEV1guYe/AlotboEYBuPAAAAajBoBgkqhkiG9w0BBwagAzPleEZAgEAMFQGCSqGSIb3DwEQQMYzETfPvyHhzpT8tvGAntNu/P2fexBnxRTa2L6T4w/d3z/5mxeTGk/aM=" } } resource "aws_db_instance" "db-sample" { ... password = "${data.aws_kms_secret.db.master_password}" ... }

Terraform에서 KMS Encryption 사용법

development

development>AWS

2018/04/04

IOS 개발하는데 있어서 참고적으로 알고 있어야 메모리 관리에 대해 적어보려고 한다. 메모리를 관리하는데 있어서 3가지지의 방식이 존재한다.

가비지 컬렉션

수동 레퍼런스 카운팅 및 오토릴리즈

자동 레퍼런스 카운팅

1. 가비지 컬렉션 (GC, Garbage Collection)

가비지 컬렉션은 JAVA를 사용해본 사람이라면 누구나 알고 있는 것이다. 동일한 것이라고 생각하면 되는데, 잠시 가비지 컬렉션의 특징에 대해 잠시 짚고 넘어가자. 가비지 컬렉션은 런타임 중(=앱이 실행되고 있는 동안)에 내가 생성했던 오브젝트가 현재 사용중인지 아닌지를 모니터링을 주기적으로 하다가, 사용중이지 않은 오브젝트가 많이 쌓이기 시작하면 불필요한 오브젝트를 제거해서 사용 가능한 메모리 공간을 확보하는 방식이다. 이런 방식때문에 아래와 같은 단점이 있다.

어떤 오브젝트가 사용중인지 아닌지 확인하고 메모리를 해제하는데 별도 비용이 발생한다. 그렇기 때문에 메모리 관리를 제대로 하지 않고 개발을 하게되면, 가비지 컬렉션이 자주 동작하게 되고 이로 인해 전체적인 앱 성능이 저하된다.

가비지 컬렉션이 언제 일어나는지 개발자 입장에서 예측할 수가 없다. 그렇기 때문에 앱을 어느 상황이든 실시간으로 빠르게 이용하고 싶어하는 사용자의 입장에선 안좋은 UX경험이 될 가능성이 있다.

2. 수동 레퍼런스 카운팅 및 오토릴리즈

이건 쉽게 생각해서 수동으로 현재 생성한 오브젝트가 몇 군데에서 사용중인지 갯수를 카운팅하는 것이다. A를 객체를 만들고 A를 사용하고 있는 사용처가 생기면 +1, 사용 후 필요가 없으면 -1하는 개념이라고 생각하면 된다. 사실 중요한건 3번이기에 ‘대충 이렇군아’하고 넘어가자.

3. 자동 레퍼런스 카운팅 (ARC, Auto Reference Counting)

바로 위에서 말한 2번의 개념을 자동으로 컨파일러가 해주는 것이다. 여기서의 핵심은 컴파일러가 해준다는 것이다. 그렇기 때문에 앱을 빌드(=컴파일)하는 시점에, 2번에서 처럼 우리가 수동으로 레퍼런스 참조하는 곳에서 카운팅을 +1 또는 -1하는 코드를 넣어야했던 것을 컴파일러가 자동으로 대신해주는 것이다.

가비지 컬렉션 != ARC

많은 이들이 가비지 컬렉션과 ARC을 동일한 것으로 착각하는데, 그렇지 않다. ARC는 가비지 컬렉션과 다르게 런타임이 아닌 컴파일 단계에서 처리가 된다. 이때문에 ARC는 런타임 중(=앱이 실행되고 있는 동안)에 메모리 관리를 위해 별도 비용이 발생하지 않는다. 또한 1번에서 언급했던, 가비지 컬렉션이 런타임중에 실행되면서 발생하는 두가지 단점들이 ARC에서는 모두 해결이 된다.

메모리 관리와 ARC

development

2018/04/02

ssh로 접속시에 실수에 의해 비밀번호를 자주 틀리게 되면 sshguard에 의한 해당 ip가 차단되는 경우가 있다. 이럴 경우 다른 서버를 통해 접속하고자 하는 서버에 접속 후 아래 명령어들을 통해 해결할 수 있다.

$ sudo iptables -L sshguard --line-numbers --numeric Chain sshguard (1 references) num target prot opt source destination 1 DROP all -- 192.168.0.123 0.0.0.0/0 $ sudo iptables -D sshguard {num}

sshguard에 의해 접속 실패하는 경우 해결방법

development

2018/04/01

1. Isolation Level

여러개의 트랜잭션에서 변경되고 수행되는 쿼리가 동시에 일어났을 때, 성능과 신뢰, 일관성 사이에서 균형을 잡는 수준이다. 예를 들어서 한 트랜잭션에서 A라는 데이터를 수정하고 아직 커밋이 되지 않은 경우, 다른 트랜잭션은 A라는 데이터에 락을 걸어 접근할 수가 없게 할 수 있다(Read Committed Isolation Level인 경우). 반면 Isolation Level을 조정하여, 한 트랜잭션에서 A라는 데이터를 B라고 수정하고 아직 커밋이 되지 않은 경우, 다른 트랜잭션은 B라는 데이터에 접근할 수 있게 할 수도 있다(Read Uncommitted) 이렇게 위에 예시로 든 2개를 포함하여 총 4개의 Level이 존재하는데, 이 중에서 innoDB의 기본값인 Repeatable Read Isolation Level에 대해서 설명하고자 한다.

2. Repeatable Read Isolation Level

하나의 트랜잭션내에서 첫 번째 SELECT 쿼리가 실행되었을 때 스냅샷을 찍어서 타 트랜잭션의 변경사항과 상관없이 SELECT 결과를 계속해서 같은 상태로 보여주는 것이다. 예를 들어 아래와 같은 테이블이 있다고 가정해 보자.

CREATE TABLE `table_1` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `val` tinyint(3) unsigned DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

그리고 아래와 같이 (1), (2) (3) 순으로 쿼리가 실행되었다고 가정해 보자

## A 트랜잭션 START TRANSACTION; SELECT * FROM table_1 WHERE id = 1; # (1) => 결과가 (id =1, val = 5) 나왔다고 가정. SELECT * FROM table_1 WHERE id = 1; # (3) => B 트랜잭션의 (2)에서 update가 이루어졌지만 repeatable isolation level에 의해 (1)의 결과와 동일하게 나옴 COMMIT; # B 트랜잭션 START TRANSACTION; UPDATE table_1 SET val = 2018 WHERE id = 1; # (2) => (1) 에서 select 했던 row의 데이터를 변경함 COMMIT;

여기에서 주의해야 할 것이 있는데, 바로 첫 SELECT 쿼리가 실행되었을 때 스냅샷을 찍는다는 것이다. 아래 두가지 예시를 비교해보면 이해가 될 것이다.

1) 첫번째 예시

## A 트랜잭션 START TRANSACTION; SELECT * FROM table_1 WHERE id = 500; # (1) => 해당 row가 비어서 empty set이 나왔다고 가정 SELECT * FROM table_1 WHERE id = 500; # (3) => (1)과 동일하게 empty set이 나옴. (1)의 첫 SELECT 쿼리에서 스냅샷을 찍고 스냅샷의 데이터를 읽기 때문에 계속해서 동일하게 (1)번의 결과가 나옴 COMMIT; ## B 트랜잭션 START TRANSACTION; INSERT INTO table_1 (`id`, `val`) VALUES(500, 999); # (2) => id=500에 데이터를 새로 추가해 줌 COMMIT;

2) 두번째 예시

위의 첫번째 예시와 동일하게 id=500인 row가 없다고 가정.

## A 트랜잭션 START TRANSACTION; INSERT INTO table_1 (`id`, `val`) VALUES(200, 300); # (1) => id=500과 상관없는 데이터를 삽입. SELECT * FROM table_1 WHERE id = 500; # (3) => (id = 500, val = 999) 데이터가 나옴 (3)번 이전에 스냅샷을 찍은적이 없기에 B 트랜잭션의 (2)에서 새로 추가된 값을 읽음 COMMIT; ## B 트랜잭션 START TRANSACTION; INSERT INTO table_1 (`id`, `val`) VALUES(500, 999); # (2) => id=500에 데이터를 새로 추가해 줌 COMMIT;

Book

Post

My Life

Post

어느덧 리디에 입사한지 3주년이 되었다. 길다면 길고 짧다면 짧은 3년이란 시간 동안 나의 변화들을 기록해보려고 한다. 리디에 있는 3년 동안 PM도 해보고 짧은 기간 매니저도 해보고 다양한 경험을 해본 것 같다. 더불어 개발적인 부분도 많이 성장하게 된 것 같다. PHP, Python, Node를 포함한 다양한 언어와 프레임워크를 써볼 기회가 있었고 AWS ECS, DynamoDB, Lambda 등 여러 인프라를 직접 써보며 관리할 수도 있었다. DevOps로써 많은 경험을 쌓았던 것 같다.

3년전의 나의 모습

사실 지금 돌이켜 생각해보면, 어떻게 입사면접을 통과했는지 모르겠다. 3년전의 나는 백엔드 개발 경험이 전무했었다. 제대로된 백엔드 개발을 해본 적이 없을 뿐더러 DB사용도 해본적이 없어서 기본적인 SELECT, INSERT문 외에는 써본 적이 없었다.

3년 전 나는 병특이 된 후6개월만에 이직을 준비하고 있었다. 이전 직장에서는 PDF 웹 뷰어를 만드는 작업을 주로 했었기 때문에, C++을 이용한 PDF 파서와 프론트엔드에서 SVG를 이용한 주석 그리는 것이 주요 업무였다. 이전 직장에서의 경력이 있었지만 백엔드 업무와는 거리가 멀었었다.

3년이 지난 지금의 모습

서두에서 짧게 언급한 것처럼 여러 경험을 했고, 여러 개발적인 부분도 성장했다고 생각한다. 그러나 이번 글에서는기술적인 성장 보다는 소프트스킬이라고 생각되는 부분에 대해 다뤄보려고 한다. 앞으로 나눌 부분은 개인적으로 회사에서 뿐만이 아니라 기타 다른 모임에서의 대인관계에서도 긍정적으로 영향을 미쳤다.

1. 실수를 관리하게 되었다.

나는 리디에서 많은 실수들을 하였다. 오랜 시간이 지난 지금에선웃으며 얘기할 수 있는 일화 한가지를 소개하자면, 테스트를 위한 개발용 AWS RDS 제일 높은 타입(기억으론 db.m4.16xlarge 였던 것 같다. 시간당 5.6 USD)을 켜놓고 퇴근한 적이 있다. 퇴근 후에는 때마침 긴 추석 연휴기간(2017.09.30 ~ 2017.10.09)이었었다. 이렇게 쓰지도 않는 RDS을 켜놓고 가버린 탓에 요금 폭탄을 받고 팀장님께 불려나간 적이 있었다. (물론 AWS에 사정을 말하고 크레딧을 받긴 했다..) 이 외에도 배포하는데 있어서 식은 땀나게 되는 크고 작은 실수들을 많이 했었다. 하지만 이런 많은 실수들을 할 때마다 비난보다는 격려를 더 많이 받았었고, 다음에는 실수하지 않도록 방법을 함께생각하는 분위기가 있었다. 이로 인해 나도 주눅들지 않고 오히려 실수를 두려워하지 않게 되었다. 그렇게 나는 실수를 관리할 수 있는데에 관심을 두는 사람으로 성장할 수 있었다. 관련해서는 김창준씨가 쓴 글을 읽어보면 좋을 것 같다.

2. 커뮤니케이션의 중요성을 알게 되다.

3년전부터 나는 꾸준히 좋은 개발자가 되려면 무엇을 공부해야 할지 고민이 많다. 그러나 “좋은 개발자란 무엇인가?”에 대해서는 사람마다 제각각 인 것 같다. 인터넷에 올라오는 여러 글만 봐도 기준이 다 다르다. 아직도 좋은 개발자에 대한 물음이 많지만, 개인적으로 가장 큰 덕목은 커뮤니케이션 능력인 것 같다. 실제 업무를 하다보면 코드를 짜는 시간 만큼 여러 팀들과의 미팅, 코드리뷰, 아사나, 슬랙 등 많은 시간 커뮤니케이션을 하는데 시간을 쓴다. 이로 인해 개발실력을 높이는 것 만큼이나 더 나은 커뮤니케이션을 하기 위한 방법과 능력을 키우고자 노력하게 되었다.

3. 동료의 중요성을 알게 되다.

개발은 혼자 하는 것이 아니라 동료와 함께 하나의 제품을 만들어 가는 것이다. 그렇기 때문에 커뮤니케이션이 중요하듯이 같이 일하는 동료들 또한중요하다. 왜냐하면 개발하다가 이슈가 생겼을 때 동료와 해결책을 고민하는 경우가 많고, 새로운 기술을 익힐 때에도 동료들을 통해 배우는 경우가 많기 때문이다. 이러한 경험을 통해 나는 동료들의 중요성을 많이 깨달을 수 있었다. 주변에 좋은 동료들이 많다보니 나도 좋은 동료가 되어주기 위해 노력 중이다.

정리

리디에서의 3년 동안 개인적으로 많은 성장을 했다고 생각한다. 다양한 기술스택을 사용해보고 소프트웨어 설계를 넘어 인프라 설계까지 많은 경험을 했고 하고 있는 중이다. 이러한 경험들을 통해 ‘개발만 잘하면 된다’라는 생각이 많이 바뀌게 되었다. 우리는 보통 협업을 통해 함께 하나의 제품을 만들어 간다. 앞으로도 이 점을 잊지 말고 내가 맡은 일에만 집중하기 보다는 옆에서 고민하고 있는 동료를 도울 수 있는 마음가짐을 가지려 한다.

리디에서 3년간 배운 것

my life

my life>회고

2019/07/17

1. 서론

2018년도는 나에게 많은 일이 있었던 해였다. 임시적이었지만 5명 정도 되는 팀을 이끄는 매니저가 되었었고, 2년 정도 함께 했던 팀(스토어팀)에서 다른 팀(뷰어팀)으로의 인사이동도 있었다. 회사에서의 변화와 더불어 학교에 복학하여 일과 학업을 1학기 정도 병행하게 되었다. 이 외에도 많은 일들이 있었지만, 내게 가장 의미있던 매니저가 된 이야기와 팀 인사이동에 대한 이야기 그리고 그 외 부수적인 이야기로 회고하려 한다.

2. 본론

2-1. 주니어가 매니저가 되다

먼저, 매니저가 되게 된 배경을 적어 보는 게 좋을 것 같다. 스토어팀은 크게 백엔드 파트와 프론트엔드 파트로 나뉜다. 당시 정확히 기억은 안 나지만 백엔드 파트는 10명 정도 있었던 것 같다. 백엔드 파트는 겉으로 보았을 때는 잘 굴러가는(?) 것 처럼 보였지만, 결제관련 코드의 복잡성이 높다라는 큰 문제가 있었다. 여러 클래스들이 얽혀있었고, 추상화가 되지 않아 결제 수단이나 상품 타입(단권도서인가 세트도서인가 같은)에 따라 if-else의 향연이었다. 이를 위해 리팩토링이 필요하다는 인식을 오래 전부터 하고 있었고, 매 분기 마다 마일스톤으로 잡혀있었지만, 계속 되는 서비스 요구사항의 대응에 1년 동안 진행을 하지 못하고 있었다. 이를 해결하기 위해 백엔드 파트를 결제 스쿼드와 서비스 스쿼드로 나눠서 좀 더 결제 도메인에 집중할 수 있도록 하였다. 이렇게 나뉘고 결제 도메인에 대한 집중도가 높아지면서 리팩토링도 진행되게 되고, 지금의 리디페이가 나올 수 있었지 않나 생각이 된다. 나는 이렇게 나눠진 서비스 스쿼드의 임시 매니저를 맡게 되었다.

2-1-1. 나는 무엇을 배웠나

대략 5개월 정도의 짧은 기간이었지만 많은 것을 배운 시기였던 것 같다. 특히나 개발 외적인 부분에서 많이 배울 수 있었던 시간이었다. 타 팀과 커뮤니케이션 하는 방법, 팀원들에게 적절한 태스크 분배, 프로젝트 일정관리 등 많은 것들이 고민의 연속이었지만, 이 고민들을 해결 해나가면서 스스로 답을 찾아갔던 것이 큰 공부가 되었다. 처음에는 정말 폭풍 같았다. 잦은 회의와 팀원들이 쏟아내는 태스크들(예를 들어 배포나 코드리뷰와 같은) 때문에 정작 내가 해야 될 업무를 할 시간이 없었다. 하루 종일 Asana를 통한 타 팀과의 커뮤니케이션과 팀원들의 태스크 관리를 하느라 코드한줄 적지 못한 채 퇴근한 적도 많았다. 이를 해결하게 도와준 도서가 있는데, 몽키 비즈니스라는 책이다. 매니저를 맡게 되면서 읽어보라고 추천받은 도서인데, 여기선 원숭이를 하나의 태스크로 정의하고 있다. 이 책을 통해 매니저로서 많은 것을 배울 수 있었던 것 같다. 여기서 이 책의 내용을 설명할 순 없지만, 이를 통해 팀원에게 분배된 태스크가 잘 진행되고 있나 수시로 모니터링 하지 않게 되었고, 나의 업무에 조금 더 집중할 수 있게 되었다.

2-1-2. 짧은 기간의 아쉬움

매니저 역할을 하면서 가장 큰 아쉬움은 매니저를 할 수 있었던 기간이 너무 짧았다는 것이다. 물론 내가 학교 복학을 하지 않고 미루었다면 계속할 수 있었겠지만 그래도 아쉬움이 많이 남는다. 특히 내가 팀원들에게 태스크를 분배하면서 가장 많이 했던 실수가 있었는데 그 해결책을 아직도 못 찾은 것이 아쉽다. 그 실수는 팀원들에게 간단하다고 생각되는 태스크를 주었는데, 막상 코드를 수정하다보니 일이 커지게 되는 경우가 많았던 것이다. 2주가 넘게 태스크를 진행하다가 일이 너무 커져서 홀딩 되는 경우도 있었고, 내가 잘못된 해결방안을 제시해서 처음부터 다시 개발을 하게 되는 경우도 있었다. 내가 좀 더 도메인 분석을 잘하고 태스크를 줬다면 이런 실수가 안 나왔을 것 같다고 생각도 들지만 사실 이게 정답은 아닌 것 같다. 내가 제시한 방향대로 개발하는 것이 아니라 스스로 고민해보고 분석해서 나보다 더 좋은 제시를 하는 것이 정답인 것 같은데, “팀원 스스로가 그렇게 할 수 있도록 어떻게 만들까”에 대한 해답은 아직 찾지 못하였다.

2-1-3. 그래도 잘한 것

그래도 잘 했다고 생각하는 것 한 가지를 뽑자면, 도메인 지식의 이중화인 것 같다. 서비스 안정화를 위해 애플리케이션 서버 이중화나 DB 이중화를 하듯, 팀원들이 갖고 있는 도메인 지식에 대한 이중화도 필수적이라고 생각한다. 실제로 당시에 CRM(고객 관계 관리, 알림센터나 앱푸시 이메인 전송)에 대한 안정화를 진행 하고 있는 중이었는데, 장애가 발생했을 시에 대응할 수 있는 팀원이 1명뿐이었다. 그래서 항상 CRM 장애 관련 대응 태스크는 한 명에게만 쏠려 있었다. 이를 해결하기 위해, CRM과 같이 큰 도메인의 경우엔 도메인 지식을 공유하는 자리를 별도로 만들어 싱크를 맞추었다. 더불어, 두 명이 한 쌍을 이뤄서 CRM 관련 다양한 태스크를 함께 해결하도록 하였다. 또한, 특정 도메인에 대한 이해도가 높은 팀원에게 주면 효율적으로 빨리 끝낼 수 있을 태스크도 되도록이면 익숙하지 않은 다른 이에게 주려고 적절한 태스크 분배를 하였다.

2-2. 새로운 팀으로 이동하다

학교 복학 시점과 동시에 타 팀으로의 인사이동 기회를 얻게 되었다. 스토어팀에서 갖고 있던 여러 도메인(별점/리뷰, 선호작품 등)이 타 팀으로 오너쉽이 넘어가게 되었고 그 작업을 새로운 팀으로 이동하여 진행할 수 있게 되었다. 물론 내가 거절하고 스토어팀에 계속 남을 수도 있었지만, 이동하기로 결정하였었다. 이 결정을 내리게 된 2가지 이유가 있었다. 첫 째로는 2년이란 긴 시간을 한 팀에 있다 보니 내가 ‘우물 안 개구리는 아닐까’라는 생각이 들기 시작했기 때문이다. 스토어팀에서 많은 것을 배우고, 해봤지만 ‘이게 정말 맞는 걸까’, ‘다른 방법은 없을까’라는 생각이 들었다. 그래서 새로운 팀에서 새로운 사람들과 함께 일하면서 익숙함에서 벗어나고자 했다. 두 번째는 새로 옮겨지는 팀에서 맡게 될 업무가 만족스러웠다. 하나의 서비스를 처음부터 쭉 만들어 본 경험이 없었는데, ‘언어를 무엇을 쓰고 어떤 프레임워크를 쓸지’부터 시작해서 인프라 구성, CI/CD 구축까지 모두 혼자 할 수 있는 기회를 얻게 되었다. 더구나 스토어 팀에서 조금씩 해보았던 것들이라, 크게 부담감이 느껴지지 않았다. 아직까지 이때의 선택을 후회하진 않는다. 아마 앞으로도 후회하진 않을 것 같다. 이 태스크와 관련한 회고는 어느 정도 완료된 후에 하도록 하겠다.