問
賢
우문현답愚問賢答
회사별직군별질문 모음서비스 소개
홈›회사별›삼성전자›SW·IT 일반›질문 상세
問삼성전자 · SW·IT 일반 · 직무 역량

객체지향과 함수형 프로그래밍의 차이, 각 패러다임이 어떤 문제에 적합한지 설명해주세요.

예상 답변
60초
예상 꼬리질문
3회
난이도
난이도 중
출제 빈도
낮음
이 질문으로 모의면접 한 번 해보기
INTENT

면접관이 진짜로 보는 건 답이 아닙니다.

이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.

01
무엇으로 가르는가?
용어 정의가 아니라 두 패러다임이 다루는 핵심이 무엇으로 다른지 가르는지를 봅니다. 정의만 나오면 면접관이 '그래서 언제 뭘 쓰죠?'를 추가로 묻는 자리가 자주 보입니다.
02
적합한 문제를 짝짓는가?
장단점 나열이 아니라 어떤 문제에 어느 쪽이 맞는지 연결하는지를 봅니다. 따로 놀면 외운 답으로 들립니다.
03
경험에 닿는가?
직접 써 보며 느낀 자리에서 설명이 나오는지를 봅니다. 책 문장만이면 안 써 본 인상을 줍니다.
04
섞임을 아는가?
둘이 배타적이 아니라 한 코드에서 섞여 쓰임을 짚는지를 봅니다. 한쪽만 옳다고 닫으면 얕게 들립니다.
읽기만 해도 충분하지만, 한 번 말로 해보면 다릅니다.
이 질문 그대로 음성 면접으로 받아볼 수 있어요. 첫 면접은 무료입니다.
EXAMPLES

세 가지 다른 결로 같은 질문을 풀어봤습니다.

하나가 답이 아니에요. 같은 질문도 강조하는 자리에 따라 결이 달라지고, 면접관이 다음에 던지는 질문도 달라집니다.

壹상태를 다루는 방식 차이로 가르는 결약 88초貳변경 가능성으로 적합성을 푸는 결약 86초參섞임에서 출발해 정리하는 결약 86초
壹
예시 답변 1
약 88초

상태를 다루는 방식 차이로 가르는 결

두 패러다임을 저는 상태를 어떻게 다루느냐로 가릅니다. 객체지향은 상태와 그 상태를 바꾸는 동작을 한 덩어리로 묶어 관리하는 쪽입니다. 함수형은 반대로 상태를 바꾸지 않고, 입력을 받아 새 값을 내는 함수로 흐름을 만드는 쪽입니다. 그래서 적합한 문제가 갈립니다.

현실의 사물과 그 변화를 모델링해야 하는 도메인은 객체지향이 자연스럽고, 데이터를 단계마다 변형해 흘려보내는 처리는 함수형이 깔끔합니다. 학부 프로젝트에서 도메인 모델은 객체로 짜고, 데이터 가공 파이프라인은 함수 연결로 짰을 때 각자 더 단순해지는 걸 직접 겪었습니다. 둘은 배타적이지 않습니다. 한 코드에서 큰 구조는 객체로, 그 안의 변환 로직은 함수형으로 섞어 쓰는 게 오히려 흔합니다. 그래서 저는 둘을 경쟁이 아니라 문제에 따라 고르는 도구로 봅니다.

이 결의 특징
축1·2·3·4에 닿는 결입니다. *상태 처리 방식*으로 가르고(축1) 도메인 모델링·데이터 변환에 짝지으며(축2) 직접 섞어 짠 경험(축3)으로 받치고 섞임(축4)을 인정해, 외운 답으로 들린다는 인상을 줄입니다.
이 결이 통하는 자리
두 패러다임을 직접 써 본 경험이 또렷한 경우에 살아납니다. 무엇으로 가르고 어떤 문제에 무엇이 맞으며 어떻게 섞이는지가 한 줄이라도 들어가야 결이 무너지지 않으며, 그 이해가 본인 것이었는지도 함께 보입니다.
貳
예시 답변 2
약 86초

변경 가능성으로 적합성을 푸는 결

