[연재] 301 리디렉트 — 검색 평가를 옮기는 법
어제 걸어둔 이사 표시가 오늘 아침이면 사라져 있었습니다
지난 편에서 흩어져 있던 사이트 여섯 개를 한 도메인 아래로 모았어요. 그리고 옛 주소 여섯 개에는 "여기 살던 사람 저리로 이사 갔습니다" 표시를 걸어뒀습니다.
그런데 그 표시가 하루를 못 갔어요.
매일 아침 9시에 사이트를 자동으로 올려주는 작업이 하나 돌고 있었거든요. 그 작업이 옛 주소 자리에 본진 내용물을 통째로 다시 덮어쓰고 있었습니다. 어제 저녁에 걸어둔 이사 표시 위에 오늘 아침 짐이 다시 들어차는 거예요. 그러면 옛 주소는 다시 "여기 사람 삽니다" 상태가 되고, 이사 표시는 흔적도 없이 사라집니다.
발견한 건 완전히 우연이었어요. 다른 걸 확인하려고 예약 작업 목록을 열어봤다가 눈에 걸렸습니다. 안 봤으면 몇 주 뒤에 "왜 검색이 하나도 안 붙지" 하면서 엉뚱한 데를 파고 있었을 거예요.
이 편의 정서는 '조용히'입니다. 화면은 멀쩡하고, 배포는 성공이라고 찍히고, 어디서도 빨간 불이 안 들어와요. 그런데 옮겨야 할 게 매일 아침 제자리로 돌아가 있습니다.

여기가 새 집입니다. 옛 본진 주소로 들어와도, www 를 붙여서 들어와도 지금은 전부 이 화면으로 옵니다. 그렇게 되기까지 챙겨야 했던 것들을 순서대로 적어볼게요.
301과 302는 한 글자 차이인데 결과가 다릅니다
먼저 이 숫자부터요.
주소를 옮겼다고 브라우저한테 알려주는 방법은 크게 두 가지예요.
- 301 — "영구히 옮겼습니다"
- 302 — "잠깐 다른 데로 보냅니다. 곧 돌아옵니다"
사람 눈에는 둘이 완전히 똑같습니다. 옛 주소를 누르면 새 주소로 넘어가고, 화면이 뜨고, 끝이에요. 둘 다 아무 오류도 안 납니다.
다른 건 검색엔진 쪽이에요. 301을 받으면 검색엔진은 옛 주소에 쌓여 있던 점수 — 그동안 사람이 들어오고, 링크가 걸리고, 색인에 올라간 그 누적치 — 를 새 주소로 옮겨줍니다. 302를 받으면 안 옮겨요. "곧 돌아온다며?" 하고 옛 주소를 그대로 붙잡고 기다립니다.

이사 표시를 거는 스크립트 맨 위에 그 이유가 적혀 있어요. 노랗게 칠한 세 줄이요. "301 을 쓰는 이유: 검색엔진이 옛 주소에 쌓인 평가를 새 경로로 넘긴다. 302(임시)면 넘어가지 않는다."
이게 왜 중요하냐면요. 통합을 한 이유 자체가 여섯 갈래로 흩어진 점수를 한 군데로 모으려던 거였거든요. 여기서 302를 쓰면 모으는 일 자체가 안 됩니다. 화면은 멀쩡히 넘어가니까 몇 달 동안 모르고 지나갈 수도 있고요.
숫자 하나 차이로 몇 달치가 날아가는 자리인데, 화면으로는 절대 구별이 안 됩니다. 이런 게 이번 편에 계속 나와요.
이사 표시는 파일 한 줄입니다
막상 거는 건 어렵지 않았어요. 옛 프로젝트마다 _redirects 라는 파일 하나를 올리면 됩니다. 안에 들어가는 건 딱 한 줄이에요.

