이 영상은 Atlassian Jira가 사실상 장악한 이슈 관리 도구 시장에 Linear가 어떻게 진입했는지를 제품 전략, 기술 인프라, 조직 운영, 채용 방식의 관점에서 분석한다. Linear의 핵심은 단순히 "Jira보다 기능이 많은 제품"을 만드는 데 있지 않고, 속도·완성도·사용자 경험을 우선하는 명확한 철학을 일관되게 실행한 데 있었다. 가장 중요한 결론은 좋은 제품을 만들려면 품질을 말로만 강조하는 것이 아니라, 기능 출시 속도나 단기 매출처럼 다른 것을 실제로 포기할 만큼 품질을 우선순위에 놓아야 한다는 것이다.

1. 죽었다고 불린 SaaS 시장과 Jira의 빈틈

영상은 2019년을 배경으로 시작한다. 당시에는 이미 SaaS, 즉 서비스형 소프트웨어 시장이 포화 상태여서 "새로운 것을 만들 수 없다"는 분위기가 있었다. 광고 수익만으로 성공할 수 있던 초기 인터넷 시대와 달리, 특히 기업용 생산성 도구와 개발팀용 이슈 관리 도구 시장은 경쟁이 극도로 치열했다.

Atlassian은 당시 약 250억 달러 가치의 거대 기업이었고, 핵심 제품인 Jira의 경쟁자였던 Trello까지 인수하면서 시장 지배력을 굳혔다. Jira는 많은 개발자가 싫어하면서도, 협업 상대 회사나 다른 팀이 사용하기 때문에 피하기 어려운 제품이었다. 영상은 이를 "애니메이터에게 Adobe가 있다면, 개발자에게는 Atlassian이 있다"는 식으로 비유한다.

"Jira는 어디에나 있다. 다른 팀과 협업하는 순간, 열에 아홉은 Jira를 쓰고 있을 가능성이 높다."

Jira의 문제는 본래 단순해야 할 일이 지나치게 복잡하고 느려진다는 점이었다. 업무 티켓을 수정해도 즉시 반영되지 않고, 수많은 워크플로와 설정, 예외 처리, 느린 동작이 겹치면서 개발자들이 업무 관리 도구 자체를 피하고 싶게 만든다. 반면 Linear는 이 불만이 쌓인 지점을 기회로 봤다.

"충분히 많은 사람이 불평하는 곳에는 기회가 있다."

Linear의 세 공동창업자 카리 사리넨, 주오리 로, 투오마스 아르트만은 Uber, Airbnb 등 대형 기술 기업에서 일한 경험을 갖고 있었다. 이들이 2019년에 Linear를 내놓으며 Jira를 겨냥한 무기는 기능 수가 아니라 품질과 속도였다. Jira가 무겁고 복잡하다면 Linear는 빠르고, 여러 사람이 함께 수정하는 변화도 거의 즉시 반영되며, 의도적으로 단순하고 명확한 작업 방식을 제안했다.

"Jira가 복잡하고 혼란스럽다면, Linear는 집중되어 있고 자기 주장이 분명하다."

2. 기능 하나가 아니라 사용자 한 명으로 좁힌 MVP

일반적인 MVP 조언은 제품에서 가장 가치 있는 기능 하나만 골라 빠르게 출시하라는 것이다. 하지만 영상은 이 조언이 언제나 충분하지는 않다고 말한다. 오늘날 사용자는 기능 하나만 잘하는 제품보다, 자신이 겪는 문제를 전체적으로 해결해 주는 완결된 경험을 기대한다. 제품이 시장에 고려될 최소 조건을 만족한 뒤에도, 속도·가격·디자인 같은 비기능적 장점으로 확실히 차별화해야 한다.

"현대 제품은 단 하나의 기능으로 정의되지 않는다. 고려 대상이 되려면 문제에 대한 전체적인 해결책을 제공해야 한다."

Linear는 기능 범위를 극단적으로 줄이기보다, 사용자 페르소나를 좁혔다. Jira가 대기업 시장을 장악한 상황에서 정면승부를 하는 대신, Linear는 10명 이하의 아주 작은 스타트업을 위한 이슈 관리 도구를 만들기로 했다. 이 선택은 단순히 시장을 작게 잡은 것이 아니라, Linear 팀 자신도 그와 같은 사용자였다는 점에서 강력했다.

