인턴으로 일하는 중인데, 몇 달 동안 시행착오 겪으면서 정리해둔 프롬프트 문서가 있어요. 카테고리별로 나눠서 결과 비교까지 기록해둔 거라 나름 애착이 있는데, 팀장님이 팀 노션에 그대로 올려두라고 하시네요. 업무 중에 만든 거니 회사 자산인 건 맞는데, 아무 얘기 없이 통째로 넘기는 게 맞나 싶습니다. 정중하게 일부만 공유하겠다고 말씀드려도 괜찮을까요? 다들 이런 경우 어떻게 정리하셨는지 궁금합니다.
제가 정리한 프롬프트, 팀장님이 공유하라는데 거절해도 되나요?
9.1 11:11조회수 0댓글 5
저작권 얘기는 잠깐 접어두고, 실무 기준으로만 보면 업무시간에 만든 문서는 회사 자산이 맞아서 거절 자체는 거의 안 먹힙니다. 대신 '어떻게' 넘기느냐는 조율 여지가 있어요. 저희 팀에서 3D 쪽 셰이더 세팅값이랑 렌더 프리셋 정리한 거 넘길 때 그렇게 했습니다. 원문 그대로 던지지 말고, 문서 상단에 작성자랑 정리 기간 명시하고 버전 히스토리 남기세요. 결과 비교 기록까지 있으시다니 그 부분이 오히려 무기입니다. 프롬프트 목록만 있으면 누가 만들었는지 금방 흐려지는데, 왜 이 값이 나왔는지 비교 로그가 붙어 있으면 그 문서는 계속 님 이름으로 굴러갑니다. 인턴이시면 이런 게 평가 근거로도 남고요. 일부만 공유는 나중에 "왜 뺐냐" 소리 나올 수 있어서 저는 비추합니다.
저는 브랜드 쪽이라 프롬프트 문서를 그렇게 체계적으로 쌓아본 적은 없는데, 몇 년 전에 비슷한 기분을 느낀 적이 있어요. 시안 만들면서 나름대로 정리해둔 레퍼런스 폴더가 있었는데, 그걸 팀 공용 드라이브에 통째로 올리라고 하셨을 때 왠지 손해 보는 것 같았거든요. 지금 돌아보면 그때 아쉬웠던 건 자료 자체보다 "이거 준호님이 몇 달 걸려 만든 거네요"라는 말 한마디가 없었던 거였어요. 그래서 일부만 공유하겠다고 하기보다는, 올리면서 문서 맨 위에 작성 배경이랑 시행착오 과정을 적어두는 쪽이 더 나았을 것 같다는 생각이 들어요. 카테고리별 결과 비교까지 있으면 그 기록 자체가 준호님 역량을 보여주는 자료가 되니까요. 다만 인턴 신분에서 어디까지 말씀드릴 수 있는지는 저도 확신이 없어서, 다른 분들 의견이 궁금하네요.
저희 팀은 프롬프트 문서 공유하고 나서 3개월쯤 지나니까 원본 버전은 거의 안 남고 다들 자기 방식대로 뜯어고쳐서 쓰더라고요. 결과 비교까지 기록해두셨다는 건 그냥 문서가 아니라 몇 달치 실험 로그인데, 그게 노션에 통째로 올라가면 맥락 없이 복붙만 되는 게 좀 아깝긴 하겠어요. 거절 여부보다는 넘길 때 형태를 정하시는 게 낫지 않을까 싶습니다. 정리한 사람 이름 남기고, 카테고리 설명이랑 실패 케이스는 왜 실패했는지 코멘트 붙여서 올리면 문서 성격이 달라지거든요. 나중에 팀에서 그 문서 얘기 나올 때 누가 만들었는지 자연스럽게 따라붙고요. 정중하게 일부만 드린다고 하면 팀장님 입장에선 이유를 되물으실 것 같은데, 그 질문에 답할 명분이 준비돼 있으신가요?
저도 인턴 때 폴더째 정리해둔 리서치 문서를 팀 드라이브에 올리라는 얘기 듣고 며칠 뜸 들였던 기억이 나요. 근데 저는 그냥 리서치라서 준호님처럼 카테고리 나누고 결과 비교까지 쌓아둔 문서는 아니었어서, 그 애착이 어느 정도일지 짐작만 될 뿐이네요. 3년차 된 지금도 이런 상황이 오면 어디까지가 회사 자산이고 어디부터가 내 방법론인지 선을 못 긋겠어요. 그래서 저도 다른 분들 답변이 궁금합니다. 혹시 팀장님이 공유를 요청하신 이유는 들어보셨어요? 팀 전체가 쓰려는 건지, 아니면 준호님 작업 방식을 참고하고 싶으신 건지에 따라 얘기 꺼내기가 좀 달라질 것 같아서요.
저는 브랜딩 쪽이라 프롬프트를 그렇게 카테고리별로 나눠서 결과 비교까지 기록해두신 건 좀 놀라웠어요. 몇 달 동안 쌓아온 거면 애착 생기는 게 당연한 것 같고요. 다만 제가 인턴 신분으로 그런 요청을 받아본 적이 없어서 어떻게 말씀드리는 게 맞는지는 잘 모르겠어요. 저라면 그냥 올렸다가 며칠 내내 마음이 개운하지 않았을 것 같아요. 궁금한 게 있는데, 팀장님이 그 문서가 있는 걸 어떻게 아셨을까요. 먼저 보여드린 거였다면 이야기 꺼내기가 조금은 수월할 수도 있겠다 싶어서요. 다른 분들 답변도 저도 같이 기다려볼게요.