Info-Tech

[실전 예제로 보는 Race Condition] 중복 보상 지급, 어떻게 막을까?

개발 로그를 쌓고 싶은 블로거 — Mon, 17 Mar 2025 14:54:43 +0900

Race Condition이란?

Race Condition(경쟁 상태)은 둘 이상의 프로세스나 스레드가 동시에 공통 자원에 접근할 때, 실행 순서에 따라 결과가 달라지는 상황입니다.
쉽게 말해, 누가 먼저 처리하느냐의 '경쟁' 상태에서 발생하는 버그로, 특히 데이터 무결성이 중요한 서비스에서 치명적일 수 있습니다.

REST API에서 Race Condition?

REST API에서도 동시 요청이 들어와 동일 리소스를 처리할 때, 순서가 꼬이면 의도치 않은 결과가 발생할 수 있습니다.
예) 중복 결제, 포인트 중복 지급, 중복 예약 등이 대표적인 사례입니다.

실전 예시 – 미션 완료 후 보상 지급

상황 설명

사용자가 미션 완료 후 보상 지급 요청을 보내는 API가 있습니다.
정상적으로는 1회만 지급돼야 하지만, 동시 요청이 발생하면 어떻게 될까요?

API Endpoint (예시용):
POST /api/v1/missions/complete
Request Body:
{"type":"investment_complete"}

서버 처리 흐름 (예시 코드)

1. API View

@router.post('/missions/complete', auth=AuthBearer())
def complete_mission(request, request_data: MissionCompleteRequest):
    user = user_repo.get_by_id(request.user_id)
    mission_service.complete(user, request_data.type)
    return {"result": "success"}

2. 비즈니스 로직

def complete(self, user: User, mission_type: str):
    mission = self.get_mission_by_type(mission_type)
    
    if not mission:
        raise ValueError("미션 정보 없음")

    if self.is_already_completed(user.id, mission_type):
        raise ConflictError("이미 완료된 미션입니다.")

    with transaction.atomic():
        # 완료 기록 저장
        self.log_repository.add_completion(user.id, mission.id)

        # 보상 지급
        if mission.reward_type == "point":
            user.add_points(mission.reward_amount)
        elif mission.reward_type == "credit":
            self.credit_service.grant(user.id, mission.reward_amount)
        else:
            raise ValueError("알 수 없는 리워드 타입")

정상 요청 흐름

단일 요청 시 정상적으로 보상 지급 후 완료 처리됩니다.

[Client]  → POST /missions/complete  → [Server] 200 OK

같은 요청을 다시 보내면, 이미 완료된 상태이므로 오류 반환:

[Client]  → POST /missions/complete  → [Server] 409 Conflict ("이미 완료된 미션입니다.")

비정상 요청 흐름 (Race Condition 발생)

악의적 사용자 또는 실수로 동시에 여러 요청을 보내면?

시나리오

[Client]  → 30개의 동시 요청 발생
   ↓
[Server]  → 중복 요청 모두 처리됨
   ↓
보상 30회 지급

테스트 스크립트 (예시)

간단한 Python 스크립트를 통해 동시 요청 테스트를 할 수 있습니다.

from concurrent.futures import ThreadPoolExecutor
import requests

def send_request():
    headers = {
        "Authorization": "Bearer <token>",
        "Content-Type": "application/json"
    }
    payload = {"type": "investment_complete"}
    response = requests.post("http://localhost:8000/api/v1/missions/complete", json=payload, headers=headers)
    print(f"Response: {response.status_code}")

if __name__ == "__main__":
    with ThreadPoolExecutor(max_workers=30) as executor:
        for _ in range(30):
            executor.submit(send_request)

결과

요청 30회 중 모두 200 OK 응답, 보상 30회 지급 → Race Condition 발생.

Race Condition 방지법

1. Redis Lock 사용

분산 락 메커니즘을 통해 하나의 요청만 처리하도록 제어합니다.

import redis
import redis_lock

redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)

def complete(self, user: User, mission_type: str):
    lock = redis_lock.Lock(redis_client, f"lock:mission:{user.id}:{mission_type}")
    
    with lock:
        if self.is_already_completed(user.id, mission_type):
            raise ConflictError("이미 완료됨")
        ...

2. 데이터베이스 락 (select_for_update)

DB 수준에서 레코드 락을 걸어 동시 처리 방지.

from django.db import transaction

def complete(self, user: User, mission_type: str):
    with transaction.atomic():
        user = User.objects.select_for_update().get(id=user.id)
        
        if self.is_already_completed(user.id, mission_type):
            raise ConflictError("이미 완료됨")
        ...

3. 단순 트랜잭션 (불충분할 수 있음)

트랜잭션만 사용할 경우, 완전한 Race Condition 방지 어렵습니다.

from django.db import transaction

def complete(self, user: User, mission_type: str):
    with transaction.atomic():
        if self.is_already_completed(user.id, mission_type):
            raise ConflictError("이미 완료됨")
        ...

마무리

실제 서비스에서는 Race Condition으로 인해 데이터 오류, 과금 문제 등이 발생할 수 있습니다.
특히 포인트/현금과 관련된 로직에서는 반드시 동시성 처리를 고려해야 합니다.
Redis 락, DB 락 등 상황에 맞는 방식을 선택해 안정적인 서비스 운영을 해봅시다!

