About Me
POST
Development
Post
검색
Intro
Project Euler 문제를 풀면서 수학적인 사고와 새로운 프로그래밍 언어를 학습하고 익혀갔습니다. 수학문제를 푸는 것을 좋아하고 평소에 알고리즘 문제를 푸는 것을 좋아했기에 적합한 난이도 였습니다. 초반에 나온 문제들은 수학적으로 많은 사고를 요구하지 않습니다. 그래서 새로운 언어를 익힐 때 ‘어떤 예제를 짜볼까’ 고민을 많이 하게 되는데, 개인적으로 여기에 나오는 문제들이 그러한 고민을 많이 해소해주었습니다.
Solution
아직 문법적으로 미숙한 상태에서 풀어가기에 부족한 점이 많이 보일 수 있습니다. 좀 더 개선할 수 있는 부분이 보이면 이글의 댓글이나, 링크에 있는 github issue에 올려주시면 감사합니다 🙂
Project Euler Solutions
development
2019/08/19
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
Book
Post
검색
My Life
Post
검색
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 구축까지 모두 혼자 할 수 있는 기회를 얻게 되었다. 더구나 스토어 팀에서 조금씩 해보았던 것들이라, 크게 부담감이 느껴지지 않았다. 아직까지 이때의 선택을 후회하진 않는다. 아마 앞으로도 후회하진 않을 것 같다. 이 태스크와 관련한 회고는 어느 정도 완료된 후에 하도록 하겠다.
2-3. 나는 올해 성장하기 위해 무엇을 했나
나는 스스로 성장하기 위한 방법으로 주로 책을 읽는다. 올해 읽었던 책은 아래와 같다.
2018년도 회고
my life
my life>회고
2018/12/31
소개
이 글의 모든 내용은 내가 출석하고 있는 교회내에 있는 “재정학교”라는 훈련을 바탕으로 기록하였다. 이 글을 작성 중인 시점은 아직 훈련을 받고 있는 중이라 내가 잘 못된 이해로 작성되었을 수도 있고, 같은 말씀을 읽어도 개개인이 다른 시각으로 이해할 수 있기 때문에 단순 참고용으로만 받아들이길 바란다. 이 것을 내가 이렇게 요약해서 공유하는 이유는 여러가지가 있다. 아직 훈련의 초반부임에도 불구하고 나만 알고 있기엔 아깝다는 생각이 든 것이 첫번째이고, 그 다음으로는 요즘 금수저, 은수저, …, 흙수저라는 말이 나오는 시대 가운데서 나의 또래(9x년생)에겐 재정, 돈, 재산을 어떻게 관리하고 바라봐야 할 지 어려울거란 생각이 들어서이다. 이 글이 여러 그리스도인에게 도움이 되고 도전이 되길 바란다. 더불어 현재 이 글을 읽고 있는 자신이 기독교인이 아니라도 현재 재정적인 어려움과 고민이 있다면 한 번이라도 훑어보길 권한다.
목차
컴퍼스 머니맵
아래 표를 보고 자신의 현재 위치를 파악하고, 참된 재정적 자유를 이루기 위해 다음 스텝이 무엇인지 확인해 보자.
참고도서
*혹시 자신이 좀 더 자세히 도움을 얻고자 한다면 아래 사이트를 통해 도움을 얻을 수 있다. (http://www.koreasa.org/)
성경적 재정관리는 무엇일까?
my life
my life>신앙
2017/01/27
Recent Post
Post
검색
<Copyright 2020. Ryan Park. All right reserved.>