꾸준함이 진리다

6초에서 0.2초로: 레거시 API 성능 개선 이야기

황심지 — Sat, 14 Dec 2024 17:04:17 +0900

서비스를 운영하다 보면 늘 예상치 못한 문제가 튀어나오곤 합니다. 이번엔 문서 및 카테고리 이동 기능이 발목을 잡았습니다.

실제로 고객들이 자주 사용하는 기능이여서, 해당 기능으로 고객들은 작성해놓은 문서를 새로운 카테고리나, 폴더등으로 옮기곤 합니다. 그런데 고객들의 사용 빈도만큼이나 "너무 느려요", "이동기능 로딩만 5초 넘게 걸려요" 같은 불만도 많았습니다.

그래서 실제로 테스트를 해보니 응답 시간이 평균 6초에 달했습니다. 사용자는 6초 동안 화면에서 로딩 메시지를 봐야 하고, 작업 도중 페이지를 닫아버리는 경우도 있었습니다.

따라서 해당 기능에 대해 어떤 부분에서 성능 문제가 발생했는지, 파악하고 개선하자는 목표로 작업을 진행했습니다.

6초의 로딩 시간, 문제는 반복되는 save()호출이었다

문제의 원인을 파악하기 위해 해당 코드 부분을 살펴보니 아래와 같은 로직이 작성되어 있었습니다.

개선 전 코드

for document in documents:
    document.position = new_position
    document.save()

이 코드는 각 문서를 하나씩 업데이트하고, 매번 save() 메서드를 호출합니다.
save() 메서드는 내부적으로 데이터베이스와 통신하기 때문에 호출할 때마다 데이터베이스 쿼리가 발생합니다.
즉, 문서가 많아질수록 요청 속도가 기하급수적으로 느려지는 구조였던 거죠.

예를 들어 문서가 95개라면, 데이터베이스에 95번의 쿼리가 발생합니다.

이건 단순히 서버 리소스를 낭비하는 것뿐 아니라, 응답 시간을 길게 만드는 주범이었습니다.

해결 방법: bulk_update로 쿼리 최적화

문서를 하나씩 저장하는 대신, Django에서 제공하는 bulk_update() 메서드를 사용해 데이터를 한 번에 업데이트하도록 코드를 변경했습니다.

bulk_update는 한 번의 데이터베이스 쿼리로 여러 개의 데이터를 업데이트할 수 있어 다수의 데이터를 업데이트 해야할 때 성능 향상에 유용 합니다.

개선 후 코드

from django.db import transaction

# 모든 문서의 position 값을 한꺼번에 변경
for document in documents:
    document.position = new_position

# bulk_update로 한 번에 저장
with transaction.atomic():
    Document.objects.bulk_update(documents, ['position'])

이 코드는 문서를 반복하며 필요한 값만 변경한 뒤, 한 번의 쿼리로 저장합니다.
문서가 95개든 1,000개든 한 번의 쿼리로 처리되기 때문에 성능이 크게 개선됩니다.

결과는? 속도가 30배 빨라졌습니다.

코드를 수정한 후 테스트를 진행해보았습니다.
결과는 정말 놀라웠습니다.

테스트 환경 : 스테이징(실제 서비스 환경과 동일한, 인프라를 구축한 환경)
개선 전: 평균 응답 시간 6초
개선 후: 평균 응답 시간 0.2초
성능 향상: 약 30배

이제 고객들이 긴 로딩 메시지를 볼 필요 없이 빠르게 작업을 이어갈 수 있게 되었고, 서버 자원의 낭비도 크게 줄어들었습니다.

정리하며: 배운 점

이 경험을 통해 한 가지 확실히 배운 점은, “데이터베이스와의 통신은 꼭 필요한 만큼만 하자” 라는 기본 원칙입니다.

단순히 반복문 내에서 저장 메서드를 호출하는 코드가 성능에 얼마나 큰 영향을 미칠 수 있는지 실무에서 직접 체감한 사례였어요.

특히, Django ORM을 사용한다면 bulk_update, bulk_create 같은 쿼리 최적화 기능을 적극적으로 활용하는 것이 중요하다는 것을 깨달았습니다.

번역 API 개선기: 번역 가능 언어 추가 요청을 받으며 배운 점

황심지 — Tue, 3 Dec 2024 23:18:23 +0900

업무를 하다 보면 늘 새로운 문제를 만납니다. 이번에는 번역 관련 API에서 번역 가능 언어를 추가해 달라는 요청이 왔습니다. 처음에는 단순히 번역 가능 언어 코드를 추가하고 끝낼 작업처럼 보였지만, 막상 작업을 시작하면서 기존 코드에서 숨겨진 문제를 발견하게 되었습니다. 그리고 그 문제를 개선하는 과정에서 많은 것을 배웠습니다. 이번 글에서는 그 경험을 나누고자 합니다.

1. 문제의 시작: 느린 번역 처리 시간

