아이디어스팀은 2022년 11월 28일(월) ~12월 2일(금)에 라스베이거스에서 진행한 행사인 AWS re:Invent에 참여했습니다.

행사에 참여한 경험을 공유드리고 추후에 있을 AWS re:Invent 예비 참석자 여러분께 유용한 팁을 전달해 드리고자 합니다.

AWS re:Invent란?

AWS re:Invent는 AWS의 클라우드 컴퓨팅 및 기술 분야에서 가장 큰 규모의 행사 중 하나로, 세계 각국의 기술 전문가와 엔지니어들이 모여 다양한 세션과 워크샵, 전시회 등에서 최신 기술 동향 및 경험을 공유하는 자리입니다.

참가자 등록

행사에 참여하면 가장 먼저 시작해야 할 것은 참여자 등록입니다.
여권과 같은 신분증을 반드시 챙겨 본인 확인을 진행해야 합니다.

Keynote

AWS re:Invent Keynote는 AWS 고객과 비즈니스 전문가, 클라우드 커뮤니티 전체에게 AWS의 기술 및 비즈니스 전략에 대한 중요한 정보를 제공합니다.

AWS re:Invent를 참석한다면 강력하게 추천해 드릴 수 있는 이벤트입니다.

그만큼 많은 인파가 모이기 때문에 키노트 시간보다 15분 일찍 참여하는 것을 권장합니다. 만약 듣지 못하더라도 영상을 통해 실시간 공유와 번역도 지원되고, Youtube에 영상이 업로드됩니다.

AWS re:Invent 2022 Keynote의 주요 키워드는 다음과 같습니다.

1.Graviton3 인스턴스 타입 출시

2.HPC7 & Trn1 & C7gn 고성능 컴퓨팅 리소스 출시

3.Amazon GuardDuty RDS Protection 서비스 출시

4.Amazon Supply Chain 서비스 출시

Expo

Expo는 AWS가 제공하는 다양한 제품과 서비스를 소개하고, AWS의 파트너사 및 고객사의 제품과 서비스를 체험하고, AWS의 전문가와 대화할 수 있는 기회를 제공합니다.

이 공간에서는 다양한 제품 및 서비스 데모, 워크샵, 기술 세션, 네트워킹 및 파트너사 스폰서 부스, Swag 등이 제공됩니다.

Session

Session은 다양한 주제로 구성되어 있습니다.
기술 세션, 전문가 패널 토론, 교육 세션, 실습 랩, 데모 및 해커톤 등이 포함됩니다. 세션 또한 온라인으로 제공되며 실시간 라이브 스트림과 Youtube를 통해 언제든지 참여할 수 있습니다.

2022 AWS re:Invent Session에서 개인적으로 추천하고 싶은 세션은 Are you integrating or building distributed applications? (API308) 입니다.

발표 스타일과 내용이 엔지니어라면 누구나 매력을 느낄 수 있는 Session으로 느껴졌습니다.

AWS re:Invent 예비 참석자 여러분들을 위한 팁

1.립밤을 챙겨주세요!

네바다주 라스베이거스는 사막 지역으로 매우 건조합니다. 하루 이틀을 지내다 보면 어느새 입술이 하얗게 일어나있습니다. 미리 립밤을 챙겨 입술 보습을 챙깁시다.

2.Session은 AWS re:Invent 등록 후 바로 확인해주세요!
인기 세션은 금방 마감됩니다. 듣고 싶은 세션 놓치지 않도록 빠르게 진행해주세요.

3.AWS Events 앱을 받아주세요!

- IOS 앱 다운받기

- Android 앱 다운받기

갑자기 듣고 싶은 세션이 생겼다면 앱을 활용해 바로 Session 등록을 진행할 수 있습니다.

4.각 Session 사이에 여유 시간을 잡아두세요!

AWS re:Invent 행사에서 강연에 참여하실 때는 충분한 여유시간을 가지고 일정을 세우는 것이 좋습니다.

행사가 열리는 주요 호텔 내부 강연장은 카지노를 거쳐 입구에서 꽤 먼 곳에 위치할 수 있기 때문입니다. 호텔 간 이동을 해야 하는 경우에도 셔틀버스를 이용하더라도 최소 1시간은 준비해야 합니다.
(같은 호텔 내의 강연장이더라도 강연 세션 이동에 최소 30분을 고려해야 합니다.)

강연 세션 장소에 적어도 30분 전에 도착해야 예약한 자리를 찾아 들어갈 수 있으며, 예약하지 않은 분들도 대기를 통해 참여할 수 있습니다.

예약이 불가능한 경우 대기열에 대기할 수 있으니 이 역시 고려해야 합니다.

글을 마치며

솔트웨어에서 AWS re:Invent 행사 이외에도 네트워킹 자리와 여행자 키트를 준비해 주어 매우 감사합니다. 또, 아이디어스 팀을 대표하여 세계 최대의 클라우드 행사인 AWS re:Invent 행사에 참여하게 되어 매우 기쁩니다.

미래의 AWS re:Invent 참석자 여러분께 작은 도움이 되길 바라며 글을 마칩니다.

감사합니다.

Written by idus DevOps/Core system Cell

Content writer
Gyeongjun Paik, Jongchan Park

아이디어스팀과 함께 할 테크인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

[아이디어스] 2022 AWS re:Invent 탐방기 was originally published in Backpackr Team (idus, Tumblbug, tenbyten) on Medium, where people are continuing the conversation by highlighting and responding to this story.

이전 회사도 배울게 많고 빠른 성장을 하는 회사지만, 나의 성장을 위해 환경을 바꿀 필요가 있었다. 여러 회사 중 아이디어스팀을 선택한 이유는 나에게 커리어 방향성을 고민하게 해 준 회사였기 때문이다.

2020년 6월 장고 라이트닝 토크에서 발표 후, 네트워킹 시간에 아이디어스 시니어 개발자님(현재 리더님)을 만나 DevOps에 대한 이야기를 듣게 되었고, DevOps 문화에 관심을 갖게 되었다.

DevOps 문화가 궁금해 SRE 스터디를 진행했었다. 초기 스타트업에서 적용하기엔 무리가 있는 부분들이 많았지만, DevOps 철학은 확실했다.

SRE에서 가장 감명받은 구절이다.

culture eat strategy for breakfast(문화는 항상 전략을 이겨왔다.)

단순히 코딩을 좋아한다고 개발 문화를 만들 수 있는 것은 아니다. 내가 생각하는 좋은 개발 문화를 만들기 위한 원칙은 다음과 같다.

1. 실패를 인정하며 스스로 혹은 누군가를 속이지 않는다.
2. 다른 사람의 실패에 대해 관용을 지니며, 도전을 응원한다.
3. 실패를 바탕으로 더 나은 환경으로 개선한다.

이러한 DevOps 철학은 매력적이었다. 철학이 주는 영감을 나의 경험으로 녹여내고 싶었다.

마침 DevOps에 호기심을 심어준 아이디어스팀 DevOps 포지션이 열렸고,
2021년 5월 아이디어스에 합류하게 되었다.

아이디어스에서 진행한 업무 경험

아이디어스에서 진행한 업무

업무는 크게 3가지 관점으로 나눈다.

1. 장애 대응 : 안정적인 서비스 제공을 위해 우선순위를 가장 높게 잡은 업무.

프로세스

• 장애 발생 → 장애 인지(보고자 or 경고) → 장애 전파(연관 업무자) → 장애 해소 → 장애 리뷰(Post-mortem)

Post-mortem

장애 발생 이후, 장애 원인을 분석하고 같은 실수 반복하지 않도록 시스템화하는 것.

Post-mortem은 IT 산업 이전, 의료/항공 산업에서 유래된 것으로 알고 있다.

사고로 인한 인명피해가 있다면, 원인 제공자에게 책임을 물을 것이다. 원인 제공자는 책임 회피를 위해 원인을 숨길 수도 있지만, 원인이 숨겨진다면, 반복된 문제로 또 다른 누군가가 피해를 볼 수 있다. 이것만큼 끔찍한 일은 없을 것이다. 또, 책임을 져야 하는 일이 있다면 모두가 도망칠 것이다.

이를 방지하기 위해서, Post-mortem은 누군가를 탓하지 않는다. 오히려, 구조의 문제를 잘 파악하고 개선한 사례가 있다면 포상을 주는 회사도 있다.
(* 대표적인 예시로는 구글이 있다.)

아이디어스의 장애 대응은 Post-mortem 문화의 이해도를 갖고 있으며,
Short term을 통해 문제에 대한 주의사항을 팀원들과 공유하고,
Long term으로 같은 실수를 방지하기 위해 시스템화를 위한 업무를 준비한다.

2. 기술 연구 : 신기술 도입 & 기술 부채 상환

팀 전체의 생산성 향상을 위해 팀에 적합한 도구를 탐색하고, 팀에서 얻을 수 있는 이점을 검토하여 사용한다.

참여했던 프로젝트는 다음과 같다.

1. DEV/QA 분리 개선 작업
2. EKS Helm & 배포 파이프라인 리팩터링
3. 테라폼 클라우드 도입
4. Datadog 도입
5. 글로벌 서비스 준비

프로젝트에 대한 자세한 내용은 다음 포스팅에서 다뤄보도록 하겠다.

3. 운영 업무 : 아이디어스 성장을 원활히 돕는 업무

1. 아이디어스의 인프라 구성
2. Legacy system 성능 개선
3. 비용 최적화
4. ISMS 대응