"주제 전문가이거나, 자기 자신을 위한 무언가를 만들어야 한다. 그렇지 않으면 아무도 원하지 않는 것을 만들게 된다."

초기 Linear는 중견기업이나 엔터프라이즈 고객을 적극적으로 받지 않았고, 경우에 따라서는 아예 거절했다. 제품이 그 규모를 감당할 준비가 되지 않았으며, 너무 많은 고객을 너무 빨리 온보딩하면 아직 미완성인 제품의 약점만 반복해서 드러날 수 있기 때문이었다.

"사용자에게는 제품의 첫인상을 받을 기회가 한 번뿐이다."

대신 회사는 매주 약 10명의 신규 사용자만 초대했다. 몇 달 동안 일정한 속도로 피드백을 받으며 제품을 다듬었고, 이를 통해 이른 시기에 제품-시장 적합성을 찾아갔다. 투자 유치와 대규모 채용도 제품이 충분히 좋아졌다고 판단할 때까지 미뤘다.

창업자들은 Uber나 Airbnb에서 과도한 성장의 부작용을 경험했기 때문에, 시장 전체를 빠르게 점령하기보다는 특정 사용자 집단을 위한 제품을 건강하게 키우려 했다. 시간이 흐르며 기능과 인프라를 확장한 뒤에야 더 큰 기업 고객을 받아들일 수 있게 됐다. 그 결과 Linear는 적극적으로 투자를 구하지 않았는데도 투자자들이 먼저 찾아왔고, 느린 온보딩 방식에도 불구하고 2년 안에 수익성을 달성했다.

3. 속도의 토대가 된 동기화 엔진

Linear의 기술적 핵심은 공동창업자 투오마스 아르트만이 만든 Sync Engine, 즉 동기화 엔진이다. 그는 핀란드 게임 회사, 중국의 애니메이션 스튜디오, Groupon, Uber 등 여러 회사에서 동기화 시스템을 만든 경험이 있었다. Linear에 합류한 뒤에도 제품 기능을 먼저 만드는 대신, 첫 6개월을 동기화 엔진 구축에 투자했다.

"그가 Linear에서 가장 먼저 한 일이 무엇이었을까? 제품 기능이 아니라, 6개월 동안 동기화 엔진을 만든 일이었다."

이 엔진은 Linear가 빠르고 반응성 높은 협업 제품처럼 느껴지게 만드는 기반이다. 초기 방식에서는 사용자가 Linear 작업 공간을 열 때 사용자, 상태, 이슈, 댓글 등 작업 공간의 데이터를 기기에 내려받아 로컬에 저장했다. 이후 사용자가 이슈 제목을 바꾸거나 담당자를 지정하면, 화면은 서버 응답을 기다리지 않고 즉시 로컬 상태를 변경한다.

React와 MobX의 관찰자 패턴을 사용해 상태가 바뀌면 관련 화면이 자동으로 다시 렌더링된다. 동기화 엔진은 이 변화들을 감지해 백엔드로 전송하고, 동시에 웹소켓을 열어 다른 사용자가 만든 변경도 받아온다. 사용자 화면 관점에서는 내가 바꾼 변경과 다른 사람이 바꾼 변경이 같은 방식으로 처리된다.

"UI의 관점에서는 로컬 변경과 원격 변경이 동일하다."

이 방식의 중요한 특징은 낙관적 업데이트다. 사용자는 서버의 허가를 기다리지 않고 우선 변경 결과를 본다. 이후 GraphQL을 통해 전송된 작업이 백엔드에서 거절되면, 클라이언트는 이전 상태로 되돌린다. 즉시성은 유지하면서도 오류가 있으면 복구하는 구조다.

"클릭하면 바로 바뀐다. 로딩도, 스피너도, 기다림도, 어긋남도 없다."

이 아키텍처는 개발 방식에도 영향을 준다. 엔지니어는 여러 API 엔드포인트와 동기화 처리, 화면별 실시간 업데이트를 일일이 고민하기보다, 제품의 상태를 직접 바꾸는 데 집중할 수 있다. 그 결과 많은 엔지니어가 자연스럽게 제품 엔지니어처럼 행동하게 된다. 즉, "이 API는 어떻게 만들까?"보다 "사용자가 이 흐름을 어떻게 느낄까?"를 더 많이 생각하게 된다.