참고

테스트 도구로는 Locust, JMeter, 간단한 Python 멀티스레드 활용 가능.
Redis 락 구현 시, 락 타임아웃 설정도 함께 고려하면 더 안전합니다.

정리 포인트

Race Condition은 실제 서비스에서 빈번히 발생
특히 보상, 결제, 예약 등 한정 리소스 처리에서 중요
상황에 맞는 락 메커니즘으로 미리 방지 → 나중에 고통 줄이기!

검색엔진 도입기와 인간 뉴렐릭 시절 회고

개발 로그를 쌓고 싶은 블로거 — Sun, 16 Mar 2025 17:55:01 +0900

– Elasticsearch, Haystack, 그리고 htop으로 버텨낸 그 시절 이야기

시작하며

지금이야 Sentry, Datadog, CloudWatch 같은 모니터링 툴 없으면 불안해서 서버 못 만지지만,
그때는 2017년. 그런 거 잘 안 쓰던 시절이었다. 서버 상태는 감으로 느끼고, 장애는 몸으로 겪었다.

그 시절, 나는 모니터링 시스템이자 에러 알림 툴,
그야말로 인간 뉴렐릭이었다.

이 글은 내가 검색 성능 때문에 Elasticsearch를 도입하면서 겪은 삽질과,
서버가 터질 때마다 htop으로 위기 넘긴 그 시절, 2017년 이야기다.

검색 성능 터지기 직전

참고로 당시 내가 담당했던 서비스는 해당 블로그 에서 확인이 가능하다.
지금은 사라졌지만, 그 시절엔 실제 사용자도 많았고 트래픽도 꽤 됐다.
상품도 100만 건 넘게 등록돼 있어서, 검색 한 번 누르면 서버가 한숨 쉬는 상황이었다.

당시 운영하던 서비스에서 상품 수가 100만 건을 넘기면서 검색이 슬슬 버벅대기 시작했다.

상품 검색 속도가 눈에 띄게 느려졌고,
연관 검색은 아예 못 보여주고 있었음.

예를 들어, 유저가 "빨간 원피스" 검색하면
red, 빨강, 붉은 등도 함께 검색돼야 했는데,
ORM으로 OR 조건 조합해서 쿼리 짜는 건 한계가 있었고,
속도도 느리고 검색 결과도 부정확했다.

그때 처음으로 "이건 ORM으로 해결할 게 아니다" 라는 걸 느꼈다.

검색엔진을 알아보다

검색 성능 이슈를 해결하려고 검색엔진 도입을 고민했다.
지금처럼 Elasticsearch가 당연한 선택지는 아니었고,
그냥 검색엔진이라는 단어조차 익숙하지 않았다.

당시 알아봤던 건 대충 이 3가지였다.

1. elasticsearch-py

공식 Python 클라이언트인데, 너무 로우레벨이라
직접 쿼리 짜고 통신 처리해야 해서 조금 버거웠다.

2. AWS Elasticsearch

지금은 OpenSearch로 바뀌었지만,
그때는 비용이 부담스럽기도 했고,
기능 제약도 있어서 패스.

3. Django Haystack + Elasticsearch

이건 Django ORM처럼 검색을 다룰 수 있어서
처음 도입할 때 편할 것 같았다.

결국 Haystack 선택

결국 Haystack을 선택했다.
검색엔진 경험도 없었고, 일단 익숙한 Django 스타일로
시작하는 게 맞다고 판단했다.

Django 모델인 Product 기반으로
search_indexes.py에 인덱스 정의
Elasticsearch랑 연동해서 검색 처리

여기까지는 괜찮았다.
문제는 인덱싱 작업에서 터졌다.

rebuild_index, 그리고 서버 다운

Haystack에는 rebuild_index라는 명령어가 있다.
검색 인덱스를 밀고 새로 쌓는 작업이다.
쉽게 말하면 기존 걸 다 날리고,
전체 데이터를 로드해서 다시 Elasticsearch에 보내는 작업.

문제는, 이걸 돌리자마자 서버가 터졌다.

전체 데이터를 메모리에 올리면서 OOM(Out of Memory) 발생
DB I/O도 많고, Elasticsearch로 bulk 요청이 미친 듯이 나감
근데 문제는 이걸 서버랑 Elasticsearch가 같은 EC2 인스턴스에서 돌리고 있었다는 거

결국 서버 자체가 멈춤. SSH 접속도 안 됨. 공포.

모니터링은 htop으로

당시엔 Sentry도 없고, CloudWatch 알람 같은 것도 안 썼다.
서버 이상하면 그냥 직접 SSH 접속해서 htop 켰다.

ssh ubuntu@서버아이피
htop

딱 보면 메모리, CPU 사용률 다 나옴.

CPU: 98%
MEM: 91%
Swap: 40%

Elasticsearch가 메모리를 다 먹고 있었음.
바로 F9 → 9 (Kill)로 죽이고 다시 띄움.
이게 그때 내가 하던 모니터링의 전부였다.

그래도 해결은 해야 하니까