IaC의 등장은 DevOps의 인기의 큰 지분을 준 것 같다. 인프라를 코드로 관리할 수 있게 되었고, 코드를 통해 자동화까지 가능하게 되었기 때문이다.

인프라 구성에 대한 기본적인 module 작성을 진행하고, variable을 주입하여 인프라를 생성할 수 있도록 테라폼 코드를 구성했다. 개발자분들께 인프라 구축 가이드를 제공하고, 리뷰를 통해 자원을 생성하고 있다.

좋았던 점

• 인프라 구조 통일 기여

과거 PROD와 STAGE 환경으로 구성되어 있었으며, STAGE 환경에서 개발과 테스트 그리고 검증(QA)을 같이 진행하여 인프라 구조가 복잡해졌고, 시간이 지나 STAGE 환경의 인프라 구조는 PROD와 약간은 다른 구조를 갖게 되어 QA의 안정성을 보장하지 못했다.

STAGE 환경을 제거하고, QA와 DEV 환경을 새로 구성하였고, 환경별 인프라 구조 통일과 각 환경의 전문성 부여에 대한 고민에 집중하였고, 이전에 겪었던 문제는 해결되었다.

• 인프라 생성 프로세스 병목현상 해소

내가 합류하기 전, 인프라 구성은 A부터 Z까지 DevOps의 손을 거쳐야 했다.
하지만, 현재는 개발자분들이 가이드를 보고, 직접 인프라 생성에 개입할 수 있어 DevOps셀이 업무를 진행하기 전까지 기다려야 하는 상황을 줄일 수 있었다.

개선할 수 있는 점

• 작업의 데이터화

IT 회사에서 일하는 장점 중 하나는 작업의 데이터화가 쉽다는 것이다. 데이터화는 작업으로 인해 어느 정도 기여했는지 간단명료하게 말할 수 있다.

예를 들어보자.

AS-IS: OO서비스의 XX 엔드포인트에 대한 API latency를 개선시켰다.

전자는 어느 정도 기여를 했는지 모호하게 만든다. 다음과 같이 말하면,

TO-BE: OO서비스의 XX 엔드포인트에 대한 API latency(p99)를 50%(500ms에서 250ms) 개선시켰다.(작업시간: 5시간)

데이터화를 하기 위해 공수가 필요하지만, 데이터화로 인한 커뮤니케이션 비용 감소가 더 크며, 일을 더 잘 할 수 있는 방법이라고 느꼈다.
초기에는 업무에 급급하여 대략적인 이점에 관해 이야기했는데, 아이디어스팀에서 일하면서 데이터 기반으로 이야기하는 상황이 늘고 있다.

• 작은 작업일지라도 공유하기

최근 DEV 환경의 Datadog Integration을 추가할 때, 실수로 EC2 호스트 필터를 제거하여 비용이 크게 늘었던 적이 있었다. 티켓의 작업 완료 알림을 받고 있긴 하지만, 모든 티켓의 알림 사항을 확인하기 어렵다. 간단히 메신저에 공유하고 진행했다면, 문제를 더 빠르게 파악할 수 있었다.

• 작업 전, 한 번 더 다시 확인하는 습관 들이기

장애의 대부분은 휴먼 에러에서 발생한다. 모든 업무가 보장된 시스템으로 진행된다면 문제가 없겠지만, 초기 작업에서 핸드메이드(수기)로 진행해야 하는 경우가 있을 수 있다. 이런 경우, 작업 진행 전 2~3회 검토하고, 팀원들과 더블 체킹하여 진행하는 습관을 들여 발생 빈도를 줄여야 한다.

그 외: (사람 + 개발) 좋음 = 개발 커뮤니티 활동

개발 커뮤니티 활동하며 많은 영감을 얻는다. 또, 나와 같은 고민을 하는 개발자 동료들과 좋은 벗이 되기도 하며 스트레스 해소가 되기도 한다. 내가 성장할 수 있고, 행복하게 일할 수 있다면 아이디어스에서는 응원과 지원을 아끼지 않는다.

글을 마치며

작년보다 나은 올해를 만들기 위해 회고를 매년 작성하고 있다. 이번 회고는 뜻깊었다. 회고를 작성하면서 아이디어스 팀원분이 한 분 한 분 떠올라 감사 말씀 드리고 싶다.

올해 겨울 AWS Re:invent를 갈 기회를 아이디어스팀에서 제공해 주어 인생 첫 미국 방문을 하게 된다. 아마 다음 포스팅은 AWS Re:invent 후기이지 않을까 싶다.

아. 그리고, 내년 회고를 쓸 땐, 처음으로 유부남이 되어 글을 쓰게 될 것 같다.

Written by idus DevOps Cell

Content Writer
Gyeongjun Paik

아이디어스팀과 함께 할 테크인재를 영입 중입니다.
지금 여기에서 지원해 보세요!

아이디어스팀 DevOps셀에서의 1년 회고 was originally published in Backpackr Team (idus, Tumblbug, tenbyten) on Medium, where people are continuing the conversation by highlighting and responding to this story.

이전글: [오늘의 헤드라인] 테스트 코드 작성기(1) — 단위 테스트 프레임워크

안녕하세요. 오늘의 헤드라인 서버팀 소프트웨어 엔지니어 Jun입니다.

오늘의 헤드라인팀은 성능을 위해 coroutine 라이브러리를 활용하고 있습니다. 그러나 해당 coroutine 라이브러리(aioredis, aiobotocore) mock에 대한 use case가 부족해 약 2주간의 삽질을 통해 해결한 경험을 이번글을 통해 공유하고자 합니다

서버팀은 서비스의 안정성을 높이기 위해 백엔드 프로젝트에 테스트 코드 작성을 시도했습니다. 이 프로젝트는 외부 서비스와 통신하는 코드였고, 테스트를 위해서는 각각의 시스템이 필요했습니다.

위의 문제를 쉽게 해결할 방안이 Mock이었습니다.

Mock이란?

직역하면 “모조품”이라는 뜻입니다.

테스트 코드를 실행할 때 외부의 다른 서비스나 모듈을 사용하지 않고 ‘실제 모듈과 유사하게 동작하는 가짜’를 Mock이라고 합니다.

Mock을 사용하는 이유

특정 경우에는 테스트가 외부 서비스(데이터베이스, 다른 웹 서버)로부터 의존하는 경우가 있습니다.

이럴 때는 다음과 같은 이유로 인해 테스트가 어려워집니다:

* 글에서 ‘상용 서비스나 데이터베이스’를 축약하여 ‘외부 서비스’라고 지칭하겠습니다.

1) 외부 서비스를 호출하는 것은 테스트 성능을 저하시킵니다.

• Mock 자원은 외부 서비스를 흉내 냈지만 ‘실제 자원’보다 작은 리소스를 사용합니다. 또한, CI에서 실제 서비스를 띄우는 과정이 없어 테스트 속도를 최적화할 수 있습니다.

2) 성공해야 하는 테스트일지라도 만약 외부 서비스가 예기치 못한 결과를 반환하면 실패할 수 있습니다.

• 외부 서비스는 외부 프로세스로 동작하면서 예기치 못한 결과를 반환할 수 있습니다. (ex — 5xx error)그와 달리 테스트 코드와 같은 프로세스에서 동작합니다. 즉, 외부 요인에 영향을 받지 않아 Mock은 Input에 따른 결과가 일정합니다.

3) 외부 서비스를 사용하여 모든 가능한 성공과 실패 시나리오를 테스트하는 것은 어렵습니다.

• 실제 외부 서비스의 장애를 내기는 쉽지 않습니다. (ex — 데이터베이스 디스크 용량 부족 문제) 하지만, Mock을 사용한다면 이러한 케이스를 쉽게 만들 수 있습니다.

∴ 외부 서비스에 의존하기보다는, 이러한 의존성을 “mock” 으로 대체할 수 있습니다.

mocking 101

pytest에서 mocking을 사용하는 방법을 간단히 설명하겠습니다. pytest에서 mock을 사용할 때 pytest-mock 플러그인을 사용합니다.

pytest-mock: fixture에 대한 mock을 지원하는 pytest 플러그인입니다.

테스트 코드에서 pytest-mock의 patch 함수를 통해 기존의 메소드(or 클래스)에서 사용하는 코드가 mocking된 코드를 호출하게 만들 수 있습니다.

• set_new_method라는 fixture를 다른 테스트 코드에서 사용했을 때, 기존의 old_method는 테스트 코드에서 new_method로 동작합니다.

coroutine test code 101

pytest에서 coroutine 코드를 테스트하는 방법을 간단히 설명하겠습니다. pytest에서 coroutine 코드를 테스트할 때pytest-asyncio 플러그인을 사용합니다.

pytest-asyncio 사용법

오늘의 헤드라인에서 사용하는 주요 서비스와 라이브러리

오늘의 헤드라인팀에서 다루는 mock을 설명하기 위해 주요 서비스와 라이브러리를 간단하게 소개하겠습니다.

Dynamo DB: AWS의 빠르고 유연한 NoSQL 데이터베이스 서비스입니다.

Elasticache: AWS의 인 메모리 데이터 저장소 및 캐시 서비스입니다. Redis와 Memcached를 지원합니다. 오늘의 헤드라인팀은 그 중 Redis 자원을 사용합니다.

Kafka: 분산처리에 효과적으로 설계된 메시지 브로커입니다.

