따근따근한 신입 개발자의 온보딩 후기

author_profile오성택
  1. 간단한소개
  2. TDD 경험
  3. AWS ECS, CodePipeline을 사용하여 Blue/Green 배포 및 CI/CD 구축
  4. 마무리 소감

1. 간단한 소개

안녕하세요, 22년 5월 2일에 팀스파르타의 개발팀으로 들어오게 된 오성택입니다. 지난 2주의 온보딩 기간의 후기를 공유하도록 하겠습니다. 온보딩의 목표는 아래와 같았습니다.

2. TDD 경험

항해99를 하면서 처음 들어봤었던 TDD (Test Driven Development) 를 실제로 해본다는 것이 설레기도, 낯설기도 했습니다. 따라서 TDD에 대해 일단 먼저 알아볼 수밖에 없었습니다.

  1. TDD란 무엇인가?

테스트 주도 개발이라고 불리는 TDD는 반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 (Unit Test)를 작성하고 이를 통과하는 코드를 단계를 반복하여 구현한다.

  1. TDD는 왜 쓰는 것인가?
  2. 일반 개발 방식
  • 문제점 * 불확실한 소비자 요구사항 ⇒ 완벽한 초기 설계 불가 ⇒ 재사용 & 유지보수 힘듦
  • 자체 버그 검출 능력 저하 or 소스코드의 품질 저하
  • 자체 테스트 비용 증가
  1. TDD 개발 방식

  • 장점 * 실제 코드 작성 전에 테스트 코드를 작성함으로써, 보다 좋은 설계 가능

  • 재사용 & 유지보수 용이

  • 단점 * 높은 장벽

  • 코딩 시간 증가 → 생산성 저하 가능

  1. TDD 개발 주기
  2. RED: 실패하는 테스트 코드 작성
  3. GREEN: 테스트 코드를 성공시키기 위한 실제 코드 작성
  4. BLUE: 리팩토링

**실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않을 것.

**테스트는 독립적일 것.

TDD를 어는 정도 알아보고, 결제 모듈 테스트 시나리오를 작성했습니다. 테스트 시나리오 작성은 결제 모듈을 테스트할 때 고려해야되는 케이스들을 미리 구상하고 테스트 코드를 작성하기 위해 진행했습니다.

[결제 테스트 시나리오]

1. 주문 정보는 아래와 같은 종류를 기록할 수 있다.
    1) [결제 요청, 결제 완료, 환불 요청, 환불 완료]

2. 각 기록은 직전 기록에 의존성을 갖는다.
    1) 결제 요청: 직전 기록이 [결제 시작] 이어야  한다.
    2) 결제 완료: 직전 기록이 [결제 요청] 이어야 한다.
    4) 환불 요청: 직전 기록이 [결제 완료] 이어야 한다.
    5) 환불 완료: 직전 기록이 [환불 요청] 이어야 한다.

3. 다음과 같은 경우 결제 실패이다.
    1) 사용자의 카드가 문제일 경우
        a. 금액이 부족한 경우
        b. 사용 불가한 카드일 경우
        c. 한도 초과일 경우
        d. 카드 정보값 오류인 경우
    2) 상품이 문제일 경우
        a. 재고가 부족한 경우
        b. 더 이상 판매하지 않는 상품일 경우
...

시나리오를 다 작성하고 이에 맞는 테스트 코드를 작성했습니다.

describe("결제 실패 테스트", () => {
 
...

  test("2) a. 재고가 부족한 경우", () => {
    const product = createProduct("mouse", 1, 100000, true);
    const card = createCard(
      "amex",
      10000000,
      true,
      1000000,
      10000000,
      "00:00",
      "00:30"
    );
    const order = createOrder("Aron", "010-1234-5678", product.name, 2);
    expect(() => completeOrder(order, product, card)).toThrow(ProductError);
  });

  test("2) b. 더 이상 판매하지 않는 상품일 경우", () => {
    const product = createProduct("mice", 10, 100000, true);
    const card = createCard(
      "amex",
      10000000,
      true,
      1000000,
      10000000,
      "00:00",
      "00:30"
    );
    const order = createOrder("Aron", "010-1234-5678", product.name, 2);
    expect(() => completeOrder(order, product, card)).toThrow(ProductError);
  });

  test("5) 카드사 점검 시간일 경우", () => {
    const product = createProduct("mouse", 10, 100000, true);
    const card = createCard(
      "amex",
      10000000,
      true,
      1000000,
      10000000,
      "00:00",
      "00:30"
    );
    const order = createOrder("Aron", "010-1234-5678", product.name, 1);
    if (
      card.checkStart <
      new Date().toLocaleTimeString("en-US", {
        hour12: false,
        hour: "numeric",
        minute: "numeric",
      }) <
      card.checkEnd
    ) {
      expect(() => completeOrder(order, product, card)).toThrow(CardError);
    } else {
      completeOrder(order, product, card);
      expect(order.state).toEqual(ORDER_STATE.PAY_COMPLETED);
    }
  });
});