서버 죽어나가니까 방법을 찾아야 했다.
찾아보니 rebuild_index 명령어에
--batch-size 옵션이 있다는 걸 발견.

이걸로 한 번에 인덱싱하는 양을 줄이니까
서버가 버틸 수 있었고, 시간은 오래 걸렸지만
어쨌든 서버 다운 없이 인덱싱 성공.

지금 생각하면

지금은 Datadog, Sentry, CloudWatch 알람으로
서버 상태 실시간으로 확인하고,
에러는 Slack으로 실시간 알림 받는다.

근데 그때는 진짜 나 자신이 모니터링 툴이었다.
서버 이상한지 감으로 느끼고, htop으로 실시간 확인하고,
직접 문제 찾아서 고치던 그 시절.

정리

그때 경험하면서 느낀 건:

검색엔진 도입은 단순히 라이브러리 추가하는 게 아니라 구조 설계까지 고려해야 한다.
서버 자원, 인덱싱 전략, 데이터 양 다 포함해서 계획해야 한다.
그리고 진짜 모니터링 툴은 필수다. 감으로는 못 버틴다.

마무리

지금 돌아보면 진짜 고생했지만,
덕분에 실전에서 많이 배운 프로젝트였다.
그리고 서버가 터질 때마다
htop과 함께 했던 그 시절,
나는 진짜로 인간 뉴렐릭이었다.

개발자가 비즈니스적 고민도 필요할까?(2)

개발 로그를 쌓고 싶은 블로거 — Sat, 24 Feb 2024 20:18:31 +0900

나무를 넘어서 숲을 봐야하는 이유

과거에 필자는 코드를 보다 깔끔하고 우아하게 작성하려는 노력의 일환으로, DDD(도메인 주도 설계)와 클린 아키텍처(Clean Architecture)에 관한 자료들을 크롬 탭에 수십 개 열어놓고, 단 한 줄의 코드를 작성하기 위해 몇 시간을 할애한 적이 있다. 이 글을 읽는 많은 개발자분들 역시 필자와 유사한 경험을 하셨을 것이라 생각한다.

필자는 깔끔하고 완벽한 코드를 작성하기 위한 노력하다가 프로젝트를 기한 내에 완수하지 못하게 한 경험이 있다. 이러한 경험을 통해, 단순히 코딩(나무)에만 집중하는 것이 아니라, 코딩+α(숲)를 고려하는 관점에서 사고하는 것이 중요함을 깨달았다.

개발자로서 앞으로 발생할 수 있는 상황을 고려하여 유지보수가 쉽고 확장성 있는 설계를 기반으로 코딩하는 것은 중요하다. 하지만, 숲을 보는 관점에서 벗어나 코딩 중심적인 관점만을 생각하기보다는 비즈니스 및 기술적 요구 사항의 중요성을 인식하고, 균형 있는 우선순위를 설정하는 것이 더욱 중요하다고 생각된다.

그러면 나무만 보고 숲을 못봤을 때 어떤 문제가 뒤따를까? 예시로 영화"콰이강의 다리"를 통해서 확인해보자.

영화 "콰이강의 다리" 줄거리

제 2차 세계 대전 당시, 영국군 장교인 니콜슨 대령과 그의 부하들은 일본군에게 포로로 잡혀 콰이강 근처의 포로 수용소로 끌려가게 되었다.

포로 수용소에서 일본군 지휘관인 사이토 대령은 포로들에게 콰이강을 가로지르는 철도 다리를 만들라는 명령을 내렸고, 처음에는 명령에 불복했지만, 니콜슨 대령은 부하들의 사기와 영국군의 명예를 위해 다리 건설에 동의하게 되었다.
니콜슨은 다리가 일본군에게 전략적으로 유리하게 작용할 수 있다는 사실을 알면서도 다리를 완성하는 데에만 집중했다.

얼마 후, 미국 특공대가 포로들을 구하기 위해 콰이강에 진입했고, 특공대는 다리에 폭탄을 설치했지만, 다리에 강한 집착을 보이던 니콜슨 대령은 판단력을 잃어버리고 특공대원들을 막으려 했다. 그러나 결국 특공대는 일본군에게 발각되어 모두 사살되었고, 니콜슨 대령은 포격에 의한 파편을 맞고 다리에 설치된 기폭제 위로 쓰러지면서 다리를 폭파시켰다.

"콰이강의 다리 실수" (a.k.a 숲을 지나치고 나무만 본 경우)

"콰이강의 다리" 문제에서, 니콜슨은 다리 건설이라는 구체적인 과제에만 몰두하여, 그것이 전쟁의 전체적인 맥락에서 어떤 의미를 가지는지를 잊어버린다. 다시말해, 그는 자신의 임무와 기술적인 도전에 성공하는 것에만 집중하다가 그의 노력이 실제로는 적에게 이익을 주고 있다는 사실을 간과하게 된다.

나무 = 다리 건설이라는 구체적인 과제에만 몰두
숲 = 다리가 전쟁의 전체적인 맥락에서 어떤 의미를 가지는지를 잊어버림

