들어가며
신입 개발자 시절, 기획서의 요구사항을 보고 구현하는 것이 개발의 전부라고 생각했습니다.
하지만 경력이 쌓일수록 보이지 않았던 것들이 보이기 시작합니다:
- 회사는 어떻게 일을 만들어내는가?
- 왜 이런 방식으로 일하는가?
- 회사의 의사결정 기준은 무엇인가?
IT 기업의 일하는 방식: 애자일
왜 애자일인가?
신규 사업이거나 방향성이 결정되어 있지 않은 IT 사업의 특성상 애자일 방식이 주로 사용됩니다.
전통적인 폭포수(Waterfall) 방식의 한계:
기획 → 설계 → 개발 → 테스트 → 배포
(6개월 후...)
"시장이 변했습니다"
"고객이 원하는 게 이게 아니었습니다"
애자일의 핵심 원리
애자일 방식은 단기간에 프로토타입을 만들어 고객의 반응을 조사 및 분석을 통해 제품의 방향을 찾습니다.
1주차: 최소 기능 개발 → 출시
2주차: 고객 피드백 수집 → 분석
3주차: 개선 및 새 기능 개발 → 출시
4주차: 반복...
장점:
- 빠른 시장 검증
- 위험 분산
- 유연한 방향 전환
- 지속적인 개선
업무 정의의 중요성
명확한 정의가 필요한 순간
회의에 들어가거나 클라이언트나 상사와 업무에 관한 영역을 정할 때, 혹은 분석할 요건을 정의할 때 해결하고자 하는 결과물의 형태, 목적, 고객을 처음부터 명확하게 정의해둬야 합니다.
3가지 핵심 질문
모든 업무를 시작하기 전에 물어야 할 질문들:
1. 결과물의 형태는?
❌ "사용자 관리 기능을 만들어주세요"
✅ "관리자가 웹 대시보드에서 사용자 목록을 조회하고,
개별 사용자의 권한을 수정할 수 있는 UI를 만들어주세요"
2. 목적은?
❌ "데이터베이스 최적화"
✅ "월말 정산 시 응답시간이 30초 이상 걸리는 문제를
5초 이내로 개선하여 고객 불만을 해소"
3. 고객(사용자)은?
❌ "모바일 앱 개선"
✅ "20-30대 여성 사용자가 출퇴근 중에 쉽게
상품을 검색하고 구매할 수 있도록 개선"
명확한 정의의 효과
- 효율성 향상: 불필요한 작업 제거
- 의사소통 개선: 팀원 간 오해 최소화
- 품질 향상: 명확한 검증 기준
- 시간 절약: 재작업 방지
기업 철학의 중요성
기업 철학과의 정렬
기업의 철학과 맞지 않는 의견을 말하는 것은 곧 회사와 맞지 않는 사람임을 의미합니다.
이것은 개인의 능력이나 성격의 문제가 아닙니다. 가치관의 불일치입니다.
예시: 서로 다른 기업 철학
빠른 성장 추구 vs 안정적 성장:
A사: "일단 빠르게 출시하고 개선합시다"
B사: "완벽하게 검증한 후 출시합시다"
같은 개발자라도:
- A사에 맞는 사람: 빠른 실험을 선호
- B사에 맞는 사람: 품질과 안정성 중시
혁신 vs 최적화:
C사: "새로운 기술을 적극 도입합시다"
D사: "검증된 기술로 안정적으로 운영합시다"
같은 기술이라도:
- C사: 최신 프레임워크 도입
- D사: 레거시 시스템 유지 보수
아마존의 플라이휠
많은 기업이 바라는 이상적인 기업 운영 프로세스의 예시입니다.
낮은 가격
→ 고객 경험 향상
→ 트래픽 증가
→ 판매자 증가
→ 선택의 폭 확대
→ 고객 경험 향상
→ 낮은 가격...
이러한 선순환 구조가 기업의 경영 철학이 됩니다.
경영 철학 이해하기
어떻게 배우는가?
소속된 기업의 경영 철학은 전문가가 아니면 단기간 안에 학습하기 쉽지 않습니다.
일반적인 학습 방법:
- 업무에서 자연스럽게: 의사결정 과정 관찰
- 회사 내 커뮤니케이션: 대나무숲, 전사 회의
- 시간이 지나며 체득: 패턴 인식
입사 전 파악하기
면접 과정에서 회사의 경영 철학과 맞는 인재인지 선별합니다.
확인할 수 있는 방법:
- 회사 웹사이트의 “Our Values”, “Culture” 페이지
- 기술 블로그의 아티클
- 뉴스 기사와 CEO 인터뷰
- 직원 후기 (블라인드, 잡플래닛)
- 면접관의 질문 패턴
맞지 않을 때
회사의 경영 철학과 맞지 않는다면 자연스럽게 퇴사를 하게 됩니다.
신호들:
- 반복적으로 의견이 받아들여지지 않음
- 가치관의 충돌로 인한 스트레스
- “이 회사는 내 스타일이 아니야”
- 업무에 대한 동기 부여 하락
이것은 실패가 아닙니다. 더 잘 맞는 곳을 찾는 과정입니다.
신입 vs 시니어의 시야
신입 개발자의 시야
“기획서에 기재된 요구사항을 보고 구현하는 게 개발의 전부”
요구사항:
- 로그인 기능 구현
- 회원가입 폼 제작
- 비밀번호 찾기 기능
→ "네, 구현하겠습니다!"
초점: How (어떻게 구현할까?)
시니어 개발자의 시야
“신입 때는 보이지 않았던 회사의 목소리에 귀가 기울여지고 관심이 많아졌습니다.”
요구사항:
- 로그인 기능 구현
질문:
- 왜 지금 이 기능이 필요한가? (목적)
- 우리 고객의 주요 페인 포인트는? (고객)
- OAuth vs 자체 인증, 어떤 게 회사 방향성에 맞는가? (철학)
- 이 기능이 비즈니스 KPI에 어떤 영향을 주는가? (가치)
초점: Why (왜?), What (무엇을?)
성장의 지표
근속 기간이 쌓이고 회사 내 윗분들과 만나는 기회가 잦아지면서, 본 회사에서 다루고자 하는 경영 철학을 base로 서비스를 제작하게 됩니다.
이것이 바로 시니어로 성장한다는 것의 의미입니다.
실전 적용 가이드
1. 각 회사의 경영 철학 살펴보기
사전 조사:
- 회사 서비스 사용해보기
- 뉴스 기사 검색
- 기술 블로그 읽기
- LinkedIn에서 직원들 글 찾아보기
질문 예시:
- “이 회사는 속도와 품질 중 무엇을 우선시하나?”
- “혁신과 안정성 중 어디에 가치를 두나?”
- “실패를 어떻게 다루나?“
2. 업무 정의 연습
Before:
"사용자 피드백 기능 만들어주세요"
After:
목적: 사용자가 불편을 느끼는 지점을 빠르게 파악하여
2주 내에 개선안을 마련하기 위함
고객: 서비스를 3회 이상 사용한 활성 사용자
형태: 앱 내 "피드백 보내기" 버튼
- 카테고리 선택 (버그/개선/기능요청)
- 텍스트 입력 (최대 500자)
- 스크린샷 첨부 (선택)
- 관리자 대시보드에서 실시간 확인
측정: 주간 피드백 접수 건수, 평균 응답 시간
3. 회사 철학과 정렬하기
자기 점검:
- 최근 의사결정에서 회사의 방향성을 고려했는가?
- 내 제안이 회사 가치와 일치하는가?
- 회사의 장기 목표를 이해하고 있는가?
적극적 참여:
- 전사 회의 참석
- 경영진 AMA 질문
- 회사 블로그 글 읽기
- 동료들과 회사 방향성 토론
체크리스트
업무 시작 전
- 결과물의 형태가 명확한가?
- 목적이 정의되어 있는가?
- 타겟 고객이 누구인지 아는가?
- 성공 지표가 설정되어 있는가?
- 회사의 경영 철학과 일치하는가?
회의 참여 시
- 안건이 명확한가?
- 의사결정 기준이 공유되었는가?
- 이해관계자가 명확한가?
- 실행 계획이 구체적인가?
경력 개발
- 회사의 핵심 가치를 이해하는가?
- 내 업무가 회사 목표에 어떻게 기여하는가?
- 이 회사의 철학이 나와 맞는가?
결론
핵심 메시지
- 애자일은 방법론이 아닌 철학: 빠른 검증과 개선의 반복
- 명확한 정의가 성공의 시작: 형태, 목적, 고객을 명확히
- 기업 철학 이해가 중요: 가치관 일치가 장기 성공의 열쇠
- 성장은 시야의 확장: How에서 Why로
성장의 여정
신입 때는 코드를 작성하는 것이 개발의 전부였습니다.
하지만 경력이 쌓이면서 깨닫습니다:
- 좋은 코드보다 중요한 것은 올바른 문제를 푸는 것
- 빠른 개발보다 중요한 것은 올바른 방향
- 개인의 역량보다 중요한 것은 팀과 회사의 정렬
회사가 일을 만들고 확산하는 방법을 이해하는 것, 그것이 진정한 시니어로 성장하는 길입니다.
참고 자료
- 원문: https://ppss.kr/archives/247992
- The Lean Startup by Eric Ries
- Amazon’s Flywheel Concept
- Agile Manifesto