FeelingXD

[Android] OpenCv Android 16KB 지원 문제

FeelingXD — Mon, 1 Sep 2025 18:38:39 +0900

최근 안드로이드를 작업하면서 일전에 작업해둔 OpenCv 및 카메라 모듈 관련 구글 경고가 나오기 시작했다.

해당 이슈는 안드로이드 SDK 15 관련 업데이트가 되면서 이제 안드로이드 메모리 지원 이 기존 4kb -> 16kb 까지 늘어나게되었는데 카메라 모듈 및 OpenCv 라이브러리에도 문제가 생겼다.

openCv github 이슈 및 토론 글을 보니 해당 문제가 이미 해결되었으며 (4.11 버전이상에서 ) 관련 모듈을 업데이트 하기를 권장하고있었다.

OpenCV 는 4.11 이상
CameraX 모듈은 1.4.0 버전을 이용하도록 권장한다.
C 라이브러리 사용 모듈은 모두 27NDK 에서 빌드되어있어야함

연관링크

안드로이드 16KB 관련
[OpenCv안드로이드 빌드 이슈] (https://github.com/opencv/opencv/pull/26057)

[vs] vs(debug).exe 를 쓰기용으로 열 수 없습니다. 문제 해결 방법

FeelingXD — Tue, 26 Aug 2025 17:24:42 +0900

최근 vs(visual studio) 로 C 관련 프로그램을 생성중에 빌드시 잦은 해당에러로 솔루션 전체를 재빌드하는 일이 있어 시간을 많이 낭비했다. 우여곡절 끝에 찾은 내가 해결한 방법을 작성해본다.

디버그시 문제가된 화면

시도한 방법들

cmd 에서 vs.exe pid 찾아 강제로 삭제(그럼에도 간혹 해당문제 재발생)
작업관리자에서 vs.exe 관련 프로세스 모두 종료후 재실행
컴퓨터 자체 재부팅

그럼에도 지속적으로 해당 문제가 발생했는데 문제가 계속 발생한 원인은 보안프로그램의 실시간 감시항목이였다.

해결

window 디펜더 및 기타 보안 프로그램의 실시간 기능은 실행된(혹은 실행중인) 프로세스 모두 검사를 하기에 솔루션 디버깅 하고 종료를 하더라도 해당 보안 프로그램에서 검사 등의 명목으로 붙잡고있을경우 프로세스가 종료되었더라도 위의 문제가 재발생했다.

나는 사내 보안프로그램이였던 mcafee 를 사용 해제하는것으로 해결했다.

보안프로그램을 종료하는건 리스크있는일이지만 .. 이렇게라도 해결해야 재빌드하는시간을 아낄것같다. >:(

[Python] UV 로 파이썬 프로젝트 관리하기

FeelingXD — Sat, 2 Aug 2025 01:29:25 +0900

회사에서 파이썬 프로젝트를 진행하는데 poetry 사용 경험이 있으나 최근 uv 가 각광받고있다. uv 에대해 짧막하게 설명한다.

UV

An extremely fast Python package and project manager, written in Rust.
- github/uv/readme.md-

깃허브 에 정말 직관적으로 설명되어있다. 러스트로 작성된 정말 빠른 파이썬 패키지매니저

UV 시작하기

모든 커맨드는 uv 키워드로 시작한다.

프로젝트 시작 하기 uv init

현재 폴더 기준으로 프로젝트를 시작합니다.

기본적으로 .gitignore , project.toml 등 프로젝트 파일들이 생성되며 init 명령어 전에 프로젝트 폴더로 변경하는걸 권장함

가상환경 설정 uv venv

기본적으로 파이썬의 그것과 같이 .venv 를 기본이름으로 생성되나 -n {name} 등으로 이름을 지정가능

의존성 추가
pip 등 처럼외부 라이브러리 추가시 uv add {package name} 으로 간단하게 설치할수있음. 프로젝트 설명에서는 기존의 pip 보다 월등히 빠르다 하나 체감될정도는 아님

기본적으로는 이정도가있고 이외 uvx 등 스크립트 실행 및 자체 tool 지원등이 더있지만 간단한 소개로 이글에서는 적지않는다.

개인적으로 ..

파이썬 프로젝트관리는 java Spring 진영의 gradle 처럼 압도적 지분을 가진 툴이없기에 새로운 패키지 매니저 가 생기면 기존 에 사용하던것과 어떻게 다를까 , 어떤걸 지원하지 드의 궁금증을 가지게된다. 이전에 poetry를 사용하긴 했으나 poetry 설치시 pip 에서 설치하지않고 다른 경로로 설치하는 등의 복잡함(귀찮음) 때문에 다음프로젝트 부터는 uv 를 차용해서 하지않을까싶다. 또 poetry 에서 처럼 project.toml 로 관리해서 기존의 poetry 를 uv 로 쉽게 마이그레이션을 지원하기도하는점이 꽤 괜찮은 것같다.

연관 문서

[Anecdote] - 첫 취직

FeelingXD — Mon, 21 Jul 2025 04:28:26 +0900

취준

작년(2024) 5월 첫 취직을 했다. 그때를 기억해보면 시골에서 서울- 경기로 면접보러 다닌다고 아침일찍 기차 타고 상경하고 사촌형집에서 머물면서 이곳 저곳 면접을 보러다닌기억이 선하다.

면접과 첫 합격

취준생의 면접은 누구에게나 그렇듯 당혹에 쭈뼛거리며 서툴럿던 기억뿐이다. 여러 기업에 서류도 넣어보고 , 면접도 보고, 합/불 여부는 잘 알려주지도 않는 기업때문에 기분나빠하기도하다 지금 다니고잇는 기업에 합격했다. (글쓰는 기준 이제 1년 1개월째 재직 중이다.)

지금 다니는 회사 면접에서 는 다른회사들과 다르게 지원자에게 최근 개발이나 IT 관련 뉴스중 흥미있거나 , 아니면 관심있는 새기술이 있는지 질문을 해 꽤나 자세하고 상세히 대답했던것같다. 뭔가 내 스스로를 소개 ( 학교, 포트폴리오, 자격증 ~ ) 보다는 나는 .. 이런것들에 관심이 있어요 라고 어필하는것이 지금생각해보면 조금더 당당하게 했던것같다.

면접에서 그렇게 기죽을 필요가 없었는데 .. 그게 뭐라고 쭈뼛 거렸던걸까..

회사일은 마감과 기한이 있다.

회사일은 마감과 기한이있다. 라고말하면 .. 학교에서 과제나 프로젝트도 기한이 있는걸요 ? 라고 반문할수도있겠지만 . 회사의 일과 학교의 일은 무게가 다름을 느끼게 되었다. 일정이 밀리는건 IT 에서는 꽤나 자주있고 그 원인도 다양하지만 그때마다 고객 - 회사 와의 커뮤니케이션이 그리 좋은방향으로 흘러가지는 않는다. 그럼에도 어쩌겠는가 . 모두들 계획대로 되길바라지만. 어쩔수없다면 현재상황에 맞게 해야하는것을 .

나도 일에 적응하느라 . 내 업무를 끝내느라 . 자발적으로 회사에 더남아 프로젝트 , 사용기술 등 조금더 DEEP 하게 공부하는 계기가 되었다. 아쉬운점은 ,, 회사일에만 집중하느라 취직이후에도 꾸준히 글을쓰고싶다 .. 라는 열정이 많이 죽은것 ?

블로그 글은 사사로운것이고 회사일의 마감은 정해져있고 누군가 책임져야하는 일이기에 더욱 내게 다가왔다.

생각보다 회사를 다니고 사회구성원이 된다는건 쉬운일은 아니다.

취직도햇겠다 돈도벌겠다. 하고싶은걸 하면되나 ? 라는 생각은 일을하다보면 사라지게된다.

7일중 5일.. 9-6 만일해도 집에오면 녹초가된다. 이제 저녁시간 혹은 쉬는시간에는 .. 개인업무가 추가로주어진다. 방청소도 가끔해야할것이며, 빨래도 해야하고 기타등등 상상하지 못했던일들을 스스로 해내야한다.

월급날이 즐겁지만 돈이나가는건 꽤나슬프기도하다. 신용카드를 썻다면 카드값이나갈테고 .통신비 보험비등 숨만쉬어도 나가는돈이 꽤나 많다는걸 이제는 인정하게되었다.

이렇게 앞으로 30년은 더넘게 해야한다는게 눈앞이 깜깜하다..

부모님은 어떻게 이대단한것들을 ..아무내색없이 할수있는지 .. 아직은 잘모르겠다.

[독서] - 켄트 벡의 Tidy First? - 1

FeelingXD — Fri, 28 Mar 2025 23:47:24 +0900

저자 켄트백은 TDD(테스트 주도개발) , EX(익스트림 프로그래밍) 등의 개념과 애자일 방법론의 대가로 테스트 주도개발문화를 설파한 개발자이다.

Tidy First?

제목대로 Tidy( 깔끔하게 ) First? ( 먼저 )? 마치 책 제목을 통해 코드의 정리 가 먼저인가 코드의 작성 이 먼저인지
마치 닭 과 알 논쟁인것 처럼보이기도한다. 켄트백은 이책을 통해 다양한 상황에서 코드 정리법 또 자기만의 기준을 제시한다.

코드 정리법

안 쓰는 코드

지워버리세요 그게 다입니다. 심플하고 충격적인 답이다. 실무를하면서 어쩌면 나도 이생각을 가지고있지만 막상 실천하기는 정말어렵다. IDE 에서 실행되지 않는 변수, 메서드 등이 사용되지 않는다는 경고 가 나와도 차마 지우지는 못하고 주석 처리하는 정도로만 대응했다. (코드 작성자가 어떤이유에서 코드를 남겨두었는지 몰랐기에) 사실 git 기록을 통해 언제든 복원을 할수있더라도 코드를 작성하는 것보다 기존 코드를 지운다는 것이 내게는 더어렵게 다가왔다. 만약 지웠다가 문제가 생긴다면 ? 의문의 불안감을 지워낼수가없다. 물론 내가 작성한 코드는 지우려고 하고있다. :/

대칭으로 맞추기

이 주제는 일관성 있는 코드로 표현해도 좋을것같다.

# 비슷한동작 혹은 메서드, 함수 작성시 일관된 규칙을 사용해서 반환 혹은 예측가능하게 일관성을 가져가도록 하자 
foo() return 1 condition else 2
foo2() = lambda x: 1 condition(x) 2

최근에 안드로이 관련 코드를 작성하면서 주제와 관련해서 피드백을 받은 경험이 있어 찔린다.

응집도를 높이는 배치

패키지 구조, 메서드 클래스를 묶어서 가져가기

예를 들어 특정 인터페이스의 구현체를 해당 패키지 하위의 Impl 형태의 디렉토리에 위치시켜 모이게 해두기

선언과 초기화는 동시에 진행하기

kotlin 에서는 lazy init 등 .. 지연초기화가 있지만 가능하면 명시적이고 초기화 시점에 변수를 해야겠다. 라는생각이 든다. 변수의 선언과 초기화가 동시에 이루어지지않으면 변수가 무슨일을 하는지 포커스를 놓지게 되고 알수없고 잠재적으로 예측 불가 한 코드를 작성할수있다.

// 선언과 초기화가 동시에 이루어지지않는경우
fun foo(){
    val a : String ;
    ......

    a = "init"
}

이 케이스에서는 상수 선언 (val) 사용이여서 실수가 줄어들수 있지만 여전히 선언과 초기화가 동시에 이루어지지 않아 상당히 별로다 :P .. 가능한 상수를 사용하고 선언과 초기화는 동시에 가져가는 코드를 작성하는 습관을 들여야겠다.

[Spring] 스프링 웹서버 멀티 포트로 열기

FeelingXD — Sat, 14 Sep 2024 00:25:41 +0900

멀티 포트의 필요성

대부분의 경우에선 그렇지 않겠지만 서버를 여러포트로 지원해야할 때가있다.

예를들어 https 와 http 둘 모두를 지원해야한다면 두개의 경우를 생각해서 포트를 구성해야한다.

코드

// kotlin 코드입니다. :)
package com.feelinxd.app.config

import org.apache.catalina.Context
import org.apache.catalina.connector.Connector
import org.apache.tomcat.util.descriptor.web.SecurityCollection
import org.apache.tomcat.util.descriptor.web.SecurityConstraint
import org.springframework.beans.factory.annotation.Value
import org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory
import org.springframework.boot.web.servlet.server.ServletWebServerFactory
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration
class ServerConfig {

    @Value("\${server.http.port}")
    val httpPort: Int = 0

    @Value("\${server.port}")
    val httpsPort: Int = 0

    @Bean
    fun servletWebServerFactory(): ServletWebServerFactory {
        val tomcat = object : TomcatServletWebServerFactory() {
            override fun postProcessContext(context: Context) {
                super.postProcessContext(context)
                val securityConstraint = SecurityConstraint().apply {
                    userConstraint = "CONFIDENTIAL"  // ssl를 강제로 설정한다.
                    addCollection(SecurityCollection())
                }
                context.addConstraint(securityConstraint)
            }
        }

        tomcat.addAdditionalTomcatConnectors(createHttpConnector())
        return tomcat
    }

    private fun createHttpConnector(): Connector { // http 커넥터에 대한 정의 
        val connector = Connector(TomcatServletWebServerFactory.DEFAULT_PROTOCOL)
        connector.scheme = "http" // 사용할 프로토콜 http 
        connector.port = httpPort 
        connector.secure = true
        connector.redirectPort = httpsPort
        return connector
    }
}

// application.yml
server:
  port: 8443  // ssl 서버 사용을 위해 443 포트를 명시
  http:
    port: 8080 // http 프로토콜을 사용할 포트 명시
  ssl:
    enable: true
    key-store: classpath:keystore.p12
    key-store-type: PKCS12
    key-store-password: changeit

Spring boot 에서 필요한 클래스가 없어요 !

Spring-boot-starter 를 사용해서 의존성을 주입 받았다면 위의코드를 그대로 사용할때

org.apache.catalina.~ 패키지 관련 문제가 생길수 있다. springboot 에서는 embedded-tomcat 을 지원하고있지만 사용할 톰캣 서버를 세세 하게 설정하려면 gradle 기준으로 다음 패키지 의존성이 추가로 필요하다.

implementation 'org.apache.tomcat.embed:tomcat-embed-core:9.0.0' // Spring Boot 버전에 맞춰 조정

위의 의존성을 추가하여 세부 조정할 수있다.

코드에 대한 시나리오

개인적으로 공부하면서 http 프로토콜을 https 로 리다이렉트 시켜보자 라는 챌린지에 도전했다.

예를들어 같은 api 를 http, https 를 지원하되 http 에대해 접근시 https 포트로 리다이렉트 를 강제한다.

위의 코드에서는 domain:8080 으로 접근시 domain:8443 으로 리다이렉트 하여 처리 한다고 보면된다.

현업에서는 직접 백엔드서버에 접근하기전 리버스 프록시를 두고 위의 멀티포트지원을 nginx에서 분기처리하는식으로 많이 구현할것이다. 사실상 쓸데 없는 삽질로 보일수도있지만 스프링에서도 멀티포트가 가능하고 또 구현해보고싶은 개인적인 챌린지였다.

[DesignPattern] 빌더패턴

FeelingXD — Sun, 25 Aug 2024 12:20:00 +0900

빌더 패턴

빌더패턴 은 디자인 패턴중 생성 패턴으로
생성 과정과 표현과정을 분리하고 다양한 구성의
인스턴스 를 만드는것을 목적으로합니다.

빌더 패턴의 개념

빌더 패턴은 복잡한 객체들을 단계별로 생성 할 수있도록 하는 패턴입니다.

대표적으로 사용되는 생성 패턴들

점층적 생성자 패턴

생성자를 매개변수에 개수만큼 구성하는 패턴을 의미합니다.

class Person{
  private String name;
  private String nickname;
  private String email;

  public Person(String name){
      this(name,null,null);
  }

  public Person(String name, String nickname){
      this(name,nickname,null)
  }
  public Person(String name, String nickname, String email){
      this(name,nickname,email)
  }
}

매개변수가 많아질수록 그만큼 커스텀 생성자를 추가적으로 생성해야 합니다.
내부필드에 동일한 타입의 클래스가 존재할 경우 모호한 표현을 야기할 수 있습니다.

자바빈즈 패턴

별도의 생성자 없이 빈 객체를 생성하고 인스턴스의 필드를 채워주는 형태의 패턴입니다.
위의 클래스 에서 만든 Person 클래스를 재활용 하겠습니다.
```
class Person{
  private String name;
  // 기타 필요 필드들
  public Person()

  public setName(String name){
      this.name= name;
  }
  // 각 필요한 필드의 세터들
}
```

class main{
public static void main(String args[]){
Person person= new Person()
person.setName("새로운 이름");
}
}

- 불필요한 생성자를 추가적으로 작성하지 않아도 되어서 작성할 코드 량이 줄어듭니다.
- `필수` 적으로 사용되야하는 필드를 객체 생성 이후 초기화 하기에 실수 할 수 있습니다.
- 필드의 set이 열려있어 객체 필드가 변할 수 있습니다.


### 빌더패턴 알아보기  

```Java
class Person{

    private String name;
    private String nickname;
    // private 생성자를 지정하여 생성자 생성 방지
    private Person(){}
    public static builder(){
        return new PersonBuilder()
    }
}
// 생성을 빌더패턴에서 담당하게됩니다.
class PersonBuilder{

    public PersonBuilder name(String name){
        this.name= name;
        return this
    }

    public PersonBuilder nickname(String nickname){
        this.nickname= nickname
        return this
    }
    public Person build(PersonBuilder builder){
        Person person = new Person()
        // 각 person 필드설정
        person.name = builder.name
        return person
    } 
    // 최종적으로 build 메서드를 통해 Person객체를 생성합니다.
    public Person build(){
        return build(this)
    } 
}

실제 사용하는 곳에서는 다음과 같이 사용된다.


public static void main(){
    Person person = Person.Builder()
    .name("이름")
    .build()
}

빌더패턴의 장점

명시적으로 어떤필드에 어떤 값이 들어갈지 개발자가 파악하기 용이합니다.
실제 사용하는 객체에서 Setter와 생성자를 사용하지 않으므로써 객체가 변경되거나 생성시 실수가 줄어듭니다.

단점

필수값으로 생성해야하는 필드들을 누락할 위험이 있습니다.

[독서] - 데미안

FeelingXD — Sun, 7 Jul 2024 14:35:17 +0900

새는 알에서 나오기 위해 투쟁한다.
알은 새의 세계이다.
누구든지 태어나려고 하는 자는 하나의 세계를 파괴하여야 한다. 새는 신을 향해 날아간다. 그 신의 이름은 아브락사스이다.

데미안 소설 중 -

나는 데미안이라는 책을 3

4번 정도 읽은 것같다.
처음과 두번은 초

중학생때의 기억이고 3~4 번은 고등학생때와 그리고 바로 오늘일이다.

데미안은 참 신기하게 읽을때마다 과거의 생각(기억) 과 마주하게한다. 어렸을때 데미안을 접하고는 .. 다 사람 욕심 대로 사는것이아닌가 라는 생각 에서 지금은 다시 왜 다들 자기통제를 하지않고 살아가지 라는 생각이든다.

작중에서

주인공 싱클레어 는 나잇대보다 성숙하고 늠름한 친구인 데미안 을 만나고 그와 겪은 사건들을 통해 내면적으로 성숙해지는 내용을 담고 있다.

싱클레어 나는 너가 부른다고 당장 말이나 기차를 타고 너가있는곳까지 언제건 올 수없어 하지만 너는 나를 부를 수있고 내면의 깊은 목소리에 귀를 귀울여야해 그렇다면 내가 너의 안에 있다는 걸 깨달을꺼야.

누구든지 태어나려고 하는 자는 하나의 세계를 파괴하여야 한다. 새는 신을 향해 날아간다. 그 신의 이름은 아브락사스이다.

생각

성장 하기위해서는 고통 또한 감내하고 결국 자신의 악한모습도 나약한모습도 자기자신임을 암시하는 내용이면서,
전체적으로 마치 한순간의 꿈, 혹은 정신이상자의 망상으로 느껴지기도한다.

싱클레어 는 또래 아이들보다 소심하고 자기확신이 부족하다. 그가 데미안 , 에바부인 ,베아트리체 등을만나면서 내면으로 성숙해지는데 나는 이러한 인물들이 싱클레어 가생각하는 이상, 내면의자아 등 자신의 투영해서 만든 다른 인격체 처럼 느껴졌다. 특히 마지막문장에서 데미안 이언급한 내면에 귀를귀울이면 내가 너안에 있다는 것과 동시에 참호에서 일어나 거울을 보았을때 싱클레어 가 본 거울 에는 자신의 우상 이였던 데미안 이 거울내 있었다던 표현등이 말이다.

전쟁 뿐만아니라 내면적 이야기에서도 어느정도 시대상을 담고 있다는 생각도 든다. 데미안이 출판되었을때 세계1차대전 중이였다. 그리고 마지막 챕터에서 러시아와의 전쟁이야기가 언급된다. 이를 통해 작가는 내적 외적 으로도 단순이 안주할뿐아니라 있는 현실을 받아 들이고 자신이 진정으로 바라는 나와 그걸위해서는 투쟁 을 해야한다는것을 암시한다는 기분이들었다.

아직은 완벽하게 극복하지못한 이분법적 사고를 가진 내게는 앞뒤가 맞지않고 묘한 두통을 유발하는책이다. 나이가 들고 다시읽었을때는 더더욱 말이다.

특히 아브락사스라는 신을 통해 선도 악도아닌 신이 있으며 자신의 내적으로 당당하고 악한면 또한 자신임을 인정해야한다. 등의 의미의 글들이 내게는 특히 그렇게 다가왔다.

요즘에는 비이성적이고, 도덕적이지못하며, 오히려 악하고, 부조리한것들이 삶(세계 )곳곳에 만연해있다는 사실이 내게는 이해하지 못할것들이다.

[Kotlin] - 코틀린 컴파일 과정

FeelingXD — Sat, 22 Jun 2024 19:41:45 +0900

Kotlin 빌드과정

코틀린도 JVM 위에서 동작한다. 이를위해서는 코틀린또한 자바처럼 JVM 이 읽을수있는 JAVA Byte 코드로 변환된다.
이과정이 JAVA의 컴파일과 비슷하면서 조금 차이가 있다.

코틀린 과 자바 컴파일 과정

Kotlin 에서 Java Annotation 사용시 발생하는 문제

Kotlin 과 Java 를 혼용해서 사용하고 Java 어노테이션 프로세서를 사용하고있다면 Kotlin 에서 읽지못하는 문제가 발생할 수 있다.

왜 발생할까 ?

Kotlin 컴파일 순서는 다음과 같다.

컴파일 : Kotlin 코드가 먼저 컴파일되어서 .class 파일을 생성한다 그리고 Java 코드가 이후에 컴파일 될때 Java 어노테이션 프로세서가 생성한 코드를 Kotlin이 사용하기전에 이미 컴파일 되어있기때문에 컴파일 이후에 생성한

Java 코드를 Kotlin코드는 참조 할 수 없다.

Lombok 사용시 코틀린은 어노테이션 프로세서가 없기에 코틀린은 Lombok 을알지못함

KAPT (Kotlin Annotation Processing Tool)

Kotlin 에서 Annotation 처리를 위해 KAPT(Kotlin Annotation Processing Tool) 플러그인 을 제공합니다.

KAPT는 어떻게 어노테이션 프로세싱을 지원할까

1. KAPT 는 Kotlin 코드를 분석하여 Java 스텁 코드를 생성합니다. 이 스텁 코드는 Kotlin코드의 구조를 Java로 표현한것입니다.

2. Java 어노테이션 프로세서 실행

이제 Kotlin 코드가 변환된 Java 스텁 코드로 Java 어노테이션 프로세스를 실행합니다. 이를 통해 Java로 작성된 어노테이션 프로세서가 Kotlin 코드의 어노테이션 을 지원하게 됩니다.

3. 코드 생성:

어노테이션 프로세서가 생성한 코드는 Kotlin 컴파일러가 이해할 수 있는 형태로 변환되어 최종 컴파일 결과물에 포함된빈다.

4. 빌드 프로세스 통합:

KAPT 는 Gradle 빌드 프로세스에 통합되어, 필요한 단계에서 자동으로 실행됩니다. 개발자는 build.gradlef 파일에 KAPT 플러그인을 적용하고, 필요한 의존성을 kapt 키워드로 선언하여 사용할 수 있습니다.(kapt 에서 지원하는지 확인 필요)

- kapt를 통해 kotlin 에서 java 어노테이션을 사용할 수 있게되었습니다. 하지만 이과정중에서 중간에 Java 스텁코드를 생성해야하는등의 불필요한 오버헤드가 발생하기도합니다. 이때문에 빌드시간이 느려질 수 있습니다.

[Git] - Git 브랜치 전략

FeelingXD — Sat, 1 Jun 2024 15:17:32 +0900

Git 브랜치 전략

Git 을 통해 협업을 하게된다면 브랜치를 통해 작업을하고 병합 하는 과정을 겪게될것이다. 다양한 git 브랜치 전략에 대해 알아보자.

GIT FLOW - 깃 플로우

GIT FLOW - 간략한 설명

Git-flow에는 5가지 종류의 브랜치가 존재합니다. 항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있습니다.

master : 제품으로 출시될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

문제점

GIT - flow 는 웹앱(web apps) 기반으로 작성하지 않았고 오히려 이전략이 불편 할 수있습니다. 다음과 같은 문제점들이 있습니다.

브랜치가 오래유지됨
브랜치 관리가 복잡함

GITHUB FLOW - 깃 허브 플로우

GIHUB FLOW -간략한 설명

깃플로우는 정석적이지만 많고 복잡한 브랜치 사용으로 상시 배포해야하는 환경에서는 익숙치 않았습니다. 이에 GITHUB FLOW는 간단한 브랜치 전략을 제공합니다.

master : 제품 브랜치
feature : 기능단위 의 브랜치

어떻게보면 TBD(Trunk based development)으로도 보일 수 있습니다.
심플한 브랜치 전략으로 더 상시 더자주 배포할 수 있게되었습니다.

문제점
- 기능 A, B 가 병합되어야하는데 기능 A 가 B에 의존하고있다면 이는 A를 MAIN 머지를 대기해야하는 일이 발생하게됩니다.
- 트렁크기반 의 장점인 빠른 병합의 장점이 오히려 몇달동안 개발해야 할 기능이 생긴다면 미루어지는 일이 생기게 됩니다.
- 바로바로 main 에 병합되므로 충분히 테스트되지 못한 코드가 병합되어 배포되는 경우가 생길 수 있습니다.

GITLAB FLOW - 깃 랩 플로우

GITLAB FLOW - 간략한 설명

GITLAB FLOW 는 GIT FLOW 의 복잡함과 GITHUB FLOW의 단순함 그사이의 절충하는 FLOW이다.

사용되는 브랜치

master(develop) : 다른 브랜치 전략의 develop 브랜치에 해당합니다. master로부터 feature 브랜치로 작업하고 다시 머지됩니다.
feature : 기능단위의 작업이 진행되는 브랜치입니다.
pre-production : 실제 배포전 테스트 하는 브랜치 입니다.
production(main,maintanance) : 실제 서비스를 하는 브랜치 입니다.

SIM GIT FLOW - SIMPLE GIT FLOW

SIM GIT FLOW - 간략한 설명

다른 브랜치 전략들은 모두 feature가 순서대로 반영되어야하는 문제점이 있었습니다.

feature -> dev 혹은 master 에 병합하고 production 으로 배포됨

이는 기능단위의 통합테스트를 목적으로는 장점이 되지만 항상 feature 등이 순서대로 반영되어야했습니다. simgit 은 각 독립적인 feature들이 빠르게 realease 되는 방법을 제공합니다.

master : 실제 서비스가 되는 브랜치
release : 배포 대기를 위한 브랜치
feature : 여러가지 단위의 기능이 작성되고 작성된 기능은 바로 release로 머지하여 배포준비를 합니다.