이러한 상황은 소프트웨어 개발에서도 발생할 수 있다. 개발자나 팀이 프로젝트의 본래 목적이나 목표를 잊고, 기술적인 도전이나 복잡성에 매몰되어 프로젝트가 본래 해결하려고 했던 문제를 간과하게 되는 경우이다. 예를 들면 아래와 같다.

1. 목표에서 벗어남: 개발자가 프로젝트의 궁극적인 목표나 사용자의 필요를 무시하고, 기술적인 완성도나 개인적인 성취에만 집중하는 경우
2. Over-engineering: 프로젝트에 필요 이상으로 복잡하거나 고급 기술을 사용하여, 결과적으로 유지보수나 확장성에 문제를 일으키는 경우
3. 프로젝트 관리 실패: 명확한 우선순위나 목표 설정 없이 프로젝트를 진행하며, 자원이나 시간을 낭비하는 경우

위의 문제는 기술적인 성취에만 초점을 맞추고, 그 과정에서 본래의 목적이나 더 큰 가치를 간과하는 상황을 의미한다. 이는 개발자 뿐만 아니라 다양한 분야에서 일하는 사람들이 경계해야 할 일반적인 함정이다. 프로젝트의 비즈니스적 가치와 궁극적인 목적에 대한 인식을 잃지 않기 위해서는, 개발자들이 정기적으로 자신의 작업을 평가하고 전체적인 관점에서 프로젝트를 바라볼 필요가 있다.

숲을 보기 위한 자신만의 원칙을 세워보자.

나무도 중요하지만, 전체적인 숲을 보기 위한 원칙을 하나쯤 만들면 어떨까? 이미 무수한 방법들이 있지만, 필자는 아래와 같은 방법들로 숲을 보기 위해 노력한다.

1. 정기적인 목표 재평가: 프로젝트의 진행 상황을 정기적으로 검토하고, 목표가 여전히 유효한지, 혹은 조정이 필요한지 평가한다.

2. 사용자 중심 설계: 사용자의 필요와 경험을 중심으로 생각하며, 기술적인 결정을 내린다.

3. 팀 내 커뮤니케이션 강화: 다양한 배경을 가진 팀원들과의 지속적인 소통을 통해 다양한 관점을 수렴하고, 프로젝트의 목표에 대한 공통된 이해를 구축한다.

4. 단계별 목표 설정: 큰 목표를 달성하기 위한 구체적이고 달성 가능한 단계별 목표를 설정하여, 전체적인 목표에서 벗어나지 않도록 한다.

5. 피드백 반영: 사용자와 이해관계자로부터의 피드백을 정기적으로 수집하고 반영하여, 프로젝트가 올바른 방향으로 나아가고 있는지 확확인한다. 이러한 접근 방식을 통해 개발자는 기술적인 세부 사항에만 몰두하는 것이 아니라, 프로젝트의 더 큰 비즈니스적 가치와 목적을 지속적으로 염두한다.

이러한 접근 방식을 통해 필자는 기술적인 세부 사항에만 몰두하는 것이 아니라, 프로젝트의 더 큰 비즈니스적 가치와 목적을 지속적으로 생각는 습관을 만들기 위해 노력한다.

마치며

"나무를 보지 말고 숲을 봐야 한다"는 교훈은 개발자와 더불어 프로젝트를 같이 진행하는 모두에게 중요하다. 우리가 작업하는 개별적인 요소나 기술적인 세부 사항에만 집중하는 대신, 프로젝트의 궁극적인 목적과 사용자의 필요를 계속 염두에 두어야 한다는 것을 상기시켜야 한다.

프로젝트가 전체적으로 어떤 비즈니스적 가치를 창출하는지, 그리고 그것이 사용자나 사회에 어떤 영향을 미치는지를 이해하는 것이 중요하다. 이러한 관점은 더 효율적이고 사용자 중심적인 비즈니스를 개발하는 데 도움이 될 것이라 확신한다.

개발자가 비즈니스적 고민도 필요할까? (1)

개발 로그를 쌓고 싶은 블로거 — Mon, 12 Feb 2024 02:05:28 +0900

당신은 방망이 깎는 노인이신가요?

수필 "방망이 깎는 노인"의 스토리는 대략적으로 이렇다.

동대문 맞은편 길가에 앉아서 방망이를 깎아 파는 노인이 있었다.
방망이를 한 벌 사 가지고 가려고 깎아 달라고 부탁을 했다. 값을 굉장히 비싸게 부르는 것 같았다.

나: "좀 싸게 해 줄 수 없습니까?"

노인: "방망이 하나 가지고 에누리하겠소? 비싸거든 다른 데 가 사우."

대단히 무뚝뚝한 노인이었다. 값을 흥정하지도 못하고 잘 깎아나 달라고만 부탁했다. 그는 잠자코 열심히 깎고 있었다.
처음에는 빨리 깎는 것 같더니, 저물도록 이리 돌려 보고 저리 돌려 보고 굼뜨기 시작하더니, 마냥 늑장이다.
내가 보기에는 그만하면 다 됐는데, 자꾸만 더 깎고 있었다. 인제 다 됐으니 그냥 달라고 해도 통 못 들은 척 대꾸가 없다.
타야 할 차 시간이 빠듯해 왔다. 갑갑하고 지루하고 초조할 지경이었다.