“번역 가능 언어 목록에 새로운 언어를 추가해 주세요”라는 요청을 받았습니다. 요청 자체는 간단했지만, 테스트를 진행하던 중 의외의 문제가 드러났습니다. 번역 API를 호출할 때 번역 처리 시간이 너무 오래 걸렸던 것입니다. 약 4,500자의 텍스트를 번역하는 데 17초가 걸렸죠.

“왜 이렇게 오래 걸리지?” 하는 의문에서 코드를 살펴보니 문제는 바로 for-loop 안에서 매번 번역 API로 HTTP 요청을 보내고 있다는 것이었습니다.

2. 문제의 원인: 반복적인 API 호출

from google.cloud import translate_v2 as translate

def translate_text(text):
    translate_client = translate.Client()
    lines = text.split("\n")  # 개행 문자 기준으로 텍스트 분리
    translated_lines = []

    for line in lines:
        if line.strip():  # 빈 줄은 건너뜀
            response = translate_client.translate(line, target_language="ko")
            translated_lines.append(response["translatedText"])

    return "\n".join(translated_lines)

-- 예시 용으로 작성된 코드 입니다 --

• text.split("\n")로 개행 문자를 기준으로 텍스트를 분리합니다.

• 각 줄을 번역 API에 개별 요청(translate_client.translate)합니다.

• 요청이 많아질수록 네트워크 레이턴시가 누적되고, 성능이 저하됩니다.

기존 코드는 텍스트를 ”\n”(개행 문자) 기준으로 분리한 뒤, 각 줄을 번역 API에 개별적으로 요청하고 있었습니다. 즉, 줄이 많아질수록 API 요청 횟수가 기하급수적으로 늘어나고, 이로 인해 전체 처리 시간이 길어졌던 겁니다.

문제를 간단히 정리하면 다음과 같았습니다:

• 4,500자 기준으로 개행 문자가 많을수록 HTTP 요청 횟수가 늘어남.

• API 호출은 네트워크 레이턴시와 처리 시간이 포함되기 때문에, 반복 호출은 성능을 크게 저하시킴.

• 전체 작업 시간이 비효율적으로 길어짐.

3. 개선 방법: API 문서를 참고해 새로운 구조로 변경

구글 클라우드 번역 API의 공식 문서에서 translate 메서드가 **문자열(str)**뿐 아니라 리스트(list) 형태로도 요청할 수 있다는 점을 확인했습니다.

translate(
    values,
    target_language=None,
    format_=None,
    source_language=None,
    customization_ids=(),
    model=None,
)

values

str or list
String or list of strings to translate.

즉, 개행 문자로 나뉜 텍스트를 한 번에 리스트 형태로 API에 전달하면, 응답 또한 번역된 결과를 담은 딕셔너리 리스트로 반환된다는 것을 알게 되었습니다.

4. 개선 코드: 한 번의 요청으로 처리

구글 번역 API는 긴 텍스트를 한 번에 처리할 수 있기 때문에, 텍스트 전체를 API로 전달하도록 코드를 수정했습니다. 개선된 코드는 아래와 같습니다:

from google.cloud import translate_v2 as translate

def translate_text_optimized(text):
    translate_client = translate.Client()

    # API 요청을 한 번만 수행
    splitted_text = text.split("\n")
    response = translate_client.translate(splitted_text, target_language="ko")
	
    # ... 그외 처리

    return translated_text

• text 전체를 API로 전달하여 한 번의 요청으로 번역을 처리합니다.

• 불필요한 for-loop와 여러 HTTP 요청을 제거했습니다.

4. 결과: 성능의 극적 개선

• 개선 전: 4,500자 기준 번역 처리 시간 약 17초

• 개선 후: 같은 텍스트를 번역하는 데 약 0.9초 (1초 이내로 단축)

이 작업을 통해 요청 횟수를 대폭 줄이고, API의 성능을 최대한 활용할 수 있었습니다.

마무리하며

작은 문제처럼 보였던 비효율적인 구조가 전체 번역 프로세스의 성능을 좌우한다는 점을 이번 경험을 통해 실감했습니다. 특히 API의 문서를 잘 읽고 활용하면 단순한 최적화 작업에도 큰 성과를 낼 수 있다는 것을 배웠습니다. 앞으로도 문서를 꼼꼼히 살피며 개선할 수 있는 부분을 찾아갈 계획입니다.

정기 실행 쿼리 최적화

황심지 — Wed, 22 May 2024 16:41:20 +0900

APM 툴에서 정기적으로 실행되는 쿼리가 평균 25초 정도 소요되어 성능 개선이 필요했습니다. 이 쿼리는 30분마다 실행되는 배치 작업에 사용됩니다.

문제점

기존 쿼리는 다음과 같은 문제점을 가지고 있었습니다:

Using filesort와 Using temporary가 실행 계획에 포함됨.
reg_date 칼럼에 인덱스를 걸어도 정렬 처리에서 인덱스를 사용하지 못함.

예시

SELECT
  ...(필요한 컬럼들)