dynamodb, redis, kafka를 mock 사용법과 mocking하는 과정에서 겪었던 삽질들에 대한 이야기를 시작하겠습니다.

(note)이번 예제에서 사용할 Python 라이브러리와 프레임워크를 정리했습니다.

# for test
pytest(6.1.2) # python의 단위테스트 프레임워크입니다.
moto[dynamo](1.3.16) # 대괄호 안에 있는 AWS자원을 mock하는 용도로 사용합니다.
pytest-mock(3.3.1) # test에서 사용하는 자원을 mock처리 할 때 사용합니다. 
pytest-asyncio(0.14.0) # coroutine 테스트 코드를 실행하는 용도로 사용합니다.
fakeredis(1.4.4) # redis 자원을 mock하는 용도로 사용합니다.

# for production
aioboto3(8.0.5) # AWS의 sdk인 boto3에 coroutine을 적용한 라이브러리입니다.
aioredis(1.3.1) # redis client의 coroutine을 적용한 redis client입니다.
confluent-kafka(1.5.0) # python kafka client입니다.

Dynamodb mock

오늘의 헤드라인 팀에서는 AWS자원(aioboto3)에 mock을 지원하는 moto 라이브러리를 사용하여 dynamodb를 mocking합니다.

aioboto3란?

AWS의 sdk인 boto3에 coroutine을 적용한 라이브러리입니다.

Dynamodb test 예제

dynamodb table( id, title, author, published_at)이 있고, 간단한 서비스 (book_id로 정보를 가져오는 시스템)를 테스트 하겠습니다.

다음은 테이블의 id를 이용해 query를 보내는 소스 코드를 작성했습니다.

테스트를 위해 moto를 사용해서 production 테이블을 mocking 합니다.

이 코드가 잘 동작하는지 확인하는 테스트 코드를 작성하겠습니다.

* fixture 데이터는 분리해서 관리하는 게 좋지만, 설명을 위해 테스트 코드 안에 작성했습니다.

삽질 1: aioboto3 mocking하기

오늘의 헤드라인 서버에서 dynamodb에서 데이터를 빠르게 가져오기 위해 bulk query 사용합니다. 실제 코드에서는 정상 동작하지만, moto에서 bulk query를 사용할 때 aiobotocore에 이슈가 있습니다.

aiobotocore란?

aioboto3보다 low level의 영역을 다루는 coroutine AWS SDK입니다.

moto에서 mocking된 dynamodb에 bulk query 응답을 받는 과정에서 botocore에 정의된 대로 AWSResponse.raw_header에 접근을 합니다. 하지만, aiobotocore가 botocore와는 다르게 AWSResponse.raw_header가 존재하지 않아 발생한 이슈입니다.

* 이 이슈는 aiobotocore 1.0.4 버전 기준으로 에러가 발생합니다. 자세한 내용은 aiobotocore 라이브러리 이슈 링크에서 확인 할 수 있습니다.

해당 이슈를 우회하기 위해 다음과 같은 코드를 작성했습니다.

이슈가 존재하는 메서드를 patch합니다.

위 방법으로 라이브러리 이슈를 해결할 수 있습니다.

Redis mock

오늘의 헤드라인은 Elasticache의 Redis를 사용합니다. redis client로는 aioredis를 사용했습니다. aioredis는 python redis client의 coroutine redis client 입니다. moto는 Elasticache를 지원하지 않습니다. Redis 자원의 mocking을 지원하는 fakeredis라는 라이브러리를 이용했습니다.

삽질 2: aioredis mocking하기

aioredis를 mocking하기 위해서는 아래와 같은 작업을 거쳐야 합니다.

fakeredis 1.4.4버전 기준으로 파라미터 없이 pool을 생성하지만, aioredis는 address라는 파라미터가 필요합니다. 그래서 moto의 이슈처럼 aioredis의 pool을 mocking하기위한 메서드를 작성했습니다.

이제 conftest.py에서 aioredis 메서드 create_redis_pool을 custom_create_redis_pool로 patch합니다.

Kafka mock

삽질 3: kafka mocking하기

kafka는 인기있는 message broker지만, python에서 mocking을 할 수 있는 좋은 use case를 찾지 못했습니다. 그래서 Kafka의 message broker기능을 간단히 mocking하는 방법으로 문제를 해결하고자 했습니다.

* message broker에는 메세지를 생성하는 Producer와 생성된 메시지를 소비하는 Consumer가 있습니다.

kafka에 메시지를 전송하기 위한 기존 코드는 다음과 같습니다.

KafkaProducer를 간단히 흉내 내기 위한 Mock Class(KafkaProducerMock)를 작성하겠습니다.

KafkaProducerMock은 다음과 같이 설계됐습니다.

• _producer: 메시지의 데이터가 정상적으로 전송됐는지 확인하기 위해 kafka에 전송된 데이터를 저장하기 위해 queue(list)로 구현했습니다.
• produce(self, data): KafkaProducer는 데이터를 전송하는 메서드지만, Mock은 _producer에 데이터를 추가하는 메서드입니다.
• close(self): KafkaProducer의 연결을 종료하는 메서드지만, Mock에서 데이터를 초기화하는 메서드입니다.

KafkaProducer를 KafkaProcuerMock으로 patch 합니다.

Kafka client가 제대로 작동하는지 확인하기 위한 테스트 코드를 작성했습니다.

위에서 정의한 queue를 통해 어떤 데이터가 들어갔는지 테스트할 수 있습니다.

테스트 실행 속도가 느릴 때 꿀팁

테스트 코드의 수가 늘어날수록 테스트 소요 시간이 길어집니다.

프로젝트의 테스트 코드를 순차적으로 실행할 때,평균 1분 12초 정도가 걸렸습니다. 테스트 코드를 매번 실행할 때마다 걸리는 시간은 생산성을 낮춘다고 판단했습니다. 그래서 이문제를 해결하기 위해 코드들을 병렬로 실행하는 전략을 시도했습니다.

테스트 코드를 병렬로 실행하는 방법에 대해 리서치를 했습니다.

그 중 pytest-xdist, pytest-parallel의 선택지가 있었습니다.

pytest-xdist: 대형 오픈소스에서 많이 채용되는 pytest 병렬처리 플러그인입니다.

pytest-parallel: pytest-xdist가 Thread safe하지 않았음을 지적했지만, coroutine에 코드를 실행할 때 이슈가 있었고, stable 버전이 제공되지 않아 선택에서 제외했습니다.

pytest-xdist를 사용하여 아래의 실행 환경 기준으로 1분 12초의 테스트 코트 실행 시간이 12초로 단축됐습니다.

결론

• 외부 서비스와 결합하는 부분에서 mocking을 사용해야 했고 쉽지는 않았지만 오늘의 헤드라인 서버팀은 해결할 수 있습니다.
• 테스트 코드를 github action에 연동하여 CI/CD 작업까지 끝내니 API의 안정성을 얻을 수 있었다.

궁금한 내용을 댓글에 올려주시면 친절하게 답변하겠습니다.

긴 글 읽어주셔서 감사합니다.

오늘의 헤드라인 팀에서 함께할 ML 엔지니어를 찾습니다!

• 오늘의 헤드라인은 머신러닝 및 딥러닝 기술이 핵심인 뉴스 추천 서비스입니다.
• 오늘의 헤드라인 ML/추천 팀은 머신러닝 및 데이터 기술을 적극적으로 활용하여 서비스에 적용하고 있습니다.

함께 대한민국 국민들의 뉴스 소비 습관을 혁신하고 싶은 분 연락주세요.

오늘의 헤드라인 ML 엔지니어 채용 공고

Reference

• Mockito를 사용하여 의존성들에 대해 mock 객체 생성하기
• 깊이 있는 Singleton

[오늘의 헤드라인] 테스트 코드 작성기(2) — Mock was originally published in 빅펄 (헤드라잇) on Medium, where people are continuing the conversation by highlighting and responding to this story.

안녕하세요. 오늘의 헤드라인 서버팀의 소프트웨어 엔지니어 Jun입니다. 오늘의 헤드라인에서 ‘python 기반 테스트 코드를 작성한 과정과 고민’을 2편으로 나누어 공유하고자 합니다.

(1) 단위 테스트 프레임워크

(2) Mock

이번 글에서는 (1) 단위 테스트 프레임워크를 알아보겠습니다.

테스트 코드를 작성하는 이유

1. 코드의 안정성을 높일 수 있다.

제품이 시장에 나오기 전, 안정성 검증으로 퀄리티를 보장하는 것 까지가 엔지니어의 필수적인 업무입니다. 테스트 코드를 통한 CI를 진행하면서 안정성을 높이고, 프로젝트 품질을 보증할 수 있습니다.

2. 커뮤니케이션 비용을 줄일 수 있다.

훌륭한 테스트 코드는 ‘코드 사용 설명서’ 역할을 하기도 합니다. 시간이 지나며 프로젝트가 커지더라도, 테스트 코드가 있다면 어떤 의도로 코드가 작성됐는지 알 수 있습니다

3. 프로젝트 코드 품질을 유지하며 운영할 수 있다.

테스트 코드를 추가했을 때, 코드에 변경사항이 있더라도 기존에 있었던 기능들이 잘 작동하는 것을 쉽게 확인할 수 있습니다. 테스트 코드는 실제 코드의 품질을 떨어트리지 않으면서 테스트를 쉽게 할 수 있습니다.

4. 생각의 흐름을 정리하며 개발하기 좋다.

