소마 생활 (무사히) 완주하기

소마에서 중요한 것은 단순히 결과물을 많이 만드는 일이 아닙니다.

더 중요한 것은 6개월 동안 팀이 무너지지 않게 유지하고, 같은 문제를 보고, 필요한 순간에 방향을 조정하는 것입니다.

개인적인 사례와 회고는 별도 글인 소마 14기 회고: 팀 구성, 피봇팅, 취업 병행에서 배운 점으로 분리했습니다.

먼저 가져가면 좋은 3가지

소마 완주는 개발 실력만으로 되지 않습니다. 루틴, 팀 리듬, 소통 구조가 같이 있어야 합니다.
소통은 친하게 지내는 일이 아니라, 팀이 같은 문제를 보게 만드는 일입니다.
막힘은 오래 품을수록 커집니다. 기록 → 공유 → escalation 순서로 빨리 다뤄야 합니다.

1. 소마 완주의 기준

소마는 짧은 해커톤이 아니라 6개월짜리 장기 프로젝트입니다. 3명이서 하는 프로젝트이지만, 실제로는 멘토, Expert, 사무국, 발표 대상자까지 여러 이해관계자와 계속 맞물려 움직이게 됩니다.

그래서 “개발만 잘하면 된다”는 생각으로는 오래 버티기 어렵습니다. 오히려 아래 3가지를 같이 관리해야 끝까지 갑니다.

내가 무너지지 않게 유지하는 개인 루틴
팀이 흔들리지 않게 만드는 운영 리듬
문제가 커지기 전에 맞는 사람에게 공유하는 소통 구조

그래서 실전에서는:

오늘 할 기능만 보지 말고
이번 주 팀 리듬이 유지되는지,
지금 막힌 문제가 기술 문제인지 방향 문제인지,
누구에게 언제 말해야 하는지를 같이 봐야 합니다.

2. 무너지지 않게 가는 루틴

루틴은 생산성 팁이 아니라, 6개월짜리 프로젝트를 버티기 위한 장치입니다. 처음 의욕으로만 밀어붙이면 중간에 번아웃이 오기 쉽습니다.

1) 쉬는 시간 만들기

주 1회 정도는 의도적으로 쉬는 시간을 만드는 것을 추천합니다. 장기전에서는 하루를 더 밀어붙이는 것보다, 다음 주에도 다시 돌아올 수 있는 리듬이 더 중요합니다.

팀 단위로 쉬는 시간을 맞출 수 있으면 더 좋음
어렵다면 개인 일정에라도 먼저 고정해두는 편이 좋음

2) 운동

운동은 체력 관리 이상으로, 하루 리듬을 잡는 데 도움이 됩니다. 강도가 센 운동이 아니어도 괜찮습니다. 중요한 것은 비슷한 시간에 몸을 움직이면서 생활 리듬을 유지하는 것입니다.

3) 공부

취업이 목표라면 기업 탐색이나 필요한 기술을 낮은 몰입도로 계속 보는 것은 도움이 됩니다. 다만 여기서 중요한 것은 소마 외에 또 다른 장기 프로젝트를 벌이지 않는 것입니다.

원하는 기업과 직무를 계속 탐색하기
필요한 기술을 가볍게 따라가기
취업 방향을 수시로 조정하기

이 정도는 괜찮지만, 별도 사이드 프로젝트를 깊게 병행하는 것은 대부분 부담이 커집니다.

4) 기록

기록은 나중에 발표 자료, 회고, 포트폴리오, 면접 답변의 재료가 됩니다. 일주일만 지나도 왜 그런 결정을 했는지 기억이 흐려집니다.

최소한 아래 정도는 남겨두는 것을 추천합니다.

어떤 문제가 있었는지
왜 그 결정을 했는지
멘토가 어떤 피드백을 줬는지
다음 액션이 무엇인지

그래서 실전에서는:

주 1회 휴식
주간 운동 리듬
결정/멘토 피드백 기록 이 3가지만 먼저 고정해도 훨씬 덜 흔들립니다.

3. 팀 문화는 친목이 아니라 리듬이다

팀 문화는 거창한 슬로건이 아니라, 팀이 같이 움직이는 리듬을 만드는 것입니다.

작은 팀에서는 개발만 같이 하면 된다고 생각하기 쉽습니다. 그런데 실제로는 자주 대화하고, 같이 밥을 먹고, 작은 불편을 빨리 말할 수 있는 분위기가 생각보다 중요하게 작용합니다.

아이디어 회의를 어떤 방식으로 할지
오프라인으로 얼마나 자주 만날지
멘토 피드백을 어떻게 공유할지
결정이 바뀌면 어디에 기록할지

이런 것이 팀 문화입니다.

