개발자 어썸블로그

Vitess, 로컬에서 직접 만들어보며 이해하기

2026-08-09T23:15:14+09:00

MySQL 하나로는 데이터를 감당하기 힘들어지는 시점이 옵니다. 유튜브, 슬랙, 깃허브 같은 곳들이 이 문제를 풀 때 쓴 방법 중 하나가 Vitess입니다. Vitess가 뭘 하는 물건인지, 어떤 부품으로 이뤄져 있는지, 그 부품들을 실제로 어떻게 배치해야 하는지를 로컬 Docker 환경에 직접 만들어보면서 정리했습니다. 여기 나오는 구성은 GitHub 저장소에 그대로 올려뒀고, Docker만 있으면 그대로 따라 켤 수 있습니다.

1. Vitess가 뭔가요?

MySQL 하나로는 데이터가 너무 커지거나 쓰기 트래픽이 너무 많아지는 순간이 옵니다. 이때 흔히 쓰는 해법이 샤딩입니다. 데이터를 여러 MySQL로 쪼개서 나눠 담는 거죠. 문제는 샤딩을 직접 하면 애플리케이션 코드가 “이 데이터가 몇 번 서버에 있더라"를 일일이 알아야 해서 지저분해진다는 점입니다.

Plane을 더 편하게 쓰는 크롬 확장, Enhancer for Plane

2026-08-09T22:58:36+09:00

오픈소스 프로젝트 관리 도구 Plane을 팀에 도입해 쓰고 있습니다. 만족스러운 만큼, 매일 부딪히는 작은 아쉬움들도 보입니다.

버그 리포트, 장애 기록처럼 반복해서 쓰는 이슈에 템플릿이 없어서 매번 형식을 다시 씁니다.
슬랙 메시지나 PR 제목에서 본 PROJ-123 같은 이슈 키를 바로 열 방법이 없어서 검색 화면을 거칩니다.
목록과 드롭다운에서 긴 이름이 잘려서 비슷한 항목을 구분하기 어렵습니다.
이슈를 채팅이나 PR에 공유하려면 키, 제목, 주소를 따로따로 복사해야 합니다.

이 아쉬움들을 서버 수정 없이, 브라우저 확장 하나로 메우려고 직접 만든 것이 Enhancer for Plane입니다. Plane(makeplane)용 비공식 크롬 확장이고, Chrome Web Store와 GitHub에 공개되어 있습니다.

설치: Chrome Web Store
소스: github.com/gaerae/enhancer-for-plane

Plane Cloud와 자체 설치 환경에서 모두 동작하고, 사용자가 직접 켠 도메인에서만 실행됩니다. Plane 서버에는 아무것도 설치하거나 수정하지 않습니다.

무엇을 해주나

이슈 키로 바로 열기 (Quick open)

주소창에 issue를 입력하고 한 칸 띄운 뒤 PROJ-123을 치면 해당 이슈가 바로 열립니다. 문서나 채팅에서 키를 발견했다면 드래그해서 우클릭 메뉴로 열 수도 있습니다.

동작 원리는 단순합니다. 이슈 주소에서 키가 들어갈 자리를 {{key}}로 표시한 링크를 등록해 두는 방식입니다.

그래서 Plane만이 아니라 Jira, Linear, GitHub, GitLab 주소도 등록할 수 있고, 키 접두어별로 다른 도구로 보낼 수도 있습니다. ENG-는 Linear로, 나머지는 Plane으로 보내는 식이죠. Jira에서 Plane으로 이주하는 과도기에 두 도구를 오가는 팀이라면 특히 유용합니다.

키 대신 단어를 입력하면 해당 도구의 검색으로 넘어가고, 최근에 연 이슈 목록도 주소창과 팝업에서 바로 다시 열 수 있습니다.

이슈 템플릿 (제목 + 본문)

템플릿을 한 번 등록하면 이슈 설명 편집기 도구 막대의 "Template" 버튼이나 단축키(Alt+T)로 제목과 본문을 한 번에 채웁니다. 본문은 마크다운으로 작성하고, 넣는 순간 변수가 채워집니다.

{{date}}, {{date+7}} 같은 날짜 변수 — 마감일이 들어가는 양식에 유용합니다.
{{var.이름}} 형태의 사용자 정의 변수 — 같은 템플릿을 공유해도 사람마다 자기 값으로 채워집니다.

팀 템플릿 동기화

템플릿을 담은 JSON 파일을 사내 위키든 Git 저장소든 팀이 접근할 수 있는 주소에 올려 두면, 팀원 모두가 같은 템플릿을 내려받아 씁니다. 동기화 주기를 정할 수 있고, 동기화된 템플릿은 읽기 전용이라 원본 한 곳에서만 관리됩니다. 이슈 양식을 팀 표준으로 유지하고 싶은 리더에게 이 기능이 핵심입니다.

참조 복사

이슈 키 옆의 버튼이나 단축키(Alt+C)로 이슈를 원하는 형식으로 복사합니다. 일반 텍스트, 마크다운 링크, 브랜치 이름 세 가지 형식이 기본으로 들어 있습니다. {{item.key}}, {{item.title}}, {{item.url}} 세 값을 조합해 형식을 직접 만들 수도 있습니다. 이슈 키로 브랜치를 만드는 팀이라면 복사 한 번으로 브랜치 이름이 나옵니다.

잘린 이름 넓히기 (스타일 규칙)

Plane은 목록과 드롭다운에서 긴 이름을 잘라 보여줍니다. 확장에 내장된 스타일 규칙 엔진이 선택자와 속성과 값 한 줄로 원하는 너비를 강제해서 이름을 되살립니다.

자주 쓰는 규칙 두 개는 켜진 상태로 제공되고, 개발자 도구 없이 화면에서 요소를 클릭해 규칙을 추가하는 선택기도 들어 있습니다. Plane이 개편되어 선택자가 안 맞게 되어도 해당 규칙만 조용히 무효가 될 뿐 화면이 깨지지 않습니다. 각 규칙이 마지막으로 적용된 날짜를 보여주므로, 어느 규칙이 낡았는지도 바로 알 수 있습니다.

집중 모드

Alt+Shift+F로 양쪽 패널을 접고 이슈 본문만 남깁니다. 긴 설명을 읽거나 쓸 때 유용하고, 탭 단위로만 적용되어 다른 탭에는 영향이 없습니다.

설치와 첫 5분

Chrome Web Store에서 설치하고, Plane 탭에서 확장 아이콘을 눌러 이 사이트에서 사용을 켭니다. 권한은 그 사이트 하나에만 부여됩니다.
설정의 Work items에서 지금 열려 있는 이슈 주소를 붙여 넣습니다. 이 한 번의 붙여넣기로 열기, 검색, 복사가 모두 설정됩니다.
주소창에 issue와 한 칸을 입력해 봅니다. 나머지 기능은 전부 선택 사항입니다.

설계 원칙: 기본은 전부 꺼짐

브라우저 확장은 편리한 만큼 권한이 민감한 도구입니다. 그래서 다음 원칙으로 만들었습니다.

설치 직후에는 아무 사이트에서도 실행되지 않습니다. 사용자가 켠 도메인에서만 동작합니다.
Plane 서버를 수정하지 않습니다. 모든 기능이 브라우저 안에서만 동작합니다.
팀 동기화로 받아온 데이터는 신뢰하지 않는 입력으로 취급해 크기를 제한하고 텍스트로만 렌더링합니다.
설정 전체를 JSON 파일로 내보내고 불러올 수 있어, 기기를 옮겨도 다시 세팅할 필요가 없습니다.

소스가 GitHub에 공개되어 있으니 스토어 대신 소스에서 직접 로드해 쓸 수도 있고, 기능 제안이나 버그 리포트는 저장소 이슈로 남겨 주시면 됩니다.

마치며

정리하면 이렇습니다. Quick open은 어떤 이슈 트래커를 쓰든 그 자체로 이점입니다. Jira든 Linear든 GitHub든, 키가 돌아다니는 곳이라면 주소창 바로가기가 통합니다. 그리고 Plane 오픈소스를 골라 자체 구축한 팀이라면, 템플릿과 스타일 규칙까지 더해 필수 도구에 가깝습니다.

