AI를 활용한 서비스를 개발하고 있어요. 직접 만든 앱을 출시하고 사이트를 운영하면서, 요즘은 AI와 함께 일한다는 게 어떤 의미인지 자주 생각하게 됩니다. 개발을 시작한 건 정말 우연한 계기였어요. 어느 날 웹사이트 만드는 법을 알려주는 무료 영상 강의를 보게 됐는데, 재미있어 보여서 따라 해봤습니다. 화면에 나오는 코드를 입력하니 정말 웹사이트가 만들어지더라고요. 조금 고치면 화면도 달라졌어요. 제가 늘 사용하기만 하던 것들을 저도 만들 수 있다는 게 신기했습니다. 그러다 AI를 공부에 쓰기 시작했어요. 처음에는 제 생각을 읽고 대답해주는 것처럼 느껴졌습니다. 검색어를 넣고 알맞은 문서를 찾아다니던 것과는 달랐어요. 잘 모르겠다고 하면 다시 설명해줬고, 거기서 생긴 궁금증을 물으면 이야기가 이어졌습니다. 물어볼 게 끝도 없었는데, 받아주는 쪽도 지치지 않았어요. 배울수록 욕심이 생겼습니다. 개발을 더 잘 알고 싶기도 했고, 한편으로는 공부가 충분히 끝날 때까지 기다리지 않고 제 사이트부터 갖고 싶었어요. 그래서 두 가지를 같이 했습니다. 공부할 때는 자바와 스프링의 코드가 왜 그렇게 동작하는지 계속 물었어요. 이 어노테이션은 무슨 역할인지, DTO는 왜 따로 만드는지, 강의를 따라 입력한 코드에서 이해되지 않는 것을 하나씩 짚었습니다. 그런데 제 사이트를 만들 때는 태도가 전혀 달랐어요. 무엇을 만들고 싶은지만 말하고, 어떻게 만드는지는 거의 전부 AI에게 맡겼습니다. 한쪽에서는 원리를 알고 싶어 하면서, 다른 한쪽에서는 결과만 빨리 보고 싶었던 거죠. 그렇게 제 첫 개발자 커뮤니티 사이트를 만들었어요. 개발자들이 이야기를 나눌 수 있는 커뮤니티를 만들고 싶었습니다. 지금 다시 시작한다면 그렇게 구현하지는 않을 것 같아요. 물론 지금도 다 뜯어고치고 싶습니다. 공부를 할수록 고치고 싶은 목록도 같이 늘어나더라고요. 지금 생각해보면 ‘나만의 사이트를 갖고 싶다’는 목표에 마음이 쏠려 있어서, 거기까지 가는 중간 과정은 참 신경 쓰지 않았어요. AI가 된다고 하면 되는 줄 알았고, 화면에 기능이 나타나면 다음 기능을 만들었습니다. 제가 무엇을 이해하지 못한 채 넘어가고 있는지도 잘 몰랐어요. 그런데 시키는 대로 해도 안 되는 일이 자꾸 생겼습니다. 이렇게 배포하면 된다고 해서 했는데 안 되고, 이렇게 수정하면 된다고 해서 고쳤는데 다른 곳이 깨졌어요. 다시 물어보면 “죄송합니다”와 함께 새로운 설명이 나왔습니다. 사과는 충분히 받았는데, 제가 무엇을 잘못 이해했는지는 여전히 흐릿했어요. 사이트 규모에 비해 자산을 관리하는 곳이 여러 군데로 나뉘어 참조가 깨지기도 했습니다. 공개 커뮤니티와 그룹 커뮤니티에는 같은 오픈소스 텍스트 에디터를 쓰면서도 각각 따로 붙여두었어요. 비슷한 것을 고치려면 여러 곳을 손대야 했죠. 처음에는 그것도 그렇게 하는 게 맞다는 설명을 믿었습니다. 에디터 자체가 어떻게 동작하는지, 어디까지 함께 쓰고 무엇을 구분해야 하는지 판단할 기준이 없었으니까요. 뒤늦게 돌아보니, 정답이 하나로 정해져 있지 않은 문제에 정답이 있다고 생각했던 것 같아요. 어떤 구성이 가능하다는 말과 지금 제 상황에 그 구성이 적절하다는 말은 다른데, 당시에는 그 차이를 잘 몰랐습니다. 혼자 운영한다는 것, 지금의 규모, 자주 바꾸고 싶은 부분, 감당할 수 있는 복잡성 같은 배경도 충분히 전달하지 않았고요. 그때와 지금의 차이를 가장 실감하는 건 코드를 볼 때보다, 무언가를 시작하려고 할 때입니다. 예전에 심리상담 앱을 만들어 구글에 출시하려다가 심사에서 거절된 적이 있어요. 의료 관련 앱으로 분류되는 문제와 개발자 계정 요건을 만나게 됐습니다. 처음에는 AI가 안내하는 대로 이름을 바꾸고, 관련 표현을 고쳤어요. 백엔드의 DTO 이름까지 바꿨습니다. 지금 돌아보면 심사 문제와 어떤 관계가 있는지도 확인하지 않고 꽤 많은 곳을 고친 셈이에요. 이후 새 앱으로 등록했을 때는 심사를 통과했습니다. 그 경험만으로 어떤 변경이 결정적인 이유였다고 단정할 수는 없어요. 다만 당시의 저는 거절 사유와 실제 심사 대상을 먼저 좁혀보는 대신, 제안받은 수정을 전부 하는 쪽으로 움직이고 있었습니다. 사주 앱도 출시해봤어요. 그래서 지금 누군가 사주 앱을 만들겠다고 하면, 어떤 기능을 넣을지보다 어느 플랫폼에 출시할지, 해당 유형의 앱에 어떤 심사 조건이 있는지부터 확인하게 됩니다. 코드가 동작하는 것과 사람들이 실제로 내려받을 수 있는 것은 다른 문제라는 걸 겪어봤으니까요. 앱을 운영하면서는 업데이트 방식도 다르게 보였습니다. 네이티브 앱으로 만들고 나니 바꾸고 싶은 것이 생겨도 빌드와 배포, 필요한 심사 과정을 생각해야 했어요. 처음에는 네이티브의 성능이 좋다는 설명이 크게 들렸는데, 나중에는 ‘내 앱의 사용자가 그 차이를 느끼는가’와 ‘내가 얼마나 자주 바꾸고 싶은가’가 더 크게 다가왔습니다. 웹 중심으로 만들었으면 어땠을까 싶기도 했어요. 물론 그것도 모든 제약을 없애주는 답은 아니겠지만요. 리소스가 무한하다면 좋은 선택은 많겠죠. 현실의 저는 혼자 관리할 수 있는 범위가 있고, 먼저 확인하고 싶은 것이 있고, 자주 바꾸고 싶은 부분이 있습니다. 장점 목록을 아는 것과 그중 지금 필요한 장점을 고르는 것은 꽤 다른 일이었어요. 그래서 같은 AI를 쓰는데도 결과가 다른 이유를 생각하게 됩니다. AI는 저보다 훨씬 많은 기술을 알고 있어요. 그런데 그 지식이 제 상황에서 어떤 의미인지는 제가 더 구체적으로 알려줘야 했습니다. 사용자도 많지 않은 제 서비스에 Redis가 제안됐을 때, 예전에는 좋은 기술이라는 설명만 들었습니다. 지금은 어떤 병목을 해결하려는 건지, 운영 부담을 늘릴 만큼 필요한지부터 물어볼 것 같아요. 사용자 수 하나만으로 정할 일은 아니지만, 적어도 필요를 확인하지 않은 채 넣지는 않겠죠. 제가 말하는 도메인 지식은 이런 감각까지 포함합니다. 이 일을 해봤기 때문에 먼저 확인하는 것, 설명에 빠진 조건을 알아차리는 것, 그럴듯한 장점이 지금은 별 의미가 없다는 걸 판단하는 것들이요. AI의 지식보다 더 많이 외우게 돼서 달라졌다기보다, 그 답을 제 현실에 놓고 볼 수 있게 된 쪽에 가까워요. 이런 질문을 받으면 저는 피라미드를 짓는 일에 빗대어 설명하는 편입니다. 설계도 필요하고, 사람과 자원을 배분하는 일도 필요하고, 실제로 돌을 옮기는 일도 필요하잖아요. 예전에는 각 역할을 맡은 사람들을 모아야 했다면, 지금은 한 사람이 AI에게 여러 역할을 맡기며 훨씬 많은 일을 진행해볼 수 있게 됐다고 느껴요. 그렇다고 제가 손을 놓고 있어도 되는 건 아니었습니다. 설계를 맡겨도 설계가 목적에 맞는지는 봐야 하고, 자원을 나눠 맡겨도 어디가 막혀 있는지는 알아야 해요. 돌을 잘 옮기도록 시키려면 적어도 무엇을 조심해야 하는지 정도는 알아야겠죠. 여러 일을 맡길 수 있게 된 만큼, 그 사이를 이어서 판단하는 일이 제 쪽에 남는 것 같았습니다. 한 분야를 깊게 아는 사람의 가치가 줄었다는 뜻은 아니에요. 오히려 깊이 알아야만 보이는 문제가 있을 겁니다. 다만 저처럼 혼자 아이디어를 제품으로 만들어보는 사람에게는, 여러 분야의 지식을 어느 정도 이해하고 필요한 전문성을 연결하는 능력도 점점 중요해지는 것 같아요. 모든 일을 직접 잘하는 것과, 어떤 일을 맡기고 무엇을 확인해야 하는지 아는 것은 다르니까요. 이렇게 생각하다 보니, 무언가를 시작하는 순서도 바뀌었습니다. 저는 예전보다 코드가 싸졌다고 느껴요. 서비스 운영이나 유지보수까지 공짜가 됐다는 이야기는 아닙니다. 머릿속의 아이디어를 일단 돌아가는 형태로 만들어보는 데 필요한 비용이 제게는 크게 낮아졌다는 뜻이에요. 그래서 처음부터 많은 기능을 채우기보다, 이 아이디어가 실제로 쓸모 있는지를 먼저 확인하는 데 더 마음이 갑니다. 작은 PoC를 자주 해보고 싶어졌어요. PoC는 아이디어의 핵심이 실제로 가능한지 작게 만들어 확인하는 과정입니다. 제가 증명하고 싶은 것 하나를 먼저 증명해보는 거예요. 그게 되면 거기에 살을 붙이면 되지 않을까 싶었습니다. 가령 반복되는 문서 검토를 AI가 도와줄 수 있는지 궁금하다고 해볼게요. 완성된 서비스에는 로그인도 필요하고, 권한별 화면도 필요하고, 관리 기능도 필요하겠죠. 하지만 처음 확인하고 싶은 것은 AI의 검토 결과가 실제로 쓸 만한가 하는 점입니다. 예시 문서로 그 부분부터 확인할 수 있는데, 주변 기능을 다 만들고 나서야 핵심 결과가 마음에 들지 않는다는 걸 알게 되면 순서가 아쉽잖아요. 실제 사람들의 정보나 업무에 적용할 때 필요한 보호 장치는 당연히 갖춰야 합니다. 다만 작은 검증을 할 때까지 완성된 서비스의 모든 기능을 먼저 갖출 필요는 없다는 생각이에요. 무엇을 확인하려고 시작했는지 잊지 않는 게 중요해졌습니다. 지금 운영하는 AI 뉴스 사이트도 그렇게 시작했어요. 첫 커뮤니티를 만들었던 때보다 훨씬 나중의 이야기입니다. 매번 여러 사이트를 돌아다니며 AI 뉴스를 찾는 게 귀찮았어요. 영어 원문까지 읽으려니 시간도 많이 들었고요. ‘이걸 모아서 내가 읽기 편하게 정리해줄 수 없을까’라는 작은 불편이 출발점이었습니다. 처음부터 지금의 사이트를 기획한 건 아니었어요. 뉴스를 수집하고 정리한 결과를 제가 읽어봤을 때 괴리감이 없는지, 실제로 읽을 만한지가 먼저였습니다. 수집이 실패하는 일이 생기니 로그를 남기기 시작했고, 계속 쓰면서 인증과 관리자 페이지, 소개 같은 기능도 붙었습니다. 지금은 중요한 기능들이지만, 처음의 질문은 훨씬 작았어요. 처음에는 저를 위해 만들었는데, 공유하고 나니 매일 읽는 분들이 생겼습니다. 잘 읽고 있다는 메일도 받았어요. 제 귀찮음을 줄이려고 시작한 것이 누군가의 하루에도 들어가게 된 셈이라, 그런 연락을 받으면 아직도 좀 신기합니다. 진행하다 멈춘 아이디어도 많아요. 그래도 그 과정에서 ‘여기까지는 구현할 수 있구나’라는 감각이 남았습니다. 지금 운영하지 않는다고 해서 그 가능성까지 사라지는 건 아니더라고요. 나중에 비슷한 문제가 생기면 무엇을 어떻게 설명해야 하는지, 어디부터 확인하면 되는지 조금은 알고 다시 시작할 수 있으니까요. 그렇다고 이제 AI에게 맡기면 언제나 제 마음에 들게 나오는 건 아닙니다. 기능은 동작하는데 실제 사람이 쓰면 어색할 것 같은 흐름도 있고, 자동으로 검증을 돌려도 제가 직접 보면 걸리는 부분이 있어요. 마지막에 읽어보고 사용해보는 일은 여전히 제 몫으로 남아 있습니다. 원하는 결과가 나오지 않았을 때도 예전과는 조금 다르게 보려고 해요. 제가 요구사항을 충분히 설명했는지, 확인할 조건을 명확히 줬는지, 중간에 잘못된 방향을 발견할 기회가 있었는지부터 돌아봅니다. AI가 할 수 없는 문제도 있겠지만, 제가 작업 환경이나 검증 과정을 바꿔서 나아진 경험이 있었거든요. 실패를 전부 제 설명 탓으로 돌리기보다는, 제가 바꿀 수 있는 부분부터 살펴보는 셈입니다. 요즘 이야기하는 하네스도 제게는 그런 맥락이에요. AI가 사용할 도구와 지침, 결과를 확인하는 과정을 갖춰두는 것. 한 번에 끝까지 맡기기보다 어느 조건을 통과해야 다음으로 갈지 정해두는 것도 포함됩니다. 좋은 문장 하나로 모든 것이 해결되기보다는, 잘못된 방향으로 갔을 때 알아차리고 돌아올 수 있게 만드는 일이 필요하더라고요. 요즘 가장 많이 고민하는 건, 제가 생각한 것과 실제로 만들어진 결과 사이의 거리를 어떻게 줄일 수 있을까 하는 거예요. 분명히 설명했다고 생각했는데 결과를 보면 어딘가 다를 때가 있습니다. 기능은 있는데 사용 흐름이 어색하거나, 제가 중요하게 생각한 부분보다 다른 곳에 공이 더 들어가 있기도 해요. 그러면 제가 당연하게 여겼던 조건을 설명하지 않았는지, 중간에 확인해야 할 것을 마지막까지 미뤄둔 건 아닌지 돌아보게 됩니다. 이런 경험이 쌓이면서 원하는 결과만 말하는 것에 더해, 제가 무엇을 중요하게 보는지도 전달하려고 해요. 지금 확인하려는 것은 무엇인지, 어떤 복잡성은 아직 필요하지 않은지, 어디까지 됐을 때 다음 단계로 넘어가도 되는지 같은 것들이요. 처음부터 제 생각을 빠짐없이 전달하는 방법이 있는지는 아직 모르겠습니다. 지금은 작은 결과를 먼저 보고, 차이를 설명하고, 그 과정에서 알게 된 기준을 다음 작업에 남기는 식으로 조금씩 맞춰가고 있어요. 제 페르소나를 만들고 싶다는 생각도 말투를 닮게 하는 것보다는, 이런 판단 기준을 함께 갖고 일하고 싶다는 마음에 가깝습니다. 아이디어를 놓치지 않으려는 방식도 조금 바뀌었어요. 폰과 컴퓨터에서 늘 연결해두는 에이전트에게 생각이 떠오를 때 바로 메모를 남기고, 확인할 일을 시킵니다. 음성으로 이야기할 때도 있지만, 중요한 건 음성이라는 방식보다 아이디어가 휘발되기 전에 작은 행동으로 이어진다는 점인 것 같아요. 저는 AI를 쓰는 일이 수영과 좀 닮았다고 느낍니다. 교본을 읽는 것과 물에 들어가 직접 물장구를 쳐보는 것은 다르잖아요. 설명을 들을 때는 알 것 같다가도, 제 문제를 가지고 해보면 다른 곳에서 막힙니다. 몇 번 해봐야 어디까지 맡길 수 있고 어디서 제가 봐야 하는지 조금씩 감이 생겨요. 그래서 아직도 제가 모르는 가능성이 많을 거라고 생각합니다. 제가 안 된다고 여긴 일을 누군가는 이미 해결했을 수도 있고, 반대로 쉽게 될 줄 알았던 일이 제 상황에서는 어려울 수도 있겠죠. 누구에게나 맞는 사용법을 찾기보다, 제 주변의 작은 불편을 하나씩 가져와 직접 부딪혀보는 쪽이 지금의 저에게는 잘 맞았습니다. 돌아보면 운이 좋았어요. 우연히 본 영상이 재미있었고, 배우고 싶고 만들고 싶은 것이 많아지던 시기에 AI를 만났습니다. 덕분에 머릿속에만 뒀을지도 모르는 것들을 실제로 만들어볼 수 있었어요. 예전 코드를 보면 여전히 고치고 싶은 곳이 많습니다. 다만 이제는 그 안에서 당시의 제가 무엇을 몰랐고, 무엇을 만들고 싶어 했는지도 보여요. 그때는 믿고 넘어갔던 곳에서 지금은 질문을 하나 더 할 수 있게 됐고요. 앞으로도 만들고 고치다 보면, 지금은 보이지 않는 것들이 또 보이겠죠. 개발을 시작한 이야기를 하려다가 요즘의 고민까지 길어졌네요. 한 번쯤은 제가 어떤 과정을 지나왔고 무슨 생각을 하고 있는지 남겨보고 싶었습니다. 끝까지 읽어주셨다면, 두서없는 긴 이야기에 시간 내주셔서 감사합니다.

