내 인생의 최악의 코드는

근래 YES24가 뜨겁다.

 

해킹 사태로 문제가 되어 1주일 동안 시스템이 멈추고 피해액만 수십억에 달할 것이다.

 

내 인생에서 최악의 코드는 YES24에서 보았기 때문에 생각난 김에 글을 남긴다.

 

YES24에서 보았던 최악의 코드는 DB 프로시저 까지 합쳐서 약 5000줄 이상이 되는 예매 코드였다.

 

논리는 아래와 같다.

 

1. 사용자가 선택한 좌석에 대해 극장사에 질의 한다.

2. 유휴 좌석 있다고 회신하면 해당 좌석을 Lock한다. (5분 동안)

3. 제휴사의 결제 정보를 확인한다.
3-1. 제휴사 할인 정보 확인

3-2. 제휴사 결제 정보 확인

4. Yes24 결제 정보를 확인한다.

4-1. Yes24 할인 정보 확인

4-2. Yes24 쿠폰 정보 확인

5. 결제 확인된 정보에 대해 최종 결제 한다.

6. 유휴 좌석에 대하여 확정한다.

7. Yes24 결제 정보를 확정한다.

8. 제휴사 결제 정보를 확정한다.

9. 예외 및 실패 할 경우 모두 롤백한다.

 

이러한 시나리오 이다.

이러한 시나리오에 작성된 코드가 모듈화 되지 않고 try catch에 감싸져서 5000줄 이상이 되는 상황이었다.

 

그래서 아래와 같이 바꾸었다.

 

var paymentType = "Skt";
var ticketType = "Lotte";

var paymentService = PaymentFactory.GetPaymentService(paymentType);
var ticketService = TicketFactory.GetTicketService(ticketType);

try
{
    ticketService.SeatLock();
    paymentService.Pay();
    ticketService.Preserve();
}
catch (Exception e)
{
    paymentService.Cancel();
    ticketService.Cancel();
}


public interface IPaymentService
{
    void Pay();
    void Cancel();
}
public class SktPaymentService: IPaymentService
{
    public void Pay()
    {
        throw new NotImplementedException();
    }

    public void Cancel()
    {
        throw new NotImplementedException();
    }
}

public class LgPaymentService: IPaymentService
{
    public void Pay()
    {
        throw new NotImplementedException();
    }

    public void Cancel()
    {
        throw new NotImplementedException();
    }
}

public class NaverPaymentService: IPaymentService
{
    public void Pay()
    {
        throw new NotImplementedException();
    }

    public void Cancel()
    {
        throw new NotImplementedException();
    }
}

public class Yes24PaymentService: IPaymentService
{
    public void Pay()
    {
        throw new NotImplementedException();
    }

    public void Cancel()
    {
        throw new NotImplementedException();
    }
}

public class PaymentFactory
{
    private Dictionary<string, IPaymentService> _paymentServices  = new Dictionary<string, IPaymentService>()
    {
        { "Skt", new SktPaymentService() },
        { "Lg", new LgPaymentService() },
        { "Naver", new NaverPaymentService() },
        { "Yes24", new Yes24PaymentService() }
    };

    private PaymentFactory()
    {

    }
    
    public static IPaymentService GetPaymentService(string paymentType)
    {
        var instance = new PaymentFactory();
        return instance._paymentServices[paymentType];
    }
}

public interface ITicketService
{
    void SeatLock();
    void Preserve();
    void Cancel();
}

public class LotteTicketService : ITicketService
{
    public void SeatLock()
    {
        throw new NotImplementedException();
    }

    public void Preserve()
    {
        throw new NotImplementedException();
    }

    public void Cancel()
    {
        throw new NotImplementedException();
    }
}

public class CgvTicketService : ITicketService
{
    public void SeatLock()
    {
        throw new NotImplementedException();
    }

    public void Preserve()
    {
        throw new NotImplementedException();
    }

