스포카

RSS

게시글: 142
등록: 2026년부터

All Frontend Backend AI DevOps Architecture Etc

Backend
단지 권한 기능을 추가해달라고 했을 뿐인데(feat. 인증 기능 개선)
이 글은 키친보드 서비스의 인증 방식을 개선한 경험을 공유합니다. 기존 JWT 기반 인증 방식은 권한 변경 시 즉각적인 반영이 어렵다는 한계가 있었는데, 특히 매장 앱에 직원별 권한 관리 기능이 추가되면서 이러한 문제가 부각되었습니다. 이를 해결하기 위해 서버가 상태를 관리하는 Refresh Token을 도입하여 Access Token의 만료 시간을 짧게 유지하면서도 사용자 경험을 저해하지 않고 보안성을 강화하는 방안을 모색했습니다. Refresh Token 도입을 통해 권한 변경에 대한 즉각적인 대응과 토큰 탈취 시 보안 위험을 줄이는 것을 목표로 합니다.
인증JWTRefresh Token
스포카·2025년 4월 18일
Backend
식자재 품목 검색을 더 쉽게! 검색 엔진 도입과 개선
스포카 백엔드팀은 식자재 품목 검색 기능 개선을 위해 Elasticsearch를 도입한 경험을 공유합니다. 기존 DB의 LIKE 검색 방식은 띄어쓰기나 맞춤법 오류 시 검색 결과 누락 문제가 있었고, 이는 사용자 불편으로 이어졌습니다. 이러한 문제를 해결하고자 Elasticsearch 도입을 결정했으며, 이전 서비스의 경험을 바탕으로 POC를 진행했습니다. POC에서는 'product' 인덱스를 설정하고 'korean' 및 'korean_ngram' 분석기를 활용하여 DB LIKE 검색과 Elasticsearch 검색의 성능을 비교했습니다. 이 글은 검색 엔진 도입 초기부터 점진적인 개선 과정을 다루며, 검색 품질 향상을 위한 여정을 보여줍니다.
Elasticsearch검색 엔진DB LIKE
스포카·2025년 3월 4일
Backend
스포카의 백엔드팀에서 코딩 컨벤션을 관리하는 방법
스포카 백엔드팀은 더 나은 코드 작성과 팀 생산성 및 유지보수성 향상을 위해 코딩 컨벤션 관리의 중요성을 인식하고 이를 발전시켜왔습니다. 초기에는 README.md 파일을 통해 코딩 컨벤션을 관리했으나, 점차 문서화된 규칙이 제대로 적용되지 않거나 구식이 되는 문제에 직면했습니다. 이에 팀은 문서, 코드 리뷰, 자동화 도구를 활용하는 방식을 도입했으며, 궁극적으로 Konsist라는 새로운 도구를 도입하게 되었습니다. 이 글은 스포카 백엔드팀이 코딩 컨벤션 관리 과정에서 겪었던 시행착오와 이를 극복한 경험을 공유하며, 개발 문화 변화와 팀의 협업 효율성 증대에 기여한 여정을 담고 있습니다. 이를 통해 다른 팀에게도 적용 가능한 인사이트를 제공하고자 합니다.
코딩 컨벤션백엔드팀생산성
스포카·2024년 11월 18일
Backend
Querydsl에서 Kotlin JDSL 으로
이 글은 스포카 백엔드팀에서 Querydsl을 Kotlin JDSL로 전환한 경험을 공유합니다. Querydsl은 Kotlin에서 kapt를 필요로 하는데, kapt의 향후 지원 중단 가능성과 KSP로의 전환 어려움이 전환의 주요 배경이 되었습니다. 또한, Querydsl의 긴 배포 주기도 전환을 고려하게 만든 요인 중 하나입니다. 글에서는 전환 과정에서 겪었던 이슈와 유용한 팁들을 공유하며, Kotlin JDSL 도입의 필요성과 장점을 설명합니다. 이를 통해 다른 개발팀들이 유사한 전환을 고려할 때 참고할 수 있는 정보를 제공하고자 합니다.
QuerydslKotlin JDSLkapt
스포카·2024년 5월 3일
Backend
기능 테스트 전환 이야기
이 글은 키친보드 제품팀의 백엔드 개발자가 통합 테스트에서 기능 테스트로 전환한 경험을 공유합니다. 과거 언어 전환 시 통합 테스트를 선택했지만, 테스트 코드 작성의 어려움과 데이터 초기화 문제 등 여러 이슈를 겪었습니다. 개발팀은 테스트 코드 작성 숙련도를 높여 기능 테스트의 난이도를 감수할 수 있다고 판단, 2023년 목표로 기능 테스트 전환을 진행했습니다. 이 글에서는 통합 테스트에서 기능 테스트로 전환하게 된 배경, 전환 과정에서 겪었던 이슈들을 상세히 설명하며, 안정적인 서버 개발을 위한 테스트 전략의 중요성을 강조합니다.
기능 테스트통합 테스트테스트 코드
스포카·2023년 10월 20일
Backend
이벤트 로그 체계 구축 여정
스포카의 키친보드 서비스에서 새로운 이벤트 로그 체계를 구축한 경험을 공유하는 글입니다. 기존 로그 체계의 부족함, 분리된 문서, 디버깅의 어려움 등 배경을 설명하고, 새로운 로그 설계 과정을 상세히 다룹니다. 특히 경험이 부족한 상태에서 로그 체계를 개편하고 기존 데이터를 이전하는 과정에서 발생할 수 있는 데이터 무결성 및 기타 이슈들을 고려해야 했던 점을 강조합니다. 이 글은 이벤트 로그 설계 경험이 없거나 기존 체계를 개편하려는 개발자, 분석가들에게 실질적인 도움을 줄 수 있는 내용을 담고 있습니다.
이벤트 로그로그 체계데이터 무결성
스포카·2023년 4월 28일
Backend
청구/수납 서비스 개발기
본 글은 키친보드 서비스의 청구/수납 도메인 개발 경험을 공유합니다. 청구/수납은 식자재 유통사가 매장에 거래 대금을 청구하고 매장이 이를 납부하는 과정을 의미하며, 기존의 복잡한 방식을 개선하여 사용자 경험을 향상시키는 것을 목표로 합니다. 개발 과정에서 겪었던 다양한 고민과 이슈들을 소개하며, 특히 주문 서비스 성공 이후 다음 단계로 청구/수납 서비스의 중요성을 강조합니다. 이 서비스는 요식업 매장과 식자재 유통사를 연결하는 키친보드의 핵심 기능 중 하나로, 효율적인 거래 대금 관리 및 결제 프로세스를 제공하고자 합니다.
청구/수납 서비스키친보드개발기
스포카·2023년 2월 24일
Backend
스포카에서 Kotlin으로 JPA Entity를 정의하는 방법
이 글은 스포카에서 Kotlin으로 JPA Entity를 정의할 때 발생하는 문제점과 해결 방안을 다룹니다. Kotlin은 불변성을 지향하지만, JPA는 Java 기반으로 설계되어 가변 프로퍼티 사용에 초점을 맞추고 있습니다. 이로 인해 Kotlin의 언어적 특성과 JPA의 설계 방식 간의 충돌이 발생할 수 있습니다. 글에서는 이러한 안티 패턴 사례를 소개하고, JPA 규격을 준수하면서도 Kotlin의 개발 철학에 맞게 Entity를 작성하는 방법을 모색합니다. 특히, 무분별한 가변 프로퍼티 사용의 문제점을 지적하며, 도메인 모델로서 Entity의 중요성을 강조하고 있습니다.
KotlinJPAEntity
스포카·2022년 8월 16일
Backend
우당탕탕 주문서 개발기
키친보드 팀의 백엔드 개발자가 서비스의 주문서 도메인 개발 경험을 공유하는 글입니다. 요식업 매장과 식자재 납품 거래처를 연결하는 서비스에서, 매장이 거래처에 식자재를 주문하고 거래처가 이를 처리하는 과정을 지원하는 주문서 기능 개발에 대한 내용을 다룹니다. 주문서 접수, 수정, 취소, 조회 등 다양한 유저 스토리를 정의하고, 주문서의 생명주기 다이어그램을 통해 개발 과정에서 겪었던 고민과 이슈들을 설명합니다. 특히 동시성 제어와 같은 복잡한 문제 해결 과정에 대한 인사이트를 제공하며, 백엔드 개발 관점에서 주문서 도메인 설계의 중요성을 강조합니다.
주문서 도메인백엔드 개발유저 스토리
스포카·2022년 7월 8일
Backend
서버 언어 전환 이야기
스포카 키친보드 팀에서 서비스 서버 언어를 Python에서 다른 언어로 전환한 경험을 공유하는 글입니다. 팀 내 Python 및 관련 프레임워크에 대한 높은 이해도를 가진 인력이 부족하고, 동적 타입 언어인 Python의 유지보수성 한계를 느껴 언어 전환을 결정했습니다. 언어 전환에 드는 시간과 노력이 장기적으로 팀의 생산성과 제품 품질 향상으로 이어질 것이라는 판단 하에 진행되었으며, 이는 더 나은 서비스를 제공하기 위한 팀의 노력의 일환입니다.
서버언어 전환Python
스포카·2022년 4월 15일
Backend
Flask, marshmallow, apispec으로 API 문서화 자동화하기
이 글은 Flask 웹 프레임워크에서 marshmallow와 apispec 라이브러리를 활용하여 OpenAPI 3.0 명세 기반의 API 문서를 자동화하는 경험을 공유합니다. 과거 풀스택 개발 문화에서 별도의 API 문서가 없었던 스포카는 개발자 분업화에 따라 프론트엔드와 백엔드 개발자 간의 효율적인 소통을 위해 고도화된 API 문서의 필요성을 느꼈습니다. 필자는 OpenAPI Specification(OAS)을 활용하여 API 문서 작성의 효율성을 높이는 방법을 모색했으며, marshmallow를 통해 데이터 유효성 검증 스키마를 정의하고 apispec을 사용하여 이를 기반으로 OpenAPI 문서를 자동으로 생성하는 과정을 설명합니다. 이를 통해 API 문서의 일관성을 유지하고 개발 생산성을 향상시킬 수 있습니다.
Flaskmarshmallowapispec
스포카·2021년 3월 23일
Backend
안드로이드 앱에 Koin으로 DI 적용하기
본 글은 스포카의 안드로이드 앱 '키친보드'에 Koin을 활용하여 의존성 주입(DI)을 적용한 사례를 공유합니다. 기존에는 싱글톤 객체 내부에 서버 클라이언트 코드와 세션 정보가 혼재되어 의존성이 높아지고 가독성이 떨어지는 문제가 있었습니다. DI를 도입하여 `CartRepository` 내부의 코드를 분리하고 각 모듈을 주입받는 방식으로 리팩토링함으로써, 객체 간의 결합도를 낮추고 코드의 재사용성과 테스트 용이성을 높였습니다. DI는 클래스 내부에서 객체를 직접 생성하는 대신 외부에서 생성하여 주입하는 방식으로, 이를 통해 앱 아키텍처의 견고함을 더하고 유지보수성을 향상시킬 수 있습니다.
KoinDIDependency Injection
스포카·2020년 11월 2일
Backend
파이썬 의존성 관리자 Poetry 사용기
이 글은 파이썬의 의존성 관리 도구인 Poetry를 소개하고, 기존의 pip와 비교하며 Poetry의 장점을 설명합니다. 의존성 관리자의 개념과 필요성을 설명한 후, pip의 한계점, 특히 의존성 충돌 해결의 어려움을 지적합니다. Poetry는 이러한 문제를 해결하고 프로젝트의 의존성을 명확하게 관리하며, 패키지 빌드 및 배포까지 지원하는 통합적인 솔루션임을 강조합니다. 이를 통해 개발자는 더 효율적이고 안정적인 파이썬 프로젝트 관리가 가능해집니다.
PoetryPython의존성 관리
스포카·2019년 8월 9일
Backend
파이썬의 시간대에 대해 알아보기(datetime.timezone)
이 글은 파이썬에서 시간대를 올바르게 처리하는 것의 중요성을 강조하며, 특히 `datetime.datetime` 객체 사용 시 발생할 수 있는 혼란을 설명합니다. 저자는 Google Calendar API 연동 중 시간대 미지정으로 인해 발생한 문제를 예시로 들며, 명시적인 시간대 설정이 왜 필요한지 보여줍니다. 시간대가 지정되지 않은 시각은 모호하며, 의도치 않은 시간대로 해석될 수 있어 예상치 못한 결과를 초래할 수 있습니다. 글에서는 대한민국 시간대(KST)와 UTC를 비교하며, `datetime.timezone`을 사용하여 시간대 정보를 명확히 지정하는 방법을 제시합니다. 이를 통해 국제화 서비스를 제공하는 프로덕트에서 시간 관련 오류를 방지하고 정확한 데이터 처리를 보장하는 방법을 다룹니다.
Pythondatetimetimezone
스포카·2019년 2월 15일
Backend
SQLAlchemy의 연결 풀링 이해하기
이 글은 파이썬 데이터베이스 툴킷인 SQLAlchemy의 핵심 기능 중 하나인 연결 풀링(Connection Pooling)에 대해 설명합니다. 연결 풀링은 데이터베이스 연결을 캐싱하여 빈번한 연결 생성 및 종료 비용을 줄이는 기법으로, 특히 웹 서비스와 같이 짧은 요청이 자주 발생하는 환경에 유용합니다. SQLAlchemy의 기본 풀인 큐 풀(QueuePool)의 작동 방식과 생애주기를 상세히 다루며, 연결이 생성되고 관리되는 과정을 단계별로 설명합니다. 또한, `pool_size`와 `max_overflow` 설정값의 중요성을 강조하며, 서비스 규모에 따라 적절한 설정을 통해 성능을 최적화하는 방안을 제시합니다.
SQLAlchemy연결 풀링데이터베이스
스포카·2018년 1월 17일
Backend
파이썬의 개발 “환경”(env) 도구들
이 글은 파이썬 개발 환경 구성에 사용되는 다양한 도구들의 필요성과 활용 지침을 제안합니다. 과거 라이브러리 배포 방식부터 시작하여 sys.path와 PYTHONPATH 환경 변수의 활용, 그리고 site-packages 디렉터리의 등장까지 파이썬 패키징 생태계의 역사적 흐름을 간략하게 설명합니다. 이를 바탕으로 virtualenv, pyvenv, virtualenvwrapper와 같은 가상 환경 도구들이 왜 필요한지 이해를 돕고, 각자의 개발 환경에 맞는 도구를 선택하는 데 도움을 주고자 합니다. 궁극적으로는 파이썬 개발자들이 보다 효율적으로 프로젝트 환경을 관리할 수 있도록 안내하는 것을 목표로 합니다.
Pythonvirtualenvpyvenv
스포카·2017년 10월 6일
Backend
도도 테이블 101
이 글은 스포카의 사내 라이브러리인 '도도 테이블'을 소개합니다. 도도 테이블은 Python의 ORM인 SQLAlchemy에서 가져온 검색 결과를 HTML 테이블 태그로 쉽게 변환해주는 라이브러리입니다. 기존에 사용하던 jQuery 플러그인 방식의 라이브러리는 비동기 통신 시 URL이 변경되지 않아 브라우저의 뒤로가기/앞으로가기 기능 사용 불가, 특정 페이지 정보 공유의 어려움 등의 단점이 있었습니다. 이러한 문제를 해결하기 위해 SQLAlchemy 모델 구조와 테이블 구조를 활용하여 URL이 보존되고 정보 공유가 용이한 도도 테이블을 개발하게 된 배경과 필요성을 설명합니다.
PythonSQLAlchemyORM
스포카·2017년 2월 17일
Backend
flake8-import-order-spoqa
이 글은 스포카에서 파이썬 코드의 임포트 스타일을 관리하기 위해 사용했던 `flake8-import-order`라는 린트 도구에 대해 소개합니다. 기존에 사용하던 `import-order` 도구의 한계를 극복하고, 사실상의 표준이 된 `flake8-import-order`를 도입하는 과정에서 겪었던 문제점과 해결 방안을 다룹니다. 특히, 스포카의 자체적인 임포트 스타일을 유지하면서 `flake8-import-order`를 활용하기 위해 프로젝트를 포크하여 커스터마이징하는 방안을 모색합니다. 이를 통해 코드 스타일의 일관성을 유지하고 개발 생산성을 향상시키고자 하는 스포카의 노력을 엿볼 수 있습니다.
Pythonflake8import-order
스포카·2017년 2월 12일
Backend
CTE for postgresql and sqlalchemy
이 글은 PostgreSQL의 CTE(Common Table Expression)와 SQLAlchemy를 활용한 변환 예제를 다룹니다. CTE는 WITH 절을 사용하여 SELECT 문에서 테이블 식을 효과적으로 정의하는 기능으로, VIEW보다 편리하며 쿼리 지속 시간 동안만 존재합니다. 특히 재귀 CTE는 조직 구조와 같이 계층적인 데이터를 다룰 때 유용하며, 'WITH RECURSIVE' 키워드를 사용하여 구현됩니다. 글에서는 PostgreSQL의 CTE 예제와 이를 SQLAlchemy Core로 변환하는 과정을 설명하며, 데이터베이스 쿼리 작성의 효율성을 높이는 방법을 제시합니다.
PostgreSQLSQLCTE
스포카·2013년 8월 21일
Backend
RESTful API를 설계하기 위한 디자인 팁
이 글은 RESTful API 설계를 위한 추가적인 디자인 팁을 제공합니다. 컬렉션 리소스와 단수 명사로 표현되는 도큐먼트 리소스의 차이를 설명하고, URI에서 계층 구조를 표현하는 방법을 보여줍니다. 또한, Content-Type 헤더를 활용하여 요청에 맞는 응답 형식을 제공하는 것의 중요성을 강조하며, URI에 파일 확장자를 포함하지 않는 것이 좋다는 점을 설명합니다. 이를 통해 RESTful API의 가독성과 유연성을 높이는 방법을 다룹니다.
RESTful APIAPI 설계HTTP 헤더
스포카·2013년 6월 11일