2023 - 2025 면접 회고
2025년이 다 끝나가는 마당에 갑자기 지난 면접회고를 하고싶어졌다.
면접 회고라고는 하지만 별건 아니고 내가 제대로 답하지 못했던 것들을 이제와서 생각해보면 어떻게 답할 수 있을까 하는 생각에서 시작한 기록이다.
따라서 개인적으로 충분히 잘 대답했다고 생각하는 것들에 대한 기록은 없다.
여전히 대답에 아쉬움이 남았던 것들, 예상치 못한 질문들, 기억나는 건 많지 않지만 그것들에 대한 회고를 좀 해보겠다.
1. 왜 하필 윈도우 서버로 개발하셨죠?
2023년도 하반기에 받았던 질문이다.
잠깐 배경설명을 하자면, 대학원 석사 1차 때 개발용역으로 진행한 프로젝트를 소개할 때 받았던 질문으로 고객사에서는 윈도우 환경에서 실행 가능한 프로그램을 원했다.
고객사는 하드웨어 위주의 회사로 본인들이 판매하는 하드웨어와 호환되는 소프트웨어를 원했고 이러다보니 윈도우 환경을 원했던 것 같다.
솔직히 말하자면 당시에 별로 원하는 프로젝트도 아니었고 제대로 뭘 할 줄 아는 상태도 아니었기에 이것저것 고객사에게 설명하고 좋은 방향으로 이끌기보단 해달라는 것들이 뭔지도 제대로 모르는 채로 개발을 진행했었다.
프로젝트가 끝나고 보니 함께 진행했던 팀원들은 나름 이 프로젝트를 잘 포장해서 어느 정도 덕을 봤다고는 하는데 나는 아니었다.
변명아닌 변명을 해보자면 PM역할을 하면서 개발 자체보다는 일정관리나 의사소통에 좀 더 많은 시간을 할애했고 이렇다보니 이 프로젝트에서 "개발자"로서의 역할은 좀 약했다고 생각한다.
그리고 이런 문제는 면접에서 그대로 드러나버렸다.
윈도우 서버보단 다른 옵션도 있었을 것 같은데...
이것저것 이 프로젝트를 설명하다보니 개발 임원급 되시던 분이 왜 하필 윈도우 서버로 개발을 했냐는 질문을 했다.
그리고 나의 대답은
- 고객사가 원했기 때문에 윈도우 서버에서 개발을 진행할 수 밖에 없었습니다.
예전에 7년차 쯤 되는 개발자분께 이 대답에 대해 어떻게 생각하느냐 물어본적이 있다.
돌아온 답은 "팩트긴 하지만 경우에 따라선 생각없이 프로젝트를 진행한 것처럼 보일 수 있다" 이다.
나도 동의한다.
무엇보다 저 대답을 한 뒤에 돌아온 답은
- 다른 옵션은 고민해본 적 없느냐
- 더 선택지가 많았을 것 같은데
였으니까 일단 부정적인 인상이었던 것은 틀림 없어보인다.
아마 내가 해당 프로젝트를 잘 설명 못했던 것도 있겠지만 그 임원분의 입장에서는 기술 분석조차 제대로 안하고 무지성으로 개발하는 사람처럼 보이지 않았을까 싶다.
그렇다면 이제와서 저 질문을 받는다면 과연 어떻게 대답할 수 있을까.
생각해본다면 아마 이렇게 답할 것 같다.
"요구사항을 분석해본 결과 윈도우 서버보단 안정적인 리눅스 서버에서의 개발을 제안드려봤으나 결론적으로는 본인들이 현재 보유 중인 윈도우 소프트웨어와의 호환이 되는 것을 목표로 한다는 것을 알고 윈도우 서버를 구축하기로 했습니다."
실제로 1차적인 개발은 리눅스에서 진행한 뒤 2차 개발로 윈도우 서버로의 포팅작업이 있었고 이를 위해서 고객사와 여러번 회의도 진행했었다.
다만 이런 과정을 면접관들에게 제대로 어필하지 못한 채로 그저 그들이 원했으니까 그렇게 했다라는 식의 대답이 문제였다고 본다.
면접에 정답은 없으니 저런다고 면접관들의 마음에 들지는 확신하지 못하겠지만 적어도 개발 진행에 있어서 더 나은 결과물을 위해 고민한 흔적을 전달할 수 있는 대답이라고 생각한다.
2. CoT에 대해 어떻게 생각하시죠?
2025년 상반기에 받았던 질문이다.
이때 지원 직무는 AI 엔지니어고 주된 업무는 LLM 소프트웨어 개발이었다.
당연히 LLM 프롬프팅 기법 관련 질문과 최근의 트랜드에 대한 질문이 나올줄 예상하고 있었고 아니나 다를까 위의 질문이 들어왔다.
당시 나는 몇몇 LLM 관련 사이드 프로젝트들을 진행하며 프롬프팅 기법이나 MCP나 하는 것들에 대한 공부를 하긴 했으나 결국 내 개인적인 생각은 최신 기법이나 트랜디한 기술들이 중요한게 아니라 필요에 따라 자유롭게 적용할 수 있는, 필요 없다면 과감하게 버릴 수 있는 개발 능력이 더 중요하다는 것이었다.
이는 아직도 변함이 없다만 질문에 대한 나의 대답은 아주 오만하기 그지 없었다.
- 몇 번 적용시켜보고 성능을 비교해보았지만 큰 성능의 변화는 느끼지 못했습니다. 아무래도 LLM 관련 기술들이 비교적 최신의 기법들이라 연구가 많이 이뤄지지 않은 것 같습니다.
지금 다시 읽어보니 이렇게 느껴진다.
"더 좋은거 나올 때까지 기다려야죠 뭐."
다시 말해서 스스로 성능을 끌어올리기보단 남들이 연구해놓은거 가져다 쓰겠다는 심보가 눈에 띈다는 소리다.
마침 현재 AI 엔지니어, LLM 서비스 개발 직무에서 일하는 입장에서 생각해보면 이 직무는 개발직으로 느껴지긴 하지만 연구 업무가 없는 것은 또 아니라고 본다.
어떻게하면 지금 있는 데이터에서 성능을 더 끌어올릴 수 있을까.
RAG 과정을 좀 더 최적화할 수는 없을까.
데이터를 다른 형태로 가공해볼까.
대학원 시절 해왔던 제안서 작성이나 기초 모델 연구 같은 것들과는 조금 방향성이 다르긴 하지만 어쨌든 연구 비스무리한 업무를 자주 한다.
때문에 저런 대답은 확실히 이 직무에 대한 고민이 전혀 없는 것처럼 들린다.
물론 다른 직무라고 저런 대답을 좋아하진 않겠지만.
결국 이때 지원했던 직무에서 일하고 있기 때문에 과연 다시 저런 질문을 받으면 어떻게 대답할지 크게 생각하진 않았다만 아마 지금 가진 철학과 지속적인 연구의 필요성을 더 어필하지 않았을까 싶다.
3. 그러면 싱글톤이 되는거 맞아요?
이것도 2025년 상반기에 들었던 질문이다.
이 기업에서는 대면 면접 전에 과제 전형이 있었는데 이 때 약간 디자인 패턴에 딥하게 몰입해 있던 터라 아는 것 조금이라도 더 어필해보겠다고 싱글톤 패턴 어쩌고 하면서 구현 방식을 설명했었다.
사실 그게 중요한게 아니었단건 지금에서야 깨달았지만 어쨌든 그랬었다.
해당 직무도 AI, LLM 영역이라 사용 언어가 파이썬이었는데 과제 전형 당시 싱글톤을 구현하기 위해 두 가지 방식을 썼다.
첫 번째는 아래와 같이 직접 객체에 초기화 정보를 주는 방식이다.
class Singleton:
_initailized = False
_instanse = None
def __new__(cls, *args, **kwargs):
if cls._instance is None:
cls._instance = super().__new__(cls)
return cls._instance
def __init__(self):
if not self.__class__._initialized:
self.__class__._initialized = True파이썬 문법과 관련된 방법이기 때문에 딱히 설명은 하지 않겠지만 대충 보면 인스턴스가 없다면 인스턴스를 만들고 초기화 플래그를 True로 바꿔서 더이상 인스턴스가 만들어지지 않게 하는 방법이다.
두 번째 방법은 간단하다.
# Singleton module
singleton = Singleton()
# Other module
from singleton_module import singleton
...그냥 싱글톤으로 쓰고싶은 객체를 전역에서 선언해버리는 것이다.
이건 나도 해당 과제를 진행하기 전까지는 몰랐는데 이렇게 전역에서 인스턴스를 생성하면 파이썬 프로그램의 생명주기 내에 메모리에 계속해서 올라가 있게 되고 직접 메모리를 해제하지 않는 이상 같은 인스턴스가 유지된다.
사실 파이썬 메모리 관련해서 깊게 공부한적이 많지 않아서 이 설명이 맞는지는 모르겠다.
아마 GC와 파이썬 객체 생성 및 메모리 할당 방식을 좀 더 공부해야지 싶다.
아무튼간에 실제로 해시값을 읽어보면 어디서 해당 객체를 읽어오던 같은 값을 가리킨다.
과제 전형에서 나는 두 가지 방식을 혼용해서 썼고 면접에서는 두 번째 방식이 정말로 싱글톤이 되는게 맞냐는 질문을 받았다.
아마 아닐텐데..?
면접관은 두 번째 방식은 틀렸다는 의견을 내놓았고 나는 어떻게 보면 최악의 답변을 했다.
- 아 그렇다면 제가 잘못 알고 있었나봅니다. 다시 공부해보겠습니다.
인정하고 배우려는 자세는 좋다고 생각하지만 내가 면접관의 입장에서 이런 대답을 들었다면 조금 실망했을 것 같다.
면접관이 일부러 속이려고 했든, 진짜로 잘못 알고 있었든,
최소한 내가 왜 그렇게 알고 있었는지,
어디서 어떻게 그런 지식을 얻었는지,
좀 더 나가면 왜 싱글톤을 두 가지 방식으로 구현했는지 까지는 말했어야 한다고 생각한다.
적어도 개발자로서 그것이 비록 잘못 알고 있는 지식이더라도 명확하게 알고 구현하는 것과 "그런것 같다"는 식으로 구현하는 것은 다르다고 보기 때문이다.
그런 면에서 나의 대답은 후자의 뉘앙스를 풍겼을 것 같다.
이외에도 후회되는 답변들이 있긴 하지만 가장 기억에 남고 생각해볼만한 질문들은 여기까지인 것 같다.
혹시 나중에 더 생각난다면 그때 다시 적어보기로 하겠다.
공교롭게도 적어보고나니 질문의 카테고리가 다 다르다.
1번 질문은 프로젝트에 관한 질문,
2번 질문은 직무에 관한 질문,
3번 질문은 개발 지식에 관한 질문이다.
결국은 원하는 직무, 원하던 업무를 하고 있긴 하지만 이런 부분들을 더 보완했었더라면 선택지가 더 넓지 않았을까 하는 생각이 든다.
그래도 덕분에 요즘 만드는 서비스들은 더욱 이런 것들을 염두에 두고 만들고 있다.
서비스는 더 나은 방향으로 가고 있는지, 적용시켜볼만한 새로운 기법들은 없는지, 프로그램에 기술적으로 문제되는 부분은 없는지 파악하려 한다.
이런 것들이 쌓여서 다시는 저런 실수들을 하지 않게 될테니까.