로그인한 사용자의 이름이 아주 가끔 다른 계정으로 보이는 문제는 재현하기가 어렵습니다. 원인은 서버 파일 위쪽에 둔 변경 가능한 사용자 변수일 수 있습니다. 서버 모듈은 요청마다 새로 만들어지는 지역 저장소가 아닙니다. 같은 프로세스에서 A 요청과 B 요청이 겹치면 두 요청이 같은 모듈 변수를 사용합니다. B가 값을 덮어쓴 뒤 A가 다시 읽으면 사용자 정보가 섞일 수 있습니다. 사용자별 값은 요청 함수의 지역 변수에 두고, 필요한 하위 컴포넌트에는 props로 전달하는 편이 안전합니다. Server Component에서 같은 함수를 같은 인자로 반복 호출한다면 React의 cache로 중복 작업을 줄일 수 있습니다. 이 캐시는 서버 요청마다 무효화됩니다. 모듈 스코프에는 바뀌지 않는 설정과 정적 자산을 남기세요. 공유 캐시가 필요하다면 사용자별로 캐시 키를 나누고 TTL과 접근 범위를 명확히 해야 합니다. 서버 파일 위쪽의 변경 가능한 변수가 정적 설정인지 사용자별 값인지 한 번 확인해 보세요.

서버에서 실행된다는 이유만으로 Server Action이 자동으로 보호되지는 않습니다. 클라이언트는 Server Action을 네트워크로 호출하고 인수도 직접 보냅니다. 따라서 postId 같은 값은 신뢰하지 않는 입력으로 보고, 함수 안에서 현재 사용자와 대상 리소스의 권한을 확인해야 합니다. 영상의 Before는 전달받은 postId로 곧바로 게시물을 삭제합니다. After는 세션을 확인하고 게시물 소유자와 현재 사용자를 비교한 뒤 삭제합니다. 'use server'; export async function deletePost(data) { const { postId } = deletePostSchema.parse(data); const session = await verifySession(); if (!session) throw new Error('Unauthorized'); const post = await db.post.findUnique({ where: { id: postId } }); if (!post || post.ownerId !== session.user.id) { throw new Error('Forbidden'); } await db.post.delete({ where: { id: postId } }); } 버튼 숨김, 미들웨어, 레이아웃 가드는 화면 접근을 빠르게 제어하는 장치입니다. 민감한 변경을 허용할지는 Server Action 내부에서 최종 판단하세요. 로그인 확인과 리소스 단위 인가는 서로 다른 검사입니다. 영상처럼 입력 검증 → 인증 → 리소스 단위 인가 → 변경 순서로 actions 파일을 점검해 보세요. #React #Nextjs #웹보안