위쪽이 짝 맞추기예요. parental-pay 는 /leave 로, card-wallet 은 /cards 로, equity-holdings 는 /equity 로. 옛 본진(victor-simpson)만 뒤가 비어 있는데, 이건 도메인 뿌리로 보내라는 뜻입니다.
그리고 노랗게 칠한 줄이 실제로 만들어지는 한 줄이에요. 여기 표시 두 개가 들어 있습니다.
/*— 옛 주소의 모든 페이지를 잡습니다. 첫 화면만이 아니라 그 아래 있던 것 전부요.:splat— 잡힌 주소에서 뒤에 남은 부분을 그대로 이어붙입니다.
말로는 헷갈리는데 결과를 보면 바로 이해가 돼요.
card-wallet.pages.dev/ → victor-house.com/cards/
card-wallet.pages.dev/index.html → victor-house.com/cards/index.html
뒤에 뭐가 붙어 있든 그대로 따라옵니다. 저 두 번째 줄은 방금 실제로 확인해본 결과예요. 이게 왜 필요하냐면, 옛 주소로 색인돼 있던 게 첫 화면 하나가 아니거든요. 검색 결과에 올라가 있던 안쪽 주소들이 전부 자기 짝을 찾아가야 합니다.
여기서 흔한 실수가 "첫 화면끼리만 연결"하는 거예요. 옛 주소 안쪽 페이지들을 전부 새 도메인 첫 화면으로 보내버리는 건데, 그러면 검색엔진은 그걸 이사로 안 봅니다. "찾던 페이지가 없어서 홈으로 튕겼구나"로 읽어요. 점수는 안 넘어가고요.

그 아래에 한 가지가 더 있어요. 이사 표시를 안 따르는 손님을 위한 안내 페이지입니다. 옛 주소에 사람이 읽을 수 있는 한 장을 같이 올려둬요. "이 페이지는 저기로 옮겼습니다" 한 줄과 링크가 들어 있고, 검색엔진한테는 "이건 색인하지 마라"(noindex)와 "원본은 저기다"(canonical) 표시를 붙였습니다.
브라우저로 들어오면 이 페이지는 볼 일이 없어요. 위의 한 줄이 먼저 잡아서 바로 넘겨버리거든요. 못 보는 게 정상인 페이지를 굳이 만들어 두는 겁니다. 리디렉트를 안 따르는 기계가 세상에 얼마나 있는지 저도 모르고요, 없으면 안 쓰이고 마는 한 장이라 손해 볼 게 없어서요.
그런데 그 한 줄을 매일 아침 누가 지우고 있었어요
자, 여기가 도입에서 말한 그 자리입니다.
당시 배포 구조가 이랬어요. 본진을 올리는 스크립트가 따로 있었고, 도구마다 자기 배포 스크립트가 또 따로 있었습니다. 흩어져 살던 시절의 잔재였죠. 그리고 매일 아침 9시에 도는 자동 작업이 본진 배포 스크립트를 부르고 있었어요.
문제는 그 스크립트가 아직 옛 주소 자리에 올리고 있었다는 겁니다. 이사 가기 전 주소로요.
순서를 늘어놓으면 이렇게 됩니다.
1. 저녁에 옛 주소 여섯 곳에 이사 표시를 건다 2. 다음 날 아침 9시, 자동 작업이 옛 주소 자리에 본진을 통째로 올린다 3. 올라간 내용물이 이사 표시를 덮는다 4. 옛 주소는 다시 "여기 사람 삽니다" 상태가 된다
하나도 안 고장 났어요. 자동 작업은 시킨 대로 정확히 돌았습니다. 시킨 내용이 어제 것이었을 뿐이에요. 이 연재에서 몇 번 나왔던 그 모양입니다 — 전제가 바뀌었는데 자동화만 예전 전제로 계속 도는 것.
고친 방법은 조건을 더 붙이는 게 아니었어요. 그 스크립트들을 지웠습니다.

배포 폴더 안내문에 그 결정이 그대로 적혀 있어요. 옛 프로젝트 여섯 곳에는 새 경로로 보내는 이사 표시만 들어 있어야 하고, 거기에 내용물을 올리면 표시가 덮여서 그동안 쌓인 게 끊긴다고요. 그래서 그 사고를 낼 수 있는 도구별 옛 배포 스크립트는 아예 삭제했습니다. 지금 필요한 배포 명령은 통합 배포 하나뿐이에요.
이건 32편에서 이관 자동화를 끌 때랑 똑같은 판단이었어요. 한 번의 실수로 깨지는 방어는 방어가 아닙니다. "옛 주소에는 올리지 않도록 조심하자"는 조심으로 지켜지지 않아요. 올릴 수 있는 도구가 손 닿는 데 있으면 언젠가는 눌립니다. 그래서 도구 자체를 없앴습니다.
재미있는 건, 지운 스크립트 이름이 아직 한 군데 남아 있다는 거예요. 본진 생성기 파일 맨 위 설명에 "만들고 나면 이걸로 배포하세요" 하고 그 이름이 그대로 적혀 있습니다. 파일은 없는데 이름만 남은 거죠. 사고를 내는 줄은 아니지만, 그대로 따라 치면 "그런 파일 없다"는 말을 듣게 됩니다. 코드는 지워도 문서는 안 따라 지워지더라고요.
옛 프로젝트를 지우면 더 나쁩니다
여기서 저는 반대로 생각했었어요. "이사도 갔는데 옛날 집은 그냥 없애버리면 되는 거 아닌가?"
안 됩니다. 그게 제일 나빠요.
프로젝트를 지우면 옛 주소는 404 — "그런 페이지 없음"이 됩니다. 그러면 검색엔진 입장에서 이건 이사가 아니라 소멸이에요. 옮겨줄 대상이 없어졌으니 쌓인 점수는 그냥 사라집니다. 검색 결과에서도 조용히 빠지고요.
그러니까 옛 주소는 빈 껍데기로 계속 살려둬야 합니다. 아무것도 안 들어 있고, 오는 사람마다 새 주소로 보내주기만 하는 상태로요. 이사한 집에 우편물 전달 신청을 걸어두는 거랑 똑같아요. 신청을 해두면 편지가 따라오고, 집을 없애버리면 편지는 반송됩니다.
값은 안 들어요. 어차피 빈 프로젝트라 파일이 몇 개 없고, 요금제도 무료 그대로입니다. 정리하고 싶은 마음만 참으면 됩니다.
이사 표시가 덮였을 때 되돌리는 명령도 안내문에 한 줄로 적어뒀어요. 또 덮이는 일이 없게 만들어 놨지만, 되돌리는 법을 안 적어두면 그때 가서 다시 만들게 되니까요.
덤 — 손으로는 되는데 자동으로만 안 되던 것
이사 표시 이야기에 딸려 나온 사고가 하나 더 있었어요. 성격이 아주 비슷합니다.
배포 명령을 제가 직접 치면 잘 됩니다. 그런데 같은 명령을 예약 작업이 대신 돌리면 조용히 실패했어요. 오류 화면도 안 뜨고, 기록에도 딱히 안 남고요.

원인은 노랗게 칠한 두 줄이에요. 예약 작업은 제가 쓰는 터미널이랑 다른 환경에서 명령을 실행합니다. 프로그램을 찾는 경로 목록이 훨씬 짧아요. 그래서 제 터미널에서는 잘 찾아지던 도구들이 예약 작업에서는 "그런 명령 없음"이 됩니다.
지금은 스크립트 안에서 그 경로를 직접 넓혀줘요. 저 한 줄이 그거예요.
이 종류가 제일 무섭습니다. 확인해보려고 손으로 돌려보면 잘 되거든요. "어? 잘 되는데?" 하고 넘어가게 돼요. 안 되는 건 내가 안 보고 있을 때뿐입니다.
옮기고 나서 챙기지 않은 것 세 가지
이사 표시를 제대로 걸어놨다고 끝이 아니었어요. 새 주소 쪽에서 챙길 게 세 가지 더 있었는데, 셋 다 안 챙겨도 아무 오류가 안 납니다. 유입만 조용히 줄어요.
① www 붙은 주소도 같이 보내야 합니다
사람들은 www. 를 붙여 치기도 하고 안 붙이기도 하잖아요. 둘 다 열리는데 서로 다른 주소로 취급되면, 같은 내용이 두 주소에 있는 꼴이 됩니다. 검색엔진은 어느 쪽이 원본인지 헷갈려 하고, 점수도 둘로 갈려요.
이건 40편에서 도메인 붙일 때 한 번 다뤘던 건데, 이번 편 맥락에서 다시 보면 성격이 완전히 같은 일이에요. www 쪽도 결국 "옛 주소를 새 주소로 영구히 보내는" 일이거든요. 지금은 www 로 들어오면 www 없는 쪽으로 301로 넘어갑니다.
② 없는 주소에 404를 안 내주고 있었어요
이게 저는 제일 놀랐어요.
사이트를 올리는 방식이 정적 파일이라, 없는 주소를 요청받았을 때 뭘 내줄지도 제가 정해야 했습니다. 그런데 그 파일을 안 만들어뒀더니, 못 찾은 주소에 뿌리 첫 화면을 200(정상)으로 내주고 있었어요.
무슨 뜻이냐면요. victor-house.com/아무거나12345 를 쳐도 홈페이지가 멀쩡히 떴다는 겁니다. 그것도 "정상입니다"라는 응답을 달고요. 오타 주소도, 내린 글 주소도, 세상에 없는 주소도 전부 홈페이지 복사본으로 살아 있는 상태가 된 거예요.
검색엔진은 그걸 하나하나 읽고 "중복이네" 하고 버립니다. 버리는 건 그렇다 쳐도, 읽는 데 쓴 몫은 새 글에서 빠진 겁니다. 검색엔진이 한 사이트를 도는 데 쓰는 품에는 한도가 있거든요.
그때 색인된 페이지 수가 사이트맵에 적어낸 수보다 훨씬 많았어요. 448 대 312. 지금 보면 그 차이가 어디서 왔는지 짐작이 갑니다.

지금은 없는 주소를 치면 이 화면이 나와요. 그리고 화면만 바뀐 게 아니라 응답도 "없음"으로 나갑니다. 아까 그 확인 명령으로 찍어보면 404가 뜹니다.
한 가지 재밌는 게 있는데요, 안내문에 이 사고를 적어두면서 옆에 이렇게 써뒀어요 — "www 가 200을 내주던 것과 같은 병이다." ①번과 ②번은 겉보기엔 딴 얘긴데, 속은 하나예요. 같은 내용이 여러 주소에서 정상으로 응답하고 있는 것.
③ 검색엔진 소유 확인은 안 따라옵니다
이게 셋 중에 제일 조용했어요.
검색엔진에 "이 사이트 내 겁니다" 하고 등록하려면 소유 확인을 해야 합니다. 페이지 머리에 발급받은 코드를 한 줄 심어두는 방식이에요. 저도 예전 주소로 해뒀었고요.
그 코드는 주소를 따라오지 않습니다. 사이트별로 따로 내주는 값이라, 옛 주소용 코드는 새 주소를 인증하지 못해요.

그래서 같은 실수를 또 안 하려고 주소 설정 바로 옆에 경고를 붙여놨습니다. 노랗게 칠한 부분이요. 여기 적힌 게 실제로 겪은 일이에요 — 도메인을 붙이고 한동안, 네이버 쪽에는 새 주소가 등록조차 안 돼 있었습니다. 심어둔 코드가 옛 주소 시절 값 그대로였거든요.
구글은 등록을 안 해도 어떻게든 찾아와서 긁어가기라도 하는데, 네이버는 달라요. 등록하고 사이트맵을 내밀지 않으면 사실상 안 긁어갑니다. 그러니까 이건 "조금 손해"가 아니라 그쪽 검색에서는 통째로 없는 사이트인 상태였던 거예요.
며칠 뒤에 코드를 새로 발급받아 갈아 끼웠습니다. 이것도 알아챈 계기가 오류가 아니었어요. 유입이 안 늘어서 이상하다 싶어 하나씩 열어보다 나왔습니다.
셋의 공통점이 이거예요. 안 챙겨도 아무 일이 안 일어납니다. 사이트는 뜨고, 배포는 성공하고, 화면은 멀쩡해요. 다음 날부터 조용히 덜 들어올 뿐입니다.
글을 내릴 때도 301입니다 — 어디로 보낼지는 사람이 정합니다
이사 표시는 사이트를 옮길 때만 쓰는 게 아니더라고요. 글 한 편을 내릴 때도 같은 판단이 필요했습니다.
사이트에 올려뒀던 협찬 리뷰들을 내리게 됐어요. 협찬 글은 네이버에 싣는 게 계약 조건이라 원본이 그쪽이거든요. 같은 글이 제 사이트에도 한 벌 더 있는 건 여러모로 안 맞았습니다.
그냥 지우면 그 주소들은 전부 404가 돼요. 그러면 두 가지를 잃습니다.
1. 검색으로 들어오던 사람이 글을 못 읽습니다. 그 사람은 그냥 못 찾고 나가요. 2. 검색엔진에게는 "글이 사라졌다"고만 말하게 됩니다. 원본이 어디 있는지는 안 알려주고요.

그래서 지우는 대신 원본이 있는 곳으로 301을 걸었습니다. 사람은 글을 읽고, 검색엔진은 "원본은 저기구나" 하고 알아들어요. 덤으로 같은 글이 두 군데 있던 중복 문제도 그걸로 풀립니다.

실제로 내린 글 주소를 열어보면 이렇게 네이버 원문으로 넘어갑니다. 헛걸음이 아니라 원본으로 도착하는 거죠.
목록은 파일 하나에만 적어둡니다. 지금 53편이 들어 있고, 앞으로 내리는 글도 거기에만 한 줄 더하면 돼요. 여기 붙은 잔손질이 두 개 있는데 둘 다 실제로 필요했습니다.
하나, 주소를 두 벌로 적습니다. 제 글 주소에는 한글이 들어 있어요. 브라우저는 한글을 알아볼 수 없는 부호 덩어리로 바꿔서 보냅니다. 그런데 그걸 받는 쪽이 도로 한글로 풀어서 규칙을 맞추는지, 부호인 채로 맞추는지가 문서에 분명하지 않더라고요. 그래서 두 가지 모양을 다 적어뒀습니다. 어느 쪽이든 하나는 걸리게요.
둘, 아직 안 내려간 글을 짚어줍니다. 목록에는 올려놨는데 사이트에 그 글이 아직 남아 있으면 이사 표시가 안 걸려요. 진짜 파일이 있으면 그게 먼저 나가거든요. 그러면 "넘긴 셈 치고" 넘어가게 되는데, 실제로는 안 넘어간 상태입니다. 그래서 배포할 때 그런 글이 몇 개인지 세서 경고를 찍게 했어요.
그리고 순서도 못 박아뒀습니다. "여기 이런 주소들이 있어요" 목록(사이트맵)을 만든 다음에 이사 표시를 겁니다. 순서가 반대면 사이트맵에는 있는데 열어보면 딴 데로 튕기는, 앞뒤가 안 맞는 상태가 돼요.
여기서 사람이 한 건 어디로 보낼지 정한 거예요. 코드가 할 수 있는 건 "지울까요, 넘길까요"까지고, 어디로 넘길지는 협찬 글의 원본이 왜 네이버여야 하는지 아는 쪽이 정해야 합니다. 계약 조건은 코드 어디에도 안 적혀 있어요.
조용한 사고는 확인 명령으로 잡습니다
이번 편에 나온 사고들이 전부 같은 성질이에요. 오류가 안 납니다. 그래서 "잘 됐나?"를 눈으로 볼 방법을 따로 만들어 두는 수밖에 없었어요.
배포 안내문에 확인 명령을 아예 박아뒀습니다. 그중 제일 중요한 게 옛 주소가 아직 301인지 보는 거예요.

한 줄짜리 명령으로 응답 번호와 넘어가는 주소를 같이 찍습니다. 이게 이번 편 전체의 요약이기도 해요. 여섯 개 옛 주소가 각자 제 자리로, www 도 제 자리로, 안쪽 주소는 뒤에 붙은 것까지 그대로, 없는 주소는 404로.
이 표에서 하나라도 302가 뜨거나 200이 뜨면 그날 뭔가 덮인 겁니다. 화면으로는 절대 안 보이는 걸 숫자 하나가 말해줘요.
여기 함정이 하나 더 있는데, 배포 직후 몇십 초는 옛 내용이 그대로 보일 수 있어요. 중간에 임시로 저장해둔 게 남아 있어서요. 그것 때문에 "안 됐네" 하고 헛수고를 한 적이 있어서, 주소 뒤에 아무 값이나 하나 붙여서 새로 받아오는 요령도 같이 적어뒀습니다.
이걸 실제 화면으로 확인해본 것도 있어요. 옛 주소 여섯 개를 브라우저로 하나씩 열어봤습니다.

옛 카드 혜택 주소로 들어갔더니 새 도메인의 카드 화면이 떴어요. 카드사별 장수가 그대로 뜨고, 필터도 그대로 돕니다.

옛 계산기 주소도 마찬가지고요. 통상임금을 넣으면 월별 수령액과 누적 그래프가 그대로 나옵니다.

지분·지배구조도,

성경 아틀라스도,

기술사 스터디도 전부 제 자리로 옵니다. 여섯 번 다 열어봤어요. 명령으로 한 번 확인했는데 왜 또 여는지 싶겠지만, 명령은 "넘어간다"까지만 알려주지 "넘어간 화면이 멀쩡한지"는 안 알려주거든요.
사람은 어디에 남았나
이번 편에서 AI가 잘한 쪽부터요. 왜 301이어야 하는지, /* 와 뒤에 붙는 부분을 어떻게 이어붙이는지, 리디렉트를 안 따르는 쪽을 위해 안내 한 장을 같이 두는 것 — 이건 저 혼자였으면 못 챙겼습니다. 애초에 301과 302가 다르다는 것도 몰랐어요. 스크립트 맨 위에 이유까지 주석으로 적혀 있는 게 지금 봐도 고마워요.
사람이 붙잡은 건 네 군데였습니다.
하나, 다른 자동화가 그걸 지우고 있다는 것. 이사 표시를 거는 코드는 완벽했어요. 문제는 그 코드가 아니라 다른 파일에 있는 다른 작업이었습니다. 한 파일만 보면 절대 안 보여요. "이거 걸어놨는데 왜 안 붙지"가 아니라 예약 작업 목록을 열어보다 우연히 걸린 거고요. AI는 자기가 만든 것이 잘 도는지는 확인하는데, 옆에서 도는 남의 것이 그걸 밟고 있는지는 안 봅니다.
둘, 조건을 붙이는 대신 도구를 없앤 것. 옛 주소에 올릴 수 있는 스크립트를 남겨두고 조심하는 쪽이 기술적으로는 유연해요. 그런데 그 유연함은 사고 한 번이면 몇 달치를 날립니다. 지우는 쪽을 골랐어요.
셋, 지우고 싶은 걸 참은 것. 빈 프로젝트 여섯 개가 계정에 그대로 남아 있는 게 지저분해 보였습니다. 정리하고 싶었어요. 근데 그걸 지우는 순간 쌓인 게 다 사라집니다. "안 하는 게 맞다"는 판단이 필요한 자리였어요.
넷, 오류가 안 나는 걸 의심한 것. 인증 코드는 아무도 안 알려줬어요. 오류가 없었으니까요. 유입이 안 늘어서 하나씩 열어보다가 나왔습니다.
연재를 쓰면서 계속 같은 자리로 돌아오는데요. AI는 "시킨 게 됐는지"는 잘 봅니다. 못 보는 건 "안 시켰는데 같이 어긋난 것"이에요. 이사 표시는 걸렸고, 배포는 성공했고, 화면은 멀쩡합니다. 그 표시가 내일 아침 지워질 거라는 건 아무 데도 안 찍혀요.
그래서 저는 배포가 끝나면 그 확인 명령을 한 번 돌립니다. 화면도 열어보고요. "성공했습니다"는 증거가 아니고, 응답 번호와 화면이 증거입니다.
다음 편
이사 표시까지 걸고 나니까 순서에 대해 생각하게 됐어요.
저는 사이트 여섯 개를 먼저 한 도메인 아래로 합치고, 그다음에 도메인을 샀습니다. 사실 순서가 반대일 뻔했어요. 도메인부터 사고 싶었거든요.
만약 그랬으면 이사를 두 번 해야 했습니다. 도구 여섯 개를 새 도메인으로 한 번 옮기고, 경로 구조를 바꾸면서 또 한 번요. 옮길 때마다 조금씩 새고, 그때마다 인증이랑 사이트맵을 다시 맞춰야 합니다. 오늘 편에서 한 뒤처리를 두 번 하는 거예요.
다음 편은 그 순서 이야기입니다. 그리고 아직 안 끝난 것도 같이 적을게요 — 이사 표시를 걸었다고 검색 결과가 바로 바뀌지는 않더라고요.
#301리디렉트 #302리디렉트 #리디렉트 #검색평가이전 #도메인이전 #사이트이사 #SEO기초 #검색엔진최적화 #canonical #404페이지 #서치콘솔 #네이버서치어드바이저 #사이트맵 #robotstxt #CloudflarePages #정적사이트 #무료호스팅 #개인홈페이지 #홈페이지만들기 #victorhouse #배포자동화 #크론 #자동화사고 #육아휴직계산기 #카드혜택 #지분지배구조 #성경아틀라스 #기술사스터디 #AI코딩 #휴먼인더루프