이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학부에서 Java로 객체지향을 처음 배웠고, 이후 Haskell 입문 과목에서 함수형 패러다임을 접했습니다. 처음엔 두 방식이 왜 다른지 잘 몰랐는데, 상태 변경이 있느냐 없느냐가 가장 큰 차이라는 것을 직접 코드를 짜보면서 이해했습니다.
객체지향은 상태를 가진 객체가 메시지를 주고받는 방식이라, 복잡한 시스템을 역할 단위로 나누는 데 유리했습니다. 실제로 팀 프로젝트에서 5개 역할을 클래스로 나눴더니 각자 맡은 부분이 명확해졌습니다. 반면 함수형은 입력이 같으면 출력이 늘 같아서, 데이터 변환을 연속으로 처리하는 파이프라인에 잘 맞았습니다.
솔직히 처음엔 함수형 코드를 읽는 게 어려웠습니다. map과 filter를 중첩해서 쓰면 간결하지만, 흐름을 한 번에 파악하기 힘들었고 디버깅도 낯설었습니다. 두 패러다임을 실제로 써보고 나서야 상황에 따라 고르는 감각이 생겼다고 생각합니다.
객체지향과 함수형의 차이를 가장 잘 느꼈던 건 데이터 처리 과제를 두 방식으로 각각 짜봤을 때입니다. 객체지향으로 작성한 코드는 각 단계의 상태를 추적하기 쉬웠지만, 중간에 상태가 바뀌는 버그가 한 번 생겼습니다. 함수형으로 짠 코드는 불변 데이터 원칙 덕분에 같은 버그가 생기지 않았습니다.
그 경험에서 함수형이 데이터 변환 파이프라인에 잘 맞는다는 것을 알았습니다. 반대로 UI 인터랙션처럼 상태가 계속 바뀌고 역할이 여럿 얽히는 경우엔 객체지향이 더 자연스러웠습니다.
아직 두 패러다임을 실무에서 모두 깊이 써본 건 아닙니다. 학부 과제와 개인 프로젝트 수준이지만, 어느 쪽이 어떤 문제에 더 적합한지를 고민하는 습관은 그때 생겼습니다. 현업에서는 두 방식을 섞어 쓰는 경우가 많다는 것도 코드 리뷰 자료를 보면서 알게 됐습니다.
캡스톤 프로젝트에서 팀원들과 언어를 고를 때 이 주제가 실제로 논의됐습니다. 팀원 중 한 명이 Scala를 제안했는데, 객체지향과 함수형을 섞어 쓸 수 있다는 이유였습니다. 저는 익숙한 Python을 선호했고, 두 의견이 부딪혔습니다.
결국 Python으로 진행하면서 함수형 스타일을 부분 적용했습니다. 데이터 전처리 단계는 map·filter를 쓰고, 모델 클래스는 객체지향으로 구성했습니다. 처음엔 어색했지만, 데이터 흐름이 명확해지고 테스트가 쉬워졌습니다.
제가 느낀 차이는 이렇습니다. 객체지향은 무엇이 하는가를 중심으로 설계하고, 함수형은 무엇이 변환되는가를 중심으로 설계합니다. 어느 쪽이 낫다기보다, 다루는 문제의 성격에 맞는 방식을 고르는 것이 중요하다고 생각합니다. 그 판단을 더 잘 하고 싶어서 이 직무를 지원했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.