일곱째 주 (슬기로운 클라우드팀 생활) - 7

때때로 그런 생각을 하고는 합니다.

내가 3초전에 무엇을 생각했나.

내가 1시간전에 정확히 무엇을 하고 있었나.

1년 전에 나는 무엇을 하고 있었나.

50년 전의 사람은 누가 있었지?

 

지금까지 대략 1100억 정도의 인류가 살았다고 합니다.

그렇지만 그 1100억의 인류 중에서 저희가 알고 있는 사람은 도대체 누가 있을까요.

영원할 것 같지만 그 무엇도 영원하지 않죠.

 

하드디스크에 기록된 데이터는 얼마나 오래 갈까요.

종이에 쓰여진 기록은 얼마나 오래 갈까요.

 

당사자도 기억하지 못하고.

아무도 기억하지 못한다면. 그건 존재했던 시간일까요. 누군가 알아줄 수 있는 시간일까요.

주관주의적인 세계관에서 생각하자면, 그것들은 없는게 되겠죠.

있었는데. 없었습니다.

기억 하지 못하는 시간들...

회사에서 업무를 맡아서 OpenAPI와 OAuth 에 대해서 좀 더 알아보고.

기존의 코드들도 살펴보고. 프로젝트도 구성하고. 어떻게 배포할지도 조금 고민해보고.

이것저것 생각할 거리들이 많아서 그런걸지도 모르겠습니다.

 

OAuth에 대해서는 뭐랄까.. JWT 을 처음 받아들였을 때의 그런 느낌이 들었습니다.

강한 거부감이랄까요. 왜 그렇게 해야만 하는걸까. 어째서? 그냥 하면 안돼? 그냥 만들면 안돼? 내가 원하는 정도로만...

이런 생각이 많이 들었습니다.

 

여기서 많은 사람들이 햇갈리는게, OpenAPI 와, OAuth 을 같은 것으로 생각한다는 오류를 범한다는 것입니다.

저도 그랬고요.. 아니요, 저만 그랬으려나요..

 

OpenAPI 이라는건 OOP 처럼 일종의 방법론이라고 생각합니다.

단순하게 비유를 들자면, 프론트 앤드와 백엔드가 OpenAPISpecification, 이하 OAS 의 양식에 맞춰서 개발하면.

다른 모든 클라이언트 개발자들은 OAS 만 참조하면서 개발하면 된다는 것이지요.

 

그 OAS 가 가장 잘 적용되어 있는게, Docker 라고 생각합니다.

Docker CLI, Docker Compose, Docker Potainer, Docker ...., 그리고 온갖 플러그인들.

그것들을 전부다 Docker 개발사가 만든걸까요? 아니요. Docker OAS 에 따라서, 온갖 다양한 클라이언트들이 만들어진거랍니다.

 

OAS는 아직 성장중인 개발 방법론이라고 생각합니다.

그리고 동시에 미래지향적인 개발 방법론이고, 대세가 될 개발론이라는 생각이 듭니다.

지금이야 누구나 OOP 을 하고, 함수형 프로그래밍을 하지만 처음나온 그 당시는 아닌 것 처럼.

수십년전에는 MIT 입학 시험 문제로 미분과 적분이 나왔던 것 처럼. 해당 개발 방법론이 가까운 미래에는 무척이나 당연한 것으로 받아들여질 것 같습니다.

 

OpenAPI 이야기를하면 GraphQL 에 대한 이야기도 꼭 나오는 것 같았습니다. 아마 그 까닭으로는 많은 현장이 웹 클라이언트와 웹 백엔드로 나뉘어지다 보니까. GraphQL 쓰면 OpenAPI 안써도, 클라단에서 원하는대로 쉽게쉽게 할 수 있다. 라는 그런 취지에서 GraphQL 이 강력하다는 의미로 나온 것 같았습니다.

 

제가 GraphQL 에 대해서 안건, 2020년도 때 였습니다. 연구실에 계신 무척이나 열혈 실원분이 계셨는데, 그 분이 GraphQL 에 대해서 세미나를 해 주었거든요.

 

그런데 이런 데이터베이스를 다루는 무엇인가를 사용했을 때.

내가 원하는 것 만큼의 자유도가 없다는것이고, 무척이나 쿼리가 복잡해져서 뭐가뭔지 모르는 그런 상황이 온다는 것 입니다.

GraphQL은 도대체 무슨 쿼리를 사용하는지 모르겠다는 겁니다. 그게 최적화가 된 쿼리인지 아닌지 모르겠다는 것. 그리고 앤드포인트가 하나라는 것...

 

DB는, 무조건 생쿼리를 사용을 해야한다. 어떠한 DTO 나 어떤 wrapping 하는걸 사용하는 것은 비효율의 극치다. 라고. 저는 생각을 하고 있기 때문인지도 모르겠습니다.

어쩌면 새로운 기술에 대한 거부감이었을지도 모릅니다만...

 

do you know map-reduce?

DB를 다루는 일에서는 극도로 보수적이고 틀딱충(?)이어야 한다고 생각합니다.

MongoDB와 같은 NoSQL들은 약간 Data Server 으로서의 역할에 적합한 것이지 Data Store 에는 RDB가 더 적합하다고 생각합니다.

MongoDB 는 개발자적인 입장에서 굉장히 마음에 듭니다. 자유롭거든요. 마치 Javascript 같습니다.

RDB 는 프로그램적인 느낌이 매우 강합니다. Domain Specific 하다는 느낌이 파박 꽂힙니다.

