paca94 Develop Blog

결제와 주문은 다르다 - 팀원에게 설명했던 이야기

2026-04-01T00:00:00+00:00

결제 == 주문? 외주사 코드를 인수하며 마주친 설계 문제와 팀 전체에 설명한 과정

배경

2025년 5월쯤, 현 직장에서 외주사가 개발한 서버를 인수받게 됐다. 서비스는 C2C 거래 마켓으로, 사용자가 직접 상품을 올리고 구매하는 플랫폼이다.

코드를 파악하기 시작하면서 바로 눈에 띄는 문제가 있었고, 곧바로 팀 전체에 설명했다.

문제: 결제 == 주문

외주사 코드에서 결제와 주문이 하나의 개념으로 묶여 있었다. 두 개가 별개의 테이블로 존재하긴 했지만, 주문이 결제 ID를 직접 들고 있는 구조였다. 서로 강하게 의존하고 있어서, 사실상 하나나 마찬가지였다.

언뜻 보면 “어차피 결제하면 주문 아닌가?” 싶을 수 있다. 팀원도 처음엔 그렇게 생각했다.

왜 분리해야 하는가

주문(Order) 은 구매를 확정하는 행위다. 무엇을, 얼마에, 누구에게 살지를 확정하는 것이다.

결제(Payment) 는 그 확정에 대한 대가를 지불하는 행위다. 어떤 수단으로, 얼마를, 언제 냈는지를 담는다.

둘은 일어나는 시점도 다르고, 담고 있는 정보도 다르다.

설령 비즈니스 규칙상 항상 1:1로 처리된다 하더라도, 개념 자체가 다르기 때문에 가급적 분리해야 한다고 생각한다. 주문이 취소되는 이유와 결제가 취소되는 이유는 다르다. 묶어놓으면 필요 이상으로 복잡해진다고 생각한다.

팀 전체가 알아야 한다고 생각한 이유

설명한 이유는 단순했다. 주문과 결제의 개념이 명확하게 잡혀 있지 않으면, 이후 디자인 작업에서 그 부분이 섞여 혼선이 생길 거라고 생각했다. 개발 단에서만 분리해놓고 다른 직군이 모르고 있으면, 결국 화면 흐름이나 용어가 뒤엉킨 채로 일이 진행된다.

PM과 프론트엔드 개발자는 이야기를 꺼내자마자 바로 이해했다. 디자이너에게는 조금 더 풀어서 설명이 필요했다.

쿠팡으로 설명하기

기술적인 맥락 없이도 이해할 수 있도록, 쿠팡을 예시로 들었다.

쿠팡에서 상품을 장바구니에 담는다. 그리고 “주문하기” 버튼을 누른다 — 이게 주문이다. 무엇을 사겠다는 확정.

그다음 카드로 돈을 낸다 — 이게 결제다. 그 확정에 대한 지불.

이해한 것 같긴 한데 뭔가 아리송한 대답이 돌아왔다. 그래서 반품 케이스를 추가로 붙였다.

쿠팡에서 반품 신청을 해본 적 있지 않냐. 반품 신청하면 바로 환불이 되지 않는다. 상품이 회수되고 검수가 끝난 다음에야 환불이 된다.

즉, 반품 신청은 됐지만 환불은 나중에 일어난다. 둘이 같은 개념이었다면 이런 흐름 자체가 불가능하다.

이렇게 설명하니 디자이너도 바로 이해했고, 이후 화면 설계에서도 주문 흐름과 결제 흐름을 자연스럽게 분리해서 작업해줬다.

기술적으로 더 정확한 예시(결제 실패, 가상계좌 등)도 있지만, 비개발자에게는 직접 경험해본 상황을 예시로 드는 것이 가장 빠르게 와닿는다고 생각한다.

정리

이러한 개념을 팀 전체가 공유하는 건 단순히 개발 설계의 문제가 아니라고 생각한다. 개발, 디자인, 기획이 같은 언어로 이야기할 수 있어야 불필요한 혼선 없이 일이 진행된다고 생각한다.

이번 경우엔 기술 용어 없이 일상적인 비유 하나로 충분히 전달할 수 있었다.

Python(Django) Unittest Performance 개선 (with. seeds)

2024-11-30T00:00:00+00:00

테스트가 계속해서 느려진다! 왜그럴까? (600s -> 70s)

찾아보거나 알게된 배경

테스트 개수가 더 늘어나고 있고, 테스트시간이 다시 10분씩 걸리게 되어서 개선방법을 찾아봤다.

요약

느렸던 이유는 각 테스트가 돌 때마다 고정데이터(seed data)를 insert 해서 였음. (500개의 테스트라면 500번 데이터를 삽입함)

