[크래프톤 정글 3기] 2/13(화) TIL

ClassBinu·2024년 2월 13일
0

크래프톤 정글 3기 TIL

목록 보기
111/120

추석 연휴 내내 이력서, 포트폴리오, 자기소개서를 썼으나..
아직도 완성 못함.
엄청 길게 쓰긴 했는데, 뭔가 핵심이 없어 보임..?

멘토링

각자 1개씩 문제를 해결한 과정 스토리텔링해서 슬랙에 올리기

문제-과정-결과-성과

문제:
1. (사용자 관점) 사용자가 글을 쓰면 동화가 생성되기까지 40여 초를 빈 화면을 보고 대기해야해서 사용자 경험 저해 요인

  1. (개발자 관점) 동화책을 생성하는 API 호출 함수가 하나의 함수로 구현되어 있어, 해당 함수가 비대해지고 역할과 책임이 명확하지 않아 유지 보수성이 떨어짐.

원인: '사용자 글 전송 -> 동화 텍스트 생성 -> 이미지 프롬프트 생성 -> 이미지 생성 -> 동화책 생성'으로 진행되는 플로우를 하나의 함수로 구성하고, 단일 API 요청으로 처리하여, 함수 호출부터 동화책 완성까지 어떠한 중간 정보도 클라이언트로 전달할 수 없음. 프론트엔드 개발 편의성을 고려하여 단일 API 요청으로 구현하였으나, 기능 구현의 유연성이 떨어짐.

과정:
1. 기존 단일 함수를 다음과 같이 분리함.
(1) 동화 텍스트 생성 함수
(2) 이미지 프롬프트 생성 함수
(3) 이미지 생성 함수
(4) 동화책 생성 함수

  1. 단일 API 엔드포인트를 다음과 같이 분리함.
    (1) 동화 텍스트 생성 요청
    (2) 동화책 생성 요청(이미지 프롬프트, 이미지 생성 포함)

결과: '동화 텍스트 생성 API 요청'을 통해 텍스트가 반환되면, 사용자에게 동적으로 텍스트가 생성되는 애니메이션을 보여주고, 텍스트가 화면에 순차적으로 렌더링 되는 동안 '동화책 생성 API 요청'을 통해 서버에서 이미지 및 동화책을 생성하는 방식으로 변경

성과:
1. (사용자 관점) 사용자의 대기 시간을 기존 40여 초에서 10초 이내로 줄이고, 나머지 30여 초는 텍스트가 동적으로 생성되는 과정과 이미지가 스켈레톤에서 점점 나타나는 애니메이션을 추가하여 사용자 경험 개선

  1. (개발자 관점) 하나의 API 엔드포인트 호출에 하나의 함수만 대응하는 건 비효율적인 개발 방식임을 깨달음. 함수를 역할별로 여러 개로 나누고, API 엔드포인트 안에 여러 함수를 조합하여 사용할 수 있음. 이를 통해 코드의 유지보수성이 향상됨.

브랜치 관리 전략

GitFlow

  • master: 제품으로 출시될 수 있는 브랜치입니다. 이 브랜치에 merge되는 코드는 새로운 버전 출시 준비가 완료된 상태여야 합니다.
  • develop: 개발을 진행하는 주요 브랜치입니다. 기능(feature) 브랜치들은 이 브랜치에서 분기되며, 완료된 기능은 다시 이 브랜치로 merge됩니다.
  • feature: 새로운 기능 개발이나 버그 수정 작업을 위한 브랜치입니다. 각 기능이나 수정 사항은 별도의 feature 브랜치에서 작업되며, 완료 후 develop 브랜치로 merge됩니다.
  • release: 릴리스를 준비하는 브랜치입니다. develop 브랜치에서 분기되며, 릴리스 준비 작업(버전 번호 변경, 버그 수정 등)이 완료되면 master로 merge되고, 동시에 develop 브랜치에도 반영됩니다.
  • hotfix: 제품에서 발생한 긴급한 버그를 수정하기 위한 브랜치입니다. master 브랜치에서 직접 분기되며, 수정 후 master와 develop 브랜치 모두에 merge됩니다.

배민: 우린 Git-flow를 사용하고 있어요.
https://techblog.woowahan.com/2553/

github flow

  • master: 항상 "배포 가능한" 상태를 유지합니다.
  • feature / bugfix / etc: master에서 직접 분기하여 작업을 시작합니다. 작업이 완료되면 코드 리뷰를 거친 후 master 브랜치에 merge되며, 즉시 배포됩니다.
    이 전략은 간단하며, 소규모 팀이나 지속적으로 배포하는 환경에 적합합니다.

Trunk Based Development (TBD)

  • trunk / master: 모든 개발이 이루어지는 주요 브랜치입니다.
  • short-lived feature branches: 필요한 경우, 매우 짧은 기간(보통 하루에서 며칠) 동안만 존재하는 기능 브랜치를 사용합니다. 가능한 한 빠르게 trunk에 merge합니다.
  • feature flags: 특정 기능이 완성되지 않았거나 배포되지 않도록 하기 위해, 기능 플래그를 사용하여 관리합니다.

기능 플래그?

# 기능 플래그 설정
feature_flags = {
    "new_feature": True,
    "beta_feature": False
}

# 기능 플래그를 사용하여 조건부 기능 실행
def main():
    print("Application Start")
    
    if feature_flags["new_feature"]:
        print("New Feature is enabled. Running New Feature.")
        new_feature()
    else:
        print("New Feature is disabled.")
    
    if feature_flags["beta_feature"]:
        print("Beta Feature is enabled. Running Beta Feature.")
        beta_feature()
    else:
        print("Beta Feature is disabled.")

def new_feature():
    print("This is a new feature!")

def beta_feature():
    print("This is a beta feature, still under testing.")

if __name__ == "__main__":
    main()

https://tech.mfort.co.kr/blog/2022-08-05-trunk-based-development/

스토리파이 사용자 피드백

  1. 잘 되긴 했는데 글과 상관없는 뜬금없는 그림이 나왔어요! ㅎㅎ
  2. 한 번 올려보긴 했는데...이미지랑 제목은 따로 수정할 수 없는 것 같아 조금 아쉬웠다.
  3. 나 왜 회원가입에 실패했다고 뜨지?

0개의 댓글