MongoDB 는 MongoDB 의 세계에서. RDB 는 RDB 의 세계에서. 각자 갈길을 찾아가서, 각자의 자리를 지키고 있을 것 같습니다.

 

(실제로도 NoSQL 들 자체가 그렇지요. Data Store 이라는 느낌 보다는, Data Server 이라는 느낌이 강합니다.)

 

 

레거시 코드를 만났을 때

아는 연구실 후배가, 제가 생각했을 때 기술적으로 괜찮다는 생각이 드는 회사로 인턴에 있었습니다. 어땟냐고 물어보니까... 레거시가 좀... 이라고 하더군요.

또 제가 생각했을 때, 저희 나라에서 IT 업계에서 1위라고 생각하는 곳 또한.... PHP 코드가 레거시로 남아 있다고 하더군요.

 

레거시 코드라는건 왜 생기는걸까요. 그리고 그걸 왜 방치하면 안되는 걸까요.

Perl 이라는 언어의 철학 모토가, 우스겟 소리로, write once never read 이면 안되는걸까요?

잘 작동만하고, 그걸로 문제가 없으면 되는거니까요.

그리고 당연하게도. write once 까지는 좋지만, never read 가 되지 않기 때문에... "잘 작동"하지 않기 때문에. 말이에요.

 

이러한 레거시 코드들은 도대체 어떻게 생기는 걸까요.

어떤 건물을 공사할 때에도, 마지막에는 마감처리를 합니다. 특히 시멘트 바닥 마감이 그렇죠.

바닥이 마감처리 되지 않은 그 느낌..... 그게 레거시죠.

현실에서도 오래된 보도블럭이나, 도로를 재정비를 하는것을 보면. 공사에 대한 비유가 적절해 보이다는 생각이 드네요.

 

일단 작동하니까. 일단 다 했으니까. 마감 처리를 해야하는데... 바쁘다보니까. 그러다 보니까.... 어쩔 수 없이....

그러면 나오는 말이 있습니다. "처음부터 잘 만들면 되지" 그렇지만 그렇게 말하는건 너무나도 가혹한게 아닐까요? 흑흑...

문제라는건, 처음부터 정답을 알고 있으면 문제가 아닐까요.. 그런 생각이 듭니다.

 

인프라에도 관심이 좀 많습니다.

저희 회사는 bitbucket 을 기반으로 pipe line 을 돌려서 instance 에 배포를 하고 있습니다.

나쁘지 않은 방법이라고 생각합니다. 정석이라고 생각합니다.

Global 으로, 11개의 리전으로 배포하는 것만 아니었다면요.

 

AWS 에서 들어가면. 콘솔이 Region 단위로 되어있습니다.

한 Region 에서 클릭을 100번 해야 한다면, 항상 * 11이 되어버립니다.(과장 보태서..)

production 을 배포할 때 항상 불안합니다.

그런데 그런게 11개이라니요. 쉽지 않은 일입니다.

 

이런 인프라 관련 문제로, Java Bible 처럼 제시되는게 테라폼입니다.

그래서 테라폼이 뭔가요? 그냥 AWS SDK, Azure SDK, GCP SDK 가져다가.

자신들이 그것들을 랩핑해서 하나의 인터페이스를 제공해주는 것. 그것 뿐입니다.

마치 DTO 쓰면, MariaDB 에서도 쓸 수 있고. Oracle 에서도 쓸 수 있고. 그런 것 처럼요.

 

테라폼은 마법이 아니라고 생각합니다.

그것으로 무엇을 하느냐가 더 중요하다고 생각합니다. 테라폼은 그저 도구일 뿐이지요.

테라폼 안쓰고 Azure SDK 써서 스크립트 작성해도 됩니다.

빌드 스크립트. 배포 스크립트. 테스트 스크립트. 온갖 쉘 스크립트... 결국 그것의 근본은 스크립트이지요.

어떠한 DevOps 을 원하는지 모르니까. 테라폼은 그 모든것을 할 수 있도록 지원해주니까. 무척이나 일반적이고 유용한 도구이지요.

 

DevOps 에 대해서 이야기를 하면, 바이블과 같이 k8s 에 대한 이야기가 나옵니다.

물론. 정말로 k8s 가 필요로해서, k8s 을 하는 경우도 있지만. 대부분의 경우는 그게 아니라고 생각 합니다.

k8s가 아니라, 테라폼과. 어떠한 스크립트가 필요한 경우가 대부분이라고 생각합니다.

 

그리고 실제로도 많은 경우에 있어서, k8s 는 DevOps 보다도.

분산환경 인프라 구성에 더 잘 활용되는 면모가 있는 것 같습니다.

예를 들어서. 내가 분산환경 프로그램을 만들었는데. 그래서 이걸 도대체 어떻게 분산배포할거냐?

그 때에. 직접 구현하기보다는, k8s 을 사용하는 것이지요. 어떤면에서는 솔리디티와 유사하기도 하네요.

 

저는 DevOps의 끝판왕이 Serverless 이라고 생각합니다.

그리고 그렇게 될 거라고 확신합니다. 99.99999999999% 으로요.

물론 풀어야할 숙제들이 많겠지만, 극복할 수 있다고 생각합니다.

음... 말하고 싶은건 많지만. 너무 길어질 것 같아서.. 이만 줄이겠습니다.

 

:...(

 

References

https://medium.com/ddosify/cold-start-comparison-of-aws-lambda-and-cloudflare-workers-a3f9021ee60a