또한 백엔드 동기화를 끈 채 완전히 로컬에서 새 기능의 상호작용을 먼저 실험할 수도 있다. 사용감이 좋다고 판단되면 검증 로직을 더하고 동기화를 켜서 출시할 수 있다. 서버로 보내는 업데이트를 묶어서 처리할 수 있으므로 서버 비용 측면에서도 일부 이점이 있다.

다만 이 방식은 모든 제품에 맞는 만능 해법이 아니다. 사용자 수와 데이터가 늘자 모든 데이터를 처음부터 내려받는 방식은 더 이상 감당할 수 없었고, Linear는 현재 작업 공간의 뼈대만 먼저 받아온 뒤 이슈와 댓글을 필요할 때 지연 로딩하는 방식으로 바꿨다. 초기 데이터 적재 문제를 해결하기 위해 MongoDB 캐시, 큐 등의 백엔드 구조도 추가했다.

영상은 이 복잡한 기술을 그대로 따라 하라고 권하지 않는다.

"여기서 얻어야 할 교훈은 동기화 엔진을 만들라는 것이 아니다."

"말 타는 사람을 위한 Tinder 프로젝트에 6개월을 쓰며 맞춤형 동기화 엔진을 만들 핑계로 삼지 마라."

진짜 교훈은, 제품의 경쟁 우위를 만들거나 이후 제품 개발에 집중하게 해 주는 핵심 인프라에는 일찍 투자하라는 것이다. Linear의 동기화 엔진은 Jira가 쉽게 복제하기 어려운 속도 우위를 만들었다. Jira가 같은 수준의 경험을 만들려면 기존 코드베이스 전반을 크게 바꾸는 비싼 마이그레이션이 필요할 가능성이 크다.

4. 빠른 제품 실험과 느린 기반 설계의 균형

Linear의 공동창업자들은 겉보기에는 상반된 운영 철학을 갖고 있는 듯하다. 제품 측면에서는 아이디어를 결정한 지 3일 안에 사용자가 기능을 써볼 수 있을 정도로 빠르게 움직이고, 실험하며 배우는 방식을 취한다. 반면 인프라 측면에서는 1년 앞의 필요까지 치밀하게 계획하고, 안정성을 위해 천천히 움직인다.

"우리는 너무 빠르게 출시한다. 뭘 만들지 결정한 지 3일이면 사용자가 기능을 쓰고 있다."

"인프라 수요는 1년 앞까지 세심하게 계획하고, 안정성을 위해 아주 천천히 간다."

영상은 이 두 방향이 충돌하는 것이 아니라 서로를 가능하게 하는 관계라고 설명한다. 제품 팀이 빠르게 움직일 수 있는 이유는 기반 인프라가 견고하기 때문이다. 특히 나중에 바꾸기 어려운, 즉 마이그레이션 비용이 큰 인프라는 초기에 신중하게 선택해야 한다.

Linear는 처음부터 Kubernetes와 Google Cloud를 사용했다. 이는 창업자가 Uber의 초고속 성장 과정에서 겪은 경험과도 연결된다. 그는 Uber 초기 모바일 엔지니어 15명 중 한 명이었고, 퇴사할 때는 그 조직이 300명 규모가 된 것을 보았다. Linear에서는 같은 방식의 무분별한 확장을 반복하고 싶지 않았던 것이다.

하지만 영상은 인프라에 너무 일찍 과도하게 투자하는 위험도 인정한다. 많은 사업이 잘못된 것에 과몰입해서 실패하기도 한다. Linear가 과감한 투자를 할 수 있었던 이유는 Jira와 Atlassian의 규모를 통해 이 시장에 실제 수요가 있다는 사실이 이미 검증돼 있었기 때문이다.

"제품-시장 적합성을 찾아야 하는 것은 맞다. 하지만 이제는 작은 MVP를 던지고 저절로 성장하길 바라기만 해서는 안 된다."

5. 조급한 성장 대신 집중과 인내를 택하다

영상은 Linear의 초창기를 '허슬과 그라인드'가 아니라 집중과 인내의 이야기로 정의한다. 회사는 무리하게 문을 열고 들어가려 하지 않았다. 훌륭한 제품을 만들자 기회가 오히려 회사를 찾아왔고, 이를 자신들이 올바른 방향에 있다는 신호로 해석했다.