중요한 것은 “좋은 팀처럼 보이는 것”이 아니라, 우리 팀이 반복 가능한 방식으로 움직이는 것입니다.

그래서 실전에서는:

회의 방식 1개
결정 기록 위치 1개
주간 리듬 1개 를 먼저 정하는 것이 좋습니다.

4. 소통은 같은 문제를 보게 만드는 일

소마에서 소통은 친하게 지내는 것이 아니라, 팀이 같은 문제를 보게 만드는 일입니다.

같은 회의에 있었고, 같은 문서를 봤고, 같은 단어를 썼다고 해서 같은 문제를 보고 있는 것은 아닙니다. 특히 소마는 기획, 개발, 발표, 멘토링, 행정 일정이 한꺼번에 움직이기 때문에 더 그렇습니다.

그래서 계속 맞춰야 하는 질문은 아래와 같습니다.

우리가 지금 풀고 있는 문제가 무엇인가?
이 문제가 왜 중요한가?
지금 막힌 것은 기술 문제인가, 방향 문제인가, 운영 문제인가?
누구와 같이 해결해야 하는가?
문제가 더 커지기 전에 누구에게 알려야 하는가?

개발자 소통의 핵심 역량

문제 설명: “API가 안 돼요”가 아니라 “응답은 오는데 인증 헤더가 누락됩니다”처럼 말할 수 있어야 합니다.
판단 설명: “AI가 추천했어요”가 아니라 “우리 일정과 데이터 조건에서는 이 선택이 더 현실적입니다”라고 설명할 수 있어야 합니다.
위험 공유: “내일까지 해결되지 않으면 데모 범위를 줄여야 합니다”처럼 리스크를 미리 말할 수 있어야 합니다.
의견 견지: “이 기능은 지금 넣으면 발표 리스크가 커집니다”처럼 자기 판단을 근거와 함께 말할 수 있어야 합니다.
도움 요청: 필요한 사람에게 필요한 도움을 구체적으로 요청할 수 있어야 합니다.

“AI가 그러던데요?”의 위험

예를 들면 이렇게 바꾸는 편이 좋습니다.

나쁜 예: “AI가 이 구조가 좋다던데요.”
더 좋은 예: “AI가 두 가지 안을 줬는데, 우리 일정과 현재 구현 범위를 보면 B안이 더 안전하다고 판단했습니다.”
나쁜 예: “이거 AI가 해준 건데요.”
더 좋은 예: “초안은 AI 도움을 받았지만, 이 선택을 유지한 이유는 사용자 흐름과 데모 안정성 때문입니다.”

그래서 실전에서는:

결과만 가져가지 말고
문제 / 판단 / 리스크를 한 문장씩 붙여서 말하는 습관이 중요합니다.

5. 같은 문제를 보고 있는지 확인하는 질문

작은 팀일수록 “말 안 해도 알겠지”라는 착각이 자주 생깁니다. 그럴수록 아래 질문을 자주 맞춰보는 편이 좋습니다.

연수생끼리

우리는 같은 문제를 보고 있는가?
역할, 일정, 결정, 막힘을 서로 같은 말로 이해하고 있는가?

연수생과 멘토

기술 / 기획 / 일정 리스크를 구체적인 질문으로 가져가고 있는가?
멘토가 판단할 수 있을 정도로 맥락을 정리해서 말하고 있는가?

연수생과 Expert

팀 운영, 갈등, 장기 프로젝트 관리 이슈를 늦기 전에 공유하고 있는가?

연수생과 사무국

일정, 규정, 활동비, 행정 정보를 제때 확인하고 있는가?

6. 소통이 특히 필요한 순간

프로젝트에서는 아래 순간에 소통 문제가 자주 생깁니다.

초기 팀 구성: 역할 분담, 기대치, 투입 시간 정렬
기획: 왜 이 문제를 푸는지, 어디까지 만들지 정렬
설계: 어떤 구조로 갈지, 무엇을 포기할지 결정
개발: 일정 지연, 막힘, 의존성 공유
런칭/데모: 최소 범위, 검증 방식, 일정 관리
발표: 메시지, 시연 흐름, Q&A 준비
회고: 무엇이 잘됐고 무엇을 바꿀지 정리

결정을 해야 할 때는 기준을 미리 적어두면 도움이 됩니다.

시간이 얼마나 남았는지
비용이 얼마나 드는지
구현 난이도가 어떤지
발표나 데모에 꼭 필요한지
지금 하지 않으면 나중에 더 큰 문제가 되는지

이 기준이 있어야 감정 싸움으로 가기 전에 현실적인 대화를 할 수 있습니다.

7. Escalation과 Delegation

소마에서 막힌 일은 혼자 오래 끌어안는 것보다, 맞는 사람에게 빨리 공유하는 것이 중요합니다.