FROM
  A
  INNER JOIN  ON 
  INNER JOIN  ON 
  INNER JOIN  ON 
  INNER JOIN  ON 
WHERE
  조건문 1
  AND 조건문 2
ORDER BY
  `some_table`.`reg_date` ASC;

주요 원인

Using filesort: ORDER BY 처리가 인덱스를 사용하지 못할 때 발생하며, 조회된 레코드를 정렬용 메모리 버퍼에 복사해 정렬합니다.
Using temporary: 임시 테이블을 사용하여 결과를 정렬합니다.

해결 방안

created_at에 인덱스를 추가해 ORDER BY 절에서 인덱스를 사용할 수 있도록 처리:
- 그러나 WHERE 절에서 created_at을 사용하지 않기 때문에 인덱스가 정상적으로 작동하지 않음.
- 비즈니스 로직상 WHERE 절에 created_at을 추가할 수 없으므로 이 방법은 사용 불가.
ORDER BY 구문을 삭제하고 애플리케이션 로직에서 정렬 처리:
- 비즈니스 로직상 ORDER BY를 통한 정렬이 중요하지 않기에 애플리케이션 로직을 변경해서 처리함.

최적화 후 쿼리 실행 시간

AS-IS: 약 29초 소요
TO-BE: 약 19초 소요 (약 10초 감소)

최적화된 쿼리 예시

최적화된 쿼리는 ORDER BY 구문을 제거하고, 애플리케이션에서 정렬을 처리하도록 변경했습니다.

SELECT
  ...(필요한 컬럼들)
FROM
  A
  INNER JOIN  ON 
  INNER JOIN  ON 
  INNER JOIN  ON 
  INNER JOIN  ON 
WHERE
  조건문 1
  AND 조건문 2;

이 쿼리는 데이터베이스에서 직접 정렬을 처리하지 않고, 애플리케이션에서 정렬을 수행하도록 하여 성능을 개선했습니다.

결론

ORDER BY 구문 한줄을 삭제함으로써, 쿼리 실행시간을 약 10초 정도 줄일 수 있었습니다. 이 과정에서 해당 쿼리에 대한 실행계획을 이해하고 튜닝을 진행하는것 뿐만아니라 해당 쿼리의 각 부분이 실제로 유용하게 쓰이고 있는지 불필요한 정렬이 발생하고 있는건 아닌지와 같은 부분을 토대로 튜닝을 진행할 수 있었습니다.

시스템 로그 페이지 조회 성능 최적화

황심지 — Thu, 4 Apr 2024 12:12:03 +0900

개발 과정에서 성능 최적화는 매우 중요한 과제 중 하나입니다. 특히, 대용량 데이터 처리 시, 데이터 조회 성능은 사용자 경험에 직접적인 영향을 미칩니다. 본 포스트에서는 시스템 로그 페이지 조회 성능을 개선한 사례를 공유하고자 합니다.

문제 상황

라이브 환경에서 시스템 로그 페이지 조회 시, 약 8.10초가 소요되는 문제가 발생했습니다. 조회 대상 데이터는 약 76,040건이었습니다.

문제 분석

ListView를 사용하는 클래스에서 전체 시스템 로그 데이터 갯수를 조회하는 과정에서 성능 저하가 발생했습니다. 특히, get_context_data 메서드에서 len(self.get_queryset())을 호출할 때 전체 테이블 데이터에 대한 조회 쿼리가 발생했습니다.

def get_context_data(self, **kwargs):
    ...
    context['objects_count'] = len(self.get_queryset())
    ...

데이터베이스 로그를 확인해보니, limit 없이 system_log 테이블에 대한 전체 데이터 조회 쿼리가 두 번 전송되었습니다. 이로 인해 성능 저하가 발생했습니다.

len(self.get_queryset()) 대신 context['paginator'].count를 사용하는 방식으로 변경하여, Paginator 클래스의 count 속성을 사용했습니다. 이 방식은 전체 데이터 수를 조회할 때 데이터베이스에 쿼리를 날리지 않고, Paginator가 이미 계산한 결과를 사용합니다.

또한, get_queryset() 메서드에서 queryset에 대한 반복 처리 시, 쿼리셋이 평가되어 전체 데이터 조회 쿼리가 발생했습니다.

def get_queryset(self):
    ...
    for query in queryset:
        query.convert_log_data()
    return queryset

이를 context의 object_list를 사용해 처리하도록 변경함으로써, ListView에서 지정한 paginated_by 값만큼만 처리되도록 개선했습니다. 이는 불필요한 전체 데이터 조회를 방지하고 성능을 향상시킵니다.

개선 결과

개선 전

소요 시간: 약 1분

개선 후

소요 시간: 0.7 밀리초

결론

이번 최적화 과정을 통해 데이터 조회 성능이 크게 향상되었습니다. Django의 Paginator 클래스와 쿼리셋의 평가 시점을 이해하고 적절히 활용함으로써, 대규모 데이터 처리 시 성능을 개선할 수 있음을 확인했습니다.

참고 자료

주니어 개발자가 말아주는 간식 구매 요청 자동화