저는 두 패러다임의 선택 기준을 상태가 자주 바뀌느냐로 봅니다. 객체지향은 상태를 가진 것이 자연스럽고, 그 상태를 안전하게 바꾸는 규칙을 객체 안에 두는 데 강합니다. 함수형은 상태 변경을 피해, 같은 입력이면 같은 출력을 보장하는 데 강합니다. 그래서 동시에 여러 곳에서 건드려 꼬이기 쉬운 처리는 함수형이 안전하고, 복잡한 규칙을 가진 도메인 객체는 객체지향이 관리하기 낫습니다. 과제에서 동시 처리 중 공유 상태 때문에 버그가 났을 때, 그 부분을 상태 없는 변환으로 바꾸자 문제가 사라진 경험이 있습니다. 그때 함수형의 이점을 책이 아니라 손으로 알았습니다. 다만 모든 걸 함수형으로 하면 현실 모델이 어색해지는 자리도 있어, 저는 둘을 문제의 성격에 맞춰 섞는 편입니다.

이 결의 특징
축1·2·3·4에 닿는 결입니다. *상태 변경 빈도*로 적합성을 가르고(축1·2) 공유 상태 버그를 함수형으로 푼 경험(축3)으로 받치며 섞어 쓰는 태도(축4)를 들어, 정의 암기와 구분됩니다.
이 결이 통하는 자리
상태 문제로 패러다임을 가른 경험이 또렷한 경우에 살아납니다. 무엇을 기준으로 갈리고 어떤 문제에 무엇이 안전하며 어디서 섞는지가 한 줄이라도 들어가야 결이 무너지지 않으며, 그 이해가 본인 것이었는지도 함께 보입니다.
參
예시 답변 3
약 86초

섞임에서 출발해 정리하는 결

저는 둘은 경쟁 관계가 아니다라는 데서 시작하고 싶습니다. 실무 코드 대부분은 이미 둘이 섞여 있습니다. 핵심 차이만 짚으면, 객체지향은 상태를 가진 객체 단위로 세상을 나누고, 함수형은 상태 변경 없는 함수의 조합으로 흐름을 만든다는 점입니다. 적합성은 거기서 나옵니다.

규칙이 복잡하고 오래 살아 있는 도메인은 객체로 묶는 게 관리되고, 데이터를 단계로 변형하거나 동시성이 얽힌 처리는 함수형이 덜 위험합니다. 과제에서 큰 구조는 객체로 잡되, 그 안의 계산 로직만 순수 함수로 떼어 두니 테스트가 훨씬 쉬워진 경험이 있습니다. 그래서 제 결론은, 어느 게 옳으냐가 아니라, 한 문제 안에서도 부분마다 맞는 쪽을 고르는 것이 핵심이라는 점입니다.

이 결의 특징
축1·2·3·4에 닿는 결입니다. 섞임(축4)에서 출발해 핵심 차이를 가르고(축1) 도메인·데이터 변환에 짝지으며(축2) 순수 함수로 테스트가 쉬워진 경험(축3)으로 받쳐, 한쪽만 옳다는 답과 구분됩니다.
이 결이 통하는 자리
한 코드 안에서 둘을 함께 써 본 경험이 또렷한 경우에 살아납니다. 핵심 차이와 부분별 적합성, 섞어 쓴 구체 자리가 한 줄이라도 들어가야 결이 무너지지 않으며, 그 이해가 본인 것이었는지도 함께 보입니다.
!
위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
WHAT OFTEN MISSES예시

이 질문에서 자주 빠지는 자리.

답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.

1
떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
2
선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
3
결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
4
지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
FOLLOW-UPS

진짜 면접은 두 번째 질문부터입니다.

이 질문에 이어 삼성전자 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.

壹
예상 꼬리질문 1
상태를 안 바꾼다는 게 현실에서 늘 가능한가요?
貳
예상 꼬리질문 2
섞어 쓰면 일관성이 떨어지지 않을까요?
參
예상 꼬리질문 3
함수형으로 바꿔 버그가 사라진 게 운은 아니었을까요?
NEXT
읽으셨다면, 한 번 말로 해보세요.
같은 질문으로 음성 면접을 받아보면 어디서 막히는지 바로 보입니다. 첫 면접은 무료입니다.
3 크레딧 차감 · 첫 회 무료 · 음성 데이터는 종료 즉시 폐기됩니다
DISCLAIMER

이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.

우문현답 · 愚問賢答
© 2026 · 어떤 질문에도, 현명하게.
이용약관개인정보처리방침문의