삭제 버튼을 관리자에게만 숨겼는데, Server Action 안에는 권한 검사가 없나요? 버튼을 감추는 코드는 화면을 정리할 뿐 요청을 막지 못합니다. Server Action은 서버에서 실행되지만 클라이언트가 네트워크로 호출할 수 있는 진입점입니다. 함수에 전달된 postId 같은 값도 클라이언트가 바꿀 수 있다고 보고 처리해야 합니다. 'use server'; export async function deletePost(data) { const { postId } = deletePostSchema.parse(data); const session = await verifySession(); if (!session) throw new Error('Unauthorized'); const post = await db.post.findUnique({ where: { id: postId } }); if (!post || post.ownerId !== session.user.id) { throw new Error('Forbidden'); } await db.post.delete({ where: { id: postId } }); } 순서는 분명합니다. 먼저 입력을 검증하고 현재 세션을 확인한 다음, 그 사용자가 해당 리소스를 바꿀 권한이 있는지 검사합니다. 로그인 여부만 확인하면 다른 사용자의 postId로 요청하는 경우를 막지 못합니다. 미들웨어, 레이아웃 가드, 숨긴 버튼은 빠른 화면 제어에는 쓸 수 있습니다. 민감한 변경의 최종 보안 경계는 Server Action 내부에 두세요. 공통 검사는 Data Access Layer로 모아도 각 Action이 그 검사를 호출해야 합니다. 지금 actions 파일을 열어 세션 검사와 리소스 단위 인가가 모두 있는지 확인해 보세요. #React #Nextjs #웹보안