테스트 코드를 작성하며, 개발 당시 복잡했던 생각의 흐름이 정리된다는 느낌을 받았습니다. 테스트 코드를 작성하는 과정이 ‘생각을 단위로 정리’하면서 ‘글을 읽는 느낌을 주는 코드’를 짜는데 도움이 되었기 때문입니다. 이제 제게 테스트 코드는 선택이 아닌 필수가 되었습니다.

Python의 단위 테스트 프레임워크

오늘의 헤드라인의 서버팀은 프로젝트에 가장 적합한 자원을 사용하기 위해 분석하고 고민합니다. 단위테스트 프레임워크를 선택할 때,어떤 기준으로 생각했는지 정리하여 이야기 해보겠습니다.

python의 대표적인 단위 테스트 프레임워크로는 unittest와 pytest를 살펴보았습니다. 그 외에 doctest와 nose가 있지만 아래의 이유로 선택 기준에서 제외했습니다.

doctest : 주석을 이용한 구조로 테스트 코드를 작성하는데, 다양한 케이스의 테스트 코드(실패하는 테스트 코드 등)를 주석에서 관리하는 것이 의문이라는 이야기가 많아 제외했습니다.

nose: 메인테이너의 부재로 다른 테스트 프레임워크를 사용할 것을 권장하고 있어 제외했습니다.

unittest

unittest는 Java의 단위 테스트 프레임워크인 JUnit으로부터 영감을 받아 만들어진 프레임워크 입니다. 장점으로는 Python 2.7 버전 이상부터 기본적으로 내장되어 추가 설치가 필요하지 않습니다. Junit의 영향을 많이 받아 자바를 사용해 본 분들에게 친숙할수 있습니다. 개인적인 견해지만 unittest에 아쉬움이 있습니다.

Class의 의무적인 사용

매번 정의해야하는 fixture

fixture에 관하여 간단하게 설명하겠습니다.

fixture란?

직역하면 “고정 장치”라는 뜻입니다.

테스트 코드가 실행되기 전 test의 필요한 데이터나 리소스를 load 하여 사용 가능한 형태라고 설명할 수 있습니다.

unittest는 fixture를 사용하기 위해 Class 안에 setUp과 teatDown이라는 메서드를 작성해야합니다.

setUp: 테스트 코드가 동작하기 전, fixture를 불러오는 역할을 합니다.

tearDown: 테스트 코드 동작 후, 자원을 해제하는 역할을 합니다.

매번 setUp/tearDown 메서드를 정의해야하는 부분이 불편하다고 생각합니다.

Camel case 사용

Python의 Convention에서 메서드는 snake case를 사용합니다.

그러나 unitest는 Python의 Convension보다 먼저 만들어졌고, Java의 Junit을 기반으로 만들어졌기 Java의 컨벤션을 따른 것으로 보입니다.

pytest

pytest는 간단하고 확장 가능한 테스트를 쉽게 구축할 수 있는 프레임워크입니다.

강력하고 쉬운 fixture는 pytest의 큰 장점이라고 생각합니다.

scope와 autouse는 fixture에서 자주 사용하는 옵션입니다.

scope 옵션은 fixture의 life cycle을 의미합니다. “function”이 default 값이며 그 외에 “class”, “module”, (“package” or “session”) 등이있습니다.

autouse 옵션은 테스트 코드에서 명시적으로 call 하지 않아도 사용할 수 있는 옵션입니다. db 또는 redis등의 전역 코드에 해당하는 fixture를 사용할 때 편하게 사용할 수 있습니다. default 값은 False입니다.

위에 테스트 코드가 여러 개라도, 함수의 파라미터를 지정하듯 간편하게 호출해서 사용할 수 있습니다.

강력한 플러그인 다수 존재

315개 이상의 pytest 플러그인이 있습니다. 테스트를 위한 코드를 작성하기 전에 플러그인을 먼저 확인해보세요 :)

경험으로는 테스트 코드가 많아질수록 실행 속도가 오래 걸려 병렬처리 작업이 필요했는데 pytest-xdist 설치와 옵션 하나로 쉽게 병렬 처리를 할 수 있었습니다.

유연한 코드 작성 가능

pytest는 Class 사용 없이 function만으로 테스트 코드를 작성할 수 있습니다. Class 형식도 지원하면서, unittest도 함께 사용이 가능합니다.

대형 오픈소스에서 사용

SQLAlchemy, Flask 등의 대형 오픈소스에서도 pytest는 사용됩니다. 대형 오픈소스를 사용하는 수 많은 사람들에게 안정성과 품질을 인정받고 사랑받는다는 의미이기도 합니다.

1. 오늘의 헤드라인의 Python 코드는 Pythonic 함을 지향합니다.
2. 유연하고, 느슨한 결합의 구조를 지향합니다.
3. 모호함보단 명시적인 코드를 지향합니다.
4. 지속 가능한 빠른 개발 cycle을 만들기 위해 복잡도를 낮추는 방법을 항상 고민합니다.

서버 팀의 지향점을 생각해 볼 때, unittest보단 pytest가 더 적합하다고 판단했습니다.

테스트 코드 작성 팁

1. 소스 코드와 테스트 코드의 구조는 단순하고 간단하게 구성합니다.

소스 코드와 테스트 코드의 구조가 복잡하면 이해하기 위해 코드에 대한 추측을 하게 됩니다. 이 내용은 클린코드와 이여지니 잠시 책의 내용을 인용하겠습니다.

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.

지속 가능한 개발을 위해 코드는 명확하고 이해하기 쉽게 작성해야 합니다. 추측을 만들지 않는 명확한 코드를 작성해야 합니다.

자세한 내용은 위 책을 읽는 것을 추천합니다.

2. conftest.py를 사용한다.

테스트 코드를 실행하기전 conftest.py가 우선 실행됩니다. conftest안에 테스트에 필요한 세팅을 합니다. 보통 fixture 데이터를 설정하는 작업을 합니다.

3. 자주 사용하는 pytest의 플러그인

pytest-env # 테스트 환경 변수 설정에 사용하는 플러그인입니다.

pytest-mock # mocking 작업을 할 때 사용하는 플러그인입니다.

pytest-asyncio # coroutine 함수를 테스트 할 때 사용하는 플러그인입니다.

pytest_freezegun # 특정 시간으로 시간을 멈출 수 있습니다. 
                 # fixture의 time 객체를 테스트 할 때 사용하는 플러그인입니다.

pytest-xdist # 테스트 코드를 병렬로 실행할 때 사용하는 플러그인입니다.

다음 포스팅은 오늘의 헤드라인의 Mock에 관한 이야기를 다루려고 합니다.

긴 글 읽어주셔서 감사합니다.

모두 코로나 조심하시고, 새해 복 많이 받으세요 :)

오늘의 헤드라인 팀에서 함께할 ML엔지니어를 찾습니다!

• 오늘의 헤드라인은 머신러닝 및 딥러닝 기술이 핵심인 뉴스 추천 서비스입니다.
• 오늘의 헤드라인 ML/추천 팀은 머신러닝 및 데이터 기술을 적극적으로 활용하여 서비스에 적용하고 있습니다.

함께 대한민국 국민들의 뉴스 소비 습관을 혁신하고 싶은 분 연락주세요.

오늘의 헤드라인 ML 엔지니어 채용 공고

Reference

• pytest로 파이썬 코드 테스트하기
• unittest vs pytest
• 설마 아직도 테스트 코드를 작성 안 하시나요?

mock을 활용한 테스트 코드 작성기(1) — 단위 테스트 프레임워크 was originally published in 빅펄 (헤드라잇) on Medium, where people are continuing the conversation by highlighting and responding to this story.

작년 회고 링크: 2019년 빵빵한 빵년차 백엔드 회고

재작년부터 회고를 일 년 주기로 작성하고 있다. 너무 타임라인 순으로 한 행위에 강조하기 바빴다.

이번 회고에서는 내가 느꼈던 것과 반성하고 발전 할 수 있는 부분에 초점을 맞추고 싶다.

고려대학교 백엔드 멘토 참가

선욱이의 콜로 고려대 해커톤의 백엔드 멘토로 참여하게 되었다. 주변의 빵빵한 멘토들의 멘터링과 멘티분들의 열정을 보면서 배우며 자극받았던 해커톤이다. 그중에서 가장 기억이 남는 팀은 구독 에그리게이트 서비스를 개발하는 “구구독”이라는 팀이다.

Django를 이용해 개발하는 유일한 팀이었고, 해커톤 이전부터 개발해 어느 정도 고도화 돼 있는팀이었다. 내 부스에서 아예 자리를 잡고 같이 피자를 먹으며 이런저런 얘기를 나누었는데, 완성도가 높아 모두가 창업에 집중하는 학생분들인 줄 알았는데, 팀원 중 한 분은 이미 취업을 하고, 출/퇴근을 하면서 개발을 하고 있었다.

그 모습을 보면서 내 창업에 대한 욕구가 조금 두근거렸다.

프로그라피

발표 자료: JWT 이해하기

프로그라피에 들어온 지 벌써 2년이 다 되어간다. 처음 프로그라피에 들어와서 좋은 멘토들을 만나 많이 성장했고, 멘토 제안이 왔을 때도 “내가 이전 멘토들 처럼 할 수 있을까?”라는 고민이 있었고, 주변에서 응원에 힘입어 “할 수 있다!”라는 마음으로 임했다.

멘토링을 하면서 멘티분들의 실수는 오히려 나의 성장을 만들어 주었다. 내가 만나지 못한 에러와 상황들을 가지고 오면 같이 고민하고 해결하는 과정이 좋았다.

