어릴때 밴드 동아리를 했는데, 거기에선 자작곡을 만들어야 한다고 친구들을 설득하는 아이가 있었습니다. 연주 기술을 연마하기보단 뭘 노래하고 싶은지를 고민해야한다고 했죠. 물론 유명한 노래 카피하면서 밴드 하자는 아이들의 의견이 더 강했던걸로 기억나요.
그런데 요즘은 그 친구 생각이 자주 나요.
사느라 바빠서 외면하고 있던 질문인데, AI 의 발전으로 내가 개발자를 업으로 삼은 뒤, 코드를 작성하는 행위를 좋아하는건지 가치창출을 좋아해 그 수단으로 코드를 작성하는 것인지.
지금까진 그 두 부류가 서로 뒤엉켜서 지냈다면 앞으로는 내가 어느쪽인지 분명히 해야 할 순간이 금방 다가올것 같아요.
저도 최근에 비슷한 작업을 했는데, 위에 URL바를 보는게 거슬리지 않는다면 그냥 웹페이지를 로드해도 됩니다.
킨들은 기본적으로 웹브라우저에서 URL접속이 가능해서 거기서 대시보드를 불러오면 됩니다.
회사에선 킨들로, 집에선 페이퍼 라이트 구세대로 같은 페이지를 로딩하고 있어서 나름 크로스플랫폼 이네요 ㅎㅎ
물론 킨들도 계속 켜져 있는 모드를 위해서는 루팅 또는 비슷한 작업을 해야합니다.
페이퍼라이트는 루팅 까지는 필요없고, adb 연결만 열어주고 거기서 스크린세이버를 끄는 동작을 해야합니다.
Next.js가 오픈소스이고 구조와 목표가 비교적 명확해서 이런 시도가 가능했을 것 같다는 생각이 듭니다.
특히 풍부한 테스트 코드와 레퍼런스가 있으니, 테스트를 통과하는 방향으로 구현을 유도하는 접근도 충분히 현실적이었을 것 같네요.
AI의 발전 속도가 정말 놀랍습니다.
여전히 일자리가 위험하네요.. 현장직으로 직종을 바꿔야할지..ㅠㅠ
클로드 코드나 코덱스한테 추가하라고 하면 해주지 않을까 생각도 듭니다.
기본이 잘 된 코드라면 기능 추가하는 건 더 잘하더라고요.
앤트로픽이 아무리 고집을 부려도 결국 미국방부가 까라면 까야하는 것이겠죠. 결국에는 이렇게 될 수순이었던 건 아니었을까요.
이래서 SaaS가 다 죽는다고 하는군요... 저희도 내부 도구들은 점점 AI 에이전트가 하나씩 만들어서 대체하고 있는데 SaaS의 종말 이후는 어떤 시대가 또 될런지 두렵기도 합니다.
고객의 요구대로 잘 작동하는 프로그램, 고장이 나지 않는 프로그램을 만들 책임은 여전히 개발자에게 있어서 코드를 작성하는 행위를 포기하지 않으셔도 괜찮습니다. 타이핑만 ai가 해주지 본질은 같다고 생각해요
애드센스 도배인데 다른 사용자분들은 아무렇지 않아 하시나요?
네카라쿠배 다 의미없다 이말이여 저런거 보면 ㅋㅋㅋㅋ
screen studio 구독해서 gif 로 제작 후 업로드했습니다!
정말로 타이핑해서 코드를 짜는 시대는 끝난듯해요
Codex 앱에 13개의 프로젝트 올려두고 작업하는데, 그중에 코드 창이 열려있는건 3개뿐이네요
최근에 만들어서 가장 잘 쓰는 도구 하나는 코드를 본 적이 아예 없어요.
프로덕션용은 그래도 아직 코드 리뷰도 거치고 고민할게 많지만, 내부용 도구 같은거는 정말 잘 만들어줍니다.
안드레카파시가 그렇다면 그런 것
오 좋네요.
혹시 Readme.md에 gif 따로 만드는 툴이 있나요?
오 확실히 이런게 필요하긴 하죠. 모든 브라우저에서 지원되면 엄청 좋을거 같네요
문서를 안본 것에 대한 짜증...이 저도 났었는데, 바꿔서 생각해보니 저조차도 남자는 매뉴얼 따윈 보지 않아! 하면서 사고치던 생각이 많이 났습니다.
그래서 지금은 LLM에게 사용법을 RAG 기반으로 답변하게 해놓고 사용자들이 매뉴얼 없이 그냥 물어보면서 기능들을 쓸 수 있겠금 했더니 다들 좋아하더라구요.
호기심도 중요한데 약간 역지사지? 같은 자세도 필요한 것 같습니다. 넓게 보면 이것 또한 메타인지겠네요.
어릴때 밴드 동아리를 했는데, 거기에선 자작곡을 만들어야 한다고 친구들을 설득하는 아이가 있었습니다. 연주 기술을 연마하기보단 뭘 노래하고 싶은지를 고민해야한다고 했죠. 물론 유명한 노래 카피하면서 밴드 하자는 아이들의 의견이 더 강했던걸로 기억나요.
그런데 요즘은 그 친구 생각이 자주 나요.
사느라 바빠서 외면하고 있던 질문인데, AI 의 발전으로 내가 개발자를 업으로 삼은 뒤, 코드를 작성하는 행위를 좋아하는건지 가치창출을 좋아해 그 수단으로 코드를 작성하는 것인지.
지금까진 그 두 부류가 서로 뒤엉켜서 지냈다면 앞으로는 내가 어느쪽인지 분명히 해야 할 순간이 금방 다가올것 같아요.
7개 사이드 프로젝트를 만든 사람으로서 공감하면서도 약간 다른 생각이 있습니다.
취향이 중요하다는 건 맞는데, 문제는 취향이라는 게 만들어보기 전엔 자기가 가지고 있는지도 모른다는 점이요. 저도 처음엔 "이건 좀 다르지 않을까"하고 시작했는데, 만들고 공개하고 피드백 받으면서 비로소 "아 이건 아니었구나"를 체감하게 됩니다.
바이브코딩으로 나오는 조잡한 결과물이 넘치는 건 사실이지만, 그 과정에서 취향을 발견하는 사람도 분명 있을 거라고 봅니다. 처음부터 취향이 있었던 게 아니라, 만들면서 생기는 거니까요.
다만 글에서 지적한 것처럼 "최소한의 문턱은 넘긴 뒤에 내놓아야 한다"는 건 진짜 동의합니다. 그 문턱을 못 넘기는 건 취향 부족이 아니라 성실함 부족인 경우가 더 많은 것 같아요.
저도 최근에 비슷한 작업을 했는데, 위에 URL바를 보는게 거슬리지 않는다면 그냥 웹페이지를 로드해도 됩니다.
킨들은 기본적으로 웹브라우저에서 URL접속이 가능해서 거기서 대시보드를 불러오면 됩니다.
회사에선 킨들로, 집에선 페이퍼 라이트 구세대로 같은 페이지를 로딩하고 있어서 나름 크로스플랫폼 이네요 ㅎㅎ
물론 킨들도 계속 켜져 있는 모드를 위해서는 루팅 또는 비슷한 작업을 해야합니다.
페이퍼라이트는 루팅 까지는 필요없고, adb 연결만 열어주고 거기서 스크린세이버를 끄는 동작을 해야합니다.
시스템으로 돌아가는 큰조직이 나태해지면 격는 함정이죠
더 큰 문제는 그 드러난 문제를 또 해결하겠답시고 요식행위로 덮어버리는것
직원이 대부분 히스패닉과 아시안 같네요. 이것도 웃기네.
좋네요
대운이 안좋은편이라 좀 슬프지만... 팔자가 일반적으로는 시 일 월 년 순인데, 이 서비스는 반대라서 쪼끔 헷갈리는 측면이 있었습니다. 뭔가 의도가 있는게 아니시라면 일반적인 배열로 바꾸는게 어떨까요?