ChatGPT로 내 취준생 시절 면접을 재현할 수 있을까?
2023. 2. 14. 04:33ㆍIT/Review
들어가며
ChatGPT. 개발자들 사이에선 이미 잘 알려진 AI다. 몇달 전부터 "대답이 정말 사람같아서 소름 끼친다" 등의 평가가 이어졌었는데, 최근에는 언론 보도를 기점으로 인기가 폭발할듯이 치솟았다.
AI는 내 전문분야가 아니기에 잘은 모르지만, 알파고 사태 때 보였던 "가능성"이 이제는 정말 구현이라는 영역으로 넘어오고 있음을 느낀다.
ChatGPT를 가지고 놀다보니 문득 "내가 취준생 시절일 때 했던 면접을 AI에게 맡기면 그대로 진행될까?"하는 궁금증에 빠졌다. 사실대로 풀어쓰자면 "나와 사고패턴이 비슷한 AI가 나올 수 있는가"에 대한 궁금증이고, 매우 거창하게 쓰자면 "인격 복제의 가능성을 엿볼 수 있을까"에 대한 궁금증이었다. (물론, 이 단계에서 가능성을 본다한들 실현되려면 한참 남았겠지만)
시켜보니 결과는 꽤 놀라웠다. 아래에서 설명한다.
ChatGPT에게 학습을 시키자
아래와 같은 조건을 학습시켰다.
- 언어는 영어를 전제로 함(한국어는 부정확하다는 제보들이 많았음)
- ChatGPT는 Bob이라 불리는 가상인물에 대한 정보를 듣고, 이 사람 대신 대답을 해야 함
- 질문을 하는 사람은 면접관 역할을 할 것이며, 이 대화는 모의 면접이 될 것임
- Bob의 정보는 아래와 같음
- Bob은 24세이다. (만 나이 기준)
- Bob은 일본어와 컴퓨터 과학을 복수전공했다.
- Bob은 백엔드 개발자에 지원했다.
- Bob은 아래와 같은 프로젝트들을 경험해봤다.
- Express.js를 이용한 간단한 웹 서버
- 간단한 Android 모바일 게임
- 몇 가지 Python 프로젝트들
자, 그럼 시작해보자
모의면접, 시작
주의사항
이 모의 면접에서 나오는 질문들은 제 경험과 생각을 기반으로 만들어졌습니다. 일부는 실제로 면접에서 들었던 내용이고, 일부는 제가 취준생 시절에 '이런 질문도 할 수 있지 않을까?' 하고 상상했던 문항도 섞여있습니다. 면접은 업무 분야, 회사 분위기, 면접관 등에 따라 천차만별이니 "아~ 이 회사의 백엔드 면접은 이런가보구나~" 하는 일반화는 피해주세요.
내 질문과 ChatGPT의 답변 순으로 진행된다.
| 면접관 | 이력서를 읽어봤습니다. 일본어도 전공하셨더군요? 왜 개발자가 되기로 하신거죠? 컴퓨터 과학이 일본어학보다 가치있다 생각하셨나요? |
| ChatGPT | 전 컴퓨터 과학과 일본어 양쪽 과목을 좋아합니다. 단지 소프트웨어 엔지니어링이 도전적이고, 끊임없이 발전하는 분야이며, 그렇기에 제 문제 해결 능력과 창의성을 이용해 실제 세상에 산재한 문제들을 해결할 수 있을 것이라 생각했습니다. 컴퓨터 과학 지식이 일본어 능력보다 더 가치가 있다고 생각하지는 않습니다. 그러나 소프트웨어 엔지니어링은 제게 직업적, 개인적으로 성장할 수 있는 많은 기회를 줄 수 있으리라 강하게 믿고 있습니다. 또한, 소프트웨어 프로덕트와 솔루션을 개발하기 위한 기술을 이용하여 일을 할 수 있는 능력은 언제나 제게는 신나는 미래로 다가왔었습니다. |
| 나 | (아니.. 진짜 내가 생각하던 그 답안과 크게 다르지 않는데?) |
| 면접관 | 백엔드 개발자를 원한다고는 했지만.. 저희 팀은 자바(Java)로 일을 합니다. 면접자분은 Java 프로젝트 경험이 있고, Javascript로 백엔드 프로젝트를 해본 경험이 있는 건 알겠는데, 정작 Java로 백엔드를 해본 적은 없으시더군요? 그럼에도 저희랑 잘 일할 수 있을 것 같으신가요? |
| ChatGPT | 네, 설령 제가 Java 백엔드 프로젝트 경험이 없다 하더라도 저는 팀에서 잘 일할 수 있을 것이라 자신합니다. 저는 프로그래밍을 경험해왔고, 소프트웨어 개발 이론에 대해 깊은 이해도가 있으며, 컴퓨터 과학 기반 지식들 또한 탄탄합니다. 또한, 전 새 기술들을 빠르게 경험해왔고, Javascript나 Python 등의 언어를 포함해 다양한 언어로 일을 해 왔습니다. 이제 저의 스킬셋에 Java를 추가시킬 생각에 신이 나네요. 그래서 저는 팀에 합류하여 빠르게 1인분을 해낼 수 있을 것이라 자신합니다. |
| 나 | (이거 내가 면접 때 했던 말과 논조가 거의 비슷하다..? 물론 얘가 근자감이 더 넘치긴 하지만서도.. 흠터레스팅하군) |
| 면접관 | 저희 회사는 다국적 법인입니다. 그래서 어떨 때는 일본 개발자들과도 협업을 하게 됩니다. 일본 분들과 의사소통이 가능하신가요? 일본어로 쓰여진 문서를 읽어본 적은 있으신가요? |
| ChatGPT | 네, 저는 일본어를 몇 년간 배웠기에 읽기, 쓰기, 말하기도 가능합니다. 수업 시간 외 여러 상황에서 일본어 원어민과 만날 기회들이 있었습니다. 저는 일본 개발자들과 능숙하게 의사소통할 수 있을 것이라 자신하며, 일본어로 쓰인 기술 문서를 읽는 것도 버겁지 않습니다. 제 일본어 지식은 다국적 업무환경에서 좋은 자산이 될 것입니다. 서로 다른 문화적 배경을 가진 팀원들과 관계를 맺고, 효율적인 협업을 할 수 있게 될 테니까요. |
| 나 | (실제로 나는 일본인들과의 대화 경험도 있었고, Ruby 개발문서를 찾다가 일본어로 쓰인 도큐멘테이션도 읽어봤었다. ChatGPT는 단순히 주어진 정보대로 추론했겠지만...) |
| 면접관 | 포트폴리오를 봤습니다. 대학생 시절에 간단한 P2P 채팅 프로그램을 만들었던 것 같네요. 이 프로젝트에 대해 설명해주실 수 있나요? |
| ChatGPT | 물론이죠. 저는 네트워크 프로그래밍 수업시간 때 이 채팅 프로그램을 만들었습니다. 이 프로그램은 채팅방과 유사하게, 실시간으로 유저들간 메시지를 주고 받을 수 있도록 디자인되었습니다. 이 프로그램은 Python으로 만들어졌으며, 클라이언트들간 연결을 제어하기 위해 소켓라이브러리를 활용했습니다. 저는 서버사이드의 핵심 로직을 담당했습니다. 서버 사이드 로직은 클라이언트 커넥션을 관리하며 유저들 사이의 메시지를 중계하는 것에 초점을 뒀습니다. 또한, 클라이언트 사이드의 UI도 제가 담당했는데요, 이를 통해 유저들은 메시지를 입력하거나 도착한 메시지를 볼 수 있었습니다. 결론은, P2P 채팅 프로그램은 제게 어려우면서도 동시에 많은 걸 배워가는 계기가 되었던 프로젝트입니다. 이 프로젝트 덕에 저는 네트워크 프로그래밍과 소프트웨어 개발 능력을 키울 수 있었습니다. 효율적이며 확장 가능한 커뮤니케이션 프로토콜을 비롯해, 네트워크 기반 프로그램을 만드는 과정에 대해 많은 것을 배웠습니다. 이 경험이 이후의 프로젝트들에 대한 좋은 준비가 되었고, 실시간 네트워크 기반 프로그램 개발에 대한 탄탄한 기반지식을 얻게 되었습니다. |
| 나 | (실제로 내가 개발한건 1:1 채팅 프로그램이었지만.. 언어를 실제로 Python을 사용했던 것, 이 프로젝트를 컴퓨터 네트워크 시간에 만들게 되었다는 점은 일치한다. 이 프로젝트를 통해 내가 많은 부분을 배웠다는 점까지... 뭐지?) |
| 면접관 | 그 프로젝트에서 가장 어려웠던 부분이 뭔가요? 어떻게 해결하셨죠? |
| ChatGPT | 가장 어려웠던 파트는 클라이언트와 서버 사이의 통신 프로토콜을 설계하는 것이었습니다. 여러 클라이언트가 메시지를 실시간으로 주고받게 한다는 목표를 달성하려면, 이 flow를 핸들링할 수 있는 강직하고 효율적인 프로토콜이 필요했습니다. 이 때의 경험에 대해 말하자면, 저는 여러 디자인 선택지 중에서 장단점을 면밀히 따져봐야 했습니다. 대표적으로는 중앙 서버를 사용하느냐, 혹은 P2P 네트워크를 사용하느냐 같은 문제가 있었죠. 저는 결국 클라이언트 연결을 중앙 서버가 맡아 메시지를 중개시키도록 하는 디자인을 채택했습니다. 이게 프로젝트의 요구 조건을 만족하면서도 더 간편한 구현이었기 때문이죠. 또 힘들었던 점은, 프로그램이 확장 가능해야 하면서 성능 저하 없이 대량의 클라이언트 연결을 감당할 수 있어야 한다는 것이었습니다. 이 문제를 풀기 위해 저는 멀티쓰레드 기반 서버 디자인을 구현하여 여러 클라이언트를 동시에 핸들링할 수 있도록 함과 동시에 오버헤드를 줄이기 위해 시스템 리소스의 사용도 최적화 했습니다. 결론을 말하자면, 저는 신중하게 계획하고 디자인 함으로써 당면한 문제들을 해결할 수 있었습니다. 프로젝트의 요구조건을 만족할 때까지 끊임없이 테스트하며 반복 구현한 것도 잊지 않았죠. 저는 이 경험이 제게 확장 가능하며 효율적인 커뮤니케이션 프로토콜을 설계하는 데 필요한 기반지식을 탄탄히 하는 것을 도왔다고 생각합니다. 이 또한 이후 프로젝트들에 큰 도움이 되겠죠. |
| 나 | (P2P 프로그램이라 말했으면서 중앙 서버를 사용했다는 것은 상호 모순되는 발언처럼 들린다. 부정확한 정보같은데.. 하지만 질문이 "실시간 채팅 프로그램"이었다는 전제라면 모두 말이 된다. 이부분은 약간의 오류라고 봐야겠군) |
| 면접관 | 파이썬의 멀티쓰레딩이 그리 성능상 좋지 않다는 건 알고 계시나요? |
| ChatGPT | 예, 파이썬의 멀티 쓰레딩은 성능 상에서 몇가지 제약이 있죠. Python 구현체 중 CPython이 갖고 있는 GIL(Global Intepreter Lock)은 파이썬이 병렬로 다중 쓰레드를 실행하지 못하도록 제한한다고 알고 있습니다. 그래서 CPU 부하가 큰 task들을 멀티쓰레딩으로 돌리면 효율이 아주 좋지는 않다고 하더군요. 그렇지만 특정 경우에는 이 멀티쓰레딩이 꽤 쓸만하단 것도 알아야 합니다. 예를 들어 I/O에 치우쳐진 task들이나 외부 리소스를 기다리는 작업들은 위 한계로부터 자유롭습니다. 또한, Python 구현체는 CPython만 있는 것은 아닙니다, Jython이나 IronPython 같은 구현체들은 GIL이 없기에 멀티쓰레딩 프로그램 개발에서 더 향상된 성능을 보여줍니다. 결국엔 파이썬 프로그램에서 멀티쓰레딩을 쓸 것이냐 아니냐는 프로젝트의 성능 제약 같은 특정한 요구사항에 따라 달라집니다. 소프트웨어 개발자로서 저는 장단점을 면밀히 평가하여 문제를 해결하는 최선책을 찾아낼 것입니다. |
| 나 | (GIL 이야기는 오히려 내가 면접 때 먼저 꺼냈던 이야기다. 파이썬의 대표적인 단점으로 지적받던 사항이니.. 다만 그 당시 나는 수박 겉핥기로 답변했었고, 얘는 더 심도있는 답변을 했다는 차이가 있네. GIL이 없는 Python 구현체가 있는 건 이번에 나도 처음 알았다..) |
| 면접관 | 과제를 하나 드리겠습니다. 개인 블로그를 만든다고 해보죠, 어떻게 구현하시겠어요? db나 언어 상관 없이 한번 설계를 해보세요 |
| ChatGPT | 제 개인 블로그는 아래와 같은 구조가 될 것입니다. |
프론트 엔드
- 저는 React/Angular 같은 모던한 프론트엔드 프레임워크를 이용해 다이나믹하고 반응성 좋은 UI를 블로그에 붙일 것입니다.
- 프론트 엔드 쪽에서는 백엔드 서버에 API를 호출하여 데이터를 가져온 다음, 렌더링할 것입니다.
백엔드
- 백엔드에서는 전 API 구현을 위해 Express나 Flask 같은 서버사이드 프레임워크를 사용 할 것입니다.
- API는 프론트 엔드와 DB 사이의 연결을 담당할 것입니다.
DB
- 저는 MongoDB나 Cassandra 같은 NoSQL DB를 사용하여 블로그 포스트나 유저 정보를 담을 것입니다.
- 이런 타입의 DB들은 제가 느슨한 구조의(semi-structured) 데이터를 효율적으로 저장하고 가져오도록 하며, 블로그의 규모가 커질 때에도 쉽게 확장할 수 있습니다.
배포
- 제 블로그를 배포하기 위해 저는 AWS나 GCP(Google Cloud Platform) 같은 클라우드 플랫폼을 사용할 것입니다.
- 저는 고가용성 확보를 위해 트래픽을 여러 인스턴스의 백엔드에 분산하기 위한 로드 밸런서를 사용할 것입니다.
| ChatGPT | 이렇게 할 경우, 제 개인 블로그의 아키텍처는 확장 가능하고, 효율적이며, 유지 보수하기도 쉬운 아키텍처가 됩니다. 프론트엔드/백엔드/DB로 깔끔한 관심사의 분리도 덤으로 따라오죠. 저는 프로젝트의 요구사항에 최적으로 맞는 도구와 기술을 사용할 것이며, 블로그가 시간에 지남에 따라 변할 경우 지속적으로 아키텍처를 평가하고 최적화할 것입니다. |
| 나 | (Node.js를 사용할 수 있다는 점은 나와 같지만, DB는 NoSQL을 골랐네. 생각해보니 얘한테는 MySQL 경험만 있고 NoSQL 경험이 없다는 점을 학습시키지 않았다. 아마 그 이유 떄문에 결과가 다른 걸 지도) |
| 면접관 | MySQL 같은 RDBMS를 사용하는 건 어때요? 이 경우에는 NoSQL보다 더 좋은 선택 아닐까요? |
| ChatGPT | RDBMS나 NoSQL이나 각각 장단점이 있다는 걸 알고 있습니다. 그러니 어떤 것을 써야 하느냐는 프로젝트의 요구사항을 따를 수밖에 없겠죠. 개인 블로그의 주 목적은 블로그 포스트를 저장하고 가져오는 것입니다. 이를 위해서는 MongoDB나 Cassandra 같은 NoSQL이 아래와 같은 이유로 더 좋은 선택이 될 것입니다. - 확장가능성 NoSQL DB는 확장이 용이하고, 대량의 느슨한 구조의 데이터를 효율적으로 다룰 수 있도록 설계되었습니다. 개인 블로그는 성장할 수록 대량의 트래픽이 발생할테니 확장 가능성은 중요합니다. - 유연성 NoSQL DB는 엄격한 스키마를 강제하지 않습니다. 그러므로 데이터를 저장하고 가져옴에 있어 유연성을 확보할 수 있습니다. 개인 블로그는 시간이 지나면서 데이터 구조가 변할 수도 있으니 이 특성은 유용할 것입니다. - 성능 NoSQL DB는 읽기 작업이 다량 발생하는 작업에 최적화되어 있습니다. 그러므로 유저들에게 블로그 포스팅을 제공하기에 적합하죠. 그러나 MySQL 같은 RDBMS를 사용하는 것이 더 적합할 경우도 있습니다. 예를 들어 블로그가 포스트, 유저, 코멘트 등의 객체들간 복잡한 연관 관계를 사용한다면 말이죠. RDBMS는 트랜잭션과 연관관계를 견고히 하는 데 특화되어 있어 이 경우엔 더 좋을 수 있습니다. 끝으로, RDBMS와 NoSQL 중에 선택하는 것은 프로젝트의 제약과 요구사항에 의존하게 됩니다. 그 트레이드 오프는 반드시 확장 가능성/유연성/성능 사이에서 발생하게 되죠. 소프트웨어 개발자로서 저는 블로그의 요구사항을 평가하여 그 조건에 맞는 최적의 DB를 고를 것입니다. |
| 나 | (나는 NoSQL 경험이 전혀 없었기에 애초에 선택하지도 못했을 거고, 대답하지도 못했을 것이다. 아마 내가 NoSQL 경험이 없다고 정보를 줬다한들 "전 모든 기술을 빠르게 습득합니다!" 식으로 다시 또 NoSQL을 들고 왔을 것이란 생각이 드네. 어쨌든, 이 부분은 확실히 내가 졌다.) |
| 면접관 | 댓글 기능 이야기를 해봅시다. 보통 포스트를 보는 페이지에 접근하면 페이지 아랫 부분에서 댓글들을 볼 수 있습니다. 면접자 분은 포스트와 댓글을 동시에 가져오도록 할 건가요, 아니면 포스트를 먼저 가져온 다음에 스크롤을 내리는 이벤트가 발생할 때 댓글을 가져오게 할 건가요? |
| ChatGPT | 저라면 포스트와 댓글을 동시에 가져오는 방안을 택하겠습니다. 이 접근방식은 몇가지 이득이 있습니다. - 사용자 경험 포스트와 코멘트를 동시에 가져온다는 것은 페이지 로드가 끝나자마자 유저는 모든 컨텐츠를 볼 수 있다는 의미입니다. 이는 더 좋은 사용자 경험을 만들고, 사용자가 대기 시간이 적다고 느끼게 만듭니다. - 성능 포스트와 코멘트를 한꺼번에 가져오는 용도의 API를 하나 만드는 것으로 서버와의 round-trip 횟수를 줄일 수 있습니다. 따라서 웹사이트의 성능도 좋아지고, 서버의 부하도 줄어듭니다. - 코드 복잡성 포스트와 코멘트를 하나의 호출로 처리함으로써 필요한 API 호출의 수를 줄이고, 코드를 단순하게 만들 수 있습니다. 유지보수와 디버깅도 더 편해지겠죠. 그러나 이러한 접근이 항상 옳은 것은 아닙니다. 예를 들어, 포스트에 달린 댓글의 수가 매우 크다면, 한번에 가져오는 동작은 페이지 로딩을 느려지게 만들고, 대역폭도 더 많이 사용하겠죠. 그러한 경우에는 포스트를 먼저 가져오고 스크롤 다운이 발생했을 때 댓글을 가져오도록 하는 것이 더 적절합니다. 이런 방식은 댓글을 lazy loading 하여 초기 페이지 로드 시간을 더 빠르게 만듭니다. 결론을 말하자면, 소프트웨어 개발자로서 저는 프로젝트의 특정 요구사항과 조건을 면밀히 분석하여 제일 맞는 방안을 택할 것입니다. 이하생략 |
| 나 | (나는 이 때 "lazy loading(따로 가져오는 방법)"을 택했었다. 이 친구는 효율성을 근거로 한꺼번에 가져오는 것을 대답했으니 나와는 정 반대라고 할 수 있는데, ChatGPT의 방식은 올드하지만 동시에 잘 먹히는 방식이기도 하다. 말미에 덧붙인 것처럼 상황에 따라 다르긴 하니.. 결론적으로는 나와 같은 대답이라고 봐도 될 것도 같다.) |
| 면접관 | 좋아요. 댓글이 너무 크다면 어떤 전략을 쓸 건가요? 보통은 두 가지가 있죠, 페이징과 인피니트 스크롤. 어떤 걸 사용할 건가요? |
| ChatGPT | 댓글이 너무 방대하다면 페이징 전략을 쓸 것 같네요. 페이징은 댓글 중 딱 어느 일부분만 가져오기에 필요한 데이터가 전송되고 처리되는 시간을 줄일 수 있습니다. 이 방식은 성능을 향상시키고, 대역폭 사용도 줄이면서, 어플리케이션의 메모리 사용량도 절감할 수 있습니다. 페이징 전략을 이용할 경우, 저는 일정한 수의 댓글만을 가져와 (예 : 페이지당 10개) 유저에게 페이지를 이동할 수 있는 네비게이션 버튼(예 : 이전, 다음)을 제공하겠습니다. 이 방법은 유저가 댓글을 쉽게 탐색할 수 있게 하고 전체 댓글 수가 몇 개인지 깔끔하게 알려줄 수 있습니다. 반면, 인피니트 스크롤은 페이지를 스크롤 다운할 때 새 댓글을 불러오는 방법이기에 네비게이션 버튼을 분리할 필요가 없습니다. 이 방법은 자연스럽고 방해 없는 사용자 경험을 제공하지만, 댓긍를 더 불러오고 처리할 때마다 성능이 느려질 수 있습니다. 또한, 인피니트 스크롤은 원하는 코멘트를 찾으려면 스크롤을 내려야 하므로 사용자가 어려워 할 수 있습니다. 결론은, 페이징 전략이 성능과 사용자 경험 양쪽의 균형을 가지고 있으며, 구현도 간편하고 유지보수하기도 쉽기에 저는 페이징 전략을 택하겠습니다. |
| 나 | (난 이전 대답에서 lazy loading을 택해서 그런가, 나였으면 인피니트 스크롤을 썼을 것 같은데 이 친구는 페이징을 골랐다. 다시 생각해보니 lazy loading이라고 해서 꼭 인피니트 스크롤일 필요는 없네? 허점을 찔린 기분. 어쨌든 답변은 다 이치에 맞다.) |
| 면접관 | NoSQL을 이 프로젝트에 사용할 것이라 말씀하셨는데요, NoSQL로는 페이징 전략을 어떻게 구현할 수 있나요? |
| ChatGPT | 몇 가지 전략이 가능합니다. 1. Skip-Limit : 이 방식은 db에서 값을 가져올 때 쿼리에 "skip"과 "limit"을 사용하는 방식입니다. 예를 들어, 첫 번째 10개의 댓글을 가져오고 싶다면 limit 10에 skip 0을, 그 다음 댓글을 가져오고 싶다면 limit 10에 skip 10을 주는 식입니다. 2. Cursor-Based 페이징 : 이 방법은 db 안의 특정 도큐먼트 식별자로 사용되는 커서를 사용합니다. 커서는 보통 데이터의 정렬 순서에 기반하여 생성됩니다. 예를 들어, 댓글의 생성 시간을 정렬 순서로 사용하여 댓글을 chunk 단위로 가져오도록 하는 전략을 쓸 수 있습니다. 3. Offsetting Document IDs : 이 방법은 배치를 이용해 마지막으로 가져온 도큐먼트의 id들을 추적하는 것입니다. 이 마지막 도큐먼트 id들은 다음 배치의 시작점이 됩니다. 예를 들어, 쿼리를 이용하여 모든 댓글을 가져온 다음 원하는 순서대로 정렬해 첫 10개의 댓글을 가져올 수 있습니다. 이 댓글의 id들을 저장하여 다음 쿼리 수행 때 사용할 수 있습니다. 결국 이것도 케바케입니다. 예를 들어, 데이터들이 특정 방법으로 정렬되어야 한다면 전 커서 기반 페이징을 사용할 것이고, 데이터가 주기적으로 업데이트 되지 않고 순서가 별로 중요하지 않다면 더 직관적이고 효율적인 offsetting 방식을 사용할 것입니다. |
| 나 | (이건 그냥 순수하게 내가 NoSQL은 페이징을 어떻게 구현하는지 몰라서.. 3번은 잘 번역됐는지도 모르겠다. 나중에 찾아봐야지) |
| 면접관 | 이미지 업로드 기능을 넣는다면 어떻게 하실건가요? |
| ChatGPT | 아래와 같은 순서로 작업할 것입니다. 1. 이미지 업로드를 위한 서버 엔드포인트를 만듭니다. 이 엔드포인트는 전송된 이미지 파일을 핸들링하고, 유효한지 검사하며, db나 AWS S3 같은 클라우드 기반 스토리지에 저장합니다. 2. 클라이언트 쪽에서 이미지 업로드를 구현합니다. form을 이용하여 유저가 이미지를 선택하여 업로드 할 수 있도록 합니다. 3. DB나 클라우드 스토리지에 이미지를 저장합니다. 서버는 유효성 검증이 끝난 이미지를 DB나 클라우드 스토리지에 적재하며, 그 후에 클라이언트에 이미지가 올라간 URL을 응답합니다. 4. 이미지를 포스트에 표시합니다. 이미지를 저장한 후, 저는 블로그 포스트에서 이미지를 표시하는 기능을 넣을 것입니다. 클라이언트 쪽 코드를 변경해 서버로부터 이미지를 가져와 적절한 곳에서 표시하도록 하겠죠. 5. 이미지의 크기와 규격을 최적화할 것입니다. 사용자 경험을 최적화하기 위해 저는 db나 클라우드 스토리지에 이미지를 저장하기 전에 이미지의 크기나 형식을 최적화할 것입니다. 예를 들어 리사이징하거나, 압축하거나, 웹에 알맞은 형식으로 전환하는 작업들이 되겠죠. 이미지 업로드 기능을 개인 블로그에 추가하기 위해선 서버와 클라이언트 양쪽의 로직이 필요하며, 어떻게 이미지를 저장하고 최적화할 지에 대한 전략도 고려해야 합니다. |
| 나 | (정석적인 대답. 리사이징이나 압축은 내가 저 당시에 대답할 수 있었을 지는 확신이 서지 않는다.) |
| 면접관 | HTTP가 무엇인지 간단 요약해볼 수 있나요? |
| ChatGPT | HTTP(Hypertext Transfer Protocol)은 인터넷을 통해 데이터를 전송하는 프로토콜입니다. 어쩌고저쩌고 |
| 면접관 | 프로토콜이 뭔가요 그럼? 이것도 설명해주실 수 있나요? |
| ChatGPT | 프로토콜은 서로 다른 시스템간 커뮤니케이션을 도입하기 위한 규칙과 규격의 집합입니다. 프로토콜은 데이터가 어떤 형태어야 하고, 어떻게 전송되어야 하고, 기기 간에 어떻게 처리되어야 하는지를 정의합니다. 이하 생략 |
| 면접관 | 다른 프로토콜도 한번 예를 들어볼까요? 간단하게만 설명해주세요. |
| ChatGPT | 다른 프로토콜 종류는 이런 게 있습니다. - TCP - IP - DNS - FTP - SMTP - DHCP - SSH - TLS/SSL |
| 나 | (나는 이 질문에 Application 계층에 속하는 프로토콜만 예로 들었는데, 이 친구는 Transport 계층까지 포함해서 대답을 하고 있다. 뭐... 나라면 이것까지 포함하지 않았을 것 같지만, 자세히 생각해보면 백엔드 스택은 Application 외에도 그 아래 계층도 당연히 고려를 하기 마련이니 이게 더 맞는 답일 수도 있겠다는 생각이 든다.) |
| 면접관 | 완벽합니다. 어떤 팀에서 일하고 싶으세요? |
| ChatGPT | 열린 소통과 협업, 그리고 지속적인 학습을 중요시 하는 팀에서 일하고 싶습니다. 혁신을 장려하고, 다양성을 축복하며, 개개인의 기여가 제대로 인식되고 평가받는 업무 환경을 제공할 수 있는 팀이요. 또한 품질을 중요시하며 디테일에 주의를 기울이고, 사업과 고객의 요구에 맞는 하이 퀄리티 소프트웨어 솔루션을 만들어내는 데 전념하는 팀이면 좋겠습니다. |
| 나 | (난 이때 그냥 "전 백엔드 개발자니까 트래픽 많은 팀에서 일하고 싶습니다" 라고 말 했었는데.. 말 꾸며내기는 문과 출신인 나보다도 잘 하는 듯) |
종합적인 평가
적은 정보로도 내 개인적 경험을 잘 재현했다.
사실 정보가 너무 적었기에 통계적 찍어맞추기였겠지만, 그럼에도 개인사에 관한 답변은 상당히 나와 유사했다. 컴공/일본어의 관계라든가, 학부생 시절 했던 프로젝트 등... 더 많은 정보를 제공했으면 더더욱 그럴싸했을 것 같은데, 결국 내 행동들이 AI 입장에선 예측하기 쉬운 것들이라는 점은 약간 소름을 돋게 만든다.
당연히 지식 위주의 대답은 AI의 압승이다.
매우 매우 당연한 이야기다. 실제로 이 면접을 행하면서 "뭐야 나한테 스마트폰 열람 권한 주고 면접 들어오게 한 거랑 별반 다를 거 없는거 아님?" 이란 생각을 했다. 이 부분은 내가 이길 수가 없었다. 특히 후반부의 프로토콜 관련 대답들은 오히려 내게 다른 인사이트를 던져줄 정도로 깊이 있는 대답이었다.
면접 연습에 도움이 될 지도
종합해보면, ChatGPT로 내 과거 면접을 재현하는 것은 어느정도 성공이다. 상당 부분이 내가 했었던 대답/내가 할 것 같은 대답과 논조가 일치한다. 당연하게도 이를 이용하여 면접을 대리를 보는 건 안 될 일이고 (실제로 쓰다 걸린 사례가 있다고도 들었음) 대신 모의면접을 검토해보는 용도로는 꽤 쓸만할 것 같다는 생각이 들었다.
먼 미래에는 날 복제할 수 있을까
나름 재미있는 경험이었다. 불과 텍스트 몇 줄만으로 AI에게서 나와의 동질감을 느낄 수 있다니. 기술이 더 발전하고, 내 정보를 더 많이 학습시킬 수 있다면 정말 복제된 제로벨을 가질 수 있게 될 지도 모르겠다. 물론 그 시기가 임박하면 대중들이 마냥 호의적으로만 보진 않을 것 같지만.. 앞으로의 ChatGPT의 향방이 기대된다.