황심지 — Sat, 27 Jan 2024 15:07:21 +0900

사용 기술

Slack API

Slack API를 사용하여 간단한 명령어, 예를 들어 /간식구매요청 과 같은 것들을 처리합니다. 이는 사용자가 Slack을 통해 쉽게 요청을 할 수 있게 해줍니다.

AWS Lambda

AWS Lambda는 이러한 Slack 명령어에 대한 반응을 처리하는 서버의 역할을 합니다. 우리는 많은 종류의 요청을 처리할 필요가 없기 때문에, 간단하고 효율적인 AWS Lambda를 선택했습니다.

AWS API Gateway

AWS ApiGateway는 Lambda와 연결되어, 사용자의 요청을 Lambda로 전달하는 역할을 합니다. 이를 통해 사용자의 요청을 쉽게 처리할 수 있습니다.

추가적으로, 구글 스프레드 시트를 조작하거나 웹에서 정보를 수집하기 위해 파이썬의 gspread 패키지와 bs4라는 도구를 사용했습니다.

자동화 하게 된 계기

기존 업무 프로세스는 그림과 같습니다.

위 워크플로의 단점은 요청자가 많아지면, 이를 모두 처리하기가 어려워집니다. 이 문제를 해결하기 위해 자동화 시스템을 도입하기로 결정했습니다.

간식 구매요청 자동화 아키텍쳐

사용자가 "/간식구매요청" 명령어를 입력하면, Slack API가 이를 감지하고 설정된 API 주소로 요청을 보냅니다. 이 주소는 API Gateway에 설정되어 있으며, Gateway는 이 요청을 받아 Lambda 함수를 실행시킵니다.

Lambda 함수는 요청을 처리하고 결과를 Slack으로 다시 보냅니다.

간식 구매요청 자동화 과정에서 만난 문제

API Gateway로 사용자가 요청한 /간식구매요청 에 해당하는 커맨드값을 가져오는 과정에서, 요청 데이터를 제대로 처리하지 못하는 문제가 발생.

문제 파악
Slack Slash Command 공식문서를 살펴보니 다음과 같은 내용이 있었습니다.

token=gIkuvaNzQIHg97ATvDxqgjtO
&team_id=T0001
&team_domain=example
&enterprise_id=E0001
&enterprise_name=Globular%20Construct%20Inc
&channel_id=C2147483705
&channel_name=test
&user_id=U2147483697
&user_name=Steve
&command=/weather
&text=94070
&response_url=https://hooks.slack.com/commands/1234/5678
&trigger_id=13345224609.738474920.8088930838d88f008e0
&api_app_id=A123456

This data will be sent with a Content-type header set as application/x-www-form-urlencoded.

/간식구매요청 명령어로 요청을 보내면 해당 요청을 처리하는 URL로 위와 같은 x-www-form-urlencoded형식의 form data형식이 보내지게 됩니다.

이 데이터 형식을 API Gateway에서 Lambda로 처리할 때, 매핑 템플릿 이라는 걸 설정해줘야 합니다

_매핑 템플릿_이란 Velocity Template Language(VTL)로 표현된 스크립트로, JSONPath를 사용하여 페이로드에 적용됩니다.

매핑 템플릿을 설정해주게 되면 원하는 데이터를

def lambda_handler(event,context):
    #TODO implement

    option = event['text']
    command = event['command']
    response_url = event['response_url']

위와 같은 식으로 사용할 수 있습니다.

Slack Command의 짧은 응답 시간제한으로 인한 "operation_timeout"이 발생하는 문제

위 그림은 기존에 구현했던 워크플로우 입니다. 문제점은 슬랙에서는 요청을 보낸 후 3초 이내에 응답을 보내주지 않으면 에러를 반환하게 됩니다. https://api.slack.com/interactivity/slash-commands#:~:text=This%20confirmation%20must,ignore%20the%20request

operation_timeout이 반환되지만 실제 응답은 정상적으로 처리되었기에, 사용자 입장에서 혼란이 생길 수 있다 판단에 해당 문제를 해결하고자 했습니다.

위와 같이, API Gateway 요청이 들어오면 1번 함수에서 실제 작업이 진행될 2번 람다 함수를 실행 시킵니다. 그 후 바로 slack으로 응답을 반환시켜 해당 문제를 해결 했습니다.

실제로는 아래 그림과 같이 동작합니다

간단한 자동화 과정이지만, 이번 작업한 내용을 토대로 추후에 새로운 기능들을 계속해서 추가하고 기존 기능을 고도화 하는등의 작업을 진행하며 Slack Command를 활용한 ChatOps를 만들어보려 합니다.

2023년, 나의 한 해를 돌아보며: 성장과 변화의 시간

황심지 — Mon, 1 Jan 2024 21:21:43 +0900

서론:

2023년을 시작하며 전 직장을 퇴사하고 본격적으로 학습에 집중하기로 마음먹은 시기였습니다. F-LAB 멘토링 과정을 병행하며 백엔드 개발자로서 큰 성장을 이룰 수 있었습니다. (이와 관련한 자세한 내용은 제가 작성한 'F-LAB 후기' 글을 참고해주세요.)

