ryanpark.dev

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

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

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

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

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

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

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

*책의 기본적인 정보는 여기에서 볼 수 있다

모두 생각하고 있지만 실천하지 않는 것, 나는 그것을 실천할 뿐이다. 바로 ‘시간을 잘 쓰는 것’이다.

세상을 살면서 한번도 ‘시간을 잘 쓰는 법’에 대해서 배워본 적이 없다. 이 문장을 통해 ‘시간을 잘 쓴다’라는 의미가 무엇이고 어떻게하는 것이 잘 쓰는 것인가에 대해서 고민을 하며 책을 읽어 내려간 것 같다.

욜로(YOLO, You Only Live Once)라고 하면 사실 ‘현재를 즐기자’는 뜻으로 통용되지만 사실 ‘한 번뿐인 인생의 소중함’을 의미한다. 즉 시간의 가치를 강조한다고 보는 것이 맞다.

YOLO라는 의미가 시간의 가치를 강조를 한다는 것에 100% 공감을 하지는 않지만, ‘한 번뿐인 인생의 소중함’을 다시 생각하게 되었다. 인생을 사는데 있어서 무엇에 가치를 두느냐에 따라 한 번뿐인 소중한 인생을 어디에 투자할 것인지를 나타내는 것같다. 나의 소중한 한번뿐인 인생을 의미없는 youtube 동영상을 보며 보내고 싶진 않았다.

1만 시간의 법칙이 성과로 연결되기 위해서는 ‘제대로 설계된 방식에 의한 훈려Practice’이 필요하다고 한다. ‘의식적인 연습이 바로 그것이다.’

‘시간을 잘 쓰기’를 위해서는 의식적인 연습이 필요하다는 것이다. 우리는 무의식 속에서 습관적으로 하는 행동들이 의외로 많은 것 같다. 나의 경우에는, 집에 오자마자 옷을 갈아입기전에 컴퓨터 키기, 집을 나오는 순간부터 핸드폰 보기, 핸드폰을 보며 무의미하게 여러 앱들 켰다 꺼보기, 다른 사람 카카오 프로필 사진 훑어 보기 등등.

목표가 남들과 비슷하거나 똑같다면 곤란하다. 탁월한 성를 내고 싶다면 남과 다른 길을 가는 법을 배워야 한다. 남과 같은 길을 걸어가는 건 그 만큼 누구나 진입이 쉽다는 말도 된다. 집입이 쉬운 만큼 경쟁은 치열하다.

이 문장에 대해서는 대체로 동의하지만, ‘목표가 남들과 비슷하거나 똑같다면 곤란하다’는 것에는 동의하지 않는다. 삶을 살아가는데 있어서 남들과 비슷하고 똑같은게 나쁜것인가? 내 생각은 그렇지 않다. 물론, 시간을 잘 쓰기 위해서는 남들과는 다르게 시간관리를 해야한다고 저자는 말하고 싶었던 것 같다.

100년의 인생에서 우리가 맡게 되는 역할은 직없인 하나가 아니다. 우리는 아버지이자 아들이고 친구 또는 선배, 선생님, 상담가가 되기도 한다.

*책의 기본적인 정보는 여기에서 볼 수 있다

이미 소프트웨어 개발 역량 자체는 충분하니 더 나은 절차와 소통 방식“절차만 개선하면 돼. 다른 것들은 괜찮아”.

여기서는 애자일을 도입할 때, 종종 기술적인 탁월함이 전제되어 있다는 것을 잊을 때가 있다고 말한다. 이 전제를 잊은 채, 단순히 절차만을 개선하면 더 나은 소프트웨어가 나올거라고 생각하면 안 된다는 것이다. 내가 PM이나 애자일 코치가 아님에도 불구하고 이 문장에 관심을 가진 이유는 내 실력이 애자일에서 전제되어 있는 실력에 충분조건인지 생각해 보게 되었기 때문이다. 여기서 말하는 기술적 탁월함이 어느 정도인지 모르겠지만, 스스로에 대해 생각해 보기 바란다. 애자일 방법론에 앞서 나는 기술적 탁월함이 있는 개발자인가?

피드백 시스템이 동작하려면 자기가 하는 일에 충분히 주의를 기울이고자기 목소리를 내는 재능 있고 프로페셔널한 사람들이 있어야 한다

이 문장에 주목한 이유는 가장 최근에 내가 이와 같은 개발자가 되어야 겠다고 생각했기 때문이다. 쉽게 말해 내가 주어진 업무를 처리할 때, 왜 이렇게 개발되어야 하며 이것이 최고의 선택이라고 설명 할 수 있어야 한다는 것이다. 기획자 또는 운영팀에서 요구한 요구사항들만 순순히 모두 개발 했다고 해서 좋은 개발자라고 할 수 없다는 것이다.

우리는 항상 업무와 일정의 압박 속에 있다는 생각을 가지고 있다 언제나 급하게 일해야 한다고 느낀다.

개발자들이 의도적으로 나쁜 코드를 작성하지는 않는다.

항상 우리가 유념해 둬야 할 것이라 생각한다. 스스로가 만든 일정의 압박감 때문에 나쁜 코드를 작성하지 않아야 한다. 빨리 개발하는 것 보다 정확하게 개발해야함을 우리는 이미 많이 들었고 경험으로도 알고 있을 것이다.

테스터가 버그를 발견하는 것은 개발자로서 대단히 수치스러운 일이다.

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

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

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

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

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

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

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

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

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

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

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

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

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

나는 스스로 성장하기 위한 방법으로 주로 책을 읽는다. 올해 읽었던 책은 아래와 같다.

청지기 성경적 재정 교육(하워드 데이튼 저자 / 한국청지기아카데미 번역 / 한국청지기아카데미) 돈에 넘어진 성경의 사람들(척 벤틀리 지음 / 왕진무 옮김 / 한국청지기아카데미)

*혹시 자신이 좀 더 자세히 도움을 얻고자 한다면 아래 사이트를 통해 도움을 얻을 수 있다. (http://www.koreasa.org/)