"억지로 문을 열 필요가 없었다. 훌륭한 제품을 만드는 데 집중했고, 기회가 그들을 찾아왔다."

물론 창업자들이 Airbnb, Uber, Groupon, Coinbase 같은 유명 기업 출신이라는 점은 분명한 장점이었다. 초기 대기자 명단에도 그들의 이전 경력과 연결된 사람들이 많았고, 투자자들은 제품만큼이나 창업자 자체에 투자한다. 영상은 이것이 일종의 생존자 편향일 수 있음을 솔직하게 언급한다.

그럼에도 장기적으로는 허슬 문화보다, 실제 문제를 해결하는 제품을 꾸준히 만드는 방식이 더 지속 가능하다고 본다. 단기적인 과로와 마케팅은 영원히 유지될 수 없지만, 실제 고객의 고통을 해결하면 더 많은 기회가 생길 수 있다는 것이다.

"허슬과 그라인드는 영원히 지속되지 않는다. 집중과 인내가 더 지속 가능한 장기 전략이다."

6. 지표보다 사람을 우선하는 제품 철학

Linear가 포화 시장에서 두드러질 수 있었던 또 하나의 이유는 디자인과 제품 철학이다. 영상은 2008년처럼 새로운 종류의 앱 하나만 내놓아도 큰 성공을 거둘 수 있던 시기는 지났다고 말한다. 이제는 대부분의 아이디어가 이미 수없이 만들어졌기 때문에, 사람들은 제품이 특별하게 느껴지지 않으면 관심을 주지 않는다.

"이제는 모든 것이 이미 만들어졌다. 셀 수 없을 만큼 많이 만들어졌다. 눈에 띄지 않으면 아무도 신경 쓰지 않는다."

Linear는 현대 소프트웨어가 지나치게 데이터와 최적화에 매달리면서 '영혼'을 잃었다고 본다. A/B 테스트나 지표가 무조건 나쁘다는 뜻은 아니지만, 사용자 경험보다 클릭률·체류 시간·전환율 같은 숫자를 높이는 데만 집중하면 사람이 도구에 이용당하게 된다.

"측정 기준이 목표가 되는 순간, 그것은 좋은 측정 기준이기를 멈춘다."

Linear도 지표를 보기는 하지만, 지표가 결정을 내리게 두지는 않는다. 대신 실제 사용자와 대화하고, 구체적인 문제를 이해하며, 팀의 경험과 취향을 바탕으로 해결책을 만든다. 여기서 중요한 것은 "어떤 가상의 고객군"이 아니라 실제로 불편을 겪고 있는 한 사람이다.

"기능을 만들 때 그들은 가상의 사용자가 아니라, 지금 실제 문제를 겪는 구체적인 사람을 생각한다."

이를 위해 Linear의 엔지니어들은 고객과 직접 대화하는 Slack 채널에 참여한다. 사용자를 대시보드의 숫자로만 보지 않고, 자신들이 만든 변화의 영향을 받는 사람으로 대한다. 직관과 취향으로 결정하는 일에는 불확실성이 따르지만, Linear는 그 판단력을 조직 전체가 익혀야 할 역량으로 본다.

조직 운영도 이 철학과 연결된다. Linear는 보통 3~5명 정도의 작은 팀으로 프로젝트를 진행하며, 프로젝트가 끝나면 팀을 해체하고 새 과제에 맞춰 다시 구성한다. 제품 관리자는 두 명뿐이고, 백로그도 약 30~50개 항목으로 작게 유지한다. 구성원은 다음에 무엇을 할지에 대해 상당한 자율권을 가진다.

"좋은 사람을 두고, 프로세스보다 신뢰를 우선한다."

7. 개인 기여자를 위한 도구와 반복 중심 출시

Linear는 생산성 소프트웨어가 의견을 가진 도구, 즉 사용자가 따라야 할 명확한 방식이 있는 도구여야 한다고 생각한다. 도구를 관리하고 유지하는 것 자체가 누군가의 일이 되어서는 안 되며, 이것이 Jira처럼 비대하고 복잡해지는 것을 막는 방법이라고 본다.

특히 Linear는 중간 관리자의 보고 편의를 위해 개인 기여자의 업무 흐름을 해치는 종류의 과도한 맞춤화 기능은 만들지 않겠다는 입장을 갖고 있다.