TDD에 대해 찾아봤을 때 나왔던 것처럼 실패 케이스를 우선시 했습니다. 실패할 케이스들에 대한 조건을 임의로 설정하여 테스트들이 통과하는지 확인할 수 있었고, 테스트 커버리지도 80% 이상으로 확인됐습니다.

Artillery를 사용하여 Load Test도 진행해봤습니다.

테스트 코드를 작성하며 ‘테스트는 독립적이어야 한다’ 라는 말을 많이 생각했습니다. 독립적이지 않은 테스트를 작성했을 경우에는 테스트 순서가 영향을 끼치게 되며 다른 테스트들이 실패할 수 있게 됩니다. 이로 인해 TDD를 실행하는 목적이 흐려질 수 있고, 프로덕트 코드를 수정해야 될 때 시간이 지체될 수 있으며 테스트에 대한 신뢰가 떨어질 수 있습니다. 따라서 이번 온보딩 과정에서 배운 TDD 방법론을 실제 개발에 적용하게 될 때, 마음 속에 새겨두며 작업을 해야겠다는 다짐을 했습니다.

3. AWS ECS, CodePipeline을 사용하여 Blue/Green 배포 및 CI/CD 구축

온보딩 2주차에는 AWS에서 제공하는 서비스들을 사용하여 CI/CD (Continuous Integration / Continuous Deployment) 를 구축하는 것이었습니다. 항해99에서 Github Actions를 사용하여 S3로 CI/CD를 구축해봤던 경험은 있지만, AWS의 VPC, Security Group, Target Group, Load Balancer, Cluster, Service, … 에 대해서는 무지한 상태였습니다.

AWS라는 방대한 바다에서 항해하는 것은 순탄치 않았습니다. 설정해줘야되는 것들이 정말 많았고, 어느 정도 단계까지가서야 발견되는 오류를 보고 좌절하지 않을 수 없었습니다. 하지만 위 그림에서 보여주는 ECS Architecture와 같이, VPC 생성부터 한 단계씩 이해하고 중간중간 발생했던 오류들을 해결해나가며 조금씩 감이 잡히기 시작했습니다.

CodeDeploy의 Build 과정에서 지속적으로 발생된 에러는 docker-compose 문제와 IAM 권한 설정 에러로 발생하였고, Deploy 과정에서 발생된 에러는 코드상의 naming이 AWS 설정 naming과 일치하지 않아 발생하였습니다. Load Balancer의 DNS 접속 에러는 보안 그룹 설정 에러로 발생했습니다.

결국 Deploy에 성공하였고 아래와 같은 초록색 결과들을 볼 수 있었습니다.

4. 마무리 소감

2주라는 시간이 어떻게 흘러갔는지 모를만큼 빨리 흘러간 것 같습니다.

낯선 환경에서 생소한 주제를 다룬다는 것은 언제나 겁나지만 동시에 재밌는 것 같습니다.

재미는 온보딩 목표를 달성해나가면서 앞으로 일을 할 때도 이어나갈 수 있겠다는 확신이 들었고, 겁은 주변 팀원 분들이 전부 사라지게 해주었습니다. TDD와 AWS CodePipeline 배포를 해보면서, 실무에도 도움이 될 거라는 확신이 들어서 좋았고 빨리 일을 해보고 싶다는 마음이 들었습니다. 또한 온보딩을 진행하면서 팀원 분들을 알아가고 팀스파르타라는 환경에 적응할 수 있어서 좋았습니다.

앞으로 일을 하게 되면 지금 보다도 생소한 주제를 더욱 빠르게 수행해야 되는 것을 알기 때문에 조금은 걱정이 들지만, 팀스파르타 개발팀의 일원으로서 빠르고 와우하고 진정성있게 일할 수 있도록 항상 노력하겠습니다.

감사합니다.

Copyright ©2022 TEAMSPARTA. All rights reserved.