백엔드가 이정도는 해줘야 함

필자가 고등학교 1학년 말에 처음으로 백엔드 포지션에서 프로젝트를 진행하며, 멍청했던 과거 이야기와 이 컨텐츠를 기획한 동기를 공유합니다.

버전 관리 시스템과, 이러한 버전 관리 시스템을 사용하는 프로젝트를 지원하는 웹호스팅 서비스를 의사결정합니다.

이슈 관리, 작업 진행 방식, 작업의 제품 반영 과정과 같은 것들에 대한 규칙을 정리합니다.

API 설계 원칙과 직렬화 포맷을 결정합니다.

리소스가 특정 사용자에게 귀속되는 서비스라면 인증이 꼭 필요합니다. 이 챕터에선 사용자 인증 방식을 결정합니다.

API 스펙 설계를 위한 가이드라인을 일러두고, 실제로 API 스펙을 설계합니다.

프론트엔드 팀에게 전해줄 문서를 작성해야 합니다. API 문서를 어떤 식으로 작성하고 관리할지 결정합니다.

문서화도 다 끝났으니 로직을 코드에 옮기기만 하면 된다. 그러나 아직 어떤 언어를 쓸지/의존성을 어떻게 관리할지/어떤 데이터베이스를 어디서 운영할지와 같은 것들이 정해지지 않아서 바로 개발에 착수하기는 어렵다. 이번에는 어플리케이션 기술스택(프로그래밍 언어와 프레임워크)을 결정하고, /에 GET 요청 시 'Hello World'를 text/plain으로 반...

이번엔 의존성 관리 도구를 결정하자. pip, npm, yarn, gem, maven, gradle 등과 같은 의존성 관리/빌드 도구를 써본 적 없다면 이해하기 어려울 수 있으니 의존성 관리 도구(Dependency Manager)라는 글을 읽어보자. 프로젝트 한두번 하면서 의존성 관리를 해 본 경험이 있다면 더욱 좋다. 도입 이유 의존성 관리 도구 소...

이번엔 Compute Engine을 결정하자. 우리가 구현한 서버를 실행할 위치를 결정하는 것이다. 아래 3가지에 대해 의사결정이 필요하다. 어떤 컴퓨팅 파워를 이용할 것인지(출처) 만약 외부 서비스를 이용하기로 했다면, 어떤 서비스를 사용할 것인지 해당 서비스에서 제공하는 컴퓨팅 엔진들 중 어떤 것을 사용할 것인지 등 오늘 하게 될 이야기는 AWS와...

이번엔 서비스 운영을 위한 메인 데이터베이스를 결정하고, AWS 클라우드 위에서 해당 데이터베이스 엔진을 사용하는 인스턴스를 하나 띄워보자. 가상 컴퓨팅 환경 하나 단위를 AWS에서는 인스턴스라고 부른다. 도입 이유 데이터베이스 데이터베이스는 엑셀을 떠올리면 된다. 데이터베이스의 가장 중요한 특성은 구조화된 데이터를 관리한다는 점이다. 'ID', '비밀...

이번 주제는 배포 자동화다. 원래 CI(Continuous Integration)와 CD(Continuous Deployment)같은 것들을 이야기해보려 했으나, 배포 자동화라는 용어가 덜 추상적이고 더 명시적이라 용어 선택을 선회했다. 도입 이유 배포 자동화 반복 작업 배포라는 과정은 불필요한 반복 작업이다. 우리가 만들고 있는 웹 어플리케이션의 경우...