코로나 이후로는 기술적인 이야기에 초점이 맞춰지고 원격으로 멘토링을 하다 보니 공수가 2배 이상 들어 사실 많이 지쳤다.

프로그라피는 내 개발자 인생에 많은 행복과 성장을 만들어 준 곳이다. 지명하여 말하진 않겠지만, 그 친구들에게 정말 감사하다는 마음을 여기에 표현하고 싶다.

Django 라이트닝 토크

발표 자료 : 아직도 보고서를 직접 보내시나요?

코로나가 완전히 심해지기 전 발표 할 수 있는 기회를 얻었다. 비단뱀(파이썬 백엔드 개발자 모임)에서 장고 라이트닝 토크를 주최했다.

광고 후, 보고서가 고객에게 나가는 과정을 자동화한 내용으로 발표를 했다.

네트워크 시간에 idus의 시니어 백엔드 개발자분을 만나 이야기했는데, idus의 분업화에 대한 이야기가 너무 흥미로웠다. idus의 백엔드 개발자는 비즈니스 로직과 테스트 코드의 집중을 하고, 배포의 과정은 DevOps팀에 의해 자동화되어 실제로 어떤 인프라 구조가 어떻게 구성되어있는지 모를 정도의 수준으로 개발이 진행된다고 했다.

보통의 스타트업의 백엔드 개발자는 인프라 자원을 효율적으로 다루는 것에 고민하고 오히려 테스트 코드와 거리를 두는 경향을 보곤 했다.

오히려, 큰 회사일수록 테스트 코드를 잘 짜고 비즈니스 로직에 집중하는 개발자를 찾는다는 이야기를 듣고, 나의 앞으로의 커리어를 어떻게 준비해야 할지 계속 공부를 하지만 항상 시작인 느낌이 들었다.

AngelHack Seoul 2020 Online

일주일 동안 코멘토의 팀원분들과 해커톤을 진행했다.

디자이너 1명, 프런트 개발자 3명, 백엔드 개발자 1명으로 팀이 구성됐다. 여러 곳에서 팀을 이뤄 개발을 해봤지만, 가장 프런트 비율이 높았던 팀이다. 프런트 개발 속도가 빨라 백엔드가 손이 부족했다는 느낌이 들 정도다. 코멘토 팀원들은 개발도 빠르게 하지만, 인성이 매우 훌륭한 분들이 많다.

아쉬웠던 점은 해커톤이라는 생각에 커밋 메시지와 문서화, 클린 코드에 대해 무시하고 빠르게 진행하는 데 집중했는데, 배포 이후 롤백이 필요한 부분이나, API에대한 설명을 전달하기에 많이 부족한 점이 있었다. 지금은 클린 코드를 읽은 상태이기 때문에 더욱 침착하고 기본에 집중해서 개발 할 수 있다는 자신이 있다.

사내 파이썬 스터디

회사에 새로운 디자이너분(절친, Jenny)이 오셨다.

Jenny(자체 발광)가 오고 회사의 분위기가 많이 밝아졌다. 나 또한 Jenny 덕에 회사가 재밌어졌다. 차분하지만 에너지가 넘치는 분인데, 프로그래밍에도 관심이 있으셨다. 나 또한 하고자 하는 사람이 있다면 손을 먼저 뻗는 타입이기에 파이썬 스터디를 시작했다. 일주일에 한 번 챕터를 같이 보고, 그 챕터와 관련된 숙제를 냈다. 커밋이 올라온 시간 간격을 보니 정말 열심히 하셨다.

그렇게 한 달이 지나고,

Jenny가 블로그 글( 실제 데이터로 시안 만들기 )을 공유하면서 피드백을 요청했다. 스터디에서 배운 내용을 활용해 디자인 시안을 만드셨다. 나는 매우 뿌듯한 마음에 Python korea에 올렸는데, 반응이 너무 뜨거웠다. 글은 디자이너인 Jenny가 쓰셨는데, 좋아요는 내가 다 받았다.

인싸의 삶을 잠깐이지만, 상상해 볼 수 있었다.

서비스 배포: 오늘의 헤드라인

회사의 새 서비스 “오늘의 헤드라인"이 App store와 Google play에 올라왔다.성공하는 서비스를 만들고 싶다는 마음으로 초기 개발 셋업에 어떤 자원을 사용할지에 대한 고민을 많이 했다.

MSA 도입

• 이전 서비스 운영 경험

1. 기획에 따라 무궁무진하게 늘어 날 수 있는 도메인들: 예전에는 Django 하나로 2개의 서비스를 운영했는데, 서비스 하나를 고쳤는데 2개의 서비스를 다시 배포하는 문제가 있었다.
   오늘의 헤드라인은 빠르게 변할 수 있고, 기획에 따라 도메인이 무궁무진하게 늘어날 수 있는 서비스다.
2. 이전 서비스의 서치의 검색 엔진: Django서버의 복잡도가 올라가, 검색 엔진만을 위한 Typescript와 Serverless조합으로 백엔드 API를 추가했었다.
   복잡한 로직이 많기에, 도메인 별로 영향을 주지 않게 분리하는 것도 중요했다. 오늘의 헤드라인 역시 추천이 핵심이기 때문에 추천 로직을 따로 분리하여 관리하는 것이 이득이 많았다.
3. 엔지니어 채용 계획: 데이터 & 추천 엔지니어분들과 같은 로직을 건드리면서 충돌 나는 것보단 도메인 별로 분리해 전담하는 것이 유지보수 측면에서 유연했다.

Fast API 도입

• 추천 로직이 붙기에 속도는 중요했고, 추천 & 데이터 엔지니어 분들과의 시너지를 위해 Fastapi를 사용했다.

1. 이전 검색엔진은 프레임워크를 사용하지 않았는데, 기능이 더해질수록 lambda function의 수가 많아져 관리하기 힘들었다.
2. 1번의 이유로 새 서비스를 사용하는데, express를 이용해 개발했는데, Coroutine에 대한 예외처리를 매번 넣어주는 것이 좋은 구조가 아니라고 생각했는데, Koa는 Coroutine에 대한 예외처리가 되어있어 Koa를 이용해 개발 했다.
3. 파이썬 백엔드 커뮤니티에서 우리 회사가 python backend를 이용하는 회사 리스트에 올라왔고, PO분이 회사가 언급 사실에 기뻐하는 모습을 보았다.
4. 그 모습 + 추천 & 데이터 엔지니어분들이 python을 많이 사용한다는 사실에 엔지니어들과의 커뮤니케이션 비용을 줄이기 위해 Koa로 짠 코드를 flask로 짤 생각을 했는데.
5. flask는 느리다. 추천 로직은 많은 계산이 들어갈 것이고, 초기 단계부터 속도를 어느 정도 잡아줘야 한다고 생각했다.
   ASGI기반의 서버를 생각했고, sanic에 대한 레퍼런스가 그나마 많아 선택했다.
6. 오픈소스 컨트리뷰톤에서 만난 딜리버리 히어로의 개발자분과 이야기를 하다 sanic의 메인테이너가 나갔다는 소식을 듣고, Fastapi가 괜찮다는 말을 듣고, 찾아보았는데 문서화가 잘 돼 있고, pydantic이 디폴트로 있어 validation과 타입 힌트로 더욱우아한 코드로 짤 수 있었다. sanic으로 짠 코드를 다시 fastapi로 포팅했다.

데이터 샘플링

데이터 파이프라인이 가져오는 데이터가 많아 API에서 사용할 샘플링이 필요했는데, Redis를 이용해 최신 시간을 기준으로 관리하는 로직을 설계했다. 지금은 로깅과, 추천 로직 등에 더 다양한 방법으로 활용되고 있다.

데이터 엔지니어분이 들어오고 나서 고도화가 매우 빠르게 진행됐다.

• 로그 시스템 분리
• 모든 코드 리팩토링(클린 코드&테스트 코드 도입)
• CI/CD 도입
• IAC(terraform) 도입
• 장애 노트 작성
• 쿠버네티스 도입
• Big query 도입

정도의 변화가 있었다.

서버를 혼자 담당하다 보니 핑계 겸 겁이 나 시도를 못 한 것들이 많았는데,

능력자가 오시니 가슴이 웅장해져 여러 시도에 대해 긍정적으로 바뀌었다.

오픈소스 컨트리뷰톤

훌륭한 멘토님과 열정 넘치는 멘티분들과 함께했다는 사실이 좋았다.

멘토님의 pytest로 파이썬 코드 테스트하기

세션을 듣고 내가 이전에 짠 테스트 코드는 큰 의미가 없는 코드란 것을 알았다. 그리고 오픈소스에 첫 PR을 날려보았다. (close 됐지만…)

SQLAlchemy는 정말 잘 만든 DB 툴킷이다.

멘토님께서 SQLAlchemy Korea를 운영해보는 것에 대해 권해주셨다. 새해에는 SQLAlchemy Korea를 활성화 해보려고 한다.

최영선 멘토님 감사합니다

기타

마이크로소프트웨어 400호 표지 이벤트 당첨

Pinterest Clone

기획이 러프하게 나와 중단됐지만 Flutter로 다시 만들어 볼 것이다!

회사 이전 from 삼성동 to 삼성동

회사의 사람들이 늘어 8인실에서 15인실로 이동했다.

사내 스터디