"실제로 매일 그 도구 안에서 일하는 사용자가 언제나 첫 번째 우선순위다."

즉, 구매 계약서에 서명하거나 예산을 승인하는 사람이 아니라, 실제로 이슈를 만들고 처리하며 협업하는 개발자와 개인 기여자가 제품의 최종 사용자다. 이는 Linear가 기능 요구를 모두 수용하지 않는 이유이기도 하다. 모든 고객 요구를 들어주면 제품은 결국 복잡해지고, 핵심 사용자 경험은 나빠질 수 있기 때문이다.

기능 개발은 완벽한 기획 후 출시하는 방식이 아니라, 빠른 프로토타입과 반복을 중심으로 진행된다. 목표는 가능한 한 3~5일 안에 작동하는 형태를 만드는 것이다. 처음에는 내부에서만 쓰고, 때로는 동기화 엔진을 끈 상태에서 파괴적인 변경도 자유롭게 실험한다. 구성원들이 자신의 제품을 매일 쓰므로, 새 기능이 실제로 어떤 느낌인지 빠르게 체감할 수 있다.

"모든 아이디어는 처음에는 못생겼다. 그래서 가능한 빨리 무언가를 내놓는 것이 중요하다."

내부에서 충분히 다듬은 뒤에는 일부 고객에게 기능을 열어 준다. 해당 기능을 요청한 고객이나 새 기능을 시험해 볼 의향이 있는 베타 사용자 그룹이 대상이 된다. 이후 고객과 직접 대화하며 개선하고, 준비가 끝났을 때 전체 사용자에게 공개한다. 이 과정은 다음의 3단계 출시 방식으로 정리할 수 있다.

1. 내부 사용: 직원들이 직접 쓰며 문제와 사용감을 확인한다.
2. 제한된 외부 사용자 공개: 요청 고객과 베타 사용자의 피드백을 받는다.
3. 전체 공개: 충분히 안정적이고 유용하다고 판단되면 일반 출시한다.

이런 세밀한 출시를 가능하게 하는 것도 기능 플래그와 동기화 엔진 같은 인프라다. 영상은 Linear가 제품 초기에도 작은 스타트업부터 시작해 중견기업, 엔터프라이즈로 확장한 방식이 기능 출시 전략에도 그대로 반복된다고 본다.

8. 제로 버그 원칙과 매출보다 품질을 택하는 선택

Linear는 일반적으로 강한 마감일을 많이 두지 않는다. 하지만 마감일이 생기면 최우선 등급인 P0로 다루며, 버그도 마찬가지다. 특히 회사는 제로 버그 정책을 내세운다. 외부적으로는 버그 해결 SLA를 1주일로 안내하지만, 내부 기준은 1일이다.

"버그가 생기면 그것이 가장 높은 우선순위가 되고, 담당자는 하던 다른 일을 멈춘다."

이 원칙은 기능 개발을 늦출 수 있다. 새 기능을 원하는 잠재 고객을 위한 일을 미루고, 이미 쓰고 있는 고객의 문제를 먼저 해결해야 하기 때문이다. 그러나 Linear는 이것을 장기적으로 더 합리적인 선택이라고 본다. SaaS 사업은 결국 신규 기능의 수보다 고객 유지율이 중요하며, 버그 수정은 가상의 미래 고객이 아니라 실제로 비용을 지불하는 현재 고객을 위한 일이다.

"새 기능은 가상의 신규 사용자를 위한 일일 수 있다. 버그 수정은 실제로 돈을 내는 기존 고객을 위한 일이다."

품질 우선은 엔지니어링 팀만의 규칙이 아니다. 영업, 마케팅, 고객 지원, 경영진까지 모두 매출보다 품질을 앞세워야 하며, 이는 반드시 경영진부터 분명하게 전달돼야 한다. Linear의 '메인 퀘스트'는 단순히 매출을 키우는 일이 아니라 품질 높은 제품을 만드는 일이다.

"Linear의 메인 퀘스트는 품질 높은 제품을 만드는 것이다."

그 선택은 단기적으로는 분명한 비용을 수반한다. 회사가 받을 수 있는 매출 일부를 포기하게 만들 수도 있다. 하지만 이것이야말로 붐비는 시장에서 사람들이 진심으로 좋아하는 제품을 만드는 차별점이 됐다.

