[D-1] 코드잇 스프린트 환영회

edit_note 오늘 코테 문제

문제	유연근무제
플랫폼	프로그래머스
핵심 요구사항	startday 기준 요일 매핑 + 시각 인코딩(시*100+분) 연산 처리

python

def solution(schedules, timelogs, startday):
    answer = 0

    weekday_flags = []
    for col in range(7):
        day_of_week = (startday - 1 + col) % 7 + 1
        weekday_flags.append(day_of_week not in (6, 7))

    for i, log in enumerate(timelogs):
        h, m = divmod(schedules[i], 100)
        limit_minutes = h * 60 + m + 10
        limit = (limit_minutes // 60) * 100 + (limit_minutes % 60)

        time_flag = True
        for j, time in enumerate(log):
            if weekday_flags[j] and time > limit:
                time_flag = False
                break

        if time_flag:
            answer += 1

    return answer

풀이 접근법

핵심은 timelogs의 컬럼 인덱스가 실제 요일과 그대로 매칭되지 않는다는 점이다. startday를 기준으로 각 컬럼이 무슨 요일인지 먼저 계산해서 주말 컬럼을 걸러내고, 시각 비교는 "시*100+분" 인코딩을 분 단위로 풀어서 처리해야 한다.

1

컬럼별 요일 미리 계산해두기

timelogs의 각 컬럼(0~6)이 무슨 요일인지는 startday에 따라 매번 달라지므로, 비교에 들어가기 전에 "이 컬럼이 평일인지"를 담은 flag 배열을 만든다.

python

weekday_flags = []
for col in range(7):
    day_of_week = (startday - 1 + col) % 7 + 1
    weekday_flags.append(day_of_week not in (6, 7))

2

직원별 출근 인정 시각(limit) 계산

시각이 "시*100+분"으로 인코딩되어 있어서 그냥 +10을 하면 분이 60을 넘을 때 깨진다. divmod로 시/분을 분리하고, 분 단위로 통일해서 더한 뒤 다시 인코딩 형태로 복원한다.

python

h, m = divmod(schedules[i], 100)
limit_minutes = h * 60 + m + 10
limit = (limit_minutes // 60) * 100 + (limit_minutes % 60)

3

평일 컬럼만 골라서 지각 여부 체크

weekday_flags가 False인 컬럼(주말)은 건너뛰고, 평일 컬럼에서만 지각 여부를 체크해 한 번이라도 지각하면 그 직원은 탈락시킨다.

python

for j, time in enumerate(log):
    if weekday_flags[j] and time > limit:
        time_flag = False
        break

헷갈렸던 포인트

✓인덱스 하나로 두 가지 의미(직원 번호 vs 요일 컬럼 번호)를 헷갈리지 않는 것 — schedules[i]와 weekday_flags[j]를 명확히 구분해야 함

✓인코딩된 시각에 그냥 산술 연산을 하면 안 되고, 분 단위로 풀어서 계산해야 함 (958+10 ≠ 968, 실제로는 1008)

한 줄 회고

변수 인덱스가 여러 개일 땐 각각 무슨 의미인지 이름부터 명확히 짓는 게 버그를 줄이는 지름길이었다

groups 코드잇 스프린트 환영회

이벤트	AI 엔지니어 스프린트 14기 환영회 (OT)
구성	멘토님 모티베이션 특강 → QA → 특강/스프린트 퀴즈 → FigJam 아이스브레이킹
결과	🏅 퀴즈 5등 · 메가커피 당첨

AI 엔지니어링이란?

멘토님이 특강 서두에서 던진 정의가 가장 인상 깊었다. "단순히 모델을 만드는 것을 넘어, 현실의 문제를 해결하는 '시스템'을 구축하는 과정"이라는 말. 그동안 나는 AI 엔지니어링을 "좋은 모델을 학습시키는 일" 정도로만 좁게 생각했는데, 실제로는 모델 하나가 아니라 연구 → 인프라 → 제품화로 이어지는 전체 파이프라인을 다루는 일이라는 걸 알게 됐다. 이걸 3개의 축으로 나눠서 설명해주셨다.

01. Model Development — "데이터 속에 숨겨진 지능의 패턴을 찾아냅니다."

Research & Experiment: 가장 높은 성능을 내는 알고리즘을 탐구하고, 데이터의 질을 높여 모델의 한계를 돌파하는 영역

• 최신 논문 트렌드 분석 및 구현
• 피처 엔지니어링 및 데이터 정제
• 모델 아키텍처 설계 및 학습

02. System Engineering — "모델이 거대한 데이터를 버틸 수 있게 만듭니다."

Infrastructure & MLOps: 안정적인 인프라를 구축하고, 대규모 트래픽에서도 모델이 즉각 응답하도록 최적화하는 영역

• GPU/CPU 리소스 관리 및 분산 학습
• CI/CD 파이프라인 및 자동 배포
• 모델 서빙 성능 최적화 (Latency)

03. Product Engineering — "모델을 유저의 손에 닿는 실질적인 가치로 바꿉니다."

User Value & Integration: 사용자 경험(UX)과 모델을 결합해, 유저가 AI를 통해 실제 문제를 해결하게 만드는 영역

• AI 피처 연동 및 인터페이스 설계
• 프롬프트 엔지니어링 및 워크플로우
• 유저 피드백 기반 모델 고도화 전략

이 3개가 왜 하나로 묶이는가

✓[강의] Model Development + System Engineering — Theory & Fundamentals. 강의를 통해 탄탄한 기초와 원리를 확립하는 영역

✓[프로젝트] Product Engineering — Practical Value. 실전 프로젝트로 실제 유저가 사용하는 가치 있는 기능을 직접 완성하는 영역

✓"강의로 쌓는 기초 + 프로젝트로 증명하는 실력" — 이 두 축이 붙어야 비로소 완결된 AI 엔지니어링이 된다는 게 스프린트 커리큘럼의 설계 논리였다

인공지능 학습법 — 어떻게 '딸깍'을 내 것으로 만들 것인가

요즘은 AI가 코드를 대신 짜주는 시대라 "딸깍" 한 번이면 결과물이 나온다. 그런데 그 딸깍을 진짜 내 실력으로 만드는 방법이 무엇인지에 대한 이야기였다.

Understanding AI

AI가 어떻게 동작하는지 밑바닥부터 학습하는 경험

• 기술적 블랙박스 해소 (Depth)
• 문제 발생 시 근본적 해결 능력
• 우리 서비스에 맞는 최적의 모델을 제안하는 힘

Building with AI

AI를 도구로 활용해 실제 프로젝트를 완성하는 경험

• 생산성의 극대화 (Speed)
• MVP를 빠르게 세상에 내놓기
• 유저의 피드백을 반영하는 과정

"엔지니어는 만들 줄 알아야 하고, 왜 돌아가는지 설명할 수 있어야 한다"는 문장이 이 두 축을 관통하는 결론이었다. 그리고 이걸 사람과 AI의 역할 분담으로 더 구체화해주셨다 — 창의성은 인간에게, 반복은 AI에게.

Human's Job

• 문제 정의 및 가설 설정
• 문제 해결을 위한 아키텍처 설계
• 데이터 피처 엔지니어링 전략

AI's Job

• 하이퍼 파라미터 튜닝 실험
• 보일러플레이트 코드 작성
• 성능 기록 및 시각화 자동화

그리고 실제로 AI와 함께 공부할 때 쓰면 좋은 3단계 루틴도 알려주셨다. 같은 문제를 3 Step으로 반복하며 내 것으로 만드는 방법이다.

1

AI와 함께 코드 작성

먼저 AI의 도움을 받아 문제를 풀어보며 전체적인 흐름과 접근법을 파악한다.

2

혼자서 코드 작성

AI 없이 밑바닥부터 직접 다시 짜본다. "AI가 정말 필요한 부분"이 어디인지는 이 단계를 거쳐야만 드러난다.

3

다시 AI와 최적화

혼자 짠 코드를 AI와 함께 리팩토링하고 최적화하며 마무리한다.

부트캠프 활용법 — 자원과 기회를 극대화하는 전략

Learning to Learn: 학습 근육 키우기. "지식의 유효기간은 짧지만, 학습의 원리는 영원하다"는 게 핵심 메시지였다.

Primary Source

블로그 요약글보다는 공식 문서(Docs)와 소스 코드를 직접 파는 습관을 들일 것

Critical Thinking

단순히 "돌아간다"를 넘어, "왜 이렇게 설계되었을까?"를 끊임없이 질문할 것

"부트캠프는 지식을 채우는 곳이 아니라, 스스로 지식을 흡수하는 체력을 기르는 곳"이라는 문장이 특히 와닿았다.

삽질을 자산으로: DevLog 기록법. 부트캠프의 수많은 에러와 버그를 단순한 고통으로 끝내지 말고 3단계로 기록하라는 팁이다.

1Capture (Error & Context) — 마주친 에러 메시지나 현상을 가감 없이 박제

2Hypothesis (What I Tried) — 해결을 위해 시도한 가설들과 뚝딱거린 과정을 짧게라도 기록

3Solution (The Answer) — 결국 어떻게 해결했는지 원인과 최종 코드를 요약

"오늘 한 삽질은 내일의 강력한 포트폴리오(트러블슈팅 경험)가 된다"는 말 — 오늘부터 이 습관 그대로 적용해보려 한다.

함께라면 더 멀리 갑니다: 집단 지성. "나 혼자 고민하면 삽질이지만, 함께 고민하면 연구가 된다."

Share Everything

새로운 기술(MCP, 신규 논문 등)을 발견하면 디스코드에 바로 공유하고 함께 토론하기. 공유할수록 지식은 견고해진다.

Ask Openly

버그 때문에 1시간째 막혔다면 옆 동료에게 물어보기. 이 슬라이드 자체도 이전 기수들과의 공유로 탄생했다고 하셨다.

4가지 마인드셋도 하나씩 짚어주셨다.

1압축의 고통 — 대학교 수년의 내용을 몇 달로 압축한 커리큘럼이라 학습량이 많아지는 건 내 잘못이 아니라 시스템의 특징

2완벽보다 완주 — "Done is better than perfect." 모든 코드를 이해하려다 초반에 에너지를 소진하지 말고, 일단 돌아가게 만들고 나중에 리팩토링하며 끝까지 버티는 태도

3질문하는 용기 — 질문은 무지가 아니라 열정의 증거. "내가 모르는 건 옆 사람도 모른다." 30분 넘게 혼자 고민하는 건 공부가 아니라 정체

4불편함을 즐기기 — "뇌가 아픈 느낌이 들 때가 진짜 공부가 되는 순간." 편안한 복습보다 고통스러운 삽질을 사랑하라는 것

질문을 효율적으로 하는 법도 구체적으로 알려주셨는데, 이건 나도 앞으로 계속 써먹을 것 같다. AI든 동료든 질문할 때 [Context] 목표 정의 → [Error] 현상 및 로그 → [Attempt] 시도한 흔적, 이 3가지만 정리해서 물어보면 정체 시간이 1/10로 줄어든다는 것. "맥락 없는 '이거 안 돼요'는 AI도, 최고 성능의 멘토도 해결해줄 수 없다"는 말이 뼈 있었다.

기억에 남는 QA 답변

Q. AI 엔지니어가 되는 데 학력이 중요한가요?

중요하지 않다. 결국 평가받는 건 실제로 만들어낸 결과물과 역량.

Q. 부트캠프를 마친 후에는 뭘 더 해야 하나요?

자기 서비스를 직접 만들어보는 경험이 중요하다. 이때 "왜 만들었는가"라는 목적이 뚜렷해야 한다.

Q. 논문과 오픈소스 중 뭘 더 봐야 하나요?

논문보다는 오픈소스 코드를 직접 읽어보는 쪽이 더 도움이 될 것 같다.

Q. AI 관련 자격증이 필요한가요?

저는 자격증이 아예 없다. 요즘은 자격증으로 평가받지 않는다. 그것보다 오픈소스와 공식 문서를 공부하고, 기회가 되면 깃허브에 기여해보는 게 훨씬 낫다.

FigJam 아이스브레이킹

밸런스 게임을 시작으로, 과정을 선택한 동기, 앞으로 한 달 동안 집중할 것, 스스로 통제할 수 있는 것과 없는 것 등을 기수 동료들과 함께 포스트잇으로 정리하며 마무리했다.

기수 동료들과 함께 채운 FigJam 보드

psychology 오늘 들었던 생각

"AI 엔지니어링은 모델을 만드는 게 아니라 현실의 문제를 해결하는 시스템을 구축하는 것"이라는 정의가 오늘 하루 종일 머릿속에 남았다. iOS 개발을 하면서 나는 늘 유저가 어떻게 하면 더 편리하게 접근할 수 있을지, 사용자 경험을 먼저 생각하며 개발해왔는데, AI 엔지니어링도 결국 똑같은 감각이 필요하다는 걸 깨달았다. 모델 하나 잘 학습시키는 게 끝이 아니라, 그걸 서빙하고 제품에 녹여내고 유저 피드백을 반영하는 전체 사이클을 다뤄야 한다는 것.

특히 3대 역량 중에서는 확실히 Product Engineering 쪽에 눈이 갔다. Model Development나 System Engineering도 물론 중요하지만, 결국 유저 손에 직접 닿는 부분을 설계하고 만드는 일에 더 끌린다. 생각해보면 이건 자연스러운 흐름이었다 — iOS 개발자로 일하면서 늘 "이 화면에서 유저가 뭘 느낄까", "이 플로우가 실제로 쓰기 편할까"를 고민해왔으니까. AI 피처를 연동하고 인터페이스를 설계하고, 유저 피드백을 반영해 모델을 고도화하는 과정이 지금까지 해온 iOS 작업의 연장선처럼 느껴졌다. 프론트엔드/제품 관점에서 AI를 다루는 엔지니어가 되는 방향이 나한테 잘 맞을 수도 있겠다는 생각이 들었다.

마지막으로 오픈소스와 공식 문서를 파고, 기회가 되면 깃허브에 기여해보라는 구체적인 방향 제시가 앞으로의 방향성을 잡는 데 확실히 도움이 됐다.

rate_review 마무리

본격적인 스프린트 시작 전, 마인드셋을 정비하는 하루였다. "완벽보다 완주", "질문하는 용기" — 이 두 가지는 특히 마음에 새기고 싶다. 그리고 오늘부터 DevLog(Capture-Hypothesis-Solution) 형식으로 에러를 기록하는 습관도 시작해볼 예정이다.

checklist 내일 할 일

• 프로그래머스 문제 한 개 풀기
• 오픈소스 프로젝트 탐색 및 공식 문서 읽는 습관 시작하기