회사에 새로운 데이터 엔지니어분이 오셨다. 내 완만해지는 성장 곡선을 다시 가파르게 만들어준 분이다.

클린 코드는 왜 이제 읽었을까 생각이 든다. 이전에 클린 코드 관련 블로그 글을 읽고, “아, 그렇구나" 이러고 넘어갔다. 이 책은 스타트업 개발자들이 더 읽어야 할 책이다. 책 한줄 한줄을 읽을 때마다, 내가 만들었던 “깨진 유리창”들이 나한테 박힌 느낌을 받았다.

이 책은 왜 클린 코드를 짜야 하는지, 클린 코드가 선택이 아닌 필수라는 것을 사례를 들어 이야기한다. 위에서 idus 개발자 분이 테스트 코드와 비즈니스 로직을 잘 짜는 분들을 찾는지 마음에 확 와닿았다.

이 책은 파이썬을 이용해 클린 코드 방법론을 정리한 느낌이 든다. 클린 코드를 읽고, 그다음 보면 좋은 책이라 생각한다.

이 책은 지금도 스터디를 진행하고 있다.

구글이 얼마나 대단한 회사인지 체감하게 해주는 책이다. “회사에 어떻게 도입할 수 있을까?”에 대한 내용으로 스터디를 진행하는데, 클린 코드와 테스트 코드는 규모와 상관없이 필수라는 생각이 들지만, 이 책은 규모에 따라 점진적으로 하나하나 적용해야 하는 부분이 많았다.

구글의 인프라 환경과 운영사례, 모니터링, 데이터 파이프라인, 부하 테스트 등에 관심이 있는 분들께 추천하는 책이다.

작년 목표 달성

1. 운동하기

• 9월에 보름 정도 입원했었다.
• 아직도 회복기다. 지금도 주기적으로 병원에 다닌다.

• 병실 침대에 누워 있을 때, 건강하게 살아야겠다고 생각했다.
• 퇴원하고 검도를 시작했다! 정말 재밌게 하고 있었는데… 코로나가… 빨리 상황이 좋아지면 하고 싶은 것이 검도다.
• 머리이이이이!

2.커뮤니케이션 스킬 업하기

• 결론부터 말하기, 생각을 정리하고 말하기 등 일상생활에서 노력하려고 노력했다.
• 신중하게 말하려고 노력하다 보니 말 수가 많이 줄었다…
• 단순히 일상생활에서의 노력만 하기보단, 이번 해는 커뮤니케이션 관련 수업을 들어볼 것이다.

3.좋은 책 읽기

• 연초에는 활동한다는 것이 많다는 핑계로 좋은 블로그 글이라도 출퇴근길에 많이 읽으려고 노력했다.
• 그 글들을 여기에 읽고 모은다.
• 책은 요즘 들어 몰아 읽고 있다.

내년 목표

1. SQLAlchemy Korea 활동하기(많은 관심 부탁드립니다!)

• 1월 중순에 진행할 SQLAlchemy 스터디를 만들었다.
• 스터디 멤버들과 공부 후, SQLAlchemy 튜토리얼 세션을 온라인으로 진행하고 싶다.
• 그 외에 오픈소스 활동과 번역 등의 활동도 생각하고 있다.
  (아직은 생각만)

2. 쿠버네티스와 데이터 파이프라인 정복하기

• 회사에서 사용한다고 해서 내 온전한 스킬은 아니라고 생각한다.
• 자유롭게 다루는 정도가 목표다.

3. 서비스를 사랑하기

• 기술적인 공부에 집중을 하다 보니, 서비스 개발자인데 서비스에 관심이 없는 나를 발견 할 수 있었다.
• 막연한 목표로 잡긴 싫다. 그래서 이 방법을 수치화할 수 있는 것들에 대해 고민하고 있다.
• 개발하면서도 그 방법이 무엇일까 계속 머릿속을 헤집는다.
• 방법이 있다면 이야기해주세요! (제발)

4. 안 할 것에 대해 고민하기

• Go 스터디(코로나 때문에 중단)와 로토 님께서 진행하는 바닐라 자바스크립트 스터디를 끝까지 제대로 완주하지 못했다.
• 내가 하는 것들이 많아 지쳤고, 나의 몸은 하나라는 것을 깨달았다.
• 입원하기 한 달 전에는 잠을 많이 줄이면서까지 진행했는데, 벌린 일들이 많아 따라가기 급급하다 뻗어버린 것이 아닐까? 라는 생각이 들었다.
• 할 수 있는 일들은 너무 많은데, 다 할 수 없으니 과감히 안 하는 것도 중요한 것을 느꼈다.
• 일의 우선순위를 두고, 너무 무리가 되는 것은 제쳐두고 “진행 중인 일을 더 잘해야지”라는 생각이 들었다.

하고 싶은 이야기

2020년 너무 빠르게 지나갔다.

흘러가는 시간을 담는 것이 회고라고 생각을 한다. 회고의 내용은 더 나은 내가 되기 위한 내용이 중요하다고 생각한다. 단순한 새해 목표가 아닌 성장하기 위한 나의 반성을 반영하는 새해가 됐으면 좋겠다.

이번 해의 가장 많이 이야기한 주제는 “코로나”였다. 경직되있는 분위기를 느낄 수 있고, 빨리 없어지면 좋겠다는 마음에 거리 두기를 열심히 하고 있다.

회고가 끝난 후에는 감사한 사람들에게 소식을 전하려고 한다.

새해는 모두 아프지 말고, 복 많이 받기를!

실제 보고서 작성 업무에 참여하여 프로세스를 정리했습니다.

기존 보고서 만드는 프로세스는 다음과 같습니다.

보고서를 자동화 할 수 있는 가설을 세웠습니다.

#1 보고서 로직화

이 중에서 자동화가 가능한 부분을 추출했습니다.

자동화 작업이 없다면

유튜브 채널에 방문하여 채널 정보를 확인하고, 각 영상에 대한 정보(조회수, 댓글 수, 좋아요 수 등)을 하나 하나 트래킹하는 작업이 필요합니다.

또, 수집한 데이터를 바탕으로 통계적인 계산을 통해 예측 보고서를 만들어야 합니다.

자동화를 하지 않았다면, 광고 효과 트래킹 또한 매일 해당 영상을 방문하여 트래킹하는 방법을 사용해야 합니다.

자동화를 통해 주말에도 보고서를 작성하여 전달할 수 있었고

우리 팀은 유저를 위한 서비스에 좀 더 집중 할 수 있었습니다.

#2 스케줄러 추가

동적인 스케줄링이 필요하다면 django-celery-beat

동적인 스케줄링이 필요없고, celery를 사용하면 celery beat

동적인 스케줄링이 필요없고, celery를 사용하지 않는다면 django crontab을 사용하는 것이 좋을 것 같습니다.

동적 할당이 주요 작업이었기 때문에 Django-celery-beat를 선택했습니다.

#3 스케줄러를 이용한 자동화

아직도 보고서를 직접 보내시나요? 📝django-celery-beat를 활용한 자동화 was originally published in 빅펄 (헤드라잇) on Medium, where people are continuing the conversation by highlighting and responding to this story.

스마트폰과 IOT의 등장으로 (IPV6 도입의 이유와 비슷하달까?…)

누구나 장소와 시간에 구애받지않고 인터넷을 사용할 수 있습니다.

오늘의 인터넷 사용량

인터넷 사용자가 많아지면서 자연스레 인터넷의 트래픽 또한 비례해서 증가하게 되었습니다.

또한, 과거에 텍스트 위주의 컨텐츠가 주류 였다면 지금은 유튜브나 인스타그램에서 쉽게 접할 수 있는 이미지나 비디오 같은 컨텐츠가 주를 이루게 된 것도 한 몫을 한다고 생각합니다.

과거와 달리 여러가지의 팩터들에 인해 생겨난 트래픽을 감당하기위해 엔지니어들은 어떤 노력을 했을까요?

그 결과물 중 하나가 JWT라고 생각합니다.

JWT?

• 세션 : 간단히 말하자면, 유저의 특정한 연결을 유지하는 상태라고 생각하면 좋을 것 같습니다.
• 쿠키 : 간단히 말하자면, 브라우저의 정보를 포함한 스니펫 정도라고 생각하면 좋을 것 같습니다.

세션 기반 인증

토큰 기반 인증

JWT와 세션 비교

JWT의 구조

Header

Payload

위에서 말하는 클레임이란?

Signature

JWT 실습

FAQ

1. JWT는 복호화가 가능하기 때문입니다.
2. JWT의 많은 내용이 들어가는 만큼 토큰 또한 무거워집니다.
3. 토큰을 가지고 있으면 토큰을 통해 인가가 가능하므로 만료시간을 짧게 잡아 해커들의 위협으로부터 최소한의 방어를 할 수 있습니다.
4. 로컬 스토리지나 상태 관리 라이브러리(redux, mobx 등)는 웹 브라우저일 경우 조작이 가능합니다. 하지만 쿠키에 http only옵션을 준다면 웹브라우저 내에서 데이터를 조작할 수 없습니다.

JWT 이해하기 was originally published in 빅펄 (헤드라잇) on Medium, where people are continuing the conversation by highlighting and responding to this story.

SQL, OS, XXE(Xml eXternal Entity), LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 발생한다. 공격자의 악의적인 데이터는 예상하지 못하는 명령을 실행하거나 적절한 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있다.

A2: Broken Authentication (취약한 인증)