또한 2023년은 성장뿐만 아니라, 인간 관계, 자기 사랑, 운동 등 육체적, 정신적 측면에서 의미 있는 한 해였습니다.

1. F-Lab 자바 백엔드 과정에서 멘토로서의 역할 수행:

F-LAB 자바 백엔드 과정을 수료하며 많은 것을 배울 수 있었습니다. 자바 백엔드에 국한된 지식뿐만 아니라, 어떤 언어나 프레임워크에도 적용할 수 있는 폭넓은 지식을 얻었습니다. 현업에서의 다양한 고민도 함께 학습할 수 있었고, 기술적 성장뿐만 아니라 대인 관계 측면에서도 멘토님의 도움을 받아 성장할 수 있었습니다.

2. 중요한건 꺾이지 않는 마음

저는 395번의 지원과 10회 이상의 면접을 거치며 몸과 마음이 많이 지쳤습니다. 그럼에도 불구하고, 끝까지 꾸준히 도전하며 한 번쯤은 원하는 회사에서 일할 수 있지 않을까 하는 희망을 가지고 준비했습니다. 그 결과, 사진과 같이 최종 합격의 기쁨을 맛볼 수 있었고, 현재는 그 회사에서 근무하고 있습니다.

이 글을 읽는 여러분들도 취업 준비 과정에서 여러 번의 실패를 경험할 수 있지만, 그때마다 자신을 잘 다스리며 '나는 결국 잘 될 것이다'라는 긍정적인 마음가짐으로 도전을 이어가면 결국 성공할 수 있습니다.

4. 눈떠보니 파이썬과 Django 사용중?!

F-LAB에서 자바 백엔드 멘토링 과정을 수료하며 주로 Java와 Spring을 공부했습니다. 하지만 멘토님의 조언대로 기술이나 언어에 집중하기보다는 원론적인 부분에 집중하여 학습하면 추후 다른 언어나 프레임워크에도 빠르게 적응할 수 있다는 것을 깨달았습니다.

이러한 학습 방법 덕분에 현재는 Python과 Django를 사용하는 회사에 빠르게 적응하고 업무를 수행하고 있습니다. 테스트 코드 추가, 레거시 코드 리팩토링 등을 진행하며 기존의 업무 방식을 개선하는 데 일조하고 있습니다.

5. Hello World != Real World

학습 단계에서의 토이 프로젝트와 실무는 정말 다릅니다. 실무에서 경험하는 데이터베이스 테이블의 양, 서버 인프라 구조, 클라우드 서비스의 사용 등은 토이 프로젝트에서는 경험하기 어려운 부분들입니다.

또한, 객체지향 프로그래밍에 대한 이해를 더욱 심화할 수 있었으며, 실무에서는 이론적인 지식과 함께 실제 적용에 대한 타협과 결정을 내려야 하는 다양한 상황을 직면하게 됩니다.

6. 2024년엔 어쩌지?

2024년에는 두가지 관점에서 목표를 생각해봤습니다.

학습

업무와 관련된 네트워킹, 커뮤니티 참여 또는 세미나 등에 적극적으로 참여하면서, 실무에 계신 다른개발자분들은 어떻게 업무를 하고 계신지 등등 많은 정보를 얻으려 합니다
학습 진행(회사 실무와 관련된 부분들을 중점적으로 학습할 예정입니다.)
- 리팩토링 책과 레거시 코드 활용 방법 책을 통해 레거시 코드 개편시, 어떻게 접근하는게 좋을지 학습과 더불어 실제 실무 코드에 적용을 해나가볼 생각입니다.
- 소프트웨어 아키텍쳐 설계에 대해 학습을 진행함으로써, 코드 작성뿐만 아니라 아키텍쳐 구성에도 학습을 진행할 예정입니다
- 쿠버네티스 및, AWS 공부
- Effective Python 학습
- F-LAB에서 진행했던, 사이드 프로젝트 Python과 Django로 포팅

취미

주말 서퍼 해보기
스노보드 타러가기

마무리하며

2023년이 마무리되고, 2024년이 시작되었습니다 작년에 아쉬었던 일들 이루지 못한일들 이젠 다 잊어버리시고 지금 현재에 할일들 하나하나 잘 마무리하고, 이 글을 읽으시는분들 모두 원하시는 일을 해낼 수 있을꺼라 생각합니다. 긴 글 읽어주셔서 감사합니다! 다음글로 찾아뵙겠습니다 (꾸벅)

더 궁금하신 내용이 있으시면 댓글로 남겨주세요!

HTML 텍스트 처리과정에서 발생하는 공백발생문제해결

황심지 — Fri, 15 Dec 2023 17:16:20 +0900

문제 상황

