리니어를 만든 사람이 던진 질문
리니어(Linear)라는 이슈 트래커 써보셨나요? 지라(Jira)를 쓰다 넘어온 팀들이 “빨라서 놀랐다”, “만든 사람이 신경 쓴 게 느껴진다”는 말을 많이 하는 도구예요. 리니어의 공동창업자이자 CEO인 카리 사리넨(Karri Saarinen)이 'Someone behind the software', 우리말로 하면 '소프트웨어 뒤에 있는 누군가'라는 제목의 글을 썼어요. 에어비앤비에서 디자인 시스템을 이끌었던 디자이너 출신 창업자이기도 해요.
타이밍도 의미심장해요. 지금은 프롬프트 몇 줄이면 그럴듯한 앱이 뚝딱 나오는 시대잖아요. 제목만 봐도 질문이 하나 떠올라요. 소프트웨어를 만드는 비용이 0에 가까워질수록 “이걸 누가, 어떤 생각으로 만들었나”가 더 중요해지는 것 아닐까 하는 거죠. 오늘은 이 질문을 출발점으로 개발자가 곱씹어 볼 만한 이야기를 정리해 볼게요.
‘누군가 만든’ 소프트웨어는 뭐가 다를까
동네 단골 국밥집을 떠올려 보세요. 메뉴는 몇 개 없지만 사장님은 '우리 집은 이 맛'이라는 확신이 있어요. 손님 입맛을 다 맞춰주진 않아도, 그 고집 덕분에 맛이 일정하고 믿음이 가죠. 소프트웨어도 비슷해요.
업계에서는 이런 걸 의견이 있는 소프트웨어(opinionated software)라고 불러요. 이게 뭐냐면, 모든 걸 설정으로 열어두지 않고 만든 사람이 '이게 맞는 방식'이라고 판단한 기본값을 정해서 내놓는 소프트웨어예요. 리니어가 대표적이에요. 사이클(스프린트) 운영 방식이나 이슈 상태 흐름이 어느 정도 정해져 있고, 거의 모든 동작을 키보드 단축키로 할 수 있어요. 클릭하면 서버 응답을 기다리지 않고 화면부터 바로 바뀌고요. 이런 디테일 하나하나가 '누군가 직접 써보면서 불편한 걸 그냥 넘기지 않았구나' 하는 신호가 돼요.
반대쪽 극단에는 뭐든 설정할 수 있는 도구가 있어요. 유연하긴 한데, 결국 '어떻게 일할지'에 대한 결정을 사용자에게 떠넘기는 셈이거든요. 화면마다 버튼 위치가 다르고 에러 메시지는 시스템 코드 그대로 튀어나오면, 사용자는 '이 뒤에는 아무도 없구나' 하고 느끼게 돼요.
AI 시대의 역설: 만들기가 쉬워질수록 판단이 귀해진다
바이브 코딩(vibe coding)이라는 말 들어보셨죠? 코드를 직접 짜지 않고, 원하는 걸 AI에게 말로 설명해서 나온 결과물을 쓰는 방식이에요. 덕분에 할 일 앱이나 대시보드 같은 건 이제 몇 분이면 만들어요.
그런데 여기서 역설이 생겨요. AI는 학습한 데이터의 '평균'에 가까운 답을 내놓는 경향이 있거든요. 다들 비슷한 도구에 비슷한 프롬프트를 넣으면 결과물도 비슷해져요. 기능은 다 있는데 어딘가 영혼이 없는 소프트웨어가 넘쳐나는 거죠. 그 속에서 차이를 만드는 건 결국 사람만 할 수 있는 것들이에요.
- 취향(taste): 수많은 선택지 중에 뭐가 '좋은지' 알아보는 감각
- 거절하는 용기: 기능 요청 100개 중 95개에 '아니요'라고 말하는 판단
- 책임: 문제가 생겼을 때 “제가 그렇게 결정했고, 고치겠습니다”라고 말하는 사람
업계 맥락: 장인 정신 vs 무한 확장
이런 흐름이 새로운 건 아니에요. 베이스캠프를 만든 37시그널스는 오래전부터 작고 단단한 소프트웨어를 고집해 왔고, 맥 앱 Things를 만든 Cultured Code도 적은 인원으로 디테일에 집착하는 걸로 유명해요. 반대로 엔터프라이즈 도구들은 모든 회사의 요구를 다 받아주는 방향으로 진화해 왔고요.
어느 쪽이 정답이라기보다는, AI 때문에 '기능 구현'이 더는 귀하지 않게 되면서 무게중심이 장인 쪽으로 옮겨가고 있다는 게 포인트예요. 기능은 누구나 만들 수 있으니 '어떤 기능을 왜 이렇게 만들었는가'라는 관점 자체가 제품이 되는 거죠. 요즘 실리콘밸리에서 '테이스트(taste)'라는 단어가 유독 자주 들리는 것도 같은 맥락이에요.
한국 개발자에게 주는 시사점
한국 개발 문화, 특히 SI 프로젝트에서는 요구사항 명세서대로 정확히 만드는 걸 미덕으로 여기는 경우가 많았어요. 그런 환경에서는 '내 의견'이 들어갈 틈이 별로 없죠. 그런데 AI가 명세서를 코드로 옮기는 일을 점점 잘하게 되면, 개발자의 가치는 '명세서에 없는 걸 찾아내는 능력'으로 옮겨갈 거예요. 다행히 국내에도 토스처럼 디테일과 사용성을 끝까지 파고들어 사용자 신뢰를 얻은 사례가 있어요.
당장 해볼 수 있는 것도 있어요.
1. AI가 쓴 코드도 내 코드처럼: 머지 버튼을 누르는 순간 그 코드의 저자는 나예요. '왜 이렇게 했는지' 설명하지 못하는 코드는 올리지 않는 습관을 들여 보세요.
2. 보이지 않는 곳 다듬기: 에러 메시지, 빈 화면(empty state), 로딩 상태처럼 아무도 시키지 않은 곳에 사람의 흔적이 가장 잘 드러나요.
3. 사람 냄새 나는 기록: 리니어 체인지로그가 사랑받는 건 '무엇을, 왜 바꿨는지'를 사람의 말로 쓰기 때문이에요. 팀 릴리즈 노트부터 바꿔 보는 것도 방법이에요.
마무리
한 줄 정리: 소프트웨어를 만드는 비용이 0에 가까워질수록, ‘누가 왜 만들었는가’가 제품의 가장 큰 경쟁력이 돼요.
매일 쓰는 도구 중에 ‘아, 이건 누군가 진짜 신경 써서 만들었구나’ 싶었던 소프트웨어가 있나요? AI와 함께 코드를 쓰는 요즘, 여러분의 코드에는 ‘나’라는 사람의 흔적이 어디에 남아 있다고 생각하세요? 댓글로 이야기 나눠 봐요.
🔗 출처: Hacker News