안힘들거다 그런 말 하는 게 아니라 전보다 힘들어진 건 아마 사실일 듯한데 지금 정확하게 어느정도로 힘든지 궁금하네요 최근에 우연히 취준중인 서울대 컴공 후배를 봤는데 회사 떨어지고 우울해하고 있더라고요. 근데 제가 요새 회사들 신입 포지션이 얼마나 들어가기 어려운지 감이 없어서 거의 조언을 못해줬었거든요 진짜 힘든 게 맞으면 뭐라 조언을 해야하지? 도 의문인 부분이고요 안되는거 붙잡고 있으란 것도 어찌보면 못할 말이니 IT 개발자 직군 전체적으로 어떤가요? 신입 뽑긴 하시나요? 저도 AI agent 성능 올라오고부터 거의 안 뽑긴 합니다만 다른 곳은 어떤지.. SDS도 원래 천명 가까이 뽑았다 최근엔 50명을 뽑았다 그런 이야기도 들어본 것 같기도 하네요

https://github.com/dorafather/NotebookRAG 내 컴퓨터 안의 문서를 로컬에서 검색하고, Claude Code 등 MCP를 지원하는 AI 도구에서 자연어로 질문할 수 있게 해주는 Windows용 개인 문서 검색 도구입니다. 문서는 컴퓨터 밖으로 절대 나가지 않습니다. 문서 이해(임베딩)와 검색 모두 여러분의 컴퓨터 안에서만 처리됩니다. 왜 만들었나 직장인의 노트북에는 몇 년 치 문서가 정리 안 된 채 쌓여 있는 경우가 많습니다. 어떤 파일이 최신본인지, 어디에 뭐가 있는지 기억하기 어렵고, 검색은 파일명이나 폴더 구조에 의존할 수밖에 없습니다. 기업용 RAG(검색 증강 생성) 솔루션은 많지만, 대부분 "회사 조직"을 대상으로 하지 "개인 노트북의 어수선한 문서함"을 대상으로 하지 않습니다. NotebookRAG는 그 빈틈을 채우려는 개인 프로젝트입니다 — 의미 기반 검색(파일명이 아니라 내용으로 찾기)과 완전한 로컬 프라이버시를 개인 사용자 규모에서 제공합니다. 특징 완전 로컬 처리 — 임베딩(bge-m3)과 벡터 검색(sqlite-vec) 모두 컴퓨터 안에서 실행. 인터넷 연결은 최초 모델 다운로드 시에만 필요. 백그라운드에서 조용히 색인 — CPU 사용률을 낮게 유지하도록 최적화되어, 다른 작업을 하는 동안 방해 없이 천천히 색인이 진행됩니다. MCP 표준 지원 — Claude Code를 비롯해 MCP(Model Context Protocol)를 지원하는 어떤 AI 도구에서도 연동 가능합니다(MCP는 개방형 프로토콜입니다). 이중 요약 없음 — MCP로 연동된 AI 클라이언트가 이미 언어모델이므로, NotebookRAG는 검색된 원문을 그대로 반환합니다. 별도 API 키가 필요 없습니다. 트레이 앱으로 상태 확인 — 색인 진행 상황, 디스크 사용량, 검색 연동 상태를 트레이 아이콘에서 바로 확인·제어할 수 있습니다. 관리자 권한 불필요 — 설치부터 실행까지 일반 사용자 권한만으로 동작합니다(회사 노트북 환경 고려).