고정 데이터의 경우, unittest fixtures 에 명시하는것이 아닌, test_runner에서 데이터베이스 초기화(setup_databases) 이후 넣으면 된다. ( db 연결을 끊기 전에 데이터를 지워줄 수 있지만, 고정데이터 이므로, 따로 설정하진 않음 )

# Example

class TestRunnerBase:
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        # test db는 항상 존재하는 상황에서 테스트가 진행되므로, keepdb는 항상 True로 해놓는다.
        self.keepdb = True

class CustomTestRunner(TestRunnerBase, runner.DiscoverRunner):
    # 아래 메서드를 override 해줬음
    def setup_databases(self, **kwargs) -> list[tuple]:
        result: list[tuple] = super().setup_databases(**kwargs)
        GlobalTestSetUpManager.run()
        return result

class CustomXMLTestRunner(TestRunnerBase, XMLTestRunner):
    # 아래 메서드를 override 해줬음
    def setup_databases(self, **kwargs) -> list[tuple]:
        result: list[tuple] = super().setup_databases(**kwargs)
        GlobalTestSetUpManager.run()
        return result

class GlobalTestSetUpManager:
    _is_seed_setup: bool = False

    # seeds 파일 내의 데이터를 불러옴
    @classmethod
    def setup_seeds(cls):
        if cls._is_seed_setup:
            return
        cls._is_seed_setup = True
        call_command(
            "loaddata",
            settings.SEEDS,
            format="json",
        )

    @classmethod
    def run(cls):
        cls.setup_seeds()

해당 개선으로 jenkins 에서 환경세팅을 제외한 테스트시간이 70초로 줄었다.

테스트 해봤던 가설

첫번째 가설: 데이터를 넣는데 시간이 오래걸린다
- setUpTestData ~ TearDown까지 걸리는 시간을 측정해봄
  - 실험을 잘못하긴 했었는데, 시간 차이가 거의 없었음
- 결론: 아님. 시간 차이가 거의 나질 않음
두번째 가설: 커넥션을 너무 자주맺어서 해당 시간이 오래걸린다
- django에서 db connection/close 를 하는 부분을 찾아서 걸린시간을 측정해봄
- 약 500회정도 커넥션을 맺고 끊었지만, 총시간은 10초도 걸리지 않았다

로컬에서 AWS 서비스 에뮬레이터를 사용해보자!

2024-11-29T00:00:00+00:00

로컬에서 사용해보자!

찾아보거나 알게된 배경

celery 테크스펙을 작성하며, DEVOPS에 리소스 요청 전에 테스트하기 위해 찾아봤다.

요약

Docker를 띄우거나, localstack을 pip으로 설치하여, 로컬에서 에뮬레이팅 할 수 있다.

awscli 명령어와 호환된다. endpoint_url을 변경하여 요청하면, localstack에서 해당 동작이 일어난다.

Command Example

$ aws --endpoint-url=http://127.0.0.1:4566 sqs get-queue-attributes --queue-url  --attribute-names All
{
    "Attributes": {
        "ApproximateNumberOfMessages": "1",
        "ApproximateNumberOfMessagesNotVisible": "0",
        "ApproximateNumberOfMessagesDelayed": "0",
        "CreatedTimestamp": "1659342190",
        "DelaySeconds": "0",
        "LastModifiedTimestamp": "1659342190",
        "MaximumMessageSize": "262144",
        "MessageRetentionPeriod": "345600",
        "QueueArn": "arn:aws:sqs:ap-northeast-2:000000000000:default.fifo",
        "ReceiveMessageWaitTimeSeconds": "0",
        "VisibilityTimeout": "1800",
        "FifoQueue": "true"
    }
}

boto3에서 endpoint_url을 설정하여, localstack에 동작시킬 수 있다.

Code Example

client = boto3.client(
    "sqs",
    aws_access_key_id="fake",
    aws_secret_access_key="fake",
    endpoint_url="",
)
client.create_queue("hello")

링크에서 어떤 서비스들에 대해 에뮬레이팅 할 수 있는지 볼 수 있다. ( + 구현 정도 )
테스트 환경에서 localstack을 활용하면, 기존에 테스트하기 힘들었던 sqs와 같은 aws service와 엮여있는 부분에 대해 테스트 할 수 있다.

아래의 내용으로 docker compose로 실행시키고 해당 url로 요청하면 된다.

version: '3.1'