이슈 트래커 자체를 고민 중이라면 함께 정리한 두 글도 참고하세요. Jira vs Linear 비교, 그리고 오픈소스 대안 비교입니다.

도구는 결국 팀의 일하는 방식을 담는 그릇입니다. 어떤 도구를 쓰든, 그 도구가 팀을 관리하게 두지 말고 팀이 도구를 다루는 상태를 유지하시길 바랍니다.

자주 묻는 질문

Q. Plane 공식 확장인가요? 아닙니다. Plane과 무관한 비공식 확장입니다. "Plane"은 해당 소유자의 상표입니다.

Q. 자체 설치한 Plane에서도 되나요? 됩니다. Plane Cloud와 자체 설치 모두 지원하고, 설정에서 해당 도메인을 켜기만 하면 됩니다.

Q. 크롬이 아닌 브라우저에서도 쓸 수 있나요? Manifest V3 기반 크롬 확장이라 크롬 계열(Edge 등 Chromium 기반) 브라우저에서 동작합니다. 크로미움 기반이 아닌 브라우저는 지원하지 않습니다.

Q. 회사 보안 정책상 확장 설치가 걱정됩니다. 소스가 공개되어 있어 감사할 수 있습니다. 사용자가 켠 도메인 밖에서는 실행되지 않고, 외부로 데이터를 보내는 기능이 없습니다. 팀 템플릿 동기화도 사용자가 직접 등록한 주소에서만 내려받습니다.

링크

Jira와 Linear를 대체하는 오픈소스 도구 4가지

2026-08-09T22:41:33+09:00

Plane, OpenProject, Taiga, Redmine을 같은 기준으로 비교하고, 팀 상황별 선택 기준까지 정리합니다.

비용 절감과 자체 구축이 목표라면 오픈소스 이슈 트래커가 답이 됩니다. 데이터를 우리 인프라에 두고, 좌석 비용 없이 시작하고, 필요한 만큼만 손보고, 업그레이드 압박에서 벗어날 수 있기 때문입니다.

Jira를 제대로 써본 사람이라면 압니다. 처음엔 "이 정도면 완벽한데?" 싶다가, 어느 순간부터 도구의 관리자가 되어 있고, 플러그인 하나 추가할 때마다 라이선스 비용이 올라갑니다.

Linear는 가볍고 빠르지만 클라우드 전용이라 데이터를 우리 서버에 둘 수 없고, 인원이 늘면 좌석 비용이 그대로 따라 늘어납니다. (두 도구의 상세 비교는 별도 글로 정리했습니다 → Jira vs Linear 비교)

한눈 요약

도구	라이선스	강점	이런 팀에
Plane	AGPL-3.0	현대적 화면, 속도, Jira와 Linear 가져오기	소프트웨어와 제품 팀
OpenProject	GPL v3	간트, 예산, 시간 추적, 성숙도	고전적 프로젝트 관리가 필요한 조직
Taiga	AGPL-3.0	순수 애자일(스크럼, 칸반) 집중	스프린트 중심으로만 일하는 팀
Redmine	GPL v2	플러그인 생태계, 저사양 서버	직접 손보며 오래 쓸 기술 팀

1. Plane — 지금 가장 빠르게 성장하는 대안

Plane은 Linear의 깔끔함과 Jira의 구조를 절묘하게 섞어 놓은 도구입니다. GitHub 저장소 소개부터 "오픈소스 Jira, Linear 대안"을 내걸고 있고, 3년이 안 되어 GitHub 별 4만 6천 개를 넘겼습니다.

이슈, 사이클(스프린트), 모듈(에픽), 리스트와 칸반과 캘린더와 간트와 스프레드시트까지 다섯 가지 보기, 그리고 문서(Pages)까지 한 공간에서 처리합니다. Jira, Linear, Asana에서 옮겨오는 가져오기 도구가 무료 요금제를 포함한 전 요금제에 들어 있다는 점도 이주를 고민하는 팀에는 실질적인 장점입니다.

가장 큰 매력은 속도와 현대적인 화면입니다. Jira에서 넘어온 사람들이 "드디어 가볍다"고 말하는 경우가 많습니다. Docker나 Kubernetes로 설치하고, 권장 사양이 CPU 2코어에 메모리 4GB 수준이라 작은 서버로도 시작할 수 있습니다.

라이선스와 비용 구조는 이렇습니다. 자체 설치용 Community Edition은 AGPL-3.0이고 사용자 수 제한이 없습니다.

시간 추적, 에픽, 워크스페이스 위키 같은 기능이 필요하면 유료인 Commercial Edition으로 올라갑니다. Pro가 연 결제 기준 좌석당 월 $6로 이 분야에서 가장 낮은 첫 유료 단계입니다. 즉 자체 설치가 아끼는 것은 좌석 라이선스이지 전체 기능이 아닙니다. 이 구조는 알고 시작해야 합니다.

단점이라면 OpenProject만큼 깊은 간트나 예산 관리는 아직 없다는 점, 그리고 세부 사용성에서 Linear보다 부족한 구석이 남아 있다는 점입니다. 그래도 소프트웨어 팀이나 제품 팀이라면 가장 먼저 검토할 도구입니다.

2. OpenProject — 무게감 있는 엔터프라이즈용

OpenProject는 2012년부터 발전해 온 도구라 성숙도가 다릅니다. 간트 차트, 시간 추적, 예산 관리, 회의 관리를 갖추고, 애자일과 워터폴을 한 도구에서 함께 쓰는 하이브리드 방식이 강점입니다.

유럽 공공기관과 규제 산업에서 특히 선호하는 이유가 이 안정성과 기능의 폭입니다. 데이터 주권이 중요한 환경, 그리고 "프로젝트 관리"가 이슈 트래킹보다 넓은 의미인 조직에 잘 맞습니다. Community Edition만으로도 핵심 기능을 충분히 쓸 수 있습니다.

대신 화면은 Plane만큼 세련되지 않았고, 밀도 높은 메뉴 구조 때문에 처음 온 팀원의 적응 기간이 필요합니다. 설치와 관리에도 손이 조금 더 갑니다.

3. Taiga — 애자일에 올인한 팀을 위한 선택

순수하게 스크럼이나 칸반으로만 일한다면 Taiga가 여전히 매력적입니다. 백로그 관리, 스프린트 계획, 번다운 차트, 스토리 포인트 같은 애자일 전용 기능이 깔끔하게 들어가 있고, 화면도 직관적입니다. 팀이 "이슈 트래커"보다 "애자일 보드"를 원한다면 잘 맞습니다.

다만 장기 전망은 신중히 볼 필요가 있습니다. 현재 버전(6.x)의 안정 릴리스는 이어지고 있지만, 개발사가 차기 버전을 별도 저장소에서 처음부터 다시 설계하는 중이라 현재 버전의 기능 확장 속도는 예전만 못합니다. 도구와 함께 커가야 하는 팀이라면 이 점을 감안해야 합니다.

4. Redmine — 오래됐지만 아직도 강력한 베테랑

Redmine은 "오픈소스 Jira의 원조"에 가깝습니다. 2006년부터 이어진 플러그인 생태계가 넓어서 원하는 기능을 거의 다 붙일 수 있고, 저사양 서버에서도 잘 돌아갑니다.

화면이 구식이라는 점은 분명한 단점입니다. 하지만 기술 팀이 직접 손보며 쓰고 싶다면 여전히 강력한 선택지입니다. "우리가 직접 통제한다"는 철학이 강한 팀, 그리고 한 번 세팅한 도구를 10년 쓰는 팀에 맞습니다.

그 외 눈여겨볼 도구들