안녕하세요! IT 분야 취업 준비, 직무 향상, 최신 기술(AI·클라우드·지도 데이터) 학습에 도움 되는 대표적인 무료 교육 사이트들을 정리해 공유합니다. 📌 추천 무료 IT 교육 플랫폼 ETEVERS (에티버스러닝) 주소: https://etevers.step.or.kr/main.do 특징: 네트워크 기초부터 리눅스 고급 기능, AI까지 단계별 직무 교육 진행 CCCR (한국클라우드컴퓨팅연구조합) 주소: https://www.cccr-edu.or.kr/main/index.jsp 특징: 클라우드 인프라 기반에 Ansible 자동화, Python, AI 실무 과정 위주 KCIA (한국정보통신공사협회) 주소: https://k-cia.or.kr/bbs/board.php?bo_table=sub6_1 특징: 클라우드 데이터센터 인프라 교육 (※ AIDC 인프라 구축 등 일부 유료/유급 과정 포함) KOREN (지능형 초연결망 연구소) 주소: https://koren.kr/ 특징: 국가연구개발망(KOREN) 연계 네트워크 실무, 연구망 운영, 전용회선 실습 중심 V-WORLD (브이월드) 주소: https://www.vworld.kr/v4po_main.do 특징: 공간정보산업진흥원에서 제공하는 대한민국 3D 공간정보 지도 API 및 GIS 활용 교육 💡 추가 추천 무료 IT 교육 플랫폼 SK Tacademy (SK플래닛 T아카데미) 주소: https://tacademy.skplanet.com/ 특징: SK 그룹에서 운영하는 무료 ICT 플랫폼. 딥러닝, 빅데이터, 백엔드 개발 VOD 무료 제공 STEP (스마트 직업훈련 플랫폼) 주소: https://www.step.or.kr/ 특징: 고용노동부/한기대 운영. Server, Linux, Network, AI, 가상훈련(VR) 등 1,000여 개 과정 무료 전액 제공 K-MOOC (한국형 온라인 공개강좌) 주소: http://www.kmooc.kr/ 특징: 국내 주요 대학(서울대, KAIST 등)의 컴퓨터공학, 데이터분석, 인공지능 정규강의 무료 수강 IT 분야 공부나 전직을 준비하시는 분들께 도움이 되었으면 합니다!

