CI가 갑자기 전부 빨간불이 뜨면, 대부분 코드나 설정을 먼저 의심하잖아요. 그런데 이번에는 코드도, YAML도, runner도 아니었어요. 오늘은 개발 문제가 아니라 운영 문제에 가까운 삽질을 했거든요. 시작은 단순했어요. 우리 조직의 여러 private repo에서 GitHub Actions CI가 전부 실패하고 있었어요. 처음에는 self-hosted runner 문제라고 생각했죠. 최근에 로컬 Mac mini를 GitHub Actions runner로 붙였고, 여러 repo의 CI를 self-hosted runner로 돌리도록 바꿨거든요. 그런데 증상이 이상했어요. 보통 runner에 문제가 있으면 job이 만들어진 뒤에 queued 상태로 멈추거나, "matching runner가 없다"는 식으로 실패해요. 그런데 이번에는 job 자체가 없었어요. 대표 run 상태는 이랬어요. conclusion: startup_failure workflowName: "" path: BuildFailed jobs: [] logs: 404 로그도 없었어요. 정확히는 로그가 생기기 전에 죽은 거였죠. 처음 의심한 것: self-hosted runner 설정 가장 먼저 의심한 건 로컬 runner였어요. 실제로 과거 설정에는 문제가 있었거든요. runner가 기본 _work 폴더를 쓰고 있었고, 외장 SSD에 작업 디렉터리를 두려면 --work 옵션을 줘야 했어요. 현재는 아래처럼 고쳐져 있었어요. workFolder: /mnt/ssd/actions-work/my-org runner도 online 상태였고요. runner: local-mac-mini status: online busy: false labels: - self-hosted - macOS - ARM64 - local - mac-mini 그런데도 문제가 계속됐어요. 그래서 self-hosted runner를 아예 쓰지 않는, 아주 단순한 smoke workflow도 만들어봤어요. name: Actions Smoke Test on: push: branches: - test/actions-smoke workflow_dispatch: jobs: smoke: runs-on: ubuntu-latest steps: - name: Print smoke marker run: echo "actions-smoke-ok" 그런데 이것도 똑같이 실패했어요. conclusion: startup_failure workflowName: "" path: BuildFailed jobs: [] 이 시점에서 runner만의 문제는 아니라고 봐야 했어요. ubuntu-latest도 runner에 도달하기 전에 죽었으니까요. 두 번째 의심: Enterprise / Organization runner group 꼬임 그다음에는 GitHub Enterprise 설정을 의심했어요. 최근 Enterprise 사용이 끝났는데, Organization 쪽 Actions runner group 화면에 이런 경고가 떠 있었거든요. Runner group Default already exists at the Enterprise level. Please consider renaming this group. 이건 충분히 수상했어요. organization에는 runner group Default가 있고, Enterprise level에도 Default가 남아 있는 것처럼 보였어요. 게다가 API로 보면 Default runner group이 두 개처럼 보였고요. id 1: Default, visibility=all id 3: Default, visibility=selected 그래서 한동안은 "Enterprise가 끝났는데 runner group policy가 남아서 org Actions가 꼬인 것 아닌가?"라고 생각했어요. 이 가설도 나쁘진 않았어요. 실제로 Enterprise 종료 후 잔여 설정은 정리하는 게 맞고, runner group 이름도 Default보다는 local-mac-mini 같은 구분되는 이름으로 바꾸는 게 좋거든요. 하지만 이것도 결정적 원인은 아니었어요. 왜냐하면 private repo뿐 아니라, GitHub-hosted runner를 쓰는 smoke workflow까지 BuildFailed로 죽었기 때문이에요. runner group이 원인이라면 적어도 ubuntu-latest workflow는 다르게 실패해야 했거든요. GitHub Support 답변: billing lock 결국 GitHub Support에 문의했어요. 답변은 의외로 간단했어요. The BuildFailed behavior occurs when an account's billing is locked, blocking access to billable features, like Actions. 즉 원인은 코드도, YAML도, runner도 아니었어요. billing lock 때문에 Actions 자체가 막힌 상태였던 거죠. 이 설명이면 모든 증상이 맞아떨어져요. 여러 private repo에서 동시에 실패 self-hosted runner도 실패 ubuntu-latest도 실패 job이 생성되지 않음 logs endpoint가 404 workflow name이 비어 있음 BuildFailed라는 synthetic workflow가 생김 GitHub Actions는 private repo에서 billable feature(과금 대상 기능)로 취급돼요. billing account가 locked 상태면 runner 종류와 상관없이 workflow startup 단계에서 막힐 수 있는 거예요. 문제가 된 건 organization 계정이었어요 추가로 Support에 확인한 결과, 문제가 된 billing account는 개인 계정이 아니라 organization 계정이었어요. 이걸로 범위가 확정됐어요. 처음에는 개인 계정 문제일 수도, 종료된 Enterprise 문제일 수도, organization 문제일 수도 있었어요. 그런데 최종적으로는 organization의 billing lock이었죠. Support는 billing team으로 새 티켓을 열어달라고 안내해줬어요. 이번에 배운 것 이번 삽질에서 얻은 교훈은 꽤 명확해요. 1. BuildFailed + startup_failure + jobs=[]는 runner 문제가 아닐 수 있어요 runner 문제라면 보통 job은 생겨요. 예를 들면 이런 형태가 되죠. queued waiting for runner no matching runner 그런데 이번처럼: workflowName: "" path: BuildFailed jobs: [] logs: 404 이렇게 나온다면 workflow가 runner에 도달하기 전에 죽은 거예요. 이 경우 YAML, runner label, runner online 여부만 붙잡고 있으면 시간을 많이 낭비할 수 있어요. 2. private repo Actions는 billing 상태의 영향을 받아요 self-hosted runner를 써도 Actions 자체는 GitHub의 billable feature 영역에 걸려요. 그래서 "내 runner에서 도는데 왜 billing이 문제지?"라고 생각하면 안 돼요. Actions orchestration(작업을 큐에 넣고 runner에 배정하는 과정) 자체가 GitHub feature이기 때문이에요. 3. Enterprise 종료 후에는 billing/account scope를 꼭 확인해야 해요 Enterprise를 종료했다고 해서 모든 잔여 상태가 깔끔히 사라지는 건 아닌 것 같아요. 적어도 이번에는 이 전부가 얽혀 있었거든요. Enterprise 종료 Organization billing Actions runner group private repo Actions Support ticket routing Enterprise가 끝났다면 다음을 확인해보세요. Personal billing Organization billing Enterprise billing Actions access Runner groups Outstanding balance Seats Billing cycle 특히 결제정보를 추가하기 전에 "얼마가 즉시 청구되는지" 확인하는 게 중요해요. 최종 정리 이번 문제의 root cause는 이렇게 정리할 수 있어요. organization billing lock → GitHub Actions billable feature blocked → all private repo workflows fail at startup → synthetic BuildFailed workflow → jobs=[] → logs=404 다음 액션은 runner를 다시 설치하는 게 아니라 billing team에 확인하는 거예요. 확인해야 할 핵심은 이 정도예요. 미납 잔액(outstanding balance)이 있는지, 있다면 정확한 금액은 얼마인지 결제정보를 추가하면 즉시 얼마가 청구되는지 (월결제 전환이 가능한지 포함) 종료된 Enterprise billing scope와 아직 연결돼 있는지 오늘의 결론은 이거예요. CI가 터졌다고 항상 코드나 runner 문제는 아니에요. 가끔은 결제 상태가 가장 낮은 레벨의 인프라 장애처럼 나타나거든요. 증상이 아무리 봐도 인프라 같은데 아무것도 안 잡힌다면, billing 상태도 한 번 열어보세요. When you have eliminated the impossible, whatever remains, however improbable, must be the truth.— Arthur Conan Doyle

