개발자 블로그

Onechain 거래소에서 의존성 관리를 위한 도구로 기존의 requirements.txt 대신 pipenv를 도입하게 되었습니다. 이 글에서는 왜 이 전환을 하게 되었는지, 어떤 변화가 있었는지, 그리고 얻은 이점과 고려할 점들을 공유하려고 합니다.1. 기존의 requirements.txt 방식많은 Python 개발자들이 의존성 관리 도구로 requirements.txt를 사용합니다. 간단하고 익숙한 방식이기 때문에 널리 사용되어 왔죠. requirements.txt 파일은 프로젝트에서 필요한 패키지들을 명시하고, pip 명령어를 사용해 한 번에 설치할 수 있게 해줍니다.$ pip install -r requirements.txt그러나 이 방식은 다음과 같은 한계를 가지고 있었습니다:환경 격리 부족: ..

이번 포스팅에서는 우리 팀이 어떻게 코드 품질을 높이고 일관된 코드 스타일을 유지하기 위해 자동 포매팅 도구들을 도입했는지 이야기해 보려 합니다. 특히 협업이 많은 환경에서 코드 스타일의 일관성은 유지보수성과 가독성에 큰 영향을 미치기 때문에, 도입을 위해 동료 개발자들과의 논의도 중요했던 경험이었습니다.왜 자동 포매팅이 필요한가? 협업 환경에서는 다양한 개발자들이 각자의 스타일로 코드를 작성하게 되기 때문에, 시간이 지나면 코드베이스는 일관성을 잃고 가독성이 떨어지기 쉽습니다. 이로 인해 코드 리뷰 시 불필요한 논쟁이 발생하거나, 코드 디버깅과 유지보수에 더 많은 시간이 소요될 수 있습니다. 자동 포매팅을 통해 코드 스타일을 일관되게 유지하면 코드 리뷰가 간소화되고 품질 관리도 수월해집니다. 그래서 우..

이번 포스팅에서는 Harmony 서비스 상품 팀이 대규모 트래픽과 복잡한 데이터 처리를 효율적으로 관리하기 위해 CQRS(Command Query Responsibility Segregation)를 도입하고, 배포 시 발생했던 Deadlock 문제를 어떻게 해결했는지 소개하려 합니다.문제 상황: Materialized View Refresh로 인한 Deadlock과 데이터 정합성 이슈 초기에는 조회 성능을 개선하기 위해 Materialized View를 도입해 데이터를 조회했습니다. 하지만 배포 시, Materialized View를 Refresh하는 배치 작업과 마이그레이션 트랜잭션이 맞물리면서 Deadlock이 발생했습니다. 이러한 Deadlock은 배포를 지연시키고, Refresh 주기를 1분으로 ..

커머스 플랫폼 하모니 서비스 백오피스에서 상품 데이터를 엑셀로 다운로드할 수 있는 기능을 제공하고 있었습니다. 하지만, 데이터의 양이 10만 row를 넘어가는 경우 **메모리 초과(Out of Memory)**가 발생하여 서버가 다운되는 문제가 있었습니다. 이를 방지하기 위해 임시로 기능을 제한해 두었지만, 비즈니스 요구사항을 충족하기 위해 이 기능을 최적화하는 프로젝트를 맡게 되었습니다. 이번 포스팅에서는 대용량 데이터를 처리하면서도 안정적인 시스템을 유지하기 위한 최적화 과정과 적용한 기술들에 대해 소개하고자 합니다.1. 비동기적 처리로 기획 수정대량의 데이터를 동기적으로 처리하는 대신, 비동기적인 방식으로 다운로드 프로세스를 설계했습니다. 이를 위해 다음과 같은 절차를 따랐습니다:이벤트 결과 모델링..

보호되어 있는 글입니다.

보호되어 있는 글입니다.