인증과 세션 관리와 관련된 애플리케이션 기능은 정확하게 구현되어 있지 않아서, 공격자가 패스워드, 키 또는 세션 토큰을 해킹하거나 다른 구현 취약점을 공격하여 다른 사용자 계정을 일시적 또는 영구적으로 탈취하는 것을 허용한다.

A3: Sensitive Data Exposure (민감한 데이터 노출)

많은 웹 애플리케이션들이 신용카드, 개인 식별 정보 및 인증 정보와 같은 중요한 데이터를 제대로 보호하지 않는다. 공격자는 신용카드 사기, 신분 도용 또는 다른 범죄를 수행하는 등 약하게 보호된 데이터를 훔치거나 변경할 수 있다. 중요 데이터가 저장 또는 전송 중이거나 브라우저와 교환하는 경우 특별히 주의하여야 하며, 암호화와 같은 보호조치를 취해야 한다.

A4: XML External Entities (XXE) (XML 외부 개체 (XXE))

오래되고 설정이 엉망인 많은 XML 프로세서들은 XML 문서 내에서 외부 개체 참조를 평가한다. 외부 개체는 파일 URI 처리기, 내부 파일 공유, 내부 포트 스캔, 원격 코드 실행과 서비스 거부공격을 사용하여 내부 파일을 공개하는데 사용할 수 있다.

A5: Broken Access Control (취약한 접근 통제)

취약한 접근 제어는 인증된 사용자가 수행할 수 있는 것에 대한 제한이 제대로 적용되지 않는 것을 의미한다. 공격자는 이러한 취약점을 악용하여 사용자의 계정 액세스, 중요한 파일 보기, 사용자의 데이터 수정, 액세스 권한 변경 등과 같은 권한 없는 기능, 또는 데이터에 액세스할 수 있다.

A6: Security Misconfiguration (잘못된 보안 구성)

훌륭한 보안은 애플리케이션, 프레임워크, 애플리케이션 서버, 웹 서버, 데이터베이스 서버 및 플랫폼에 대해 보안 설정이 정의되고 적용되어 있다. 기본으로 제공되는 값은 종종 안전하지 않기 때문에 보안 설정은 정의, 구현 및 유지되어야 한다. 또한 소프트웨어는 최신의 상태로 유지해야 한다.

A7: Cross-Site Scripting (XSS) (크로스 사이트 스크립팅 (XSS))

XSS 취약점은 애플리케이션이 신뢰할 수 없는 데이터를 가져와 적절한 검증이나 제한 없이 웹 브라우저로 보낼 때 발생한다. XSS는 공격자가 피해자의 브라우저에 스크립트를 실행하여 사용자 세션 탈취, 웹 사이트 변조, 악의적인 사이트로 이동할 수 있다.

A8: Insecure Deserialization(안전하지 않은 역직렬화)

안전하지 않은 역직렬화는 종종 원격 코드 실행으로 이어집니다. 역직렬화 취약점이 원격 코드실행 결과를 가져오지 않더라도 이는 권한 상승 공격, 주입 공격과 재생 공격을 포함한 다양한 공격 수행에 사용될 수 있다.

A9: Using Components with Known Vulnerabilities (알려진 취약점이 있는 구성요소 사용)

컴포넌트, 라이브러리, 프레임워크 및 다른 소프트웨어 모듈은 대부분 항상 전체 권한으로 실행된다. 이러한 취약한 컴포넌트를 악용하여 공격하는 경우 심각한 데이터 손실이 발생하거나 서버가 장악된다. 알려진 취약점이 있는 컴포넌트를 사용하는 애플리케이션은 애플리케이션 방어 체계를 손상하거나, 공격 가능한 범위를 활성화하는 등의 영향을 미친다.

A10: Insufficient Logging & Monitoring(불충분한 로깅 및 모니터링)

불충분한 로깅과 모니터링은 사고 대응의 비효율적인 통합 또는 누락과 함께 공격자들이 시스템을 더 공격하고, 지속성을 유지하며, 더 많은 시스템을 중심으로 공격할 수 있도록 만들고, 데이터를 변조, 추출 또는 파괴할 수 있다. 대부분의 침해 사례에서 침해를 탐지하는 시간이 200일이 넘게 걸리는 것을 보여주고, 이는 일반적으로 내부 프로세스와 모니터링보다 외부기관이 탐지한다.

그중에서 저는 ‘나노 봇’과 관련된 직업군을 유망하다고 이야기하겠습니다.