사업자 등록을 준비하다 보면 인터넷이나 주변에서 들은 이야기들이 머릿속에 쌓이죠. "등록일을 과거로 잡을 수 있다더라", "이 지원사업은 자격 요건이 까다롭다더라" 같은 말들이요. 그런데 이런 행정·세무 정보는 시점에 따라 기준이 자주 바뀌고, 들은 이야기가 틀린 경우도 많아요. 그래서 신청 버튼을 누르기 전에, 어떤 정보를 어디서 확인해야 하는지 정리해두는 게 중요해요. 오늘은 제가 직접 메모해뒀던 몇 가지 궁금증과, 그걸 어떻게 검증하면 되는지를 같이 적어볼게요. 아래 내용은 확인이 필요한 메모를 정리한 것이에요. 제도와 행정 기준은 수시로 바뀌니, 실제 신청 전에는 반드시 최신 공고와 공식 기관 안내, 전문가 확인을 거쳐야 해요. 사업자 등록일을 과거로 잡을 수 있을까 가장 먼저 떠오른 궁금증은 사업자 등록일을 과거 날짜로 신고할 수 있는가였어요. 사업을 실제로 시작한 시점과 등록을 신청하는 시점이 다를 때, 등록일을 소급해서 잡을 수 있는지에 대한 이야기죠. 들리는 말로는 일정 기간(예를 들어 며칠 정도) 안에서는 과거 날짜 신고가 가능하다고 하는데, 정확히 며칠까지 인정되는지는 불명확해요. "20일"이라는 이야기도 있었지만, 이건 확인되지 않은 정보예요. 이런 부분은 추측으로 넘기면 안 돼요. 등록일은 부가세 신고 시점이나 각종 자격 기준일에 영향을 줄 수 있어서, 잘못 잡으면 나중에 골치 아파지거든요. 그래서 홈택스나 세무서 공식 안내로 소급 인정 범위를 직접 확인하는 게 맞아요. 지원사업 자격 요건은 '지금 기준'으로 다시 보기 두 번째로 메모해둔 건 1인 창조기업 같은 지원 제도의 자격 요건이었어요. 예를 들어 "정회원으로 신청하려면 일정 기간 이상 고용한 직원이 없어야 한다"는 식의 조건을 들었거든요. 문제는 이런 요건이 공고 시점마다, 기관마다 다르게 적용될 수 있다는 점이에요. 작년에 맞았던 조건이 올해는 바뀌어 있을 수도 있고요. 그래서 "예전에 들었던 기준"으로 판단하면 위험해요. 자격 요건은 반드시 해당 사업의 최신 공고문을 기준으로 다시 확인하는 게 좋아요. 애매하면 운영 기관에 직접 문의하는 게 가장 빠르고 정확해요. '소급 신고로 대기 기간을 줄인다'는 아이디어 세 번째는 조금 더 전략적인 메모였어요. 등록일을 과거로 잡으면, 어떤 제도에서 요구하는 대기 기간이나 경과 기간을 앞당길 수 있지 않을까 하는 아이디어였죠. 이건 말 그대로 아이디어 단계예요. 실제로 통하는지, 그리고 그렇게 했을 때 어떤 증빙이 필요하고 어떤 리스크가 따르는지는 전혀 검증되지 않았어요. 행정 처리에서 날짜를 임의로 조정하는 건 생각보다 제약이 많고, 잘못하면 오히려 문제가 될 수 있어요. 이런 발상은 메모로 남겨두되, 실행하기 전에 세무사나 행정사 같은 전문가의 검토를 꼭 받는 게 안전해요. 확인 체크리스트로 정리하기 들은 이야기를 그대로 믿는 대신, 확인해야 할 항목을 체크리스트로 만들어두면 마음이 한결 편해져요. 제가 정리한 건 이래요. 사업자 등록일 소급 인정 범위 — 공식 기준으로 며칠까지 가능한지 지원사업 자격 요건 — 가입하려는 제도의 최신 요건 소급 신고의 증빙과 리스크 — 필요한 서류와 따라오는 위험 공식 Q&x26;A 확인 — 홈택스 및 관련 기관의 공식 안내 각 항목 앞에 "누구에게, 어디서 확인할지"까지 적어두면 실제로 처리할 때 헤매지 않아요. 마무리하며 사업 초기에는 정보가 넘쳐서 오히려 헷갈리기 쉬워요. 이럴 때일수록 들은 이야기와 확인된 사실을 구분하는 습관이 큰 차이를 만들어요. 메모에 적어둔 궁금증은 그 자체로 가치가 있어요. 다만 그걸 행동으로 옮기기 전에, 공식 기관 한 곳에 확인 전화 한 통 넣는 것만으로도 큰 실수를 막을 수 있거든요. 확신이 서지 않는 건 일단 검증부터 하고 넘어가는 게, 결국 가장 빠른 길이에요. Good people are good because they've come to wisdom through failure. We get very little wisdom from success, you know.— William Saroyan