Leantime: 목표와 전략을 업무와 연결하는 데 초점을 둔 도구. 단순 이슈 트래킹을 넘어 "왜 이 일을 하는가"를 중요하게 생각하는 팀에 적합합니다.
Huly: 프로젝트 관리에 채팅, 문서, 간단한 인사 기능까지 모은 올인원 성격. Linear와 Slack과 Notion을 한 번에 대체하고 싶을 때 검토할 만합니다.
Kanboard / Wekan: 정말 가벼운 칸반 보드만 필요할 때. 복잡함을 극도로 싫어하는 팀에 좋습니다.
GitLab CE의 Issues + Boards: 이미 GitLab을 쓰고 있다면 별도 도구 없이 바로 활용할 수 있습니다.

어떻게 고를까

솔직히 말하면 "최고의 도구"는 없습니다. 팀 상황에 따라 답이 달라집니다.

소프트웨어와 제품 팀이고 화면과 속도가 중요하다 → Plane
간트, 시간 추적, 예산, 하이브리드 방식이 필요하다 → OpenProject
순수 애자일(스크럼, 칸반)에 집중한다 → Taiga
커스터마이징 자유도와 가벼움이 최우선이다 → Redmine
목표 관리나 올인원 플랫폼이 필요하다 → Leantime이나 Huly

가장 좋은 방법은 직접 한두 주 써보는 것입니다. 대부분 Docker로 빠르게 올릴 수 있으니, 실제 워크플로를 옮겨보며 느끼는 것이 문서만 보는 것보다 훨씬 정확합니다.

Jira를 완전히 버릴 필요는 없습니다. 하지만 "이 정도면 충분한데 왜 이렇게 비싸고 무거운가"라는 생각이 들었다면, 위 도구 중 하나를 시험해 보는 것만으로도 팀의 선택지가 크게 넓어집니다.

무엇을 고르든 유용한 도구 하나

어떤 도구를 고르든, 슬랙과 PR에 돌아다니는 이슈 키를 주소창에서 바로 여는 바로가기는 그 자체로 이점입니다. 제가 만든 크롬 확장 Enhancer for Plane의 Quick open 기능이 그 역할을 합니다. Plane만이 아니라 Jira, Linear, GitHub, GitLab 주소도 등록해 쓸 수 있습니다.

그리고 이 글에서 Plane을 골랐다면 이 확장은 필수에 가깝습니다. Plane에 없는 이슈 템플릿, 잘린 이름 넓히기, 참조 복사까지 서버 수정 없이 채워 주기 때문입니다. 자세한 소개는 별도 글로 정리했습니다.

→ Plane을 더 편하게 쓰는 크롬 확장, Enhancer for Plane

자주 묻는 질문

Q. 오픈소스 자체 설치가 정말 무료인가요? 라이선스는 무료지만 서버 비용과 운영하는 사람의 시간이 듭니다. 백업, 업그레이드, 장애 대응을 팀이 직접 감당해야 하므로, Docker 운영이 익숙한 사람이 팀에 없다면 각 도구의 클라우드 요금제와 비교해 판단하는 것이 현실적입니다.

Q. Jira에서 데이터를 옮길 수 있나요? 네. Plane과 Taiga는 공식 Jira 가져오기 도구를 제공하고, OpenProject와 Redmine도 이주 경로가 있습니다. 다만 어떤 도구든 커스텀 워크플로와 자동화까지 그대로 옮겨지지는 않습니다. 이주를 워크플로 재설계의 기회로 삼는 편이 좋습니다.

Q. AGPL 라이선스면 회사에서 써도 되나요? 사내 팀이 내부 용도로 설치해 쓰는 것은 문제가 없습니다. AGPL이 문제가 되는 경우는 소스를 수정해 외부 고객에게 서비스로 제공할 때이고, 이때는 수정한 소스를 공개할 의무가 생깁니다. 상용 서비스에 얹을 계획이 있다면 법무 검토를 거치세요.

확인한 출처

Jira vs Linear, 무엇이 다른가: 철학부터 비용까지

2026-08-09T22:31:30+09:00

이슈 트래커를 고민하는 팀은 대부분 두 이름 사이에서 출발합니다.
업계 표준인 Jira, 그리고 "빠르고 깔끔하다"는 소문의 Linear.

둘은 같은 문제를 푸는 도구지만 설계 철학이 정반대에 가깝습니다. 그래서 기능표만 나란히 놓고 비교하면 오히려 판단을 그르치기 쉽습니다. 이 글은 철학의 차이에서 출발해 기능, 요금, 그리고 팀 유형별 추천까지 순서대로 정리합니다.

한눈 요약

항목	Jira	Linear
출시	2002년 (Atlassian)	2019년 (Linear)
설계 철학	무엇이든 맞출 수 있는 플랫폼	정해진 방식이 있는 도구
강점	커스터마이징, 생태계, 규정 준수	속도, 단축키, 완성된 기본값
약점	무거움, 관리 부담, 숨은 비용	커스터마이징 폭이 좁음, 상위 기능이 요금 상위 단계에 몰림
무료 요금제	10인까지	인원 무제한, 팀 2개와 이슈 250개 제한
첫 유료 단계	Standard 좌석당 월 $7.91부터	Basic 좌석당 월 $10부터
자체 서버 설치	Data Center (연간 견적, 고가)	없음 (클라우드 전용)

철학의 차이가 모든 것을 결정한다

Jira는 플랫폼입니다. 워크플로, 필드, 화면, 권한을 전부 팀에 맞게 조립할 수 있습니다. 소프트웨어 팀뿐 아니라 법무, 인사, 마케팅까지 같은 도구 위에 올릴 수 있죠.

대신 그 유연함은 관리 비용으로 돌아옵니다. 누군가는 워크플로를 설계하고, 필드를 정리하고, 마켓플레이스 앱을 관리해야 합니다. Jira를 오래 쓴 조직에 "Jira 관리자"라는 역할이 생기는 이유입니다.

Linear는 도구입니다. 이슈는 이렇게 흘러야 하고, 스프린트(Linear 용어로는 사이클)는 이렇게 돌아야 한다는 의견이 제품에 박혀 있습니다. 설정할 것이 적으니 켜자마자 빠르고, 모든 동작에 단축키가 있고, 화면 전환이 즉각적입니다. 대신 "우리 팀만의 워크플로"를 만들 자유는 제한적입니다. Linear의 방식이 팀과 맞지 않으면 도구를 팀에 맞추는 게 아니라 팀이 도구에 맞춰야 합니다.

이 차이를 받아들이면 나머지 비교는 대부분 따라옵니다.

기능 비교

이슈 모델과 계층

Jira는 에픽, 스토리, 태스크, 서브태스크 계층에 원하는 이슈 타입을 추가할 수 있습니다. Premium 이상에서는 여러 프로젝트를 묶는 상위 계획(Plans) 기능이 붙습니다.

Linear는 이슈, 프로젝트, 이니셔티브로 계층이 고정되어 있습니다. 계층을 늘릴 수는 없지만, 고정된 만큼 화면과 검색이 일관됩니다.

워크플로와 자동화

Jira의 자동화는 강력하지만 요금제별 실행 횟수 제한이 있습니다. Standard는 월 실행 횟수가 팀 전체 공유로 묶여 있어, 자동화를 적극적으로 쓰는 팀은 이 한도 때문에 Premium으로 올라가는 경우가 많습니다.

Linear는 자동화라는 별도 메뉴 대신 제품 곳곳에 규칙이 내장된 방식입니다. Git 브랜치 이름으로 이슈 상태가 바뀌고, PR이 병합되면 이슈가 닫히는 식의 개발 워크플로 연동이 기본값입니다.

보고와 인사이트

Jira는 번다운, 벨로시티, 누적 흐름 등 애자일 보고서가 방대하고, JQL(Jira Query Language)로 어떤 조합의 데이터도 뽑아낼 수 있습니다. 대시보드에 의존하는 조직이 Jira를 떠나지 못하는 가장 큰 이유가 JQL입니다.

Linear의 분석 기능(Insights)은 Business 요금제부터 제공됩니다. 시각적으로 잘 다듬어져 있지만 조회 언어 수준의 자유도는 없습니다.

AI