내 첫회사 MS 골드 파트너 G사 회사 내규에 1년동안 3일 쉬는거라고 써져 있고, OJT없고 윗대가리들도 이야기 안해줘서 주말,공휴일 일한거 대체휴가, 돈으로 받을수 있었는데 해달라고 하니까 고객사 싸인 받아오라 그래서 사직서 던지고 퇴사함 두번쨰 MS 골드파트너 회사 대기업 H사에서 상주해서 매일마다 점심 굶어가면서 15시간씩 일했는데 586 간부놈들 어딜가나 똑같슴 "해줘"",해줘야지","무슨소리야","너아니어도할사람많아" 남의 자식은 갈아넣는거 당연하게 생각하면서, 본인 자식은 선진국보내고 싶어함 (내로남불) 그러면서 결혼하라마라, 애 낳으라 마라 오지랖함 대가리 총맞았나. 저출산,고령화속도,자살율,노인빈곤율 OECD1위인데. 586 세대는 어디서 세뇌 교육을 받은거야? "이렇게 좋은 나라가 어딨서" 미쳐날뛰던데 우리나라 모든 언론사, 통계청에서 출산 30년치, 한국은행,행정안전부에서 인구소멸지역 검색, chatgpt,claude , 서울대학교 공식 유투브 채널에서 "저출산"검색해보셈. https://www.youtube.com/watch?v=iMEWpfXXjVc https://www.youtube.com/watch?v=BNpy5lDcNe4&t=139s https://www.youtube.com/watch?v=t6wRxOufGhs&t=791s 데이터, 숫자에 근거해서 반박 하길바란다. 대한민국 은 쓰레기 라는 생각 밖에 안듬. 지금 태어나면 세금 3배씩 쳐내야되는데 "난몰라","가르쳐줘야알지","어떻게 알아" 미쳐날뛰는 놈은 일 안함 나만 15시간씩 일하다가 퇴사했다. 우리나라 5대 병원 중에 한곳인 S병원 일했는데 패스워드 초기화 전직원 나한테 던졌는데 콜센터 전화기 안사줘서 사비로 삼 두번쨰 손가락 방아쇠 수술함 . 보안 팀장도 학원수강생,컴퓨터공학생보다 지식이 전무함 DNS,NAT, 변수,함수,SQL,웹서버 용어 자체에 대한 개념이 없슴. 보안 취약점 스크립트도 내가 돌리고 ISMS-P 인증 심사 문서도 서버관리자인 내가 만듬. 보안 담당자가 학원수강생,컴퓨터공학생보다 지식이 전무하니까. S&P500에 해당되는 여의도 A사에서 일했는데 학원수강생,컴퓨터공학생보다 지식이 전무한 인간들이 항상 인프라팀장,보안팀장,PM이였슴 " 최신 OS를 설치하면 왜 안되" 이럼 ㅋㅋㅋㅋ DNS,NAT,변수,함수,SQL이 뭔지 모름 ㅋㅋㅋㅋ 내가 일 다하고 설명을 다해줘야됨 "니가 만들어낸말 아니냐","여러분은 무슨말인지 알아 들으시겠나요" 이게 바로 S&P500 한국지사 인프라팀장의현실이다. ㅋㅋㅋㅋㅋ 우리나라 최고 권력기관 PM도 "최신 OS설치하면 왜 안되" 이러더라 ㅋㅋㅋㅋㅋ 586 세대가 만든거다.포괄임금제,호봉제 금지하고 직무급으로 바꿔야된다. 아니면 영어 배워서 나라 팔아 먹고 이민 가는게 Best다. 열심히 일하는 사람이 바보고, 난몰라 미쳐날뛰는 놈은 일안하는데 AWS,Azure,GCP 쓰지 돈없으면 네이버,KT클라우드 쓰는거지 AI도 미국,중국 AI쓰지 대한민국AI 가 왜 발전 못했겠나? 왜 삼성도 자기네 AI 쓸려다가 포기하고 chatgpt enterprise쓰겠는가? 포괄임금제,호봉제 금지하고 직무급으로 법으로 강제해야된다. 열심히 일하는 사람이 바보고, 난몰라 미쳐날뛰는 놈은 일 안하니까 586 세대가 만든거임