나: "더 깎지 않아도 좋으니 그만 주십시오."

노인: "끓을 만큼 끓어야 밥이 되지, 생쌀이 재촉한다고 밥이 되나."

나: "살 사람이 좋다는데 무얼 더 깎는다는 말이오? 노인장, 외고집이시구먼. 차시간이 없다니까요."

노인: "다른 데 가서 사우. 난 안 팔겠소."

나: "그럼, 마음대로 깎아 보시오."

노인: "글쎄, 재촉을 하면 점점 거칠고 늦어진다니까. 물건이란 제대로 만들어야지, 깎다가 놓치면 되나."

.. 중략 .. 어쨌든 기다려서 방망이를 샀고 집에 가져갔더니 잘 만들었다 카더라 라는 내용

위의 내용은 이렇다. 고객이 물건을 사야하는데 장인정신으로 제품을 만드는 노인으로 인해 시간이 지체되었고, 오랜 기다림을 통해 얻은 제품(방망이)은 매우 만족스러웠다.

이 수필을 지은 작가의 교훈은 '무슨 일이든, 장인정신(=자기만의 확고한 신념)을 가지고 한다면 좋은 결과를 얻을 것이다' 이다.

만약, 개발자가 방망이를 깎는 노인이라면?

서울의 한 사무실 좋은 의자에 앉아서 개발만 주구장장 하는 개발자가 있었다.

고객: "그 기능 언제 출시하시나요?"

개발자: "기능 하나 가지고 배포하겠소? 정교한 코드설계를 하는중이에요. 기다리세요"

대단히 무뚝뚝한 개발자였다. 그는 잠자코 열심히 개발하고 있었다. 처음에는 빨리 코딩하는 것 같더니, 저물도록 이리 돌려 보고 저리 돌려 보고 굼뜨기 시작하더니, 마냥 늑장이다. 내가 보기에는 그만하면 다 됐는데, 자꾸만 더 개발하고 있었다.
인제 다 됐으니 그냥 출시하라고 해도 통 못 들은 척 대꾸가 없다. 갑갑하고 지루하고 초조할 지경이었다.

고객: "더 하지 않아도 좋으니 그만 주십시오."

개발자: "끓을 만큼 끓어야 밥이 되지, 생쌀이 재촉한다고 밥이 되나."

고객: "살 사람이 좋다는데 무얼 더 개발한다는 말이오? 개발자님, 외고집이시구먼. 시간이 없다니까요."

개발자: "글쎄, 재촉을 하면 점점 거칠고 늦어진다니까. 물건이란 제대로 만들어야지, 깎다가 놓치면 되나."

장인정신은 개발자에게 필요한 중요한 덕목이다. 정확한 설계를 통해 코딩을 하고, 레거시 코드를 줄이며 제품의 코드 품질을 향상시키는 것은 매우 중요하다. 이는 빠른 개발 속도를 유지하고 다른 제품을 개발 할때 확장을 위한 도움을 준다.

하지만 위와 같이 개발자가 장인정신으로 방망이만 깎고 있다면 현실에서는 잠재 고객을 잃게 될 것이다. 현실 속 고객은 인내심이 길지 않기 때문이다. 개발자가 정성스럽게 설계한 제품을 이해해주지 않을 뿐더러 아마도 옆 업체에서 먼저 만든 비슷한 방망이를 구매해서 쓸 것이다.

그렇다면 장인정신을 포기해야 할까?

마치 위의 글에서는 고객의 만족이나 사업의 성장을 위해 장인정신을 포기하라는 것처럼 들릴 수 있다. 하지만 정확히는 아니다.

결국 좋은 장인이란, 개발자로서의 역할을 충실히 하고 고객도 생각하는 비즈니스 마인드를 포함 해야한다.

비즈니스적으로 생각을 한다는것 = 고객의 관점에서 생각해보는 것

개발자는 개발만 잘하면 되는거 아니에요?

네, 아닙니다. 라고 답변해주고 싶다.

우리가 회사에 소속되어 개발을 하는 이유는 우리가 지닌 개발 역량을 통해 제품을 만들고, 이익을 창출 하는 것이다

위에서 말한 장인정신이 투철한 노인은 단순히 물건을 만들기만 할 뿐 제때 못팔 수 있다. 이러한 개발자가 되지 않기 위해 개발능력 이외에도 사용자 만족도나 회사의 비즈니스 목표 등 여러 요소를 고려해야 한다. 따라서 회사에는 단순히 프로그래밍이 뛰어난 개발자보다 프로그래밍 능력을 통해 고객을 만족시키고, 이로 인해 발생하는 매출을 창출 할 수 있는 개발자가 필요하다.

이러한 이유로 많은 회사에서는 개발적 역량 외에도 협업 능력이나 커뮤니케이션, 오너십, 리더십 등을 개발자에게 요구한다. 어떻게 보면 당연한 얘기들이다. 이런 능력들은 회사에 당장 수익을 창출하지 않더라도, 장기적인 관점에서 회사의 문화와 조직의 전반적인 성과에 긍정적인 영향을 미치기 때문이다.