Atlassian은 Rovo라는 이름의 AI 검색과 에이전트를 유료 요금제에 통합했고, Linear는 이슈를 배정받아 일하는 에이전트 플랫폼을 밀고 있습니다. 다만 Linear의 일부 AI 기능은 좌석 요금과 별도의 크레딧으로 계량되므로, AI를 많이 쓸 팀은 요금 계산에 이 항목을 넣어야 합니다.

요금 비교 (2026년 기준)

두 제품 모두 가격이 종종 바뀝니다. 아래 숫자는 글 작성 시점에 공식 요금 페이지에서 확인한 값이고, 결제 전에는 공식 페이지를 다시 확인하세요.

요금제	Jira	Linear
무료	10인까지	인원 무제한 (팀 2개, 이슈 250개)
첫 유료	Standard $7.91/인/월	Basic $10/인/월
상위 유료	Premium $14.54/인/월	Business $16/인/월
최상위	Enterprise 견적	Enterprise 견적 (SAML, SCIM 포함)

몇 가지 주의점이 있습니다.

Jira 가격은 규모에 따라 단가가 내려갑니다. 표기 가격은 소규모 구간 기준이고, 인원이 100명, 250명 구간을 넘어갈 때마다 좌석 단가가 내려갑니다. 반대로 월 결제는 연 결제보다 비싸고, 2025년 하반기부터는 월 결제 요금이 월중 최대 사용자 수 기준으로 청구되는 방식이 적용되어 인원 변동이 잦은 팀에 불리해졌습니다.

Linear는 연 결제가 기본입니다. 공개된 가격이 연 결제 기준이고, 볼륨 할인은 Enterprise 협상 전까지 없습니다. 그리고 SAML SSO 같은 보안 요건이 생기면 Business로는 해결이 안 되고 Enterprise 견적으로 넘어가야 합니다.

Jira의 실제 비용은 라이선스보다 큽니다. 마켓플레이스 앱, 보안 부가 상품, Confluence 같은 연계 제품이 더해지기 때문입니다. 총비용이 기본 라이선스의 2~3배가 된다는 분석이 흔하니, Jira 견적을 낼 때는 라이선스만 보면 안 됩니다.

30인 팀 연간 비용 시뮬레이션

연 결제, 표기 단가 기준의 단순 계산입니다.

구성	연간 비용
Jira Standard 30인	약 $2,850
Jira Premium 30인	약 $5,230
Linear Basic 30인	$3,600
Linear Business 30인	$5,760

기본 라이선스만 보면 큰 차이가 아닙니다. 차이는 부가 비용에서 벌어집니다. Jira는 앱과 연계 제품에서, Linear는 보안 요건이 생기는 순간 Enterprise 협상에서 비용이 뜁니다.

어떤 팀에 무엇이 맞나

Jira가 맞는 팀

개발 외 부서까지 한 도구로 관리해야 하는 조직
감사 로그, 데이터 레지던시 같은 규정 준수 요건이 있는 조직
JQL 기반 대시보드와 보고 체계가 이미 자산인 조직
Confluence, Bitbucket 등 Atlassian 제품을 이미 쓰는 조직

Linear가 맞는 팀

제품과 엔지니어링 중심의 10~150인 팀
도구 관리에 사람을 쓰고 싶지 않은 팀
키보드 중심의 빠른 조작을 팀 문화로 만들고 싶은 팀
이슈 트래커의 정해진 방식을 받아들일 수 있는 팀

비용과 자체 구축을 원한다면, 세 번째 선택지

어느 쪽을 골라도 인원이 늘면 좌석 비용이 그대로 따라 늘고, 데이터는 남의 클라우드에 있습니다. 좌석 비용 없이 쓰면서 데이터를 우리 서버에 두고 싶다면, 두 도구의 비교와 별개로 오픈소스 자체 구축이 답이 됩니다.

Linear의 사용성을 목표로 만들어진 Plane부터, 엔터프라이즈급 기능의 OpenProject, 베테랑 Redmine까지 선택지가 생각보다 넓습니다. 이 대안들을 같은 기준으로 비교한 글을 따로 정리했습니다.

→ Jira와 Linear를 대체하는 오픈소스 도구 비교

자주 묻는 질문

Q. Jira에서 Linear로 데이터를 옮길 수 있나요? Linear가 공식 Jira 가져오기 도구를 제공합니다. 이슈와 기본 메타데이터는 옮겨지지만, Jira의 커스텀 워크플로와 자동화 규칙은 옮겨지지 않으므로 Linear 방식으로 다시 설계해야 합니다.

Q. Linear 무료 요금제로 얼마나 버틸 수 있나요? 인원 제한이 없어서 초기 팀에는 넉넉합니다. 다만 보관(아카이브)하지 않은 이슈 250개가 한도라서, 실제 운영에 들어간 팀은 수개월 안에 한도에 닿는 경우가 많습니다.

Q. Jira를 자체 서버에 설치할 수 있나요? Data Center 라이선스로 가능하지만 연간 수만 달러대 견적의 대형 조직용입니다. Atlassian이 클라우드 전환을 유도하고 있어 신규 도입 명분은 약해지고 있고, 자체 설치가 목적이라면 오픈소스 대안이 현실적입니다.

확인한 출처

남길 것 목록에 목표가 없었다

2026-08-13T00:00:00+09:00

프로젝트를 시작할 때 “이 일이 끝나면 무엇이 남아야 하는가”를 먼저 적어두는 편이다. 그 목록을 팀원들과 맞춰보고 일을 시작한다. “다 끝났다”의 기준이 사람마다 다르다는 걸 몇 번 겪고 나서 생긴 습관이다.

이번에 맡은 건 다른 팀의 제품을 우리 팀이 돕는 일이다. 그런데 무엇을 도와야 하는지가 아직 정해져 있지 않다. 그래서 1차 목표부터 “우리가 뭘 해야 하는지 찾아내기”로 잡았다.

남길 것으로는 두 개를 적었다. 상대 팀과 함께 정한 작업 방식, 그리고 상대 팀과 함께 정한 우리 팀의 역할 범위.

목표를 찾는 게 목표인데, 목록에 목표가 없다

며칠 뒤에 목록을 다시 보다가 이상한 걸 발견했다. 두 줄을 다 채워도 “우리가 뭘 해야 하는지”는 모르는 채로 남는다. 1차 목표의 답이 목록에 없다. 적을 땐 꽤 그럴듯해 보였다(그래서 더 별로다).

문제는 이 목록이 “다 끝났다”의 기준이라는 점이다. 기준에서 1차 목표가 빠져 있으면 두 줄을 채우고 끝났다고 말할 수 있게 된다. 정작 찾아내야 했던 건 못 찾은 채로.

끝난 뒤에 하는 회고도 같은 목록을 본다. 대볼 게 그것뿐이라 목록이 틀려 있으면 회고는 느낌 이야기가 된다. 회고 연구 46개를 묶은 메타분석에서는 제대로 진행한 회고 모임이 이후 성과를 평균 20~25% 높였다. 다만 아무 회고나 그런 건 아니었다. 순서가 정해져 있고, 진행을 맡은 사람이 있고, 목적이 분명할 때 효과가 더 컸다고 한다.

회고의 질은 프로젝트가 끝난 뒤가 아니라 시작할 때 이미 정해지는 것 아닐까?

합의는 흐릿할수록 쉽다

왜 이런 목록을 적었나 되짚어보니, 두 항목이 둘 다 ‘합의’다. 합의를 적어두면 뭔가 정해진 것처럼 보인다. 그리고 둘 다 상대 팀이 있어야 성립한다. 우리 팀 혼자서는 끝낼 수 없다.

그러면 끝났는지를 뭘로 판단하나? 우리가 만든 문서인가, 상대가 바꾼 행동인가. 문서 쪽이 훨씬 쉬워서 자연스럽게 그쪽을 고르게 된다.

“합의를 끝내는 것”이 목표가 되면 서로 다르게 읽을 수 있는 문장에 동의하고 끝났다고 말하게 된다. 해석이 갈린다는 사실은 일을 시작한 다음에야 드러난다. 목표가 눈에 보이는 산출물로 바뀌면 사람은 그걸 만드는 가장 빠른 길을 고른다. 합의서를 빨리 만들려면 아무도 반대하지 않을 문장을 쓰면 된다.