요즘 강세인 AI 중소 -> 아직 레거시가 많은 대기업으로 이직 했는데, 적응이 잘 안되네요.. 드라마틱 하지도 않고.. 일이 전에 회사가 더 적성이 맞았던거 같은 생각으로 자꾸 이전 회사가 생각이 나는데... 시간이 지나면 괜찮겠죠?? 이제 이직 3개월차네요...😂😂 어떡하면 좋을까요... 다시 가고싶은 마음도 들고.. 그러기엔 제 자신이 실패한 사람으로 찍힐까 두렵고.. 싱숭생숭합니다ㅠ

15년차 시니어개발자가 6년차 미드 개발자보다 개발을 못하는 상황. 이럴 따는 어떻게 해야할까요... 미드 개발자의 불만도 점점 커지는 거 같습니다. 자기보다 연봉도 훨씬 많이 받는데 개발도 본인보다 못하고 6개월을 넘게 코칭해도 나아질 기미가 안보이네요. 시나어가 개발한 거를 미드가 디버깅하는 상황이네요.

회사는 일반적인 중소기업이고 수습기간 100% 급여를 지급해주는 회사입니다. OA엔지니어로 1년 계약직 후 정규직 전환 조건으로 다니고 있습니다. 파견직이라 보통 1~2명에서 근무합니다. 인수인계는 대충 파일 및 서류 보라고 받았고요. 업무는 점검 때 스케쥴 정해서 현장 가거나 장애 발생시에 조치하러 가는 게 주된 업무입니다. 문제는 일정 및 업무 공유를 안합니다. 집에서 대기한 횟수만 한달 기준 13회입니다. 연락없으면 대기하라는 말하고 대기하고 있으니 나중에 보니 현장가서 혼자 일 처리하고 오더라고요. 이런 일이 몇 번 좀 있습니다. 지금 근무한지 한달 좀 지났는데요. 어려운 시기에 일단 취업을 한거라 남는 시간에는 계속해서 자기계발하고 있습니다. 수습기간 때 잘린 전 회사에서도 저보다 나이 어린 선임이란 작자가 업무일정 하나도 공유 안하고 일 생길때마다 출동했고 제대로 인수인계도 안한 상태에서 그냥 일 못한다고 위에 보고해서 수습기간 퇴사를 한 적이 있었는데요. 지금 회사도 이러지 않을까 싶어서.. 혹시 모를 상황에 대비해서 이직준비를 하고 있습니다. 이런 경험이 있으셨는지 궁금합니다.