9. 높은 채용 기준이 작은 조직을 가능하게 하다

Linear의 운영 방식을 이야기할 때 빠지지 않는 주제가 채용이다. 회사는 정식 채용 전에 실제 제품을 대상으로 하는 유급 1주일 업무 체험을 진행한다. 영상 속 화자는 후보자가 기존 직장의 휴가를 써야 할 수도 있다는 점에서 다소 비현실적으로 보인다고 농담하지만, 조사할수록 왜 Linear가 채용에 집착하는지 이해하게 됐다고 말한다.

Linear의 제품 개발 방식은 뛰어난 사람들에 대한 신뢰를 전제로 한다. 프로세스가 적고, 개인에게 큰 자율성이 주어지며, 고객과 직접 대화하고, 직관에 따라 판단하려면 단순히 기술만 잘하는 사람으로는 부족하다.

회사는 많은 사람을 뽑지 않는다. 대신 자신의 판단을 갖고 있고, 그 판단을 논리적으로 설명할 수 있으며, 세부적인 완성도와 장인정신을 보여 주는 사람을 찾는다.

"채용 기준은 매우 높다. 많이 뽑지 않고, 완성도와 돌봄을 보여 주는 사람만 뽑는다."

이는 처음에는 비용이 크고 시간이 걸리는 방식이지만, 장기적으로는 더 적은 프로세스로도 높은 수준의 결과를 내게 해 준다. Linear는 인프라에는 치밀한 설계를 적용하면서도 제품 조직에는 비교적 느슨한 프로세스를 유지한다. 그리고 그 느슨함이 가능한 이유는 결국 뛰어난 인재 밀도에 있다.

10. 독점에 맞서는 법과 최종 교훈

Jira는 여전히 Linear보다 훨씬 널리 쓰인다. 하지만 Linear는 스타트업과 개발자 중심 기업 사이에서 강한 선호를 얻었고, 약 12억 5천만 달러 가치의 기업으로 성장하며 거대한 시장의 틈을 파고들었다. 영상은 이를 단순한 시장 점유율 이야기가 아니라, 장인정신과 품질을 선택한 이야기로 정리한다.

"Linear의 이야기는 장인정신, 그리고 무엇보다 품질을 선택한 이야기다."

가장 큰 교훈은 품질 좋은 제품을 원한다면 실제로 품질을 우선해야 한다는 것이다. 이는 듣기 좋은 슬로건이 아니라, 다른 가치를 뒤로 미루는 구체적인 선택을 뜻한다. 새 기능 대신 버그를 고치고, 클릭률을 높이는 설계 대신 사용자가 더 편하게 느끼는 경험을 택하며, 빠른 고객 확장 대신 천천히 제품을 다듬는 선택이 여기에 포함된다.

영상이 제시하는 Linear식 실천 원칙은 다음과 같다.

• 고객을 천천히 늘려라. 한 번에 약 10명씩 받아 실제 문제를 해결하는지 확인한다.
• 기능이 아니라 사용자 집단으로 MVP를 좁혀라. 특히 스스로도 속한 사용자 집단을 목표로 삼으면 더 깊이 이해할 수 있다.
• 투자금보다 제품-시장 적합성을 먼저 찾아라.
• 적게 채용하되, 신뢰할 수 있는 훌륭한 사람을 채용하라.
• 기능은 빠르게 내부에서 먼저 쓰고, 제한 공개를 거쳐 전체 공개하라.
• 나중에 바꾸기 어려운 핵심 인프라에는 초기에 투자하라.
• 소프트웨어를 숫자가 아니라 사람을 위해 만들어라.

"사용자를 차트 위의 데이터 포인트가 아니라, 내가 영향을 주고 있는 실제 사람으로 생각하라."

마무리

Linear의 성공은 마법 같은 기능 하나나 무조건적인 성장 전략에서 나오지 않았다. 작은 사용자 집단에 집중하고, 느리지만 신중하게 기반을 만들며, 빠르게 실험하고, 버그와 사용자 경험을 단기 매출보다 앞세운 결과였다. 영상의 마지막 메시지는 단순하다. 좋은 제품을 만드는 일은 반드시 복잡한 것은 아니지만, 어려운 점은 그것을 진짜 우선순위로 선택하는 데 있다.