합의했다는 사실 하나로는 아무것도 증명되지 않는다.

근거가 많다는 말과 안전하다는 말은 다르다

그럼 남길 것을 미리 정해두는 방법 자체가 문제인가 싶어 찾아봤다. 좋다는 근거는 어렵지 않게 나온다. 팀 연구 65개를 묶은 메타분석에서는 팀원들이 비슷한 이해를 갖고 있을수록 팀 성과가 높았다. 경영대학원 32개 팀이 시뮬레이션 게임을 한 연구에서는 목적 문서와 실행 계획을 둘 다 잘 만든 팀이 가장 오래 좋은 성적을 유지했다.

그런데 반대쪽 연구도 그만큼 쌓여 있었다. 목표를 구체적으로 정하면 목표 안쪽만 보게 되고, 목표에 없는 일은 방치되고, 위험한 선택이 늘고, 거짓 보고가 늘고, 스스로 하고 싶어 하는 마음이 줄어든다. 다섯 가지가 따로 노는 문제는 아닌 듯하다. 목표가 정해지면 사람은 목표에 필요한 것만 보고 나머지는 시야에서 뺀다. 실험으로 확인된 것도 있다. 목표를 못 채운 사람이 자기 성적을 부풀려 적을 확률이 더 높았고, 아주 조금 못 미쳤을 때 가장 심했다.

내가 겪은 것도 저 목록 안에 있었다. 목표에 없는 일은 방치된다는 것. 남길 것 두 줄을 적는 순간 1차 목표는 그 밖으로 나갔다.

많이 검증된 방법일수록 부작용을 다룬 연구도 같이 늘어난다.

무엇을 미리 확정할지는 일의 종류가 정한다

숫자 목표는 일이 단순할수록 잘 통하고 복잡할수록 효과가 약해진다. 방법을 이미 아는 일에서는 목표가 노력의 양을 늘리지만, 방법을 모르는 일에서는 노력을 늘려도 방법이 생기지 않기 때문이다.

그래서 새롭고 복잡한 일에서는 배움을 목표로 둔 쪽이 숫자를 목표로 둔 쪽보다 결과가 좋았다. 참가자 189명이 제품을 개발한 실험에서는 차이가 더 갈렸다. 배움을 목표로 한 쪽은 여러 방법을 떠올려 더 새로운 결과를 냈고, 숫자를 목표로 한 쪽은 빨리 하나로 정해서 더 쓸모 있는 결과를 냈다.

지금 새로움이 필요한지 쓸모가 필요한지를 먼저 판단해야 목표의 종류를 고를 수 있다. 우리 일은 뭘 해야 할지부터 찾는 단계다. 새로움 쪽에 가깝다.

그런데 1차 목표는 “찾아내기”로 잡아놓고, 남길 것은 이미 다 정해진 일처럼 적었다. 남을 돕는 일이니 할 일은 분명한 쪽이겠지 하고 손이 먼저 움직인 것 같다.

무엇을 만들지 이미 정해진 일에서는 결과물과 확인 기준을 자세히 정할수록 좋다. 아직 찾는 중인 일에서는 “끝났을 때 무엇을 알게 되는가”와 “언제 그만둘 것인가”를 정하고 결과물의 모양은 열어둬야 할 것 같다.

세 줄을 더 적었다

끝났을 때 무엇을 알게 되는가, 하지 않을 일, 그리고 다시 볼 시점.

첫 줄이 비어 있던 1차 목표의 자리를 대신한다. 찾아낸 목표를 지금 적을 수는 없으니(적을 수 있었으면 이 프로젝트를 안 했겠지) 무엇을 알아낸 상태로 끝날지를 적었다.

할 일만 적으면 서로 다르게 이해한 부분이 그대로 숨는다. 하지 않을 일을 적으면 그 자리에서 의견 차이가 나온다(이건 적어보니 바로 효과가 있었다).

다시 볼 시점을 미리 정해두는 건 결정을 약하게 만드는 게 아니라 되돌릴 수 있게 만드는 일이다. 공개적으로 한 합의는 팀을 안정시키는 동시에 되돌리는 비용도 같이 올린다. 경영대 학생 240명이 투자 결정 역할극을 한 오래된 실험에서는 처음 결정을 자기가 내린 사람일수록 결과가 나쁘게 나와도 돈을 더 많이 넣었다.

목록은 다섯 줄이 됐다. 이 일이 끝나고 회고를 할 때 대볼 게 이 다섯 줄이다. 맞게 적었는지는 그때 가봐야 알 것 같다.

레퍼런스

DeChurch & Mesmer-Magnus (2010) 이해를 공유한 팀일수록 성과가 높음. 관계만 본 연구다. 원인으로 단정할 수는 없다.
Mathieu & Rapp (2009) 목적 문서와 실행 계획을 둘 다 갖춘 팀이 성적을 오래 유지. 성과를 직접 올린 쪽은 실행 계획이고, 목적 문서는 함께 있을 때 효과가 났다.
Ordóñez 외 (2009) 목표 설정의 부작용 목록. 실험 논문이 아니라 문제 제기 글이고, 같은 학술지에 반박 글도 실렸다.
Schweitzer, Ordóñez & Douma (2004) 목표를 못 채우면 성적을 부풀려 보고. 대학생 대상 실험실 과제다.
Seijts & Latham (2005) 새롭고 복잡한 일에서는 배움 목표가 유리. 실무자를 위해 정리한 글에 가깝다.
Seijts & Latham (2012) 배움 목표는 새로움, 숫자 목표는 쓸모. 참가자 189명 실험이고 요약문 기준으로 적었다.
Locke & Latham (2002) 목표의 효과는 일의 복잡성과 역량에 따라 달라짐. 목표 연구 35년을 돌아본 글이다.
Tannenbaum & Cerasoli (2013) 제대로 한 회고는 이후 성과를 20~25% 높임. 군대, 병원, 항공 분야 연구가 많이 섞여 있다.
Staw (1976) 자기가 내린 결정일수록 나쁜 결과에도 더 투입. 1976년 역할극 실험이라 지금 회사 상황에 그대로 옮기기에는 거리가 있다.

밑바닥부터 만들면서 배우는 LLM 깃허브 업데이트 안내

2026-08-08T21:26:55+09:00

세바스찬 라시카의 <밑바닥부터 만들면서 배우는 LLM> 도서의 예제 코드가 담긴 깃허브 노트북을 코랩, 파이토치 2.11 버전에서 실행하여 업데이트했습니다. 이번 실행에서는 본문과 부록의 코드와 연습문제 노트북이 포함되어 있습니다. 기존 코드 모두 최신 파이토치 버전에서 오류 없이 실행되는 것을 확인했으니 안심하고 책을 보셔도 좋을 것 같습니다. 3쇄 이전의 도서를 보신다면 블로그 에러타 페이지를 확인해 주세요. 감사합니다!

단점 대신 약점

2026-08-08T10:45:48+09:00

최근, 장기간의 이직 준비에 지친 분과 이야기를 나눴다.
면접 자리에만 가면 말을 제대로 전달하지 못하고, 대화가 수월하게 이어지지 않는다는 점이 자기 단점이라고 이야기하시길래 그건 단점이 아니라 약점일 뿐이라고 말씀드렸다.

요즘 스스로 부족한 점을 발견할 때마다, 일부러 단점이라고 말하지 않으려고 한다.
습관처럼 "이게 내 단점이지"라는 말이 올라오면, 이를 꽉 깨물고 "이건 내 약점이야"라고 생각한다.

영어로 미팅할 수도 없고,
고객이 원하는 것을 포착하는 감각도 떨어지고,
돈을 버는 감각도 뛰어나지 않다.
(요즘은 코딩도 너무 오래 쉬었다.)

예전에는 이런 것들을 모두 내 "단점"이라고 생각했다.
근데 "영어를 못하는 게 내 단점이야"라고 말하면, 영어를 못하는 현재의 상태가 마치 나라는 사람의 결함처럼 느껴졌다.