    public void Cancel()
    {
        throw new NotImplementedException();
    }
}

public class MegaboxTicketService : ITicketService
{
    public void SeatLock()
    {
        throw new NotImplementedException();
    }

    public void Preserve()
    {
        throw new NotImplementedException();
    }

    public void Cancel()
    {
        throw new NotImplementedException();
    }
}

public class TicketFactory
{
    private Dictionary<string, ITicketService> _ticketServices = new()
    {
        { "Lotte", new LotteTicketService() },
        { "Cgv", new CgvTicketService() },
        { "Megabox", new MegaboxTicketService() }
    };
    
    private TicketFactory()
    {
        
    }

    public static ITicketService GetTicketService(string ticketType)
    {
        var instance = new TicketFactory();
        return instance._ticketServices[ticketType];
    }

}

 

이렇게 모듈 형태로 개발했었다.

 

당신은 어떻게 생각하는가?

5000줄을 짜는 게 문제가 아니다.

그걸 디버깅하고 수정하는게 문제다.

 

그럼 왜 5000줄이 만들어 졌을까?

외주로 개발하니까.

아무도 책임지지 않는다.

뒤에 남은 사람도 그저 그 5000줄을 어떻게 할 수 없어서 COPY & PASTE 할 뿐이다.

MSA, 모듈화?

실전에서 그걸 해내는 기업은 소수일 뿐이다.

 

YES24에 진짜 문제는 책임지는 사람도 책임을 지원해 줄 사람도 없다는 것이다.

따라서, 오늘 날에 사고는 이미 2017년에 이미 일어날 일이였을 것이다.

당시에도 사고도 있고 문제도 있었지만 책임있는 사람이 있었다면 (당연히 경영진) 오늘에 이러한 문제는 없었을 것이다.

 

경영진의 무관심

사업부의 현실 무시

사업부간 알력

개발자들의 무력감

 

이 모든게 하나의 소용돌이를 만들었을 것이다.

 

레거시 코드

레거시 인프라

 

한 때는 나도 YES24가 훌륭한 인터넷 서점으로 생각한 적이 있었다.

진취적이고 대단한 회사라고 생각했었다.

 

하지만 직접 다녀보고 나는 현재 YES24 계정을 삭제했다.

 

바뀔 것이라고 생각하지 않는다.

 

가족 회사의 한계와 공무원 생활에 대한 만족감이 만연한 조직에서

시스템을 바꾸고 코드를 바꾸고 사업부에 일정에 쫒겨서 무엇인가 하기 바쁜 조직에서

뭘 어떻게 한다는 말인가...

 

그냥 이대로 사라지던...

현상 유지를 하던...

 

만약 이제 시니어를 향해 가는 사람이라면 가지 말기를 바란다.

 

또, CTO로 자신이 뭔가 바꿀 수 있을 거라 생각하고 가지 말기를 바란다.

 

그냥 그런 회사일 뿐이다.

 

그런데 여기서 한가지 집고 넘어가자.

 

과연 도서 사업, 티켓 사업이 카카오나 네이버, 쿠팡, 11번가 같은 서비스와 같은 규모가 될 수 있을까?

 

될 수 없다.

 

또 도서나 티켓은 로컬 성격이 매우 강한 사업이다.

 

따라서 특정 규모 이상으로 커질 수 없다.

 

이미 도서와 티켓은 인구추세와 더불어 점점 지고 있는 사업이다.

 

그래서 될 수 없다.

내가 깨우친 한 가지는 모든 문제 해결 방법은 문제가 발생했고 인식했기 때문에 해결 방법이 나온 것이다.

사업도 마찮가지라고 생각한다.

규모가 되지 않기 때문에 투자되지 않는 것이다.

 

하지만 그럼에도 불구하고 너무한 측면이 있을 것이다.

 

누군가는 공무원처럼 발전없이 똑같은 오늘을 살기를 바랄 것이다.

 

난 아니다.