services:
  localstack:
    container_name: celery-localstack
    image: localstack/localstack-full
    ports:
        - "4566-4599:4566-4599"
        - "8080:8080"
    environment:
        - DEFAULT_REGION=ap-northeast-2
        - DEBUG=1
        - START_WEB=1
        - DATA_DIR=/tmp/localstack/data
        - DOCKER_HOST=unix:///var/run/docker.sock
        - HOST_TMP_FOLDER=/tmp/localstack
        - EXTRA_CORS_ALLOWED_ORIGINS=*
    volumes:
        - ".tmp/localstack:/var/lib/localstack"
        - "/var/run/docker.sock:/var/run/docker.sock"
    network_mode: 'bridge'

참고자료

배달의민족 사용사례
- LocalStack을 활용한 Integration Test 환경 만들기 - 우아한형제들 기술블로그
로컬스택

로컬에서 DynamoDB를 써보자

2024-11-29T00:00:00+00:00

로컬에서 DynamoDB 사용해보기

찾아보거나 알게된 배경

비동기에서 데이터 저장을 DynamoDB로 할 예정이라 관련 정보를 찾아봤었다.

요약

아래 참고자료에 있는 링크로 접속하여, docker compose를 가져와서 실행한 후, endpoint_url만 변경해주면 된다.

Python Code Example

client = boto3.client(
    "dynamodb",
    aws_access_key_id="fake",
    aws_secret_access_key="fake",
    endpoint_url="",
)

AWS CLI Example

aws dynamodb describe-table --table-name=test-serverless --endpoint-url 

결과

{
    "Table": {
        "AttributeDefinitions": [
            {
                "AttributeName": "id",
                "AttributeType": "S"
            },
            {
                "AttributeName": "sort",
                "AttributeType": "S"
            }
        ],
        "TableName": "test-serverless",
        "KeySchema": [
            {
                "AttributeName": "id",
                "KeyType": "HASH"
            },
            {
                "AttributeName": "sort",
                "KeyType": "RANGE"
            }
        ],
        "TableStatus": "ACTIVE",
        "CreationDateTime": "2022-08-18T18:37:41.370000+09:00",
        "ProvisionedThroughput": {
            "LastIncreaseDateTime": "1970-01-01T09:00:00+09:00",
            "LastDecreaseDateTime": "1970-01-01T09:00:00+09:00",
            "NumberOfDecreasesToday": 0,
            "ReadCapacityUnits": 0,
            "WriteCapacityUnits": 0
        },
        "TableSizeBytes": 0,
        "ItemCount": 0,
        "TableArn": "arn:aws:dynamodb:ddblocal:000000000000:table/test-serverless",
        "BillingModeSummary": {
            "BillingMode": "PAY_PER_REQUEST",
            "LastUpdateToPayPerRequestDateTime": "2022-08-18T18:37:41.370000+09:00"
        }
    }
}

참고자료

Python Unittest Performance 개선 (with. hashlib)

2024-11-29T00:00:00+00:00

Pycharm Profile 기능을 활용하여, 유닛테스트 속도 개선

찾아보거나 알게된 배경

faker사용시, 도메인을 동일하게 설정하고, email 호출하여 랜덤 생성시, 중복되는 문제가 있어서 관련 메서드를 작성하고 있었는데, 너무 느려서 확인해봤다.

요약

테스트 데이터를 만들기 위해 UserFactory를 호출하는데, 비밀번호 생성을 위해 django.contrib.auth.hashers.make_password를 호출하고 있음.
django.contrib.auth.hashers.make_password는 내부적으로 hashlib.pbkdf2_hmac를 호출하고 있었고, 해당 메서드가 사용시간의 80%를 점유함
factory에서 필요한 상황이 아니라면, make_password를 호출하지 않도록 개선.
프로파일 결과에서 해당 메서드가 오래걸리는것을 확인

Pycharm Profile
UserFactory 에서 옵션을 통해, make_password 호출 여부를 결정할 수 있도록 개선
개선 결과 | stage | before | after | | ——- | ——- | ——— | | local | 1m33sec | 23sec | | jenkins | 11min | 8min 7sec |

Js sort ㅋㅋ

2024-11-08T00:00:00+00:00

JS sort... 네?

이직도중 W사 코테를 보던 도중, 결과를 순서대로 반환해야해서, sort를 썼었음.

일부 실패 뜨길래, 일단 다른것부터 해야해서 미뤄뒀고, 왜 그런 결과가 나오는지 시험 끝나고, GPT에 물어가며 검토하다가 알게됨.

const t= [1, 3, 13];
console.log(t.sort());
// output: [1, 13, 3]

아…. 이건 좀ㅋㅋㅋㅋㅋㅋ

MagicMock으로 호출시마다 결과를 다르게 주기 (with generator)

2024-11-03T00:00:00+00:00

generator 활용하기

찾아보거나 알게된 배경