회사식 표현으로 말하면 중요한 소통 방식 두 가지는 Escalation(상향 공유), Delegation(위임) 입니다. 소마에서도 거의 그대로 유효합니다.

언제 누구에게 말할까

프로젝트 방향, 기술 선택, 구현 난이도 문제 → 멘토
소마 생활 전반, 비용, 행정 기준 → 사무국
팀 운영, 갈등, 장기 프로젝트 운영, 개인적인 고민 → Expert 또는 사무국

Escalation 전에 먼저 할 것

무조건 바로 외부에 말하라는 뜻은 아닙니다. 기본적으로는 팀원끼리 먼저 쟁점과 선택지를 정리하는 것이 우선입니다. 다만 그 단계에서 막히거나, 시간이 지날수록 리스크가 커지는 문제는 빨리 올려야 합니다.

예를 들면:

팀 내 의견 충돌 → 쟁점 정리 후 멘토/Expert
개발 진행 지연 → 막힌 원인 정리 후 멘토/Expert
역할 불균형 → 팀 내부 공유 후 멘토/Expert
활동비/행정 이슈 → 규정 확인 후 사무국
방향성 불확실 → 대안 정리 후 멘토/Expert

좋은 Escalation 양식

감정적인 호소보다, 해결 가능한 형태로 정리해서 전달하는 편이 좋습니다.

현재 상황
막힌 지점
이미 해본 것
지금 있는 선택지
도움이 필요한 것

예시:

“현재 A/B 두 방향이 있고, 이번 주 안에 결정해야 합니다. 저희는 B가 더 현실적이라고 보지만 성능 리스크 판단이 부족해서 멘토님 의견을 듣고 싶습니다.”

Delegation에서 중요한 것

위임은 “이거 맡아줘”에서 끝나면 안 됩니다. 좋은 위임은 기대치를 맞추는 일에 가깝습니다.

같이 맞춰야 하는 것은 보통 아래입니다.

무엇을 끝내야 하는지
언제까지 해야 하는지
중간에 무엇을 공유해야 하는지
완료 기준이 무엇인지

그래서 실전에서는:

일을 던지지 말고
완료 기준 / 마감일 / 중간 공유 방식까지 같이 맞추는 편이 좋습니다.

8. 취업 준비 병행은 언제 가능한가

취업 준비 병행은 조건부 추천입니다. 무조건 하지 말라는 뜻은 아니지만, 대부분은 생각보다 에너지 분산이 큽니다.

병행을 고민한다면 아래를 먼저 체크해보는 것이 좋습니다.

병행 체크리스트

프로젝트 MVP 범위가 팀 안에서 합의되어 있는가?
현재 팀 일정이 어느 정도 안정적으로 돌아가고 있는가?
멘토와 팀원이 병행 상황을 알고 있는가?
내 주간 가용 시간이 실제로 확보되는가?
병행이 꼬일 경우 무엇을 먼저 포기할지 정해두었는가?

이 중 여러 항목에 답하기 어렵다면, 병행은 잠시 미루는 편이 안전합니다.

제 기준에서는 프로젝트가 어느 정도 안정화되고, 팀 리듬이 잡힌 뒤에야 제한적으로 고려할 만합니다.

마무리

소마 완주는 결과물만 만드는 일이 아닙니다.

6개월 동안 팀을 유지하는 것
문제를 끝까지 붙잡고 가는 것
필요한 순간에 도움을 요청하는 것
내가 한 판단을 설명할 수 있게 만드는 것
그 과정을 다음 커리어의 자산으로 남기는 것

이 전체가 소마에서 얻는 경험이라고 생각합니다.

완벽하게 하려 하기보다, 무너지지 않고 끝까지 가는 구조를 먼저 만드는 쪽이 더 중요합니다.

부록 A. 추천 책

함께 자라기
- 팀으로 성장하는 방법, 학습하는 방법, 협업하는 방법을 다시 생각하게 해주는 책
- 소마처럼 팀 프로젝트를 오래 끌고 가야 하는 과정과 잘 맞음
BE 2.0
- 주니어 시절부터 리더십과 오너십을 어떻게 볼지 생각하게 해주는 책
- 팀 안에서 자기 몫을 책임지고 싶은 사람에게 추천할 만함
일의 감각
- 본질에 다가가며 불필요한 것을 덜어내는 감각을 기르는 데 도움이 되는 책
- 기획, 발표, 팀 방향성 정리에 도움이 됨
The Nature of Software Development
- Agile을 구호가 아니라 실제 개발 방식으로 이해하게 해주는 책
- 가장 가치 있는 것을 먼저 만들고, 기능을 얇게 나눠 빠르게 검증하는 감각을 익히는 데 좋음