새 회사에 합류하기로 했을 때, 막상 첫 출근까지 뭘 준비해야 할지 막막할 때가 많죠. 익숙하지 않은 언어를 쓰거나, 도메인이 낯설거나, 팀 문화를 모를 때는 더 그래요. 합류가 정해진 시점부터 첫 한 달까지, 개발자가 미리 챙겨두면 적응이 훨씬 수월해지는 것들을 정리해봤어요. 먼저 내 포지션을 한 문장으로 정의해요 입사가 정해지면 가장 먼저 할 일은 "이 팀에서 내가 어떤 역할을 맡는가"를 스스로 정리하는 거예요. 직무 기술서에 적힌 직함 말고, 실제로 어떤 가치를 만들어낼지를 한 문장으로 정의해보세요. 예를 들어 백엔드와 프론트엔드 사이를 잇는 풀스택 브릿지 포지션이라면, 구체적인 업무는 이렇게 쪼개볼 수 있어요. 역할 구체적 업무 API 계약 정의 OpenAPI/Swagger 스펙 작성, Request/Response DTO 설계 인터페이스 조율 프론트가 필요한 데이터 구조와 백엔드 도메인 모델 간 변환 통합 테스트 API 동작 검증, E2E 시나리오 작성 도메인 분석 비즈니스 로직 설계, 이해관계자 요구사항 정리 이렇게 역할을 미리 쪼개두면, 입사 후 어떤 일에 시간을 써야 할지 헷갈리지 않아요. 면접 때 들은 기대치와 내가 정의한 역할이 어긋난다면, 그것부터 확인하는 게 좋고요. 새 언어·스택은 "읽을 수 있는 수준"부터 회사가 쓰는 언어나 프레임워크가 낯설다고 너무 겁먹을 필요는 없어요. 입사 초반에 필요한 건 밑바닥부터 다 만드는 능력이 아니라, 코드 리뷰를 따라갈 수 있는 읽기 능력이거든요. 목표를 이렇게 두 단계로 잡아보세요. 읽기 가능한 수준 — 팀의 코드 리뷰에 의견을 보탤 수 있을 정도 고치기 가능한 수준 — 간단한 버그 픽스나 필드 추가를 직접 할 수 있을 정도 예를 들어 Java를 쓰다가 Kotlin 기반 팀에 합류한다면, 핵심 문법 차이부터 빠르게 훑는 게 효율적이에요. // 1. Data Class — 불변 모델을 간결하게 data class Reserve( val id: Long, val doctorId: Long, val startTime: LocalDateTime ) // 2. Null Safety val name: String? = null name?.length ?: 0 // Elvis 연산자: null이면 0 name!!.length // Non-null 단언 (위험하니 지양) // 3. 확장 함수 fun String.toSlug() = this.lowercase().replace(" ", "-") // 4. 스코프 함수 reserve.let { println(it.id) } reserve.apply { status = "CONFIRMED" } reserve.also { log.info("Created: $it") } // 5. When (switch 대체) when (status) { "PENDING" -> handlePending() "CONFIRMED" -> handleConfirmed() else -> handleDefault() } 학습 순서를 시간 단위로 쪼개요 막연히 "공부해야지"보다, 시간과 공식 리소스를 함께 적어두면 실제로 끝까지 가게 돼요. 순서 내용 시간 리소스 1 언어 기본 문법 2시간 Kotlin Basic Syntax 2 기존 언어와 비교 1시간 From Java to Kotlin 3 프레임워크 튜토리얼 4시간 Spring Boot + Kotlin 4 비동기·동시성 기초 2시간 Coroutines basics 여기서 한 걸음 더 나아가, 회사 스택에서 자주 쓰는 표준 패턴 한두 개를 미리 따라 써보는 것도 좋아요. 레이어 구조가 손에 익으면 실제 코드베이스를 처음 열었을 때 훨씬 덜 낯설거든요. // Controller — 요청을 받아 서비스로 위임 @RestController @RequestMapping("/api/reserves") class ReserveController( private val reserveService: ReserveService ) { @GetMapping("/{id}") fun getReserve(@PathVariable id: Long): ResponseEntity&x3C;ReserveDto> = reserveService.findById(id) ?.let { ResponseEntity.ok(it.toDto()) } ?: ResponseEntity.notFound().build() } // Service — 비즈니스 로직과 트랜잭션 경계 @Service @Transactional(readOnly = true) class ReserveService( private val reserveRepository: ReserveRepository ) { fun findById(id: Long): Reserve? = reserveRepository.findByIdOrNull(id) @Transactional fun create(request: CreateReserveRequest): Reserve { // 검증 로직 return reserveRepository.save(request.toEntity()) } } 첫 한 달의 온보딩 로드맵을 그려요 입사 후 무엇을 할지 미리 단계로 나눠두면, 첫날부터 헤매지 않아요. 주차별 체크리스트로 만들어두는 걸 추천해요. 1주차: 환경 세팅과 코드 파악 로컬 개발 환경 구축 (IDE, DB, Docker 등) 프로젝트 구조 파악 (패키지 구성, 레이어 구조) 도메인 용어 정리 문서화 기존 API 엔드포인트 목록 파악 DB 스키마 분석 2주차: 첫 기여 작은 버그 수정 또는 API 응답 필드 추가 코드 리뷰 참여 시작 팀 컨벤션 파악 (코드 스타일, 커밋 메시지, PR 규칙) 한 달 후 목표 독립적으로 작은 기능 추가 가능 도메인 로직 설계에 참여 다른 팀과 인터페이스(API 스펙 등) 협의 주도 첫 기여는 작을수록 좋아요. 거창한 기능보다 필드 하나 추가하는 PR을 먼저 올려보면, 팀의 리뷰 문화와 배포 흐름을 자연스럽게 익히게 되거든요. 가진 강점을 빨리 증명해요 새 환경에서는 위축되기 쉽지만, 입사 전부터 쌓아둔 강점이 분명히 있을 거예요. 그걸 초반에 자연스럽게 드러내면 신뢰를 빠르게 얻을 수 있어요. 특히 도메인을 미리 분석해 둔 내용은 강력한 무기예요. 면접이나 사전 조사 과정에서 파악한 기존 시스템의 한계, 개선 아이디어 같은 걸 정리해두면, 합류 직후 자연스럽게 공유할 수 있어요. "기존 시스템을 살펴봤는데, 이 검증 쿼리가 3단 조인이라 복잡하더라고요. 테이블을 직접 연결하면 단순화될 것 같아요." 이렇게 구체적인 관찰을 들고 들어가면, 단순히 시키는 일을 받는 사람이 아니라 함께 문제를 푸는 동료로 자리잡기 쉬워요. 다만 입사 첫날부터 모든 걸 바꾸려 들기보다, 먼저 맥락을 충분히 듣고 제안하는 순서가 좋아요. 입사 전 미리 확인해두면 좋은 것들 계약서에 사인하기 전이나 첫 출근 전에, 다음 항목들을 확인해두면 입사 후 당황할 일이 줄어요. 코드 리뷰 문화가 있는지 온보딩 기간에 기대하는 것 프론트엔드 버전과 상태관리 방식 (Redux? Zustand? React Query?) 테스트 커버리지 기준이 있는지 원격 근무 가능 여부 커뮤니케이션 도구 (Slack, Teams 등) 이런 질문은 면접 막바지나 처우 협의 단계에서 물어보기 딱 좋아요. 회사가 일하는 방식을 미리 알수록, 첫날의 적응 비용이 줄어들거든요. 마무리 입사 준비의 핵심은 "첫 출근 전에 적응 비용을 최대한 미리 치러두는 것"이에요. 내 역할을 한 문장으로 정의하고, 새 스택을 읽을 수 있는 수준까지 끌어올리고, 온보딩 로드맵과 강점 카드를 손에 쥐고 들어가면, 첫 한 달이 훨씬 가벼워져요. 완벽하게 준비하려고 미루기보다, 지금 할 수 있는 작은 준비부터 하나씩 체크해보세요. A man who doesn't trust himself can never really trust anyone else.— Cardinal Retz