최근 회사에서 HTML 기반 텍스트 편집기를 사용하던 중, 텍스트에 색상을 적용했을 때 발생하는 불필요한 공백 문제를 경험했습니다. 이는 특히 텍스트 편집기의 특정 플러그인(텍스트 color 등)을 사용할 때 두드러졌습니다. 이러한 문제는 일반적으로 HTML 편집기의 내부 구현이나 CSS 스타일링과 관련이 있을 수 있습니다. 그렇기에 저 또한 처음에는 CSS를 통해 이 문제를 해결하려 했으나, 이 방법은 긴 텍스트에서 레이아웃이 깨지는 새로운 문제를 야기했습니다. 이를 통해 문제의 원인이 HTML이나 CSS 자체가 아니라, 원본 텍스트에 삽입된 불필요한 공백에서 비롯되었음을 파악했습니다.

해결 방법을 찾기 위해 다양한 디버깅 과정을 거쳤고, 특히 문자열 인코딩 함수의 사용 방법에 주목했습니다. 해당 함수에서 position argument를 잘못 사용함으로써 예기치 않은 동작이 발생해 버그가 생긴 것을 확인했습니다.

예를들어 다음과 같은 코드였습니다.

try:
            return self.soup.encode('utf-8','ignore').decode('utf-8') or ''
        except Error:
            return self._get_text(self.soup)

예상치 못한 동작의 원인은 encode 함수에 ignore 인자를 잘못 전달한 것이었습니다. encode 함수는 문자열을 지정된 인코딩으로 변환할 때 사용되며, errors 매개변수는 인코딩 과정에서 발생하는 에러를 어떻게 처리할지 결정합니다. 여기서 ignore 옵션을 사용하면 인코딩할 수 없는 문자를 무시하지만, 이 경우 잘못된 위치에 인자를 넣어 문제가 발생했습니다.

(method) def encode(
    encoding: str = "utf-8",
    indent_level: int | None = None,
    formatter: str | Formatter = "minimal",
    errors: str = "xmlcharrefreplace"
) -> bytes

위 코드는 beautifulSoup 4.12.2 버전 기준으로 작성되었습니다.

return self.soup.encode('utf-8','ignore').decode('utf-8') or '' 코드에서 두번째 인자값에 위치한 ignore가, errors에 해당하는게 아닌, indent_level에 해당하게 되었고, 그 이후 encode함수 처리과정에서 예기치 않은 동작이 발생해 버그가 발생했습니다.

따라서 encode 함수의 사용 방법을 수정함으로써 문제를 해결할 수 있었습니다. 코드를 self.soup.encode('utf-8', errors='ignore').decode('utf-8')와 같이 변경한 후, 함수가 정상적으로 작동함을 확인했습니다.

이 사례를 통해 복잡한 웹 개발 환경에서는 작은 코드 변경이 큰 영향을 미칠 수 있음을 다시 한번 깨달았습니다. 또한, 디버깅 과정에서 정확한 문제의 원인을 파악하는 것이 중요함을 알 수 있었습니다.

또한 파이썬을 사용하는 유저라면, positional Argument보다, Keyword Argument사용을 통해 위와 같은 일을 방지하는게 좋을 것 같다고 생각이 들었습니다. 감사합니다

참고 자료

https://m.blog.naver.com/youndok/222299302794
https://beautiful-soup-4.readthedocs.io/en/latest/index.html?highlight=encode#output-encoding

F-Lab 자바 백엔드 코스 멘토링 후기

황심지 — Sun, 3 Dec 2023 16:35:47 +0900

소개

안녕하세요! 2022년 10월부터 2023년 1월까지 F-Lab 자바 백엔드 멘토링 과정을 수료한 simgee입니다 :)
이번글을 통해 F-Lab 멘토링을 통해 깨달은 점과 공유드리고 싶은 내용에 대해 작성해보려 합니다.

경험과 성장

저는 멘토링 이전에 내가 학습하는 방향이 맞는지 제대로 성장하고 있는지 의문을 가지고 있었습니다. 그러던 와중 에프랩 멘토링 과정을 알게 되었고, 스스로 학습할 수 있는 개발자로 성장할 수 있는 기회라 생각해 신청하게 되었습니다.

그렇다면 어떤 부분에서 성장을 느꼈는가? 라는게 가장 궁금하실 텐데 다른 무엇보다 제가 작성하는 코드와, 아키텍처적 의사결정 사용 기술에 대한 고민 등 여러 부분에서 저의 생각을 녹여낼 수 있는 능력을 기를 수 있었습니다. 예를 들어 인증과 관련된 부분으로 세션방식과 JWT방식 중 어떤 것을 택할지, 현재 프로젝트 상황에 맞춰 생각한 후에 선택해 진행할 수 있었습니다. 그리고 내가 작성한 코드에 대해서도 멘토님의 세세한 피드백을 통해 다시 한번 작성한 코드에 대해 어떤 의도를 담고 코드를 작성했는지(소위 말하는 무지성 코딩)를 생각할 수 있었습니다.