말은 능력 하나를 설명했을 뿐인데, 듣고 있는 나는 내 전체를 평가받은 것처럼 받아들인다.

반면에 "영어는 지금 내 약점이야"라고 말하면 조금 달랐다.
지금은 영어가 약하다.
그러면 연습하면 된다.
다른 사람의 도움을 받을 수도 있고, 번역 도구를 쓸 수도 있고, 영어가 덜 필요한 다른 능력으로 보완할 수도 있다.
혹은 지금 내 삶에서 중요하지 않다면 우선순위를 뒤로 미룰 수도 있다.
어느 쪽이든 선택지가 생긴다.

단점이라고 부를 때는 자책부터 했는데,
약점이라고 부르면 해야 할 것들을 떠올리게 된다.

물론 단점이라는 말을 아예 없애려는 것은 아니다.
나 자신이나 다른 사람을 해치는 태도는 여전히 단점이라고 생각한다.
무례함.
폭력적인 성향.
잘못을 인정하지 않는 태도.
다른 사람을 반복해서 상처 입히면서도 대수롭지 않게 여기는 태도.
이런 건 "원래 내가 좀 그래"라고 받아들일 일이 아니다.
반성하고 고쳐야 한다.
(내가 그렇다는 건 아니고...)

하지만 아직 잘하지 못하는 능력까지 나의 흠으로 만들고 싶지는 않다.
영어를 못하는 것도,
고객이 원하는 것을 포착하지 못하는 것도,
돈에 대한 감각이 부족한 것도
나라는 사람의 결함은 아니다.
그것은 지금의 내 약점이다.
키워 갈 수도 있고, 때로는 그대로 안고 살아갈 수도 있는 것들이다.

사전에서 두 단어를 어떻게 구분하는지는 여기서 크게 중요하지 않다.
이것은 내가 나를 대하기 위해 만든 언어 규칙에 가깝다.
나는 자주 쓰는 단어가 결국 내 생각을 지배한다고 믿는다.
부족함을 계속 단점으로 부르면, 나는 나를 결함이 있는 사람으로 보게 될 것 같다.
반대로 약점이라고 부르면, 부족함을 외면하지 않으면서도 그 자리에 가능성을 남겨둘 수 있다.

말만 바꾼다고 영어가 늘지는 않는다.
그분이 다음 면접에서 갑자기 말을 잘하게 되는 것도 아니다.

그래도 말이 바뀌면, 그 부족함을 대하는 태도가 바뀐다.
"나는 왜 이것도 못하지?"에서
"이건 지금 내 약점이구나. 어떻게 더 나아질 수 있을까?"로.

그래서 요즘은 이를 꽉 깨물고라도 고쳐 부르려고 한다.
"이게 내 단점이야" 대신, "이건 지금 내 약점이야".

계속 그렇게 부르다 보면, 그 부족함들은 정말로 내가 키워 갈 수 있는 영역이 될 것이라고 믿는다.

내가 나를 부르는 말이, 내가 나를 대하는 방식이 될 테니까.

[SE-0535] Add CLI for editing global mirrors configuration

2026-08-08T20:44:33+09:00

안녕하세요. 그린입니다
이번 포스팅에서는 SE-0535 — 전역 mirrors 설정을 위한 CLI 추가에 대해 정리해보겠습니다

Intro

Proposal: SE-0535

Author: Samuel Murray

Review Manager: Tim Condon

Status: Accepted

Implementation: swiftlang/swift-package-manager#9950

SPM은 로컬(프로젝트 단위)과 공유(사용자 단위) mirrors 설정을 둘 다 지원하지만, CLI로는 로컬 설정 파일만 편집할 수 있었어요.

이 제안은 기존 CLI에 전역 설정을 편집할 수 있는 --global 플래그를 옵션으로 추가합니다.

Motivation

원래 mirrors는 최초 제안에서 설명된 대로 프로젝트별 로컬 설정만 가능했어요.

이후 릴리스에서 전역 설정 파일 지원이 추가됐는데, 처음부터 로컬/전역 설정을 모두 지원해온 package registry의 디자인을 따른 거예요.

mirrors와 package registry의 전역 설정 파일은 특정 패키지를 항상 커스텀 URL에서 받아와야 하는 엔터프라이즈 환경에서 특히 유용해요.

게다가 곧 추가될 바이너리 타깃 미러링 지원으로 전역 설정의 유용함은 더 커질 예정입니다.

하지만 현재는 전역 mirrors 설정을 쉽게 편집하고 확인할 방법이 없어요.

유일한 방법은 설정 파일을 직접 만들고 손으로 편집하는 것뿐이죠.

이걸 위한 CLI를 제공하면 이미 있는 전역 package registry 기능과 결을 맞추면서, 전역 mirrors 설정의 발견 가능성도 높일 수 있습니다.

Proposed Solution

로컬 설정 파일을 다루는 기존 CLI는 다음과 같아요.

swift package config set-mirror
swift package config unset-mirror
swift package config get-mirror

이 제안은 이 명령어들 각각에 선택적인 --global 플래그를 추가합니다.

예시

https://example.com/file.json의 mirror를 전역으로 추가하려면:

$ swift package config set-mirror --global --original https://example.com/file.json --mirror https://internal.com/file.json

그러면 ~/.swiftpm/configuration/mirrors.json에 아래 내용이 추가돼요. (파일이 없으면 새로 만듭니다)

{
  "object" : [
    {
      "mirror" : "https://internal.com/file.json",
      "original" : "https://example.com/file.json"
    }
    // ...
  ],
  "version" : 1
}

이 설정을 확인하려면:

$ swift package config get-mirror --global --original https://example.com/file.json
https://internal.com/file.json

설정을 해제하려면:

$ swift package config unset-mirror --global --original https://example.com/file.json

package registry용 CLI에서 아이디어를 얻어서, 이 명령어들 각각에 --global 플래그를 추가하자고 제안해요.

예를 들면 swift package config set-mirror --global [...] 이렇게요.

이 플래그와 함께 쓰면 명령어는 전역 설정 파일만 고려하게 됩니다.

이 플래그를 쓰면 명령어를 어느 디렉터리에서든 실행할 수 있어요.

반면 지금의 (플래그 없는) 명령어는 현재 디렉터리나 그 상위 디렉터리 어디에도 Package.swift가 없으면 실패하죠.

현재 swift package config get-mirror의 동작은, 로컬 설정 파일이 비어 있거나 없으면 전역 설정 파일을 읽는 방식이에요.
제안자는 이 동작을 그대로 두자고 제안합니다.
로컬 설정이 하나라도 있으면 전역 설정을 완전히 무시하는 것보다, 로컬을 더 높은 우선순위로 두고 로컬/전역을 병합하는 게 더 합리적이라고 생각하지만, 이건 이 제안과는 다소 별개의 주제라 후속 제안으로 다루는 게 좋겠다고 봤다고 합니다!

Detailed Design

--global 플래그와 함께 쓰는 모든 명령어는 어느 디렉터리에서든 사용할 수 있어요.

즉, 현재 디렉터리(또는 그 상위 디렉터리)에 Package.swift 파일이 있을 필요가 없습니다.

--global 플래그 없이 쓰면 모든 명령어의 동작은 기존과 동일합니다.

set-mirror

$ swift package config set-mirror --help
OVERVIEW: Set a mirror for a dependency.

USAGE: swift package config set-mirror [--global] [--original ] [--mirror ]

OPTIONS:
  --global                Apply settings to all projects for this user.
  --original    The original url or identity.
  --mirror        The mirror url or identity.
  --version               Show the version.
  -h, -help, --help       Show help information.

이 명령어를 실행하면 ~/.swiftpm/configuration/mirrors.json에 mirror 설정을 추가하거나, 파일이 없으면 새로 만듭니다.

unset-mirror

$ swift package config unset-mirror --help
OVERVIEW: Remove an existing mirror.

USAGE: swift package config unset-mirror [--original ] [--mirror ]

OPTIONS:
  --global                Apply settings to all projects for this user.
  --original    The original url or identity.
  --mirror        The mirror url or identity.
  --version               Show the version.
  -h, -help, --help       Show help information.