AD구축 및 EntraID M365 등을 다룰 수 있는 성실한 엔지니어를 찾고 있습니다 혹시 소개 가능 하시거나 업무지원 가능 하시면 연락 주세요~ 더운 날씨 건강들 조심하세요 감사합니다

여러 나라에 걸쳐 2,000명 넘는 사업주·전문가 커뮤니티를 운영해 왔습니다. 그동안은 타앱 기반으로 굴려왔는데, 규모가 커지면서 결국 자체 앱으로 옮기기로 했습니다. 막상 시작하니, 앱을 만든다는 게 생각보다 훨씬 힘들고 시간도 오래 걸리는 일이더군요. 머릿속에서는 단순해 보였는데, 실제로는 다국어 처리, 알림, 인증, 빌드와 스토어 심사까지 챙길 게 끝없이 나왔습니다. "이 정도면 금방 되겠지" 했던 게 몇 배로 늘어나는 경험을 계속했습니다. 혼자, 혹은 작은 팀으로 제품을 만들어 보신 분들은 아마 공감하실 것 같습니다. 그래도 그 구간을 지나고 보니, 이제 기술적인 부분은 대부분 해결됐습니다. 만들 수 있느냐의 문제는 거의 끝난 거죠. 그런데 여기서 깨달은 게 있습니다. 정작 어려운 건 만드는 게 아니라, 만든 걸 사람들에게 알리고 퍼뜨리는 일이라는 겁니다. 기술은 시간과 노력으로 풀리는데, "사람을 모으는 것"은 그것만으로는 안 되더군요. 그래서 앞으로는 개발보다 확산에 집중해야겠다고 마음을 잡았습니다. 그래서 이런 플랫폼 소개글도 써보고 https://www.businnect.com/blog/businnect-sogae-saeobjuwa-geomjeungdoen-jeonmungareul-wihan 다른 앱과 서비스도 실험 중입니다. 비슷하게 직접 무언가를 만들어 세상에 내놓아 보신 분들께 묻고 싶습니다. 만드는 단계에서 알리는 단계로 넘어갈 때, 어떻게 방향을 잡으셨는지 궁금합니다. 경험 나눠주시면 감사하겠습니다.

저는 스타트업에서 일을하고 있는 신입 개발자입니다. 그러다보니 사수도 없고 모든 개발을 제가 다하고 있는데 하다보니 궁금한게 있어서 글을 써요. 개인정보 처리방침, 이용약관, 마케팅 전보수신 동의, 이메일 무단수집 거부 이런 것들은 법률이나 해당 관련한 내용들을 어떻게 작성하고 홈페이지에 보이게 해야할까요??

안녕하세요. 이제 주니어 벗어난 사람입니다. 지금이 두 번째 회사인데요. 첫번째 회사는 정말 다니기 좋았으나 연봉과 커리어 욕심으로 이직을 하였습니다. 문제는 이직 이후 두번째 회사때문에 마음이 편한 적이 없었는데요. 금일 다른 건으로 면담을 진행한 이후 정말 이 회사는 아님으로 확신이 들어 사직의사를 밝히려 합니다. (회사는 좋으나 저랑은 맞지 않습니다) 먼저 메일로 보내고 내일 면담이나 기타 프로세스를 안내받으면 될까요? 제가 이직 스케줄로 전회사는 급하게 퇴사했던 터라 퇴직프로세스를 잘 알고있지 못합니다. 후배다 생각해주시고 고견을 부탁드립니다. 감사합니다.