여태까지 많은 의사결정과 작업을 섞어가며 우리가 개발에만 집중할 수 있는 환경을 열심히 만들어 봤다. 아직 꽤 부족한 상황이지만, 우리의 프로토타입 어플리케이션을 개발하는 데에는 이 정도면 충분하다. 이번엔 코드를 작성하는 데에 있어서 이런저런 판단의 기반이 될 의사결정을 진행하고자 한다. 깊게 고민할 건 딱히 아니고 체크리스트 정도라 각각의 의사결정은 (...

어플리케이션 레벨 의사결정은 이제 반 정도 한 것 같다. 뭐 이렇게 자잘한 것까지 다 결정하냐 싶겠지만, 내가 맘대로 정하고 통보하는 것보단 나을 것 같았기 때문에, 그리고 꽤 재밌는 이야깃거리일 것 같아서 이렇게 하고 있다. 12챕터의 내용들은 딱히 몰라도 상관 없기 때문에, 맘에 안 들면 그냥 13챕터로 넘어가도록 하자. 의사결정 시각 데이터 저장 방...

개발 다 하고 나서 그냥 스냅샷 링크만 던져줘도 되겠지만 여기도 '일러두기' 설명을 좀 하는 게 좋을 것 같아서 챕터를 나눴다. 일러두기 API 스펙의 변경 2019년 3월 7일 이전에 6. API 스펙 설계와 문서화 방식 결정 - (1) 챕터를 읽었다면, 사용자의 ID를 이메일로 두고자 하는 시도가 있었음을 기억할 것이다. 실제로 구현하려고 보니, 개인...

웹 어플리케이션을 개발하는 과정이 생각보다 오래 걸려서, 다른 챕터들에 비해 업로드의 텀이 매우 넓게 잡혀버린 것에 죄송한 마음을 전합니다. 이 컨텐츠를 진행하기 위한 시간이 그렇게 많지 않다는 걸 확실히 인지하고 있었더라면 범위를 좀 적게 잡을걸 싶기도 했는데, '시간이 나서' 하는 것보다 '시간을 내서' 하는 게 맞는 것 같으니 이제 좀 더 열심히 글을...

해당 챕터는 '아 그래서 테스트를 코드로 작성하는 것이 좋구나' 정도만 이해하고 넘어가도 좋습니다. Python과 Flask에 익숙하지 않은 개발자라면, 굳이 코드 전체를 이해하려고 용쓰지 않아도 됩니다. API를 개발하고, Lambda라는 완전 관리형 컴퓨팅 엔진에 이를 배포해 둔 입장에서 가장 무서운 것은, API가 원하는 대로 동작하지 않는 이슈가 ...

오늘 이야기할 내용은 사실 내가 떠드는 거 읽으면서 간접경험하는 것보다, 어떤 언어든 프레임워크든 상관 없으니 실제로 코드를 짜 보면서 직접경험을 하는 편이 훨씬 낫다. 나는 책이고 강의고 뭐고 그냥 코딩 엄청 해보는 게 최고의 경험이라고 생각한다. 그럼에도 불구하고

16. 테스트에 대한 고민 - (1)에서 이어집니다. 고민 간접 테스트에 만족할 것인가? 개발해 두었던 어플리케이션의 코드를 보면, DB에 쿼리하는 부분들을 모두 ORM 모델의 class method로 만들어 두었다. 예를 들어, ID 중복 체크는 아래처럼 메소드화되어 있다. [16. 테스트에 대한 고민 - (1)](https://velog.io

테스트 코드와 관련된 챕터에 글을 쓰고 나서, 거기서 얘기한 테스트 코드를 모두 작성한 뒤에 챕터를 진행하려고 했더니, 평일에 하루종일 코딩하다 집 들어와서 다시 코딩해야 하는 상황이라 너무 진행이 되질 않습니다. 따라서, 이제부턴 테스트 코드 작성과 챕터 진행을 동시에 진행하려고 합니다. AWS에서 인스턴스 기반으로 움직이는 요소(EC2, RDS 등)들...

60챕터 정도로 계획을 잡았고, 그동안 약 20개의 글을 통해 17개 챕터의 내용을 공유했다. 그러나 이런 주제로 글을 쓰는 게 개인의 성장에 그리 큰 도움을 주지 않는 것 같아 그동안 연재를 일시중지하고 있었다. 내용의 난이도가 높아서가 아니라, 교과서를 쓰는 느낌이