‘특이점이 온다’라는 저서로 우리에게 널리 알려진 구글의 기술 고문 ‘레이 커즈와일(Ray Kurzweil)`은 인공지능과 ’특이점(Singularity) ‘분야에 전문적인 지식을 가진 미래학자입니다.

이 분의 이야기를 기반으로 미래의 직업 전망에 관해 이야기 하고자 합니다.

“2030년대엔 ‘나노봇’이 뇌에 이식된다.”

서두에서 언급한 나노 봇(10^-9 정도의 크기같이 아주 작은 로봇)은 인간의 뇌에 이식되고 이를 통해 인간의 뇌는 클라우드에 연결됩니다.

나노봇은 우리에게 가상현실(VR) 경험을 통해 완전한 몰입감을 제공합니다.

뇌의 `신피질(neocortex)`이 클라우드에 확장되면서 가상 공간에서 살 수 있게 되고, 인간의 생각이나 기억을 저장할 수 있습니다.

앞서 말한 환상 같은 미래는 현재 진행 중입니다. 2016년 몬트리올에콜폴리테크닉 연구진은 암세포 등 측정표적에 약물을 전달할 목적으로 혈류를 통과할 수 있는 나노봇을 만들었습니다.

나노봇이 표적에만 약물을 전달하면 다른 조직 및 기관이 약물로 인한 피해를 볼 위험이 줄어들고, 화학 요법 약물이 인체에 일으키는 다양한 부작용을 감소시킬 수 있다고 합니다.

현재는 중국과 캐나다 등에서 나노 로봇을 이용하여 실험을 하고 있고, 쥐를 이용한 실험을 성공적으로 마무리했다고 합니다.

이를 통해 알 수 있는 것은 나노봇은 미래에 존재하는 것이 아닌 현재에도 존재하고 있고, 개발 진행 중이며 미래에는 모두에게 보급될 수 있다는 것입니다.

기본적으로 나노 봇을 만드는 기계공학 및 의학 공학 계열, 인간의 생명을 위한 의료 계열, 인체의 온전한 상호작용과 가격 대 성능비를 낮추어 보급률을 높일 수 있는 신소재 및 화학 계열, 악의적인 접근으로 인한 피해를 막기 위한 보안계열이 있고, 위 분야의 주춧돌이 되는 컴퓨터 공학 계열이 있습니다.

앞서 말한 현재에도 주요 직업군이고, 미래에는 개척 직업군이라고 생각합니다. 앞서 말한 직업군을 개척 직업군이라고 명칭 하겠습니다.

당연한 이야기를 전개하는 것보단 미래학자의 주장을 정리하면서 파생되는 직업에 대하여 이야기해 보겠습니다.

1. 나노봇이 ‘근본적인 생명연장’을 가져온다.

“암을 포함하여 인간의 모든 질병을 치유할 수 있어 `근본적인 생명 연장(radical life extension)`이 가능해진다. 하지만 생명이 연장되면 인간들은 ‘거대한 권태’라는 문제에 봉착한다.”

2018년 12월 2일 구글에서 만든 인공지능 알파폴드는 43개의 단백질 중 25개의 구조를 정확하게 예측했다고 합니다.

2위는 미국의 최고의 연구진 팀이 3개를 예측할 시간에 말이죠. 즉 8배 이상의 결과를 보여주었습니다.

이 대회가 말해 주는 것은 연구원 또한 대체 될 수 있다는 사실을 보여주었습니다.

하지만 어떠한 데이터가 필요한지, 왜 필요한지는 현재 컴퓨터는 스스로 알 수는 없습니다.

나노봇이 인간의 몸을 이해하고 치료하기 위해선 많은 양의 의학적 지식이 필요한 부분에 대해서는 기계학습과 딥러닝으로 늘릴 수 있지만,

초기에 나노봇을 사용하는 데 있어 인간의 몸은 개인마다 다르므로 오차라는 결과가 나왔을 때,

로그를 이용하여 오차를 전문적으로 다룰 수 있는 컴퓨팅 전문의가 필요하다 생각합니다.

2. 인류는 더욱 재미있어진다.

“인간이 사이보그화될수록 우리는 보다 `인간적`이 된다. 나노봇은 논리적인 지능뿐 아니라 감정적인 지능도 키워준다.”

시각, 청각, 후각, 촉각, 미각 등 부분을 담당할 각 각의 감각 디자이너라는 직업이 생길 것이라고 예상합니다.

감각 디자인이 고도화, 전문화될수록 미래에는 현실과 가상현실을 구분하기 힘들 것이라고 예상하기 때문에 심리치료에 대한 수요도 높아질 것이라 예상합니다.

그리고 개인의 수요는 더욱더 세분될 것이고 콘텐츠 제작으로 사람들에게 즐거움을 주는 크리에이터는 더욱더 주목받을 직업이라고 예상을 합니다.

물론 가상현실을 통해서 말이죠. 염려되는 부분은 의사소통이란 단어가 사라질까 걱정이 되기도 합니다. 네트워크라는 환경에서 지식과 감정을 공유한다면 말이죠.

모두가 똑같은 지식을 가지고, 같은 사고방식을 갖는다면 과연 재미가 있을지… 이것이 잘못 이용된다면, 한 권력자에 의해 중앙 통치될 수도 있다고 생각합니다.

더욱 투명한 세상을 위해 정보나 저작권이 공개될 것이라 예상되고, 비트코인에서 사용된 블록체인이라는 기술이 개인이 개인을 감시하고 통제할 수 있는 수단 중 하나가 될 것으로 생각합니다.

3. 모든 것을 3D 프린터로 만든다.

“2020년대가 되면 자신이 필요로 하는 모든 것을 3D 프린터로 만들 수 있다. 이미 3D 프린터로 건물이나 교량을 만들고, 몸속의 갈비뼈를 만드는 게 가능한 세상이다.”

3D 프린터를 이용해 만드는 재료는 더욱 다양해질 것이며, 인체의 온전한 상호작용과 가격 대 성능비를 낮추어 보급률을 높일 수 있는 신소재나 활용 방법 등이 집중될 것이라고 고려됩니다.

누구나 디자이너가 될 수 있다는 장점이 있지만, 소수가 자본과 재료를 독점하고 있다면, 빈익빈 부익부 문제는 앞으로 더욱 심화 될 것이고, 세계의 큰 논쟁거리가 되어 30년 이후에는 로봇에 의해 생산되고 공급받는 시스템이 이루어지고, 고등기술을 가진 사람만이 직업을 갖는 세상이 될 것이라 여깁니다.

4. AI로 부활한다.

“2030년대가 되면 사랑하는 사람의 뇌에 나노봇을 넣어 기억을 추출할 수 있다. 죽은 자의 기억을 DNA 표본 기술과 결합해 죽은 사람의 가상 버전을 만드는 게 가능해진다.”

신경 과학자들의 연구에 의하면 기억 용량을 계산한다면 약 2.5 페타바이트라고 합니다.

인구 수 만큼의 데이터가 있고, 그 데이터를 교류하는 데 있어 엄청난 양의 전송량이 생길 것이라고 예상합니다.

서버의 장애가 생긴다면,엄청난 손해가 생길 것이고 현재 엔지니어라고 불리는 직업군들이 미래의 의사 같은 직업이 될 것으로 예측됩니다.

사회적인 측면에서 바라봤을 때, 영생을 통해 인류의 가치관과 도덕은 크게 변하면서 인류에게 아노미(Anomie)에 대한 대책이 필요할 것으로 봅니다.

예를 들어, 사후와 관련된 법률 개정, 해커에 대한 법적 처리, 살인에 대한 기준 등 법은 더욱 세밀화될 것이고, 사회적인 문제 하나하나 마다 법률전문가란 직업이 생겨나 일반사람들과 네트워크를 통한 직접 민주 정치로 모든 사람이 힘을 모아 문제를 해결할 것으로 보고 있습니다.

본문의 글을 정리하자면, 크게 개척 직업군과 파생 직업군으로 나누어 볼 수 있습니다.

개척 직업군은 현재에도 존재하지만, 미래에서도 환영받을 직업이라고 예상합니다.

개척 직업군: 의료 전문가, 컴퓨터 전문가, 신소재 및 화학 전문가, 보안 전문가 등

파생 직업군은 미래의 큰 물결이 긍정적인 부분과 부정적인 부분을 생산하는데 이것을 원활하게 만들어 줄 직업군입니다.

파생 직업군: 엔지니어, 크리에이터, 감각디자이너, 법률 전문가 등

생산, 서비스 부문에 대해 언급을 하지 않았는데, 단순 노동과 반복 작업의 업무들은 로봇들이 대체 할 것으로 여깁니다.

생산 개선 전문가, 서비스 개선 전문가 등 로봇의 효율을 높이는 방법을 고민하는 직업군이 생길 것이라고 봅니다.

30년보다 먼 미래에는 직업이라는 단어가 사라지고 인력이 필요한 작업은 봉사활동이라는 개념으로 인류에 이바지하게 되리라는 것이 저의 결론입니다.

미래에 대한 답은 아무도 정확히 예측할 순 없지만, 미래를 생각하는 우리가 있어 미래가 있다고 생각합니다.

작년보다 더 알찬 한 해였다!

작년과 비교하면 한 것이 많아 회고를 적는 것이 부담스러워졌다…

그래서 사진첩을 보면서 일 년을 간단하게 정리하는 것에 집중했다.

1월 :Laravel 스터디 & 패스트 캠퍼스 Django 수업

쉬지않고 가장 많이 코드를 쳤던 때이다…ㅎ

2월 : 건국대학교 글로컬캠퍼스 컴퓨터공학과 졸업

좋은 사람과 좋은 추억을 만들어준 학교다! 벌써 졸업이라니…!

3월 :인천광역시 경찰청

인천 누리캅스 대표로 감사장을 받게 되었다! (이래도 되나?…)

3월 :조인 스타트업(나 때는 스타트업 인턴즈였다 이말이야)

도전과 열정이 넘치는 곳이다!

막연하게 동경했던 스타트업에 대해 알아볼 수 있는 곳!

3~6월 : 프로그라피 4기 Django 멘티

프랖 활동을 하면서 우물 안 개구리라는 것을 뼈저리게 느꼈다.

자동으로 겸손해지는 대단한 사람들이 많은 모임이다!

4월~ :빅펄과의 만남 시작

유저만을 생각하는 바보님들과 일해보고 싶었던 염원을 이루었다!

사랑할 수 밖에 없는 팀원들!

8월~ : 프로그라피 5기 장고 운영진

“내가 누군가의 멘토를 해도 될까?” 라는 고민이 있었는데 프랖 친구들은 나에게 믿음과 힘을 주었다!

11월 ~ : GOLANG KOREA STUDY

회사코드에 익숙해지며 나태해질 때, 스터디를 통해 많이 반성하게 되었다…!

The Go Programming Language

GO의 철학이 담긴 책이다! 추천!!!

12월 : 회사 이전(봉천동 -> 삼성동)

정들었던 관악창업공간을 떠나 스파크 플러스로 회사를 이전했다!

미나찡(대표님)가라사대 “2020년은 빅펄 팀의 멋진 레이스가 펼쳐질 것”이라고 하셨다!

2019년 진행 프로젝트

#회사 프로젝트

• 빅펄 유튜버 — 백엔드 (5월~)
• 빅펄 광고주 — 백엔드 (5월~)
• 어드민 — 광고 운영 서포팅 (5월~)
• 데이터 파이프라인 (7월~)
• 검색 엔진 — 백엔드 ( 7월~)
• CSR SEO(11월)
• 데이터 라벨링 페이지 — 백엔드(5~6월)

#동아리

• 휴모니 팀 Picxy(딥러닝을 이용한 누끼따기 프로젝트) — 백엔드(3 ~ 6월)
• 포맨 팀 개같하(개발 모임 프로젝트) — 서포터(9월~)

#개인

• 쇼핑몰 — 풀스택(12 ~ 2월)
• 외주 개발 — 백엔드(6~9월)

발표

벡엔드 엔지니어 직무소개 — 5월 사내 발표

비전공 편입생에 백엔드 엔지니어로 살아남기 — 프로그라피 4기

Go routine and channel — Golang Korea 스터디

협업은 RPG(리듬 파워 집중력) — 프로그라피 5기

참여 세미나 or 콘퍼런스

• 나의 개발이야기
• 만들면서 이해하는 PWA 코드랩
• I/O Extended 2019 Seoul
• FEconf
• 우아한 레디스

*새해 목표 *

나를 위한 운동!

제발 좀 해야겠다…

내가 받은 것들을 베풀려면

내 의식을 담을 건강한 몸을 만들어야겠다는 생각을 했다.

커뮤니케이션 스킬 업!

7개월 정도 백엔드 개발자로 근무했는데, 코드만 잘 친다고 일을 잘한다고 할 수 없다는 생각이 들었다. (물론, 코드를 잘 치는 것도 아님…ㅎ)

마음이 앞선다고 할까

내 생각의 흐름이 A > B > C였다면,

마음이 급하거나 상대방이 알고 있다고 생각하여 C를 말하곤 했는데,

그때마다 “A는요?” 라고 되묻는 팀원들에게 미안했고,

굳이 필요없는 커뮤니케이션 비용이 든다는 생각에

항상 마음과 생각을 정리하는 연습을 의식적으로 하기 시작했다!

좋은 코드를 위한 책 읽기(산드로 만쿠-소 저자의 책 읽기)

똑똑한 사람들과 일하고 이야기하고 싶었다는 욕망을 이루었다.

관찰한 결과, 그런 사람들은 항상 책을 끼고 지냈다…

천재 개발자를 만날 순 업지만, 책에서라도 만나 이야기 하고 싶다!

회고를 마치며…

지나간 것을 지나간 것이지만,

그냥 보내기는 아쉬워 회고를 쓰게 되었는데

나는 허세도 많고 장난은 많은 빈 깡통이지만, 주변에 좋은 사람들이 내 빈 깡통을 채워주고 있다는 생각이 들었다 …

이런 모습도 아껴주는 사람들이기에 더욱이 나를 채워 그들에게 나누어 주고 싶다! (오글)

P.S 12월 연말 휴가로 베트남을 다녀온 주에 고카톤 멘토로 참여하게 되었다! 좋은 경험이었고, 신년회인 듯 아는 얼굴들을 오랜만에 보아 기분이 좋았다!

찐막!!!

인복이 많았던, 내가 사랑했던 2019년 잘가!

그리고 2020년 환영해!