배포 서버로 쓰려던 슈퍼컴퓨터를 개발 서버로 바꾸는 이유

얼마 전부터 회사 개발 환경을 운영하는 방식을 바꾸고 있습니다.

처음에는 사무실에 있는 슈퍼컴퓨터를 배포용으로 쓸 계획이었습니다. 그런데 막상 해 보니 불편한 점이 꽤 있었습니다.

먼저 운영체제가 달랐습니다. 저는 평소 맥북을 쓰는데 사무실 슈퍼컴퓨터는 윈도우라서 한영 전환부터 매끄럽게되지 않았습니다.

더 큰 문제는 배포 과정이었습니다. 저희는 AWS SST로 배포하는데, 저는 VSCode 터미널에 명령어를 직접 입력하는 대신 Codex에게 배포 명령을 맡겨 왔습니다. 그런데 슈퍼컴퓨터는 여러 사람이 함께 쓰는 공용 컴퓨터라서, AWS IAM 권한이 배포만 할 수 있게 최소한으로 설정되어 있었습니다. 보안상으로는 맞는 설정이었지만, 그 때문에 배포가 실패해도 Codex가 에러 로그를 읽지 못했습니다. 결국 오류가 날 때마다 맥북으로 돌아와서 원인을 찾아야 했습니다.

그래서 역할을 바꾸기로 했습니다. 배포는 각자 컴퓨터에서 하고, 슈퍼컴퓨터는 개발용 서버로 쓰기로 했습니다.

이렇게 정한 이유는 메모리 때문이었습니다. 저희 아몬드영은 MSA 구조로 운영하고 있어서, 코드를 고치고 동작을 확인하려면 관련 서버를 여러 개 함께 띄워야 제대로 테스트할 수 있는 경우가 있습니다. 하지만 개인 컴퓨터에서 이 서버들에 Docker, Kafka까지 같이 돌리면 메모리가 부족해서 컴퓨터가 멈춰 버렸습니다. 그래서 이 무거운 개발 환경을 슈퍼컴퓨터에서 돌리기로 했습니다.

외부에서 들어오는 서버인 만큼 접근 제어도 같이 고민했습니다. 접속은 Cloudflare를 거치게 하고, 허용된 이메일로 MFA 인증까지 통과한 사람만 들어올 수 있게 설정할 예정입니다.

지금 슈퍼컴퓨터는 develop 브랜치를 기준으로 돌아가고 있습니다. 아직 운영 브랜치와 개발 브랜치를 따로 나누지 않은 건 개발 사이클을 빠르게 가져가기 위해서입니다. 다만 개발 서버 전용 브랜치를 따로 두는 게 나을지는 계속 고민하고 있습니다.