프로젝트 이전에 학습하는 과정에서는 단순히 hello world를 타이핑 하고, 학습하는 것이 아닌 자바 메모리 구조나, HTTP에 대한 깊은 이해, 등등 깊이 있게 이해하는 과정을 거치게 되었습니다. 저 같은 경우에는 필요한 CS지식이나 자바, 프레임워크에 대한 지식을 하나하나 공부하기보다는 프로젝트를 진행하면서 필요한 지식에 대해 깊이 파고들다 보면 CS적인 부분과 맞닥뜨리게 되는 경험을 할 수 있었습니다. 이러한 과정을 토대로 현재 실무에서도 깊이 있게 생각하고, 제가 작성한 코드에 대해 다시 한번 생각할 수 있는 기회를 가질 수 있었습니다.

실제로 현재 다니는 회사에서도, 자바가 아닌 파이썬을 사용하지만 에프랩 멘토링 때 학습하고 공부했던 것들을 토대로, 회사 인프라 구조에 대한 이해나, 객체지향에 대한 이해 등등 그리고, 무엇보다 재사용성을 높일 수 있는 코드를 작성하는 방법에 대해 다시한번 고민할 수 있게 되었습니다.

F-Lab 나만의 팁

저같은 경우에는 에프랩 과정 중 프로젝트를 진행하면서, 다른 분들이 작성하신 프로젝트도 참고하고, 유명한 기업들의 예시들을 참고하며 프로젝트를 진행했습니다. 그중 굿즈포유 개인 프로젝트를 진행할 당시에 예외 계층 구조에 대한 고민을 할 때, AWS SDK의 예외 계층 구조를 보고 참고해 굿즈포유에도 적용해 보는 등의 경험을 했습니다.

이러한 경험들이 이후 실무에서 회사에 존재하는 레거시 코드를 파악함에 있어도 빠르게 파악할 수 있는 능력을 길러주었고, 또한 이미 작성된 코드라 해서, 해당 코드를 단순히 복붙해 사용하는 것이 아닌, 기존 작성자가 어떤 의도를 담고 작성한 것인지, 어떻게 사용해야 할지 등을 고민할 수 있는 계기가 되었습니다.

추후 에프랩 멘토링을 진행하시는 분들도 프로젝트 진행시, 다른 분들의 프로젝트를 참고해 보면서 어떤 의도로 그분들이 해당코드를 작성했을지 생각해 보며 자신의 프로젝트에도 적용해 보면 좋을 것 같습니다. 그 과정에서 이해가 되지 않는 부분을 추가로 검색하다 보면 새로운 지식을 알아가며 성장하는 나 자신의 모습을 볼 수 있을 것입니다.

그 외에도, 이력서 작성에 대해 꾸준히 피드백을 받고, 멘토님께 요청을 통해 가상면접을 진행해 보는 등 여러 방면에서 에프랩 멘토님이 자신의 멘토라고 생각하며 많은 도움을 받으면 효과적으로 성장하는 자신의 모습을 발견할 수 있을 것입니다.

감사의 말

현재 저는 스타트업 기업에 취업을 해, 백엔드 개발자로서 일하고 있습니다. 사용하는 언어와 프레임워크가 자바 스프링이 아닌 파이썬과 장고이지만, 결국 F-Lab에서 공부한 컴퓨터 공학 근본적인 지식들을 토대로 업무에 빠르게 적응할 수 있었으며, 멘토링과정에서 멘토님이 주신 회사생활에 대한 팁이나, 앞으로 개발자로서의 자세등을 생각하며 업무를 진행하고 있습니다.

F-Lab 팀과 멘토에게 감사의 마음을 표현하며, 멘토링 프로그램으로부터 얻은 소중한 경험에 대한 감사의 말을 덧붙입니다. 에프랩 과정을 신청하는 분들께 이 글이 도움이 되기를 바랍니다. 감사합니다

MSW?

황심지 — Thu, 23 Nov 2023 18:10:15 +0900

개요

프론트엔드와 백엔드를 병렬로 개발할 때, 백엔드 API가 아직 완성되지 않아 프론트엔드 개발이 진행되기 어려운 상황이 발생할 수도 있습니다. 이럴 때 MSW(Mock-Service-Worker)를 활용하면 프론트엔드 개발을 용이하게 할 수 있습니다.

MSW란?

MSW는 프론트엔드에서 가상의 서버를 생성하여 실제 백엔드와의 통신을 모방하게 해주는 라이브러리입니다. 이를 통해 백엔드가 아직 개발 중일 때도 프론트엔드 개발을 원활하게 진행할 수 있습니다.

프로젝트에서 MSW를 적용한 상황

사용자 회원가입 시, 이메일 중복여부를 체크해야합니다. 이때 기존에 존재하는 이메일인지 체크하기 위해서는 백엔드 서버 API쪽에 요청을 보내 확인을 해야 합니다.

MSW를 이용해 이런 상황에서 백엔드쪽 응답을 Mocking 처리했습니다.

그림처럼 프론트엔드와 백엔드가 통신하는 부분이 Mocking으로 처리되기에, 백엔드와의 결합이 없어져

