팀스파르타 신입 개발자의 두근 두근 온보딩 후기
조헌일1. 간단 소개
안녕하세요. 팀스파르타 신입 개발자 조헌일입니다. 저는 개발자로서 커리어를 시작할 때 각 회사의 온보딩 과정이 어떻게 진행되는지 굉장히 궁금했습니다. 압축적으로 성장할 수 있었던 팀스파르타의 온보딩 과정을 공유해보도록 하겠습니다.
- 1주차 : TDD
- 2주차 : ECS, Fargate, Codepipeline을 이용한 CI/CD 구축
2. TDD 경험해보기
TDD(Test-Driven Development)에 대해 들어본 적은 있지만, 정확하게 어떤 것인지는 전혀 몰랐습니다. 그래서 온보딩에서 TDD를 학습해 본 것은 아주 좋은 경험이었습니다.
입사를 하면 켄트 백이 쓴 TDD책과 함께 웰컴 키트를 받습니다. 먼저 책을 통해 TDD가 어떤 것인지 이해해 볼 수 있습니다. 그런데 단순히 책만 읽었다면 “그래서 이게 대체 구체적으로 어떤 것인가?” 하는 느낌을 받을 수 있다고 생각합니다.
[결제 모듈을 TDD로]
단순히 “TDD를 학습해보자”가 아닌 TDD를 통해 결제 모듈을 만든다는 구체적인 상황이 있기 때문에 TDD에 대한 이해를 한 층 깊게 할 수 있었습니다. “결제모듈”이라는 주제도 아주 적절했다고 생각합니다. 어떤 비즈니스던 “결제”는 필수적이며 문제가 발생해서는 안되는 아주 중요한 기능이기 때문에 TDD를 적용하기 아주 적절한 주제였다고 생각합니다.
[나만의 TDD 레슨]
TDD 온보딩 과정을 통해 느낀 레슨을 정리해 보겠습니다.
- TDD는 소프트웨어 설계 방법론이다.
TDD는 소프트웨어 설계 방법론이기 때문에 너무 엄격하고 딱딱하게 접근을 하게 되면 TDD가 주는 교훈을 잘못 이해해버릴 수 있는 것 같습니다. 모든 것을 해결해 주는 silver bullet이 아닌, 이용할 수 있는 도구로 접근해야 합니다.
- “실패” 케이스를 우선시 하자.
테스트 코드는 실패 케이스를 우선시 해야합니다. 가령 어떠한 정보를 생성할 수 있는 경우와 정보를 생성을 실패하는 경우가 있다고 한다면, 정보를 생성에 대한 실패 케이스가 우선되어야 합니다.
// 성공 케이스 보다는 실패 케이스에 초점
describe("정보의 생성과 실패", ()=>{
describe("각 모델의 정보를 생성하는 **예시**들은 다음과 같다.", ()=>{
const user = createUser("ID", "PW", "name", "addr");
const product = createProduct("productNo", "productName", 1000, 1, true, true);
test("user 정보 생성 예시", ()=>{
expect(user).toEqual(new User(user.userID, user.userPW, user.userName, user.userAddr));
})
test("product 정보 생성 예시", ()=>{
expect(product).toEqual(new Product(product.productNo, product.productName, product.productPrice, product.productCount, product.isValid, product.canRefund));
})
test("order 정보 생성 예시", ()=>{
const order = createOrder(user, product, 1);
expect(order).toEqual(new Order(order.orderNo,order.userID, order.productNo, order.productName, order.productPrice, order.orderTime, order.orderCount, order.addr, order.state ))
})
test("pay 정보 생성 예시", ()=>{
const order = createOrder(user, product, 1);
const pay = createPay(user, order, PayMethod.Card);
expect(pay).toEqual(new Pay(pay.payNo, pay.payMethod, pay.payPrice, pay.payTime));
})
test("refund 정보 생성 예시", ()=>{
const order = createOrder(user, product, 1);
const pay = createPay(user, order, PayMethod.Card);
const refund = createRefund(user, order, pay);
expect(refund).toEqual(new Refund(refund.refundNo, refund.refundPrice, refund.userID, refund.payMethod, refund.refundTime))
})
});
** // 생성할 수 없는 경우에 집중!
** describe('아래와 같은 경우 각 정보를 생성할 수 없다', ()=>{
// 이 안에서 여러 정보를 생성하는 경우를 생각해볼 수 있습니다.
// 정보를 생성할 수 없는 에러 케이스들은 어떤 것이 있을까 생각하면, 데이터베이스에서 Schema를 강제 한다거나
// 타입, 꼴을 강제한다 거나 하는 것들로 이해해볼 수 있습니다.
});
})위에서 “정보 생성 성공 케이스”는 어떤 의미가 있을까? 라는 생각이 들 수 있습니다. 성공 케이스와 같은 경우는 기술서, TDD로 개발을 시작하게 되는 지점을 제공하게 됩니다. Test Code가 기술서로서 작용하면 커뮤니케이션을 위한 문서를 따로 작성하지 않아도 되며, TDD로 개발을 시작하게 되는 지점이 있으면 자연스럽게 “독립적인 행위”를 기반으로 한 설계가 가능하게 됩니다.
- TDD는 애자일이다.
TDD를 하다보면 시나리오 작성을 하게 되는데, 시나리오 작성을 조금 딱딱하게 접근해버리면 TDD를 워터폴 스럽게 이해하려 하고 있는 나 자신의 모습을 발견할 수 있습니다. TDD는 **테스트 코드 작성 → 구현 코드 작성 → 리팩토링 단계를 짧은 주기로 반복하여 개발하는 방법론 **이라는 사실을 잊으면 안됩니다.
3. AWS ECS, Fargate, Codepipeline을 통한 CI/CD 구축
다음으로는 AWS에서 제공하는 서비스를 이용해서 CI/CD를 구축해보는 경험을 가졌습니다. ECS, Fargate, Codepipeline을 이용하였고 성공적으로 구축하기 위해서는 AWS의 전반적인 시스템에 대한 이해가 필요했습니다.
AWS는 많은 것을 제공해주기도 하지만, 전반적인 기본에 대한 이해가 부족하다면 이를 잘 활용하기 힘들다는 것을 느꼈습니다. 모든 것을 이해해야 하는 것은 아니지만 기본적인 이해를 통해 AWS 시스템을 어떻게 사용하면 될 지 알 수 있었습니다.
위 그림은 AWS의 Codepipeline의 전체적인 과정을 보여줍니다. 결과적으로 변경사항만 push하거나, pull request를 날려 merge하면 서비스를 배포할 수 있게 됩니다. 빌드와 배포에 많은 시간을 절약할 수 있게 되기 때문에 팀 전체의 생산성이 굉장히 올라가게 됩니다. 작은 서비스 일지라도 CI/CD를 구축해두면 서비스를 개선시키고 성장시키는데 아주 큰 도움 될 수 있겠구나를 느꼈습니다.
4. 팀스파르타의 온보딩은 계속해서 발전하는 중
팀스파르타의 온보딩 과정은 개발자로서 학습해두면 두고두고 도움이 될 내용들이었다고 생각합니다. 좋은 개발자라면 자신만의 Task에서의 작은 부분 외에 큰 그림을 이해하고 싶다는 욕심이 있을 것이고 이를 이해하고 개선하고 싶어할 것 입니다. 또한 좋은 방향으로 소프트웨어 개발하는 방향이 어떤 방향이 있는지를 궁금해 할 것입니다. 그런 부분에서 TDD와 CI/CD 구축에 대한 압축적인 이해를 함으로써 많은 성장을 할 수 있었습니다.
팀스파르타는 [팀 곱하기]를 지향하는 문화가 있습니다. 학습하고 공유하고 개선하면서 팀 전체에 곱하기를 할 수 있습니다. 이는 온보딩 과정에서도 마찬가지였습니다. 온보딩을 경험한 스스로가 새로운 아이디어를 제안할 수 있고 개선점을 찾아 반영할 수 있습니다. 그리고 팀 곱하기를 하기 위해 학습한 내용을 공유하고 전달하면서 자신의 지식을 더 탄탄하게 만들 수 있으며 팀 전체에도 기여할 수 있습니다. 이런 선순환을 통해 팀스파르타의 온보딩은 계속해서 발전할 것이고 그것에 기여할 수 있다는 것도 아주 큰 장점 같습니다.