결국, 개발자는 자신이 속한 조직의 제품이 시장에서 성공을 거두기 위해 노력하는 많은 팀원 중 하나이다. 개발자는 프로그래밍 기술뿐만 아니라, 조직의 비즈니스 목표와 전략을 이해하고, 전체 조직의 성공을 위해 다방면으로 기여할 수 있는 넓은 시야를 갖출 필요가 있다.

비즈니스 관점을 지닌 방망이 깎는 개발자

보통 개발자라면, 고객이나 회사의 필요에 맞춰 빠르게 개발하고 배포하는 경험을 한 번쯤 해봤을 것이다. 특히 스타트업에서는 신속한 시도와 실패를 통해 학습하는 문화가 자리 잡고 있는 경우가 많다. 이러한 환경에서 개발자는 자주 고민에 빠지게 되는데, 시장의 요구 사항을 빠르게 파악하기 위해 신속하게 개발하고 배포해야 할지, 아니면 시간을 들여 안정적인 설계를 통해 추후 확장성을 고려해야 할지 기로에 선다.

하지만 아래처럼 급박한 비즈니스 이슈가 있는 상황에서는 어떻게 대처해야 할까?

교토의 한 사무실에 있는 회사는 운영 자금이 바닥나가는 상황에 직면해있다.

A: "그 기능 언제 출시되나요?"

개발자: "좋은 설계를 위해 노력 중이니, 조금만 기다려주세요."

개발자는 훌륭한 코드 작성을 위해 세심하게 설계 작업을 진행했다. 하지만 빠른 기능 출시로 시장 반응을 테스트해야 하는 A는 점점 더 조급해졌다.

A: "우리 회사 상황을 고려할 때, 이 기능이 급히 필요합니다. 무한정 기다릴 수는 없어요."

개발자는 심사숙고 끝에 고객이 요구하는 기능 배포를 우선시해야 한다는 사실을 깨달았습니다.

개발자: "알겠습니다. 최대한 빨리 마무리 지어 배포하도록 하겠습니다."

A: "바로 피드백을 반영해주셔서 정말 감사합니다."

개발자는 자신이 속한 회사의 현재 상황이나 고객의 요구사항에 맞는 비즈니스 전략을 우선순위로 삼아야 한다. 위와 같은 상황에서는 신속한 출시를 통한 시장 검증이 회사의 성장을 지원하는 최선의 방법이 될 수 있다.

GoogleNet, DenseNet, VGG, ResNet을 활용하여 무궁화, 장미의 이미지를 분류하는 실습

개발 로그를 쌓고 싶은 블로거 — Mon, 12 Feb 2024 00:03:24 +0900

대학원 학부 수업중, 여러가지 딥러닝을 활용하여 이미지를 분류하는 실습과제 입니다.

아래 영상으로 설명을 대체합니다.

https://www.youtube.com/watch?v=esc6orXnST8

DJango 5.0 주요 변화

개발 로그를 쌓고 싶은 블로거 — Tue, 5 Dec 2023 16:45:29 +0900

db_default 필드가 추가됨

Example

# db_default 값은 데이터베이스에서 계산된 기본값으로 터럴 값이나 Now와 같은 데이터베이스 함수일 수 있다.
class MyModel(models.Model):
    age = models.IntegerField(db_default=18)
    created = models.DateTimeField(db_default=Now())
    circumference = models.FloatField(db_default=2 * Pi())

GeneratedField 필드가 추가됨

class MyModel(models.Model):
    age = models.IntegerField(db_default=18)
    created = models.DateTimeField(db_default=Now())
    circumference = models.FloatField(db_default=2 * Pi())

GeneratedField  필드가 추가됨
Example
class Square(models.Model):
    side = models.IntegerField()
    area = models.GeneratedField(
        expression=F("side") * F("side"),
        output_field=models.BigIntegerField(),
        db_persist=True,
    )

area의 경우 side * side인데, 해당값을 하나의 데이터가 생성시 자동적으로 area을 계산해서 넣어주는 방식.

choices 필드의 유연성 증가

1. Field.choices (모델 필드용) 및 ChoiceField.choices (폼 필드용)는 값을 선언할 때 더 많은 유연성을 제공합니다.

Exameple

from django.db import models

Medal = models.TextChoices("Medal", "GOLD SILVER BRONZE")

SPORT_CHOICES = [
    ("Martial Arts", [("judo", "Judo"), ("karate", "Karate")]),
    ("Racket", [("badminton", "Badminton"), ("tennis", "Tennis")]),
    ("unknown", "Unknown"),
]


class Winner(models.Model):
    name = models.CharField(...)
    medal = models.CharField(..., choices=Medal.choices)
    sport = models.CharField(..., choices=SPORT_CHOICES)

보시면, SPORT_CHOICES에서 tuple 형식 이외에도 List[Tuple] 형식등 다양하게 제공

2. 호출 가능한 객체를 받아들이는 기능을 추가했으며, 또한 열거형 타입을 확장하기 위해 .choices를 직접 사용할 필요가 없어졌습니다

Example

from django.db import models

Medal = models.TextChoices("Medal", "GOLD SILVER BRONZE")