백엔드 서버의 작업 여부와 상관없이 병렬적으로 작업을 진행할 수 있게 됩니다.

무중단 배포

황심지 — Sun, 12 Nov 2023 14:51:32 +0900

무중단 배포 왜 해야할까?

현재 운영중인, 서비스의 신 기능 추가로 인해 버전이 업그레이드 되고 새로운 파일을 배포해야할 때, 다운 타임이 발생하게 됩니다
다운타임이 발생하는 배포 방식을 중단 배포라고 하며, 이 시간동안은 유저가 서비스를 이용할 수 없기에 유저에게 지속적으로 서비스를 제공하기 위해 무중단 배포 방식을 고려해봐야 합니다

무중단 배포

무중단 배포는 서비스가 중단되지 않은 상태(zero-downtime)로, 새로운 버전을 사용자들에게 배포하는 것을 의미합니다
무중단 배포를 하기 위해서는 최소 서버가 2대 이상 확보되어야 합니다.

무중단 배포의 종류

롤링(Rolling) 배포

현재 운영중인 서비스의 트래픽을 점진적으로 구버전에서 새로운 버전으로 옮기는 방식 입니다.
- 점진적으로 트래픽을 옮기는 방식은 크게 2가지 방식이 있습니다

방식 1

인스턴스를 하나 추가하고, 새로운 버전을 실행한다.
로드 밸런서에 새로운 인스턴스를 연결하고, 기존 구버전 어플리케이션이 실행되는 인스턴스를 하나 줄인다
그 후, 나머지 인스턴스도 버전을 변경한다

서버 개수를 유연하게 조절할 수 있는 클라우드 기반 환경에 적합할 것 같다.

방식 2

V1이 실행되고 있는 서버 하나를 로드밸런서에서 떼어낸다.
이 상태에서 해당 서버의 어플리케이션을 V2로 교체한다
이 과정을 반복해 모든 서버를 새 버전으로 교체한다

방식2의 경우 클라우드 환경이 아닌, 온프레미스 환경에서도 사용할 수 있을것이다

롤링 방식의 장점

롤링 배포 방식은 k8s, elastic beanstalk와 같은 많은 오케스트레이션 도구에서 지원하여 간편하게 구축할 수 있다.
많은 서버 자원을 확보하지 않아도 무중단 배포가 가능하다

롤링 방식의 단점

방식 2와 같은 경우, 배포 도중 서비스 중인 인스턴스 수가 줄어들게 되므로 그에 따른 서버가 부담하는 트래픽의 양이 늘어 날 수 있기에 주의해야 한다
또한 구버전과 신버전의 어플리케이션이 동시에 서비스되기 때문에 호환성 문제가 발생할 수 있다.

Blue/Green 배포

트래픽을 한번에 구버전에서 신버전으로 옮기는 방법이다.
- 현재 운영중인 서비스의 환경을 Blue라고 부르고, 새롭게 배포할 환경을 Green이라 부른다.

배포 진행 방식

Blue와 Green 환경을 동시에 구성해둔다.
배포 시점에 로드 밸런서가 트래픽을 Blue에서 Green으로 일제히 전환 시킨다.
Green버전 배포가 성공적으로 완료 되었고, 문제가 없다고 판단시 Blue 서버를 제거할 수 있다
혹은 다음 배포를 위해 유지해둘 수도 있다.

Blue/Green 방식의 장점

롤링 배포와 달리 한번에 새로운 버전으로 옮기기 때문에 호환성 문제가 발생하지 않는다.

Blue/Green 방식의 단점

Blue Green 환경을 구성해야 하기에, 실제 운영에 필요한 서버 리소스 대비 2배의 리소스를 확보해야한다.
- 클라우드 환경에서는 필요없는 인스턴스를 제거하거나, 배포가 완료된 Blue환경을 제거하면 되지만
  온프레미스 방식이라면 운영비용 부담이 클 수도 있다.

카나리(Canary) 배포

카나리는 롤링 배포 방식과 비슷하지만, 새로운 버전에 대한 오류를 조기에 감지하는 것이 다르다

카나리 배포 방식

소수 인원에 대해서만 트래픽을 새로운 버전에 옮겨둔 상태에서 서비스를 운영한다
새로운 버전에 이상이 없다고 판단하였을 경우에만 모든 트래픽을 신규 버전으로 옮긴다
1. 이때, 트래픽을 새로운 버전으로 옮기는 기준은 정해진 규칙(특정 유저 등)혹은 랜덤이다.

카나리 배포방식의 장점

새로운 버전으로 인한 위험을 최소화 할 수 있다.
소수 인원에 대해서만 트래픽을 옮기는 특성으로 인해 A/B 테스트를 진행하기에도 적합한 방식이다.

카나리 배포방식의 단점

롤링 배포와마찬가지로 신/구 버전의 애플리케이션이 동시에 존재하므로 호환성 문제가 발생할 수 있다.

참고

https://hudi.blog/zero-downtime-deployment/