테스트 작성하다가 알게되었다.

요약

~.side_effect에 리스트로 반환할 값들을 할당해주면 된다.

내용

만약, side_effect에 크기 2를 가진 iterator를 썼다면, 그 이후 요청부터는 StopIteration이 발생한다.

split_temp.py

class OriginAny:
    def running(self):
        return "origin_run!"

class CallingAny:
    def work(self):
        org = OriginAny()
        return org.running()

test.py

# 위 예제 수정

class TestCallingAny_work_메서드_호출시:
    @patch("split_temp.OriginAny", new_callable=AnyMock)
    def test_any(self, mock_origin_any: AnyMock):
        instance = mock_origin_any.return_value
        instance.running.side_effect = ["mock_run!", "mock_run2!"]
        calling_any = CallingAny()
        result = calling_any.work()
        result2 = calling_any.work()

        assert mock_origin_any.mock_calls == [call(), call().running(), call(), call().running()]
        assert result == "mock_run!"
        assert result == "mock_run2!"

Python은 Dict를 재활용한다

2024-11-02T00:00:00+00:00

찾아보거나 알게된 배경

dict는 언제 리사이즈될까 를 찾아보다가 함꼐 알게된 부분

요약

python 에서 dict(PyDictObject)가 삭제된다면, 해당 dict는 파이썬 내부의 free_list로 이동한다
free_list에는 최대 80(PyDict_MAXFREELIST)개까지 저장이 가능하며, 그 개수를 넘어가면 메모리를 해제한다
PyDictObject 내부의 PyDictKeysObject는 삭제된다면, 해당 데이터의 크기가 기본 사이즈일 경우, 파이썬 내부의 keys_free_list로 동한다
해당 리스트 또한 최대 80(PyDict_MAXFREELIST)개까지 저장 가능하며, 그 개수를 넘어가면 메모리를 해제한다.
free_list / keys_free_list의 경우 old gc가 돌 때 메모리에서 해제된다.

>>> d = {}
>>> id(d)
4315419008
>>> del d
>>> d2 = {}
>>> id(d2)
4315419008
>>> d3 = {}
>>> del d2
>>> del d3
>>> d4 = {}
>>> id(d4)
4315419136
>>> d5 = {}
>>> id(d5)
4315419008

instance Mock method 모킹

2024-11-02T00:00:00+00:00

객체 method 모킹하기

찾아보거나 알게된 배경

테스트 작성하다가 알게되었다.

요약

아래처럼 instance에 대해 mock으로 만들고, 테스트 인라인에서 method를 patch해주려면 아래처럼 해야한다.

내용

split_temp.py

class OriginAny:
  def running(self):
    return "origin_run!"

class CallingAny:
  def work(self):
    org = OriginAny()
    return org.running()

test.py

class AnyMock(MagicMock):
  def __init__(self, *args: any, **kw: any):
    super().__init__(*args, **kw)
    self.mock_add_spec(spec=OriginAny)

class TestCallingAny_work_메서드_호출시:
  @patch("split_temp.OriginAny", new_callable=AnyMock)
  def test_any(self, mock_origin_any: AnyMock):
    instance = mock_origin_any.return_value
    instance.running.return_value = "mock_run!"
    calling_any = CallingAny()
    result = calling_any.work()

    assert mock_origin_any.mock_calls == [call(), call().running()]
    assert result == "mock_run!"

unittest 시, 데이터는 setUpTestData에서!

2024-11-02T00:00:00+00:00

유닛테스트 퍼포먼스 약간 향상

찾아보거나 알게된 배경

테스트 러닝타임이 너무 오래걸려서, 해당 시간을 줄일 방법이 없을까 하다가 데이터를 각 테스트 method가 아닌 setUpTestData에서 만들면 되겠다 싶어서 진행해봤다.

요약

공통되는 데이터를 만들 때는 setUpTestData에서 데이터를 만들어주는게 훨씬 낫다

내용

기존에 setup이나 테스트 안에서 데이터 만들어주는 부분이 있으면, 쿼리시간때문에 테스트시간이 길어진다 가정하고 있었음
하나는 기존대로 test 내에서 각 데이터들을 만들어주게 유지
하나는 기존에서 데이터를 만들어주는 부분에 대해서 setupTestData로 빼도록 함
각 동일한 테스트에 대해 10개까지 늘린 후(복붙), 테스트 속도 비교 진행

로컬에서 실행시, 2.9s -> 1.9s 로 감소

before code:

  def test_asdf(self):
    item = generate_any_item()

after code:

  @classmethod
  def setUpTestData(cls):
    cls.item = generate_any_item()

  def test_asdf(self):
    ...

참고자료

직접해봄