SPORT_CHOICES = {  # Using a mapping instead of a list of 2-tuples.
    "Martial Arts": {"judo": "Judo", "karate": "Karate"},
    "Racket": {"badminton": "Badminton", "tennis": "Tennis"},
    "unknown": "Unknown",
}


def get_scores():
    return [(i, str(i)) for i in range(10)]


class Winner(models.Model):
    name = models.CharField(...)
    medal = models.CharField(..., choices=Medal)  # Using `.choices` not required.
    sport = models.CharField(..., choices=SPORT_CHOICES)
    score = models.IntegerField(choices=get_scores)  # A callable is allowed.

https://docs.djangoproject.com/en/5.0/releases/5.0/

Mysql 5.6 설치 및 세팅 [우분투]

개발 로그를 쌓고 싶은 블로거 — Tue, 19 Mar 2019 00:20:48 +0900

5.6 설치

sudo add-apt-repository 'deb http://archive.ubuntu.com/ubuntu trusty universe'
sudo apt-get update
sudo apt install mysql-server-5.6 mysql-client-5.6

sudo service mysql start

UTF -8 로 설정하기

(/etc/mysql/my.cnf)

[client]
default-character-set=utf8

[mysqld]
character-set-client-handshake = FALSE
init_connect="SET collation_connection = utf8_general_ci"
init_connect="SET NAMES utf8"
character-set-server = utf8

[mysql]
default-character-set=utf8

[mysqldump]
default-character-set = utf8



##변경후
sudo service mysql restart

root 계정 외부에서 호스트 접근하도록 하기

1) 특정 IP 접근 허용 설정
mysql> grant all privileges on *.* to ‘root’@‘192.168.56.101’ identified by ‘root의 패스워드’;
2) 특정 IP 대역 접근 허용 설정
mysql> grant all privileges on *.* to ‘root’@‘192.168.%’ identified by ‘root의 패스워드’;
3) 모든 IP의 접근 허용 설정
mysql> grant all privileges on *.* to ‘root’@‘%’ identified by 'root의 패스워드’;

Ruby on Rails 시작하기

개발 로그를 쌓고 싶은 블로거 — Sun, 17 Mar 2019 12:57:04 +0900

참조 : https://github.com/rbenv/rbenv

brew install rbenv ruby-build

#rbenv를 bash에 추가하기
echo 'if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi' >> ~/.bash_profile source ~/.bash_profile

#적용시키기
source ~/.bash_profile

#루비 버전 업데이트 (변경)
rbenv install 2.5.3
rbenv global 2.5.3
rbenv rehash

#레일즈 설치
gem install rails

#mysql로 시작하기
rails new projectname -d mysql

#sqlite3 오류시 Gemfile을 아래와 같이 수정한다. (만약 sqlite로 시작할시)
gem "sqlite3", "~> 1.3.6"

#rails c 에러 대처법 (Library not loaded: /usr/local/opt/readline/lib/libreadline.7.dylib)
ln -s /usr/local/opt/readline/lib/libreadline.8.0.dylib /usr/local/opt/readline/lib/libreadline.7.dylib

#db migrate
rake db:migrate

# 발판을 이용해서 빠르게 구성하기 (새로운 리소스를 위해 모델, 뷰, 컨트롤러를 만들기)
rails generate scaffold Post name:string title:string content:text

모델 만들기
레일즈에서 모델은 단수형 이름을 사용합니다
rails generate model Comment commenter:string body:text post:references 

MySQL 서버를 AWS Aurora로 이전 (마이그레이션) 하기

개발 로그를 쌓고 싶은 블로거 — Sun, 3 Mar 2019 18:02:02 +0900

EC2 m4 인스턴스에서 사용중인 mysql 디비서버를 RDS로 옮기는 과정을 적어봤습니다.

서버이전은 AWS에서 제공하는 Data Migration Service(DMS)를 이용하여 이전작업을 진행했습니다.

DMS는 데이터를 AWS로 빠르고 나름 안전하게(?) 그리고 프로덕션을 무중단 상태로 운영하면서 마이그레이션을 도와줍니다.

동종 마이그레이션뿐 아니라 Oracle 또는 Microsoft SQL Server에서 Amazon Aurora로의 마이그레이션과 같은 이기종 데이터베이스 플랫폼 간의 마이그레이션도 지원합니다

준비단계

RDS 인스턴스 생성
DMS 인스턴스 생성
DMS의 엔드포인트 생성

1 RDS 인스턴스 생성

원본 데이터베이스에서 데이터를 마이그레이션 할 인스턴스를 생성합니다.
저희 회사에서는 엔진옵션으로 Aurora를 이용했습니다.
다음으로 세부 인스턴스의 정보를 입력합니다.
최종적으로 원하는 스펙을 생성합니다.

2 DMS 인스턴스 생성

원본 -> 타겟으로 마이그레이션을 도와줄 인스턴스를 생성합니다.
크기에 알맞게 DMS 인스턴스를 생성합니다.

3 DMS의 엔드포인트 생성