이 명령어를 실행하면 ~/.swiftpm/configuration/mirrors.json에서 일치하는 mirror 설정을 제거해요.

일치하는 항목이 없거나 파일이 없으면 에러 메시지를 표시합니다.

get-mirror

OVERVIEW: Print mirror configuration for the given package dependency.

USAGE: swift package config get-mirror [--original ]

OPTIONS:
  --global                Only read settings applied to all projects for this user.
  --original    The original url or identity.
  --version               Show the version.
  -h, -help, --help       Show help information.

이 명령어를 실행하면 ~/.swiftpm/configuration/mirrors.json에서 일치하는 mirror 설정을 가져와요.

일치하는 항목이 없거나 파일이 없으면 에러 메시지를 표시합니다.

Security

이 제안이 보안에 미치는 영향은 미미해요. 사용자 홈 디렉터리에 있는 파일을 수정하거나 읽는 정도입니다. mirrors의 최초 제안에서는 전역 설정이 "예상 못한 함정" 같은 순간을 만들 수 있다는 우려가 있었지만, SPM에 전역 mirrors 설정 지원이 이미 추가된 상태라 이 CLI를 추가한다고 해서 새로운 이슈가 생기진 않습니다.

Impact on Existing Packages

이 제안은 기존 패키지에 아무런 영향을 주지 않아요. 새 CLI 플래그를 추가할 뿐, 기존 동작은 전혀 바뀌지 않습니다.

Conclusion

작지만 실용적인 CLI 개선이에요. 그동안 전역 mirrors 설정을 편집하려면 ~/.swiftpm/configuration/mirrors.json을 직접 손으로 만지는 수밖에 없었는데, --global 플래그 하나로 set-mirror, unset-mirror, get-mirror를 어느 디렉터리에서든 쓸 수 있게 됐어요.

엔터프라이즈 환경에서 특정 패키지를 항상 내부 URL로 받아오게 설정해두고 싶을 때, 그리고 곧 추가될 바이너리 타깃 미러링과 함께 쓰기에도 훨씬 편리해질 것 같습니다

References

swift-evolution/proposals/0535-global-mirrors-configuration-cli.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

Muse Glimmer 30B vs Gemma 4 31B — DGX Spark 실측 벤치마크

2026-08-12T10:15:00+09:00

DGX Spark를 조금 느리게 쓰기로 한 이유

2026-08-11T01:53:39+09:00

Unsloth DeepSeek V4는 정말 2배 빠를까? DGX Spark 두 대에서 확인해봤다

2026-08-08T00:24:51+09:00

나는 남 부끄럽지 않게 일하고 있을까

2026-08-09T18:00:00+09:00

