스트리미 입사 후 회고

오랜만에 글을 작성하는 것 같습니다.

2021년 10월 31일 이후로 작성된 글이 없는 걸 보니 대략 1년 정도 블로그 활동을 안한 것 같습니다.

 

블로그 활동을 안한 이유는 "바쁘다" 라는 핑계를 대면서 하지 않았습니다.

어느순간 반복적인 일과 일상, 새로운 것을 배워도 반짝이고 끝, 어느 정도 여유가 생기니 발전 하는 것이 싫어졌던 것 같습니다.
(배부른 돼지가 되어버렸습니다....)

DevOps라는 직군으로 입사하였지만, 막상 DevOps가 무엇을 위주로 하는지는 찾아보지도 않고, 시키는 일만 열심히 했거든요.

 

그리고 입사전, 입사 후 간절함과 노력, 성장에 대한 욕심이 많았지만 근래 들어서 그러지 못한 것 같습니다.

물론 노력과 성장에 대한 욕심은 지금도 갖고 있지만... 예전만치 못하다?? 입니다.

 

그래서 지금까지 해온 것, 앞으로 해야할 것 들에 대해 정리해보고자 합니다.

 

1. 해 온 것들.

Git.

처음 입사했을 때, git pull, git commit, git push 밖에 몰랐던 때에 Master branch에 merge되는 것이 얼마나 중요한지 모르고...

그냥 작업하던 코드를 git push를 한 기억이 있습니다. 그때 Tech leader분 께서 도와주셔서 revert한 기억이 있습니다.

그 후 rebase, merge, log, diff, stash, squash etc.... 에 대해 조금씩 배워나아가고 더 나아가 활용하고 있습니다.

 

Linux

저희는 개발환경 OS를 Linux로 사용하고 있습니다. 서버 또한 Linux입니다.

그래서 log를 분석할때나 File에서 특정 단어를 Parsing할 때,

cat, tail, head, dig, curl, awk, grep, sort etc...을 좀 더 능숙하게 활용할 수 있게 되었습니다.

 

Shell check

대부분의 언어에 대해 Lint를 기본적으로 잡아주고 있었지만, Shell script에 대해서 lint를 잡아주고 있지는 않았습니다.

때문에 Code Convention이 제각각이었으며, 가독성 또한 매우 안좋았습니다.

그래서 Google shell style guide를 적용시켜서 Code Convention을 통일 시키고 가독성을 높였으며,

Shell check 를 도입하여 lint를 잡았습니다.

 

AWS

스트리미에 입사 후 가장 많은 시간을 할애하고, 여러 서비스들을 경험해보았습니다.

사용해본 서비스들을 나열해보자면 다음과 같습니다.

• Cognito
• EC2
• RDS
• VPC
• Transit Gateway
• ECS
• API Gateway
• S3
• Lambda
• Certificate Manager
• Route 53
• CloudFormation
• Cloud Watch
• Cloud Trail
• WAF
• Direct connect
• System Manager
• IAM
• Secrets Manager
• MWAA
• Glue
• etc

이 외에도 CodeCommit, VPC Endpoint, SNS 등이 있습니다.

여기 나열한 것들의 기능들을 10% ~ 80%까지 다뤄본 것 같습니다.

 

Infra

저에게 꽤 큰 프로젝트로 다가왔던것이 Infra에 대한 구축이었습니다.

MWAA Infra구축.

Travel Rule를 이행하기위한 Verify VASP솔루션 Infra구축.

Data Mart구축을 위한 Infra구축.(현재 진행중...)

 

특히 위 프로젝트를 진행하면서 많이 성장했던 것 같습니다.

"어떻게 하면 좀 더 Private하게 구축할 수 있을까?..." 에서 많은 고민을 했습니다.

최대한 Public Access를 없애기 위해서 VPC Endpoint를 활용하였고,

각 리소스별로 IAM Policy를 최소한으로 부여하도록 노력했습니다.

그 외 기존 Infra코드들의 유지보수를 하였습니다.

 

ISMS

... 노가다 작업의 연속...

보완사항이 나오면 수정하고... 다음에 또 다른게 나오고... 연속...

특히 이해가 안가는점은... 개발환경의 DB Data들은 Dummy data인데...

이걸 주기적으로 체크해서 사용 안하는 Data를 왜 지워야 하는지 아직도 모르겠다....

(혹시 모를 실 데이터가 있기 때문이라고 생각중이긴 합니다....)

 

그 외...

Javascript를 사용해 단순한 Batch성 AWS Lambda를 만들거나 간단한 코드 수정, 

EC2에 올라가있는 Software Solution 서버 관리, Admin에 구현이 안되거나 할 수 없는 CS Ticket처리 등....

 

 

이렇게 나열해보니 많은걸 해왔었네요. 

 

2. 아쉬웠던 점

1. CI/CD 구축.

현재 내가 속한 Team은 CICD가 구축이 되어있지 않습니다. 때문에 배포일정을 잡고 매번 사람이 수동으로 배포하고 있습니다.