원본(EC2 mysql)의 엔드포인트 생성을 합니다.
원본/타겟 엔드포인트 식별자는 ‘source/target’와 같은 인식이 가능하게 단어로 입력합니다.
소스엔진은 ‘mysql’(해당 사용하고 있는 것과 맞게 끔)을 선택합니다
서버이름은 해당 퍼블릭 주소를 입력해줍니다.
포트는 3306 혹은 사용하고 계신 포트를 입력하시면 됩니다.
그다음 계정 / 비밀번호를 입력하고 테스트 연결을 해줍니다.
테스트 연결이 되어 있지않다면 계정에 대한 grant와 같은 옵션을 확인해 줍니다.
타겟 엔드포인트도 위와 같은 설정으로 진행합니다.

*주의사항*

DMS는 원본 데이터베이스의 인덱스나 외래키정보도 같이 넘겨주지 않습니다 ㅠㅠ 이부분에서 엄청 삽질 했다는..

만약 현재의 인덱스나 외래키 설정을 그대로 가져가고 싶다면 AWS에서 지원해주는 Schema convert tool을 이용하거나 (저같은 경우에는 맥을 사용하는데 오류가 심해서 설치만 하고 안씀)

아래와 같은 명령어를 통해 dump를 통해 스키마를 빼내는 방법이 있습니다.

mysqldump -u root -p --no-data dbname > schema.sql

그 다음 해당 Aurora 인스턴스에 저 스키마를 미리 import 하는 방법이 있습니다.

그 후 엔드포인트의 Aurora의 고급설정에서 외래키 점검을 비활성화 해줍니다.

initstmt=SET FOREIGN_KEY_CHECKS=0(외래키 점검 비활성화)

작업단계

DMS 작업 생성
DMS 작업 설정
DMS 테이블 매핑

1 DMS 작업생성

작업이름 : 해당 사용할 작업이름을 적습니다.
복제인스턴스 : 아까 생성한 DMS 인스턴스 선택합니다.
소스 엔드포인트 : 아까 만든 소스의 엔드포인트를 적습니다.
타겟 엔드포인트 : 아까 만든 타겟의 엔드포인트를 적습니다.
마이그레이션 유형:
- 기존데이터 마이그레이션 : 현재 시작지점까지의 데이터를 마이그레이션 해줍니다 (만약 소스 디비상태가 shutdown 상태인 경우 유리)
- 기존데이터 마이그레이션 및 지속적인 변경사항 복제 : 무중단 상태의 마이그레이션을 보장해줍니다.
- 데이터 변경사항 복제 : 현재 시작시점으로 부터 쌓이는 데이터의 마이그레이션 입니다.

2 DMS 작업 설정

대상 테이블 준비 모드:
- 아무 작업 안함 : 타겟 데이터베이스의 테이블을 건드리지 않고 데이터를 복제합니다.
- 대상 테이블에서 삭제 : 만약 대상테이블이 존재하면 삭제되고 새롭게 쓰입니다. (*주의 : 만약 이걸로 하면 위에서 dump떠서 적용한 스키마가 다 날라감 주의)
- 자르기 : 테이블의 메타정보를 보존한 상태로 데이터만 잘라줍니다
복제에 LOB 열 포함:
- 해당 설정에 맞게 LOB열을 포함 할지 말지 정해주시면 됩니다.
검증 활성화 : 데이터 마이그레이션이 다 수행 된후 무결성을 체크(?) 해주는 부분인데 만약 테이블 크기가 크다면 이 작업이 엄청 오래 걸릴 수 있습니다.. (저는 체크 안했습니다)
로깅 활성화 : CloudWatch를 볼수 있게 기능을 활성화 할 수 있습니다. (마이그레이션 작업시 오류가 어디서 났는 지 확인 가능)
고급설정 : 고급설정 탭을 통해 마이그레이션의 병렬노드할 테이블 수나 속도 커밋을 제어 할 수 있습니다.

3 테이블 매핑

스키마 이름 : 복제할 스키마를 선택합니다.
테이블 이름 형식
- % : 모든 테이블 복사
- Member이런식으로 마이그레이션 할 테이블 이름 지정 가능
작업
- 포함 : 해당 작업을 포함 시킵니다.
- 제외 : 해당 테이블의 작업을 제외시킵니다.

위 설정을 마친 후 작업 생성을 클릭하면 작업이 시작 됩니다.

upbit websocket api사용방법

개발 로그를 쌓고 싶은 블로거 — Sat, 16 Feb 2019 03:48:29 +0900

Upbit Websocket통신 할 수 있는 소스를 구현해봤습니다.

출처 : https://docs.upbit.com/docs/upbit-quotation-websocket

import websocket
import json
try:
    import thread
except ImportError:
    import _thread as thread
import time

def on_message(ws, message):
    get_message = json.loads(message.decode('utf-8'))
    print(get_message)

def on_error(ws, error):
    print(error)

def on_close(ws):
    print("close")

def on_open(ws):
    def run(*args):
        sendData = '[{"ticket":"test"},{"type":"ticker","codes":["KRW-CPT","KRW-ADA"]}]'
        ws.send(sendData)
        time.sleep(2)

        ws.close()
    thread.start_new_thread(run, ())


if __name__ == "__main__":

    ws = websocket.WebSocketApp("wss://api.upbit.com/websocket/v1",
                              on_message = on_message,
                              on_error = on_error,
                              on_close = on_close)
    ws.on_open = on_open
    ws.run_forever()