인테리어라는 건 참 어렵다. 집을 고치려고 하면 공사 자체보다 사람에 대한 걱정이 먼저 생긴다. 공사하는 동안 자주 가서 확인해야 한다고 하고, 가능하면 돈은 나중에 주는 게 좋다는 이야기도 듣는다. 내가 현장에 없으면 대충하지 않을까, 내가 잘 모르는 부분이라고 적당히 넘어가지는 않을까, 돈을 이미 받았으니 이 정도면 됐다고 생각하지는 않을까. 결국 신뢰의 문제다. 그래서 사람들은 인테리어 업자들을 욕한다. 어떻게 돈을 받고 이렇게 대충 할 수 있느냐고, 조금만 더 신경 쓰면 되는 일을 왜 이렇게 했느냐고, 본인 집이라면 이렇게 했겠느냐고 말한다. 나 역시 인테리어와 관련된 이야기를 듣다 보면 비슷한 생각을 하게 된다. 그런데 한편으로는 이런 생각도 든다. 우리는 정말 저 사람들과 다른가. 물론 안 그런 사람들이 많다. 일부다. 일부. 하지만 그 말을 잠시 빼고 생각해보면, 나 역시 그 질문에서 완전히 자유롭지는 않은 것 같다. 우리는 다른 사람이 만든 결과물을 볼 때는 꽤 엄격하다. 돈을 받았으면 그만큼 잘해야 한다고 생각하고, 조금이라도 허술한 부분이 보이면 "조금만 더 하면 되는 걸 왜 이렇게 했을까"라고 생각한다. 그런데 정작 내가 무언가를 만들 때는 꽤 많은 이유를 가지고 스스로를 이해시킨다. 시간이 부족했으니까. 사람이 부족했으니까. 일정이 촉박했으니까. 다른 일이 더 중요했으니까. 고객이 요구사항을 계속 바꿨으니까. 회사에서 이 정도를 원했으니까. 어쩌면 모두 사실일 것이다. 실제로 일을 하다 보면 내가 원하는 만큼 결과물에 시간을 쏟을 수 없는 상황은 흔하다. 모든 일을 완벽하게 만들 수는 없고, 모든 일에 내 능력의 최대치를 쏟아부으며 살 수도 없다. 게다가 회사에서 일하다 보면 이런 생각이 드는 것도 너무 자연스럽다. 내가 왜 남 좋은 일을 해야 하지? 내가 조금 더 열심히 일한다고 해서 결국 더 많이 가져가는 건 대표나 주주 아닌가. 회사가 더 성장하고 매출이 늘어난다고 해서 그 과실이 나에게 그대로 돌아오는 것도 아닌데, 내가 왜 굳이 내 시간과 에너지를 더 써야 할까. 월급을 받는 만큼만 하면 되는 것 아닌가. 나는 이 생각 자체가 잘못됐다고 생각하지 않는다. 오히려 너무 당연한 질문이라고 생각한다. 회사에 내 삶을 전부 바칠 이유는 없다. 대표를 위해 희생할 필요도 없고, 회사가 잘되기 위해 내 삶의 중요한 것들을 포기할 필요도 없다. 더 많은 일을 한다고 해서 반드시 더 좋은 사람이 되는 것도 아니다. 내가 받는 보상과 역할에 맞는 수준을 요구하고, 정해진 시간에 일하고 퇴근하는 것도 충분히 정당한 태도다. 그런데 여기서 한 가지는 구분해야 하지 않을까 싶다. 회사를 위해 더 희생하지 않는 것과, 내가 맡은 일을 대충 하는 것은 같은 이야기가 아니다. 내 시간을 더 주지 않을 수 있다. 야근하지 않을 수도 있고, 회사가 더 성장할 수 있는 기회가 보인다고 해서 그것을 내 삶의 희생으로 해결할 필요도 없다. 하지만 내가 일하기로 한 시간 동안 내가 할 수 있는 일을 굳이 낮은 수준으로 만들어야 하는지는 또 다른 문제다. 나는 이 차이가 꽤 중요하다고 생각한다. 회사에 내 시간을 더 주는 것은 회사에 대한 추가적인 헌신일 수 있다. 하지만 내가 가진 능력을 제대로 사용하는 것은 조금 다른 문제다. 내가 알고 있는 더 나은 방법을 굳이 외면하고, 조금만 더 신경 쓰면 좋아질 부분을 "월급만큼 했으니까"라는 이유로 그냥 넘기는 순간부터는 회사와의 관계를 넘어 내 자신에 대한 이야기가 된다. 그래서 월급이 적다고 해서 결과물까지 그만큼 대충 만들어도 된다는 생각에는 선뜻 동의하기 어렵다. 그렇다고 월급을 많이 받으니 더 많이 희생해야 한다는 이야기도 아니다. 월급은 회사와 내가 합의한 노동의 대가이고, 내가 만든 결과물은 그 노동의 결과로 남는 것이다. 둘 사이에는 분명 관계가 있지만, 내가 받은 돈이 결과물의 품질을 대신 결정해주지는 않는다. 물론 좋은 결과물을 만드는 데에는 환경이 중요하다. 충분한 시간이 주어지는지, 사람이 있는지, 필요한 도구를 쓸 수 있는지, 제대로 판단할 수 있는 권한이 있는지에 따라 결과물은 달라진다. 계속해서 일정이 부족하고 자원이 주어지지 않는다면 아무리 잘하고 싶은 사람이라도 포기해야 하는 것들이 생긴다. 그러니 결과물의 품질을 오로지 개인의 의지나 성실함으로만 이야기하는 것도 공정하지 않다. 다만 그런 조건들이 내가 만든 결과물에 대한 설명은 될 수 있어도, 결과물 자체를 바꿔주지는 않는다. 시간이 부족해서 여기까지밖에 못 만들었다면 그렇게 판단한 것이다. 그렇다면 적어도 나는 그 결과물이 충분히 좋은지 아닌지는 알고 있어야 하지 않을까. "이 돈 받고 이 정도면 됐지"라는 말로 결과물에 대한 아쉬움까지 없던 일로 만들어버릴 필요는 없다는 것이다. 결국 내가 만든 것은 그대로 남는다. 회사가 얼마를 벌었는지와 별개로, 고객이 얼마나 만족했는지와 별개로, 내가 얼마를 받았는지와도 별개로 결과물은 남는다. 그리고 그 결과물을 만든 과정에서 내가 어떤 판단을 했는지도 결국 내 경험으로 남는다. 개인사업자라고 해서 무조건 더 좋은 결과물을 만들어야 하는 것도 아닐 것이다. 반대로 회사원이라고 해서 자기 것이 아니니 적당히 해도 되는 것도 아닐 것이다. 결국 자기 사업인지 아닌지가 본질은 아닌 것 같다. 내가 만든 것을 다시 봤을 때 스스로 납득할 수 있는가에 더 가까운 문제인 것 같다. 여기서 조금 불편한 질문이 하나 생긴다. 나는 남 부끄럽지 않게 일하고 있을까. 남들이 나를 어떻게 평가하는지를 묻는 질문은 아니다. 상사가 만족하는지, 고객이 칭찬하는지, 시장에서 성공했는지를 묻는 것도 아니다. 내가 만든 결과물을 누군가 앞에 꺼내놓으면서 "나는 이 정도로 일하는 사람입니다"라고 말해도 괜찮은가를 묻는 것이다. 이 질문이 불편한 이유는 내가 어디에서 타협했는지를 내가 알고 있기 때문이다. 다른 사람은 모를 수도 있다. 고객은 모를 수도 있고, 상사는 더더욱 모를 수도 있다. 하지만 나는 안다. 이 부분은 조금만 더 다듬었으면 좋았다는 것도 알고, 이 부분은 사실 귀찮아서 넘어갔다는 것도 알고, 이 부분은 시간이 없어서 어쩔 수 없었다는 것도 안다. 그래서 결과물에 대한 가장 엄격한 평가는 어쩌면 다른 사람이 아니라 나 자신에게서 시작되는지도 모르겠다. 그것이 꼭 회사에 대한 충성심일 필요도 없고, 더 많은 일을 하겠다는 약속일 필요도 없다. 그냥 내가 내 일을 바라보는 기준에 대한 이야기다. 회사에 내 시간을 더 주지 않더라도, 내가 일하기로 한 그 시간만큼은 내가 가진 능력을 제대로 사용하는 것. 나는 그것과 회사에 헌신하는 것을 굳이 같은 것으로 볼 필요는 없다고 생각한다. 그렇다고 모든 결과물을 완벽하게 만들자는 이야기는 아니다. 나 역시 그렇게 살고 싶지는 않다. 시간도 필요하고 돈도 필요하고 내 삶도 중요하다. 회사가 요구하는 모든 일을 내 일처럼 끌어안고 살 필요도 없다. 좋은 결과물을 만드는 것과 자기 삶을 갈아 넣는 것은 전혀 다른 이야기다. 오히려 중요한 것은 내가 무엇을 포기했는지를 알고 있는 것인지도 모른다. 시간이 없어서 여기까지 한 것과 그냥 이 정도면 됐다고 생각해서 여기까지 한 것은 다르다. 전자는 현실적인 판단이고, 후자는 나의 기준일 수 있다. 내가 더 잘할 수 있다는 것을 알고도 다른 이유를 붙여 넘어갔다면, 적어도 그 사실만큼은 스스로에게 솔직해야 한다. 그리고 그다음은 결국 내가 할 일이다. 결과물이 마음에 들지 않는다면, 그 불편함을 그냥 넘기지 않고 무엇이 부족한지 들여다봐야 한다. 실력의 문제라면 배우고, 경험의 문제라면 더 부딪혀보고, 기준의 문제라면 더 좋은 결과물을 찾아봐야 한다. 잘한다고 생각해도 더 좋은 것이 없는지 찾아봐야 하고, 다른 사람이 나보다 훨씬 좋은 결과물을 만들었다면 왜 좋은지 들여다봐야 한다. 그리고 다음에는 조금 더 잘 만들면 된다. 인테리어 업자에게 "본인 집이라면 이렇게 했겠어요?"라고 묻는 것처럼, 우리에게도 비슷한 질문을 해볼 수 있을 것 같다. 내가 이 서비스를 직접 쓴다면 이렇게 만들었을까. 내가 이 디자인을 내 이름을 걸고 보여줘도 괜찮을까. 내가 이 시스템을 앞으로 몇 년 동안 직접 사용해야 한다면 지금처럼 만들었을까. 결국 직업은 크게 중요하지 않다. 인테리어를 하든, 코드를 짜든, 디자인을 하든, 글을 쓰든, 제품을 만들든 누군가에게 돈을 받고 무언가를 만든다는 점에서는 비슷하다. 그래서 다른 사람의 결과물을 보며 "어떻게 돈 받고 이렇게 하지?"라고 말하기 전에 한 번쯤 내 결과물을 돌아볼 필요가 있다. 나는 정말 내가 받은 만큼 하고 있는가. 아니면 그보다 못하고 있는가. 조금만 더 잘할 수 있다는 것을 알면서도 그냥 넘어가고 있지는 않은가. 그리고 내가 만족하지 못한다는 사실을 일정이나 월급이나 회사나 고객 같은 수많은 이유 뒤에 그냥 묻어버리고 있는 것은 아닌가. 아마 나도 항상 남 부끄럽지 않게 일한다고 말하기는 어려울 것이다. 나 역시 적당히 타협한 적이 있고, 귀찮아서 넘어간 적도 있고, 시간이 없다는 이유로 포기한 적도 있다. 중요한 것은 그런 일이 없도록 완벽해지는 것이 아니라, 적어도 내가 그것을 알고 있는 것인지도 모르겠다. 내가 만든 결과물을 다시 봤을 때 마음 한구석이 불편하다면, 그 불편함을 너무 빨리 다른 이유로 덮어버리지 않는 것 말이다. 모든 결과물이 완벽할 필요는 없다. 모든 일을 최선을 다할 필요도 없다. 다만 내가 만든 것을 누군가에게 내놓으면서 "이게 지금 내가 할 수 있는 만큼은 제대로 한 결과물입니다"라고 말할 수 있었으면 좋겠다. 부족하다면 인정하고, 공부하고, 다음에 더 잘하면 된다. 잘 만들었다면 거기서 멈추지 않고 더 좋은 것을 찾아보면 된다. 어쩌면 장인정신이라는 것도 거창한 것이 아닐 것이다. 매일 밤늦게까지 일하는 것도 아니고, 회사에 헌신하는 것도 아니다. 내가 만든 것을 남 앞에 내놓았을 때 남 부끄럽지 않은 것. 그리고 만약 부끄럽다면 그 사실을 그럴듯한 이유로 덮어버리지 않는 것. 결국 내가 만든 결과물에는 내가 일하는 방식과 내가 가진 기준이 어느 정도는 남기 때문이다. 그래서 다른 사람의 일을 보며 쉽게 실망하거나 화가 날 때면, 나에게도 같은 질문을 해보려고 한다. 나는 남 부끄럽지 않게 일하고 있을까. 아마 매번 그렇다고 대답할 수는 없을 것이다. 그렇다면 적어도 무엇이 부끄러운지는 알고 있어야겠다. 그리고 그다음에는 조금 더 잘하면 된다. 그것이 지금 내가 생각하는, 일을 잘한다는 것에 가장 가까운 모습이다.