하지만 CI는 아직 힘든 얘기가 될 것 같고... CD만이라도 구축하여, 사람이 배포하는 일을 없애고 싶습니다.

지금 Jenkins서버를 AWS Fargate로 구성하여 빌드를 할 때 agent가 Fargate로 띄워져서 일하고 죽는 형태로 구성을 했습니다.

이걸 현재 Data Team에서 사용하려고 시도중인데, 아직 고려해야 할 사항이 많은 작업입니다.

 

2. CloudFormation의 Nested 제거.

이번에 정기배포??를 하면서 RDS의 버전 업그레이드를 진행했었는데, 이를 CFN으로 수행하였습니다.

하지만 CFN이 Nested가 되어있다보니깐 여러 스택의 template중 하나라도 Fail이 나면 CFN특성상 모든작업을 Rollback하게 됩니다.

RDS버전 업그레이드 도중에 Fail이 나면 1~2시간동안 기다리고 있던 Update를 Rollback하게 되면서,

굉장히 복잡해지며 시간도 날리게 됩니다. 

 

물론 Fail이 났을 때 Rollback도 중요하다고 생각합니다. Rollback을 해야 실패 하더라도 이전 상태를 유지하면서 서비스를 제공할 수 있으니깐요. 뿐만 아니라 잘못된 코드의 배포도 어느정도 방지할 수 있습니다. 하지만 롤백 도중 Fail나는 경우도 있고, 특정 부분은 롤백이 안되도 되는데, 되어버리는 경우도 있습니다. 결국 이런 문제를 해결하려면 dependency를 줄여햐 하고, 결국 모듈화 시켜서 관리를 해야 한다고 생각합니다. 

 

3. 우선순위 없는 업무진행

개발자에게 있어서 우선순위를 정하는 것은 매우 중요하다고 생각합니다.

해당 우선순위에는 데드라인이 있는 Task, 없는 Task, 개인 발전과 관련있는 Task, 없는 Task, 개인 공부 등...

여러가지를 나열 할 수 있습니다. 하지만 업무를 하는데 있어서 우선순위 없이 들어오는 업무만 급급하게 처리했던 것 같습니다.

물론 데드라인이 있는 업무 위주로 하긴 했지만, 그 외에 것들에 대해서 단순하게 처리했었습니다. 

때문에 우선순위를 어느정도 정한 후 업무를 할 생각입니다.

 

우선순위를 구하는 척도는 다음과 같이 하려고합니다.

1. 데드라인이 있는 TASK

2. 당장 처리해야할 버그, 위기인 TASK

3. 팀내에 개발, 업무효율을 높여줄 수 있는 TASK

 

어찌보면 당연한 말인데, 이를 구별하기가 사실상 쉽지 않습니다. 

데드라인이 있는 TASK도 사실 데드라인이 필요 없는 경우도 있고,

급하게 처리해야할 것 처럼 보였지만, 사실 그렇지 않았고,

팀내에 업무효율을 증가시켜줄 것 같았지만, 막상 당장 사용하지 않았고... 등...

이런 업무들을 명확하게 구별해 내고 우선순위를 정해야 하는게 중요한 것 같습니다.

 

4. 성장

스트리미라는 회사를 다니면서 개인적으로 많은 성장을 이뤄냈다고 생각합니다.

하지만 요즘 정채기에 있는 것 같습니다. 비슷한 아키택처 설계, 비슷한 업무 등....

사실 찾아보면 내부적으로 개선해야할 사항이 많은데, 이를 잘 못했던 것 같습니다.

개선을 통해서 새로운 기술도입이나 더 좋은 코드를 개선하면서 같이 성장할 수 있을 텐데...

또한 AWS컨퍼런스를 가서 다양한 회사들의 사용사례들을 들어보면 전부 EKS를 사용하고 있었습니다.

저희는 아직 EKS를 사용중이지 않고, 나중에 EKS로 넘어간다고 하는데, 이번 기회에 관련된 공부를 해볼까 하는 생각입니다.

그뿐만 아니라 여러가지 세미나에 참석하면서 다양한 사람들을 만나 인맥을 넓히는 것도 중요할 것 같습니다.

 

마치며...

저희 시니어분께서 사주신 "이펙티브 엔지니어"라는 책을 틈날때마다 읽고 있습니다. 이 책에서는 레버리지가 높은 업무, 우선순위, 지속적 배포의 중요성 등에 대해서 상세히 설명해주고 있는 책입니다.

결국 같은 시간대비 레버리지가 높은 일을 하는것,

처음에는 더딜지 몰라도 나중에 더 큰 레버리지가 되는 것 등이 주된 책의 내용입니다.

여러가지 업무를 동시에 많이 진행하고 계시거나, 시간대비 Return값이 없을때, 무언가 개선을 해야할 것 같을때

읽으면 좋은 책인 것 같습니다.