예전에 개발자들끼리의 술자리에서 "프론트엔드 출신의 CTO는 왜 없을까?"에 대해 얘기를 나눈 적이 있는데 (정말로 그런지는 모르겠지만) 당시에는 "그러게요 희한하네" 정도로 넘어갔는데, 요즘 들어 드는 생각은 프론트엔드와 백엔드 각자가 집중하는 문제 해결 방향이 달라서 그런가 싶다.
MySQL에서 UUID를 PK를 쓰면 어떤 원리로 성능이 안 좋아지는지를 잘 설명하는 정성스러운 글!
1. 분산 환경이 아닌데 UUID를 PK로 쓰고 있다면 성능 부담이 크다는 걸 인지하고
2. UUID를 PK로 쓴다면 VARCHAR(36)보다는 BINARY(16)을 고려하고, UUID_TO_BIN 함수 사용하면 성능의 이득이 있고
3.
그래서 요새 고민이 넘 많다 왜냐면 자꾸 확장하고 영역을 넓혀나가서 점점 더 개미친 제너럴리스트가 되어가는데, 이걸 잘 함에도 불구하고 앞으로 계속 이렇게 하긴 싫기 때문에…뭐를 뾰족하게 가져갈 수 있을까 생각해보면 엔지니어링이나 데이터 어쩌구보단 제너럴한게 전문성이 되는 일을 해야될
스타트업 고속 승진 비결: 그냥 다 안 된다고 하면 된다. 스타트업은 대부분 망하기 때문에 그냥 그럴듯한 이유를 갖다 대면서 안 된다고 말하면 높은 확률로 맞는다. 이게 몇 번 쌓이면 사람들이 미래를 묻기 시작하고 리더로 승진한다. 이제 이직해서 이 루틴을 또 반복하면 된다.
어쩌다 ‘애자일’이 이렇게 쉬운 취급을 받게 되었는지 모르겠다. 개발자, 디자이너, PM이 한 팀에 있으면 ‘애자일 조직’이 된다는 착각. 경험상 애자일은 모두에게 일정 수준 이상의 역량을 요구하는 힘든 길이고, 그래서 솔직히 모든 회사가 갈 수 있는 길은 아니라고 생각한다.
요즘 주니어 개발자들 만나면 다들 "체계적인 개발 프로세스"를 원한다. 그래서 어떤 게 체계적인 거냐고 물어보면 결국 원하는 건 잘 짜여진 완벽한 기획서와 디자인으로 개발자는 보고 코딩만 하면 되는 상황이다. 그러면 또 니가 원하는 게 폭포수 방법론이라고 말해주는데, 그럼 대개 깜짝 놀란다.
얼마 전에 회사 동료에게 스탠드업 미팅의 목적은 업무 진행 상황 파악이 아니라고 말한 적이 있다. 나는 스탠드업 미팅을 어라?를 발견하기 위한 장치로 본다. 보통 팀의 상황에 관한 유용한 정보는 비언어적인 피드백에서 발견되는데, 스탠드업 미팅이 이러한 피드백을 수집하기 좋은 자리이기
@MarkInJeju
안녕하세요, 그렇게 기억하고 계셨다니 기쁘고 감사하네요. 사실 저도 언어 선택이 달랐다면 분명히 달랐을지 어땠을지에 대한 확신이 있는 건 아닙니다. 다만 본문의 요지는 10년이 지나도 주류로 자리잡지 못한 기술적 선택이 과연 좋았을까?에 대한 나름의 반성적 성찰이긴합니다.
그럼에도 요즘
저도 보통 다른 스타트업 CTO들이 언어 문제로 고민하면 “그 언어를 골라서 망할 확률보다 제품이 별로라 망할 확률이 훨씬 높으니까 그냥 지금 가장 좋은 걸 쓰셔라”라고 말씀드리긴합니다. 그리고 지금도 이 생각에 변함은 없습니다.
자프링이 스타트업에 적합한 언어인가? 제가 자프링을 안
CTO로서 어떤 기술과 도구를 사용할지 의사결정을 나름대로 잘 해왔다고 생각했는데 유일하게 서버에 있어 JVM/Spring을 사용하지 않은 게 요즘에 마음에 걸린다.
2014년부터 Slack과 GitHub을, 2015년부터 React를, 2016년부터 k8s와 Kotlin(Android) 등등 당시에는 나름 힙스터스러운 결정을
미국 노동부에서 만든 직무 데이터베이스인 O*NET에 따르면, (명칭 자체가 중요한 게 아니라) 소프트웨어 개발자와 컴퓨터 프로그래머의 차이 중 하나는 사람 사이의 '인터랙션'이 얼마나 작업에 포함되어 있느냐이다.
누군가 작성한 스펙대로 개발하는 것을 주 업무로 삼는다면 위 분류상 컴퓨터
Notion의 안정성, Obsidian의 가벼움과 위클리 노트, Capacities의 AI 노트(Claude 지원하는 버전으로)와 디자인 감각, Heptabase의 카드/화이트보드 체계와 훌륭한 Readwise 연동, Bear의 애플 펜슬 지원을 모두 제공하는 단 하나의 노트 앱을 찾는 건 아무래도 내 욕심인 것 같다...
아직도 노트 앱 방황 중이라 요즘엔 Reflect를 사용해 보는데 웹 클리퍼 사용성이 좀 아쉽다. Readwise와 충돌하는 것도 그렇고 하이라이트가 즉시 반영이 안 되어 계속 새로고침을 하게 되는 것도 좀 아쉽네. 노트 앱은 기본기가 참 중요한 제품이라 결국 돌고 돌아 노션인가 싶고...
그래서 결국 웹 개발자는 “프론드엔드향 풀스택” 과 “백엔드향 풀스택” 중 하나가 되는 것이 개발자라고 생각한다.
누군가는 풀스택은 유니콘적인 것이고, 일반적으론 전문성 떨어지는 것이 현실이라고 치부할 수도 있겠다.
근데 옛날엔 애초에 저런 구분이 없었다. 그땐 모두가 “웹개발자” 였다
배기홍 대표님 글은 몇 년째 RSS로 받아보고 있을 만큼 대체로 좋아하고, 이번 글 역시 기본적으로는 공감하나 그럼에도 몇 마디를 더하자면,
> 똑똑하고 능력 있는 엔지니어들은 주로 기술적으로 어렵고 난이도가 높은 문제를 해결하고 싶어 하고
내가 경험한 정말 똑똑하고 능력 좋은 엔지니어 중
반면에 프론트엔드는 코드 자체의 복잡도를 낮추는 일에 집중하게 된다. 특히 모바일 진영에서 '클린 아키텍처'가 괜히 오래도록 유행인 게 아니다. 코드베이스 자체의 복잡도가 워낙 크기 때문에 그렇다. 또한 주된 "어려운" 작업은 복잡한 상태를 다루는 일이다. 그래서 상태 관리를 어떻게 할
구글 technical writing 문서에는 “님 글을 읽는 사람이 영어 네이티브가 아닐 수도 있으니 최대한 간결하고 쉬운 단어로 헷깔리지 않게 쓰라”고 되어있음. 요새 젊은이들 탓하기 전에 한국어가 제2외국어인 한국에 연고없는 젊은이가 읽어도 헷깔리지 않게 쓰는게 베스트인거임...
나도 답답한 마음에 '주인의식'이라는 표현을 종종 사용하던 시기가 있었는데 몇 가지 사건을 겪고, 이제 거의 사용하지 않는 단어가 되었다.
1. 주인의식이란 표현의 공통된 심상이 부족하다. 그래서 오해도, 말장난도 쉬워 그리 유용하지 않다.
2. 주인의식을 대강 책임감 정도로 잡고 가더라도,
JVM이나 스프링이 아니면 안 된다는 선언을 하고 싶지는 않고요. 다만 10년 전의 저는 이게 얼마나 어려운 일인지 몰랐습니다. 주류의 선택을 하지 않으면 세상의 기준에 타협하지 않는 멋진 사람들이 기적적으로 대거 등장하기도 합니다. 저희 회사는 그런 방식으로 성장해왔고 그 방식이 대단히
@MarkInJeju
안녕하세요, 그렇게 기억하고 계셨다니 기쁘고 감사하네요. 사실 저도 언어 선택이 달랐다면 분명히 달랐을지 어땠을지에 대한 확신이 있는 건 아닙니다. 다만 본문의 요지는 10년이 지나도 주류로 자리잡지 못한 기술적 선택이 과연 좋았을까?에 대한 나름의 반성적 성찰이긴합니다.
그럼��도 요즘
번외로 이런 관점에서 볼 때 백엔드 개발에서 시스템적인 사고를 하지 않고, 자꾸 코드베이스 레벨에서 해결하려고 한다면 대체로 안 좋을 가능성이 높다고 생각한다. 예를 들어 주기적으로 무언가를 실행할 일이 있을 때 그냥 본인이 사용하는 백엔드 프레임워크 + cron job이 붙은 플러그인으로
그래서 백엔드는 코드 자체의 복잡도를 낮추는—예를 들어, 더 좋은 코드가 무엇인가? 더 좋은 코드베이스 구조가 무엇인가?—접근에는 큰 관심이 없다. 그냥 좀 코드가 길다 싶으면 일부 함수로 잘 리팩토링만 하면 된다. 그보다는 시스템의 복잡도에 더 집중한다. DB 구조를 어떻게 가져갈 것인가,
아마도 그 모 핀테크 회사 관계자로서 사실 여부를 떠나 만약 리팩토링해서 망했다고 하더라도 리팩토링 자체가 문제였다고 말할 수 있나? 리팩토링도 결국 문제를 해결하는 수많은 수단 중 하나일 뿐이다. 그러면 그 문제 정의가 옳았는지 해결책으로써 좋은 판단이었는지에 관해 얘기해야 한다.
Notion의 안정성, Obsidian의 가벼움과 위클리 노트, Capacities의 AI 노트(Claude 지원하는 버전으로)와 디자인 감각, Heptabase의 카드/화이트보드 체계와 훌륭한 Readwise 연동, Bear의 애플 펜슬 지원을 모두 제공하는 단 하나의 노트 앱을 찾는 건 아무래도 내 욕심인 것 같다...
<어제 하이브를 향해서 기자회견을 하셨던 어도어 민희진 대표님을 만났습니다.>
안녕하세요. 패스트벤처스 박인엽 심사역입니다.
저도 자본시장에 몸을 담고 있는 한 사람이지만, 작년 한 해 동안 많은 PD님을 만나뵙고 제가 내린 결론은 명확합니다.
“자본은 쉬움, 디렉팅은 어려움.”
“Money 는
한국은 공부 잘하면 다 의대 가고 로스쿨 간다. 줄 세우기에 너무 익숙한 사람들이고 다양성을 지지하기에는 사회적 풍토가 빈약하고, 다양성을 포용하기엔 시장 크기가 너무 작다. 진개는 도구를 안 가린다고 하지만 탑티어 회사는 도구를 가린다. 이게 문제라 생각하겠지만 그들은 안 바뀐다.
마이너한 언어 출신 시니어를 충원해도 (xx언어 시니어라는 말이 개인적으론 이상하다고 느끼긴 하는데) 주니어들 마음 한구석엔 한국에서 모두들 가고 싶어하는 회사들이 많이 쓰는 프레임워크를 해야한다는 마음이 한구석에 있을 가능성이 높다.. 실제 자주 목격을 했고.. 나도 그랬었고
어느 순간부터 회사의 성공과 나의 성공을 동일시하기 시작했는데 이게 정말이지 괴롭다. 조금이라도 마음에 들지 않는 구석이 있으면 다 내 앞길을 가로막는 장애물처럼 느껴져서 감정을 다스리는 게 쉽지 않다. “나는 내 파이를 구할 뿐 회사를 구하러 온 게 아니라고” 다시금 마음을 잡아본다.
백엔드 출신 CTO가 더 많은 이유는 여기에 있지 않을까? 회사에서 해결해야 하는 대부분의 문제는 좋은 '코드'보다는 좋은 '시스템'이 필요하기 때문이다. 물론 내 경험상 둘 다 힘든 일이고, 무엇이 더 어렵다고 말하기는 어려우나 어디까지나 CTO가 해야 하는 일들의 속성을 따져볼 때 그럴 가능성이
성공은 항상 장점으로 하고 실패는 항상 단점으로 한다고 생각합니다. 자프링에 대한 얘기를 처음 꺼낸 건 단점을 하나라도 줄이지 못한 선임 CTO로서의 부채감이었습니다. 그러니 제 경험담은 잊으시고 “실패 확률을 낮추기보단 성공 확률을 높이는데 집중하시라”고 감히 말씀드리고 싶습니다.
딱 말씀하신 대로 사실 저도 초기 스타트업의 프론트엔드 출신 CTO였고 어찌저찌 생존하고 투자 유치에 성공해 백엔드 출신 CTO를 모셔 온 케이스입니다. 저 역시 초기 단계일수록 출신을 떠나 사용자에 대한 이해, 비용과 임팩트 사이를 협상하는 상인의 감각이 더 CTO에게 요구된다고 봅니다.
초기 스타트업에는 프론트 출신 CTO가 꽤 있을 테고, 또 개인적으로 초기에는 프론트 출신 CTO가 백 출신보다 매우 훨씬 나은 선택이 되어준다고도 생각한다.
어찌 저찌 생존하고 투자 유치에 성공한 서비스는 시스템 규모에 맞춰 곧 백엔드 출신 CTO를 새로 모셔오게 되는...
이 아이템을 그만둔다는 글을 올리니 예비 고객사 한 분이 따로 연락을 주셔서 따스한 응원과 설득을 해주셨습니다. 지난 1년간 아이템을 찾으며 한 번도 경험하지 못했던 일이라 어려운 상황임에도 어떻게든 해보려고요. 번복하는 게 조금은 부끄럽지만😂 다시 시작해보려고 합니다.
말씀을 나누면서
@babbuedababba
작성하신 타래를 쭉 보니 어떤 맥락에서 말씀하신 건지 잘 이해가 가고, 저도 공감합니다. 우선 제 기본 전제도 개발을 어느 정도는 잘해야 한다는 가정이 있습니다. 협업은 꽤 난이도가 있는 작업이거든요. 다만 몇 가지 생각이 다른 지점이 보이네요.
예를 들어 "개발자가 기획을 고민해야 한다면
요즘 들어 개인의 '나'와 조직의 리더로서의 '나' 의 생각들이 많이 충돌한다. 예를 들면 점심만해도 조용하게 샐러드나 먹으면서 할일하는 시간을 가지고 싶지만 약간 반대로 어울려서 점심을 먹어야할 필요도 가끔 있다. 어떻게 보면 예전보다 개인의 '나'의 욕망이 커진것 같기도 하고
생산성에 진심인 지식노동자들에게 좀 더 통합적인 LLM 클라이언트가 필요할 것이라는 생각에 작년 12월에 Snack이라는 제품을 2주 만에 만들어 ProductHunt에 올리고, 한 달 정도 운영했고 아무도 결제를 안 해서 서비스를 종료했다.
당시에는 내 런웨이가 너무 부족해서 더 길게 보고 베팅을 못
Show GN: Snack - 여러 AI에게 한 번에 물어보세요
더 이상 만족스러운 답변을 얻기 위해 프롬프트를 깎지마세요! 한 번에 여러 AI에게 물어보면 간단한 프롬프트로도 훨씬 더 빠르게 원하는 수준의 답변을 얻을 수 있습니다.
지금 바로 GPT-4 Turbo, Gemini Pro,...
스타트업 고속 승진 비결: 그냥 다 안 된다고 하면 된다. 스타트업은 대부분 망하기 때문에 그냥 그럴듯한 이유를 갖다 대면서 안 된다고 말하면 높은 확률로 맞는다. 이게 몇 번 쌓이면 사람들이 미래를 묻기 시작하고 리더로 승진한다. 이제 이직해서 이 루틴을 또 반복하면 된다.
@hodolman
의 신규 프로젝트 이야기!
- TanStack Query 없이 Repository 패턴으로 HTTP 관리하기
- Class Enum 으로 타입 관리하기
- useState 대신에 DTO 사용하기
- 전통적인 의존성 주입 사용하기
등등 프론트엔드에서는 잘 사용하지 않는 사용법을 실전에
편의상 ‘매출’이라 적었는데 그냥 ‘성과’내지는 ‘임팩트’라고 이해해주시면 좋겠습니다. 10x 트래픽을 버티는 게 성과로 이어지는 상황이 있을 수 있음을 잘 압니다. 일정 레벨 이상의 (특히 제품쪽) 개발자는 성과에 대한 요구가 개발자에게도 있기 때문에 그냥 무난한 표현이라고 생각했는데
결과를 보니 특별한 이유가 없으면, B2B SaaS는 오픈소스로 시작하는 게 조금이라도 유리할 가능성이 있어 보인다. 최근에 실리콘밸리 VC들은 (한국과 달리) SaaS를 아예 오픈소스로 개발하기 시작하는 걸 권한다고 들어 한국에서의 반응은 어떨지 궁금해서 만든 투표였는데... 고민이 많아진다 🫠