DEV Community

Composite
Composite

Posted on

업무상 내 소스를 오픈하는 법

오늘 재밌는 글을 봤는데, 회사의 자산인 프로그램의 전체 소스코드를 Github에 올린 간 큰 놈을 발견했다는 글이었다.

대다나다.

그러지 말자 여러분들.

물론 회사에 기여한 프로그램의 소스는 엄연히 회사 자산이고, 회사 소유다.
하지만, 여기서 자신이 기여한 소스를 오픈소스화할 수 있다.
물론 귀찮다면 개인 노트(에버노트나 노션 등)에다가 스크랩해도 된다.
왜냐면 이런 경우는 회사 기밀 유출로 인정하지 않기 때문이다.
회사의 경우는 한 술 더 떠서, 아예 스크랩할 수 없도록 인터넷을 차단하거나, 실시간 감시를 하는 등 자산보호에 철저한 경우도 있다.
물론 이건 개발하면서 업무기밀자료가 새내가는 게 주요 목표다.
국방부 프로젝트는 한 술 더떠서 재밍(Jamming)까지 걸어 공용 PC 외에 외부 접근을 아예 차단하는 경우도 있다.
이런 경우 나는 그냥... 최대한 쉽지만 어려운 방법을 택한다.
노가다. 이런 식이지.

printf("     * ");
printf("    *** ");
printf("   ***** ");
printf("  ******* ");
printf(" ********* ");
printf("    *** ");
printf("    *** ");
printf("    *** ");
Enter fullscreen mode Exit fullscreen mode

초보와 고수 코딩 차이라 알려진 그 코드다.
저런 코드 괜히 나오는 게 아니다.
그렇다. 메리 크리스마스다.

어쨌든, 자신이 기여한 소스를 자신의 것으로 만들 수 있으며, 이건 엄연히 자신의 것이고, 이 것이 경쟁업체에 사용했다고 자산 보유사가 권리를 주장할 수 없다. 그러려면 자신의 자산에 회사 자산이라는 흔적을 제거하면 되는데, 간단하다. 모른다고? 나를 따르면 된다.

코드 조각에 회사 흔적을 제거하라.

자바를 예로 들겠다. 가장 흔한 경우인데, 바로 패키지명에 회사 패키지가 정의됐다는 것이다.

package com.somecompany.app.does.something;

import ...

@Service
public HumanResourceService {
    @AutoWired
    private HumanResourceDao humanResourceDao;

    public void saveHumanResource(HumanResourceDto dto) {
        ...
    }
}
Enter fullscreen mode Exit fullscreen mode

회사에서는 대충 이런 식으로 클래스를 작성할 것이다. 이 소스가 유용해서 어디서든 써먹고 싶다면, 먼저 해야 할 일은 바로 흔적을 제거하는 것이다.

package me.composite.does.something;

import ...

@Service
public SomethingService {
    @AutoWired
    private DoSomethingDao doSomethingDao;

    public void saveTodo(TodoDto dto) {
        ...
    }
}
Enter fullscreen mode Exit fullscreen mode

자. 이전 소스와 차이가 느껴지는가? 일반적으로 제공되는 리소스 외에 회사 티가 나는 클래스 등의 여러 심볼을 제거했다. 이것만 해도 90%는 성공.
물론 오픈소스가 아니라면 그대로 긁어도 상관은 없는데, 만약 기술을 공유하고 싶다면 이렇게 흔적을 제거하는 것이 좋다. 그래야 보안서약서 가지고 물고 늘어지며 피곤한 일을 벗어날 수 있다는 것이다.

감이 안 잡혀?

막 시작한 개발자라면, 먼저 자신의 상사에게 질문하라. 자신이 기발하게 코드를 작성했는데, 이 기술을 회사 차원에서 공유하는 일은 네임드 업체에서는 흔하고 흔한 일이다.
이럴 때 보통은 독려를 하는 게 보통이다.
하지만 아예 거부하거나 한 술 더떠 협박하는 케이스가 드물지만 있다.
그냥 깔끔하게 질문을 하지 않는게 좋겠지. 그럴 것 같으면.
이럴 때일수록 더욱 더 내가 제안한 첫번째 방법을 연구하라.

내 기술 팁들은 실무에 썼던 걸 공유한다.

ㅇㅇ 맞다. 실제로 실무에서 적용된 코드를 공유하는 것이다.
하지만 회사 티가 나는가? 내가 어디서, 어떻게 코딩했는지.
내 옆에서 내 코드를 주구장창 분석한 사람 아니라면, 모른다.
이정도는 되어야 오픈소스 개발자가 되는 것이다.

개 노뜬금 오픈소스 개발자?

네임드 업체에서 기술블로그에서 기술을 알려주는 글들 보면
다 이런 노하우가 적용되어 있다.
실제로는 회사에 맞게 복잡하거나, 아니면 간단하거나 적용되어 있다.
그리고 공개적으로는, 최대한 정석대로 알려주는 것이다.

어렵지 않지?

어렵지 않다. 오픈소스 개발자는 소스에서 공과 사가 명확히 구분된다.
대부분의 오픈소스는 회사에서 실제로 쓰는 것들이 많다.
거기서 회사의 흔적을 제거하고 오픈소스로 올리는 것이다.
최대한 다른 오픈소스의 라이선스를 존중하면서 말이다.
오픈소스는 코딩 잘하는게 능사가 아니다.
서로를 존중하고, 회사를 존중하며, 자신의 능력을 공유하여 자신을 검증하는 하나의 과정이다.

오픈소스, 매력에 빠져보자.
끗.

...?

Top comments (0)