[오만개] 비전공자 취준생의 싸이월드 클론 개발 | 김현정님 인터뷰

“비전공자 취준생이 싸이월드 클론을 개발했다고요?” 

OKKY 운영진이 내부에서 현정 님의 글을 처음 접했을 때, 솔직히 이런 생각이 먼저 들었다. 

오늘의 주인공 현정님은 흔히 말하는 ‘전형적인 개발자 코스’를 밟아온 사람이 아니다. 네트워크 보안을 전공했다가 체육으로 방향을 틀었고, 다시 개발로 돌아왔다. 프론트엔드로 2년을 일한 뒤에는 백엔드로 전향해 기본기부터 다시 파고들었다. 이론과 실전의 간극을 어떻게 메웠는지, AI를 어떻게 ‘과외 선생님’처럼 활용했는지, 그리고 돌아 돌아 온 길 끝에서 어떤 태도로 개발을 다시 붙잡았는지.

신입 백엔드 개발자로 첫발을 내딛는 김현정 님의 이야기를 들여다본다.

Q. 안녕하세요! 간단히 자기소개 부탁드립니다. 

안녕하세요. 신입 백엔드 개발자로 취업 준비 중인 김현정입니다. 저는 이력이 조금 독특(?)한데요. 특성화고에서 네트워크 보안을 전공했는데, 갑자기 체육에 꽂혀서 대학은 체육 쪽으로 갔습니다. 결국 돌고 돌아 다시 컴퓨터 앞에 앉았네요. 한창 개발자 붐이 일던 코로나 시기에 2년 정도 프론트엔드 개발자로 일했었어요.

최근에는 ‘자바의 정석’ 저자이신 남궁 성 강사님의 백엔드 부트캠프를 갓 수료했고, 지금은 스프링 부트로 저만의 싸이월드 클론 프로젝트를 만들고 있습니다. 강사님이 워낙 기본기를 강조하셔서, 남궁 성 님의 자바 강의, 김영한 님의 스프링 강의, CS 책을 '뿌리부터 다시 판다'는 마음으로 복습 중이에요. 기본기가 튼튼한, '일 잘하는' 신입이 되려고 매일 노력하고 있습니다! 

대학시절 체육을 전공했던 현정님 

Q. 프론트엔드에서 백엔드로 전향하신 것 같은데, 그 변화의 이유도 궁금해요.

솔직히 처음에는 백엔드가 정확히 어떤 일을 하는지조차 잘 몰랐어요. 눈에 바로 보이고 이해하기 쉬운 건 프론트엔드였고, 그래서 자연스럽게 프론트엔드부터 시작하게 됐습니다.그런데 국비 학원에서 강사님이 PHP를 맛보기로 보여주신 적이 있었는데, 그때 처음으로 ‘아, 사이트가 이렇게 살아 움직이는 거구나!’ 하는 느낌이 들었어요. 당시에는 수업 따라가는 것만으로도 벅차서 백엔드를 깊게 생각하진 못했지만, 언젠가는 사용자와 상호작용하는 ‘진짜 서비스’를 만들어보고 싶다는 생각이 마음 한편에 자리 잡았습니다. 그리고… 결정적으로는 제 친한 친구의 영향이 컸어요. 그 친구가 백엔드 개발자인데, 서버를 다루고 데이터를 관리하는 모습을 보는데 너무 멋있어 보이더라고요. 그런 모습을 보면서 ‘나도 저런 개발을 해보고 싶다’는 마음이 들었고, 그게 결국 백엔드로 방향을 전환하게 된 이유였습니다.

국비지원 학원에서 취업용 포트폴리오를 제작하고 있는 화면 

Q. 이번에 특별히 ‘싸이월드 프로젝트’를 선택한 이유가 있을까요?

제 인생에서 가장 재미있었던 시절은 2010년, 초등학교 6학년 때였어요. 그때의 기억은 지금도 또렷합니다. 학교가 끝나면 가장 먼저 네이트온을 켜고, 친구들 미니홈피를 구경하던 일상. 얼짱·인소 문화에 푹 빠져 있던 시절이기도 했죠. 사실 2020년에 웹 개발 국비지원 과정을 들을 때도 싸이월드를 꼭 만들어보고 싶었습니다. 하지만 당시에는 강사님이 인터랙티브한 사이트를 원하셔서 아쉽게도 실현하지 못했어요. 

그때의 아쉬움이 계속 마음 한편에 남아 있었습니다. 그래서 이번에 백엔드 부트캠프를 시작하면서부터 계속 생각했습니다.‘이번엔 진짜 꼭 싸이월드를 만들어야겠다!’ 물론 제 추억이 깊이 담긴 서비스이기 때문도 있지만, 동시에 입문 개발자가 연습하기에 정말 좋은 프로젝트라고 판단했어요. 단순 CRUD에서 끝나는 게 아니라, 일촌·방명록·사진첩 등 SNS의 핵심 기능을 모두 구현해볼 수 있으니까요. 이러한 이유들 때문에 이번에는 망설임 없이 싸이월드 프로젝트를 선택하게 됐습니다.

싸이월드 홈페이지 예시 (출처: 중앙일보) 

Q. 싸이월드 클론을 구현하면서 가장 어려웠던 기술적 문제는 뭐였나요?

솔직히 말하면… 매 순간이 새로운 난관이었다고 해도 과언이 아니에요. 가장 처음 맞닥뜨린 어려움은 ERD 설계였습니다. 최대한 “이상적인 방식”으로 만들고 싶어서, 실무에서는 어떤 컬럼과 타입을 사용하는지 하나하나 궁금해졌고, 제가 하고 있는 방식이 맞는지 계속 의문이 들었습니다. ERD를 완성한 뒤 API 설계를 하고, 백엔드 개발자인 친구에게 피드백을 부탁했는데 “이걸 어떤 생각으로 설계한 거야?”라고 묻더라고요. 제가 “그냥 학원에서 다들 이렇게 하길래…”라고 답했다가 크게 혼났습니다. 

API도 “전혀 RESTful하지 않다”는 피드백을 받았고, 그때 처음으로 ‘RESTful API’라는 개념을 제대로 찾아보기 시작했는데 이해하는 데 정말 애를 먹었어요. 그리고 본격적으로 개발에 들어가면서는 난이도가 더 올라갔습니다. 수많은 어노테이션, Spring Security 설정, 폴더 구조를 어떻게 잡아야 하는지, 어떤 방식으로 설계해야 하는지 등 생각해야 할 게 한 두 가지가 아니었어요. 

그래서 가장 어려웠던 기술적 문제를 하나만 꼽자면, 결국 스프링부트를 제대로 ‘사용하는 법’을 이해하는 과정이 아니었나 싶습니다. 프레임워크가 이미 제시하고 있는 구조와 철학을 따르면서 개발한다는 것이 처음에는 굉장히 낯설고 어렵게 느껴졌습니다.

개발 작업을 진행중인 현정님

Q. “부트캠프에서 배운 내용을 실전에서 써 먹는다는 게 쉽지 않았을 것 같아요.

맞아요. 처음부터 6개월이라는 시간이 충분하지 않다는 건 알고 시작했지만, 막상 실제 프로젝트를 하려니 예상보다 훨씬 어렵더라고요. 부트캠프에서는 주로 자바 이론 중심으로 공부했는데, 프로젝트 단계에 와보니 딱 ABC를 막 배운 수준에서 갑자기 문장을 써야 하는 기분이었어요. 머리가 딱 막히는 느낌이랄까요. 스프링부트는 또 완전히 다른 세계에 들어온 느낌이었어요. CRUD만 만들었다 지웠다를 반복한 게 몇 번은 되는 것 같아요. 같은 강의를 계속 돌려보다 보니 어느 순간 흐름이 조금씩 보이기 시작했고, 그때부터야 비로소 손에 익기 시작했습니다. 이 과정에서 제 개발자 친구와 Gemini의 도움도 정말 컸습니다. 혼자서는 넘기 어려웠던 부분들을 질문하고, 다시 시도하고, 또 확인하면서 조금씩 실전 감각을 만들어갈 수 있었어요.

Q. AI 도구를 활용하면서, 어떤 부분에서 가장 큰 도움을 받으셨나요?

가장 큰 도움은 시간 단축입니다. 예전에는 에러가 뜨면 원인을 찾겠다고 구글링만 수십 페이지 넘게 뒤지고, 스택오버플로우 글을 번역해가며 해결하곤 했어요. 그런데 AI를 사용하면서 그런 ‘삽질 시간’이 정말 많이 줄었습니다. 솔직히 말씀드리자면, AI가 없었다면 이번 싸이월드 프로젝트는 여기까지 오지 못했을 거예요. 이번 프로젝트를 진행하면서 제 이론 부족과 실전 경험 부족을 여러 번 마주하게 됐고, 그때마다 눈앞에 큰 벽이 있는 것처럼 느껴졌습니다. 

그럴 때마다 저는 Gemini를 1:1 과외 선생님처럼 활용했습니다. 모르면 묻고, 또 묻고, 거의 매일 사용 한도를 넘길 만큼 질문을 쏟아냈습니다. 컨트롤러, DTO, 서비스, 레포지토리… 이전에는 각각 따로따로 존재하는 조각 같은 개념들이었는데, 여러 도메인을 만들고 실제로 코드를 짜다 보니 ‘왜 계층을 나누는지, 왜 역할을 분리해야 하는지’에 대한 감이 잡혔어요. 저에게 AI가 가장 크게 준 도움은 바로 그 지점이라고 생각합니다. 이론과 실전 사이의 간극을 메우고, 실제 프로젝트에 첫 발을 내딛게 해준 것이요.

싸이월드 주요 기능을 구현하기 위한 데이터베이스 설계 구조도 

Q. 공부할 때 주로 어떤 방식으로 배우셨나요? 

부트캠프에 들어가기 전에 과정 흐름을 따라가고 싶어서 자바의 정석 유튜브 강의를 먼저 봤습니다. 

특히 객체지향 파트는 이해가 어려워 여러 번 반복해서 시청했어요.부트캠프가 시작된 후에는 강의보다 책이 더 잘 맞는다는 걸 깨달았습니다. 제가 이해하는 속도가 느린 편이라 직접 읽고 곱씹는 시간이 꼭 필요하더라고요. 가장 도움이 됐던 건 발표 스터디였습니다. 주 2회씩 배운 내용을 정리해 발표해야 했기 때문에, 억지로라도 제 언어로 완전히 소화해내야 했습니다. 여러 블로그를 참고하거나 ChatGPT에게 묻기도 했지만, 혹시 잘못된 정보를 전달할까봐 결국 공식 문서를 찾아가며 설명을 뒷받침할 근거를 마련했어요.

CS 스터디에서도 서로 질문하고 답하면서, 핵심 개념을 제 말로 정확히 풀어내는 연습을 했던 것이 큰 도움이 됐습니다. 예전에 회사에 다닐 때 정처기 필기를 따긴 했지만 그때는 개념을 잘 모른 채 외우기만 했거든요. 이번에 다시 책을 찬찬히 읽어보니 ‘아, 이게 그때 그거였구나!’ 하는 순간들이 많았습니다. 스프링은 김영한 님 강의를 반복해서 들으며 큰 그림을 잡았고, 최근에는 Gemini도 적극 활용하고 있습니다. 테스트 코드 연습용 예제를 만들어달라고 해서 TDD를 연습하거나, 제 코드를 보여주고 더 나은 방법을 물어보면서 시야를 넓히는 식으로 공부하고 있습니다. 

Q. 실제 구현 과정에서 깨달음이 있던 순간이 있었나요? 

네, 여러 순간이 있었지만 하나를 꼽자면 일촌평 기능을 구현할 때였습니다. 

이전까지는 강의를 볼 때 컨트롤러·서비스·레포지토리를 왜 나누는지, 그리고 서비스와 서비스Impl을 왜 굳이 인터페이스로 분리하는지 사실 크게 와닿지 않았어요. 그냥 “원래 그렇게 하니까 그렇게 하는가 보다” 정도였죠. 그런데 싸이월드 구조상, 일촌평(Board) 목록을 가져올 때 글쓴이의 일촌명(Ilchon)도 함께 가져와야 했습니다. 처음엔 단순하게 “그럼 BoardService에서 IlchonRepository를 주입받아서 쓰면 되겠네?”라고 생각했는데, 구현을 하다 보니 코드가 너무 지저분해 보이더라고요.

싸이월드 회원 기능의 비즈니스 로직이 담긴 계층별 코드 (회원가입 부분) 

그리고 문득 이런 생각이 들었습니다. ‘일촌 로직이 바뀌면 게시판 서비스까지 같이 수정해야 하는데… 이게 말로만 듣던 결합도가 높은 코드 아닌가?’ 그 순간 예전에 들었던 남궁성 강사님의 비유가 떠올랐어요. 인터페이스를 TV와 리모컨에 비유하는 설명이었는데, 딱 그 상황이었습니다. BoardService는 TV(IlchonServiceImpl)를 직접 알 필요 없이, 리모컨(IlchonService)만 알면 되었던 거죠. 그제서야 비로소 이해했습니다. “아, 그래서 인터페이스로 분리하는구나. 그래서 유지보수가 쉬워지는구나.” 자바에서 문법으로만 배웠던 추상화와 다형성이 실제로 어떤 식으로 쓰이는지 몸으로 느끼게 된, 제게는 꽤 큰 깨달음의 순간이었습니다.

Q. 백엔드로서 특히 신경 쓴 부분은 무엇인가요?

ERD 설계에 가장 많은 시간을 쏟았습니다.‘설계’만큼은 논리와 사고력으로 승부 보는 작업이라고 느꼈기 때문입니다.  “테이블을 어떻게 나눌까?”라는 단순한 질문에서부터 시작해 “이력 관리 컬럼을 전부 넣어야 할까?”, “PK는 INT로 충분할까, 아니면 BIGINT로 가야 할까?” 같은 선택들을 프로젝트 규모에 맞으면서도 이상적인 구조가 무엇인지 고민하며 진행했습니다. 특히 일촌 기능에서 시행착오가 많았습니다. 처음에는 ‘신청’과 ‘관계’를 하나의 Ilchon 테이블에서 모두 관리했는데, 유지보수 측면에서 문제가 생길 것 같아 신청(IlchonRequest)과 관계(Ilchon) 두 엔티티로 분리했습니다. 또 관계 테이블도 처음엔 한 줄 모델이었지만, 일촌 목록 조회 쿼리가

WHERE user_id = 1 OR friend_id = 1

처럼 OR 조건을 사용하게 되면서 성능이 떨어지는 걸 확인했습니다. 그래서 두 줄로 저장하는 양방향 모델로 재설계해 조회 효율을 개선했습니다. 일촌 기능뿐 아니라 전체적으로 API도 RESTful하지 못한 부분이 많아 현재 리팩토링을 진행 중입니다. 프로젝트 초기에 API를 설계할 때는 ‘행위 중심’과 ‘자원 중심’의 차이가 잘 이해되지 않았는데, 실제로 고쳐보니 이제야 눈에 들어오는 것 같습니다.

그리고 이런 대규모 수정이 진행되다 보니, 테스트 코드 작성에도 더욱 신경을 쓰고 있습니다. 리팩토링 과정에서 기존 기능이 깨지지 않도록 하는 안전망의 중요성을 많이 체감하고 있습니다.

회사에서 키우던 고양이가 낳은 귀여운 아기 고양이

Q. 인프라(AWS EC2, S3, CloudFront 등)까지 직접 세팅하셨던데, 그 과정에서 가장 기억에 남는 시행착오는?

처음 AWS에 들어갔을 때 정말 혼란스러웠습니다. 뭔가 잘못 건드리면 큰일 날 것 같고, 모든 게 어려워 보였거든요. 지금 생각하면 정말 단순한 문제였는데… 조금 부끄럽기도 합니다. 예를 들면, 첫 날 EC2 인스턴스를 미국 리전에 생성해놓고는 서울 리전에서만 찾고 있었던 적이 있습니다. 결국 “서버가 사라졌다!”고 한참 헤매다 삭제하고 서울 리전에 다시 만들었습니다. 배포 후에도 난리가 났습니다. 스터디 카페에서 테스트를 하는데 갑자기 서버가 계속 터지는 거예요. 분명 방금까지 집에서는 멀쩡했는데! 거의 한 시간은 허비한 것 같습니다. 알고 보니 집과 스터디 카페의 IP가 달라서 생긴 문제였고, 결국 인바운드 규칙에 IP를 추가해서 해결했습니다.

설정 파일 문제도 컸습니다. 처음엔 배포 서버가 뻑날까봐 겁이 나서 로컬 테스트도 제대로 못 했어요. 코드 한 줄 고칠 때마다 다시 EC2에 업로드해서 배포된 사이트에서 직접 확인하는 삽질을 반복했습니다. 심지어 application.properties 하나에 로컬/배포 설정을 모두 적어두고 주석을 켰다 껐다 하다가, 나중에서야 스프링 프로파일로 환경을 분리할 수 있다는 걸 알았습니다. 지금도 그때를 생각하면 식은땀이 납니다.

가장 심장이 내려앉았던 순간은 바로 최근 OKKY에 글을 올린 직후 겪은 프리 티어 한도 초과 사건이었습니다. 감사하게도 트래픽이 많이 몰렸는데, 며칠 뒤 갑자기 사이트가 접속이 안 되길래 메일을 확인해보니 계정이 정지된 상태더라고요. 혹시 요금 폭탄이 나왔나 싶어 심장이 엄청 뛰었습니다. RDS 로그를 보니, 불과 1분 동안 한 명이 수백 번 요청을 보낸 비정상 트래픽이 있었고(전체 트래픽은 약 30만 건), 그 영향으로 한도를 초과한 상황이었습니다. 전혀 생각하지 못한 부분이었고, 준비 없이 배포하는 것이 얼마나 위험한지 뼈저리게 달았습니다.

오히려 지금은 그 공격(?)을 보내신 분께 감사한 마음도 들어요. 덕분에 앞으로 해결해야 할 아주 좋은 숙제가 생겼습니다.

프론트엔드 개발자로 근무 당시 카페에서 공부하던 화면 

Q. 이번 프로젝트를 통해 다음엔 어떤 개발에 도전해보고 싶으신가요? 

이번엔 제가 하고 싶었던 걸 만들었으니 다음에는 기업에서 원하는 걸 만들어 보고 싶어요. 한 도메인을 콕 집어서 거기에 맞는 걸 개발해보고 싶습니다. 아니면 부트캠프에서 AI 프로젝트를 했었거든요. 챗봇을 만드는 거였는데 꽤 흥미로웠어서 AI를 접목한 프로젝트도 해보고 싶어요. 사용자 맞춤형 사이트 같은 거요.

Q. 앞으로 어떤 개발자를 꿈꾸고 있나요?

저는 기본기가 탄탄한 개발자가 되고 싶습니다. 흔한 말처럼 들릴 수 있지만, 첫 직장에서 만난 선임분들을 보면서 진심으로 느낀 목표입니다. 그분들이 어떤 방식으로 공부하셨는지는 정확히 알지 못했지만, 문제를 이해하고 해결하는 과정이 너무 자연스럽고 효율적이어서 “일을 잘한다는 건 이런 모습이구나”를 몸소 느낄 수 있었습니다. 저도 그런 개발자로 성장하고 싶습니다.

그러기 위해서는 기본기를 단단히 다진 뒤 새로운 기술의 변화 흐름을 꾸준히 따라가는 것이 중요하다고 생각합니다. 특히 요즘은 AI가 빠르게 발전하면서 개발자의 역할 자체가 흔들린다는 말도 많지만, 오히려 이럴 때일수록 기본기가 탄탄한 사람이 AI 시대에도 ‘필요한 사람’이 된다고 믿습니다. AI가 결과물을 만들어낼 수는 있지만, 그 결과를 판단하고 상황에 맞게 적용하는 일은 결국 사람이 해야 하니까요.

개발 공부를 하면서 인프런 CTO 향로님의 ‘기억보단 기록을’ 블로그를 자주 보는데, 그중 “개발자에겐, 그저 각자의 장점과 단점이 있을 뿐이다. 중요한 것은 어떤 상황에 놓여 있느냐이다.” 라는 문장이 기억에 남습니다. 저는 성향이 활발한 편이라 한동안 “과연 개발자가 나와 맞는 직업일까?”라는 고민도 했었는데, 그 글을 보고 방향성을 다시 잡을 수 있었습니다.

그래서 제 최종 목표는 기술만 아는 개발자가 아니라, ‘나의 성향’과 ‘우리 팀·회사 상황’을 정확히 이해하고 그 안에서 최적의 기술적 판단을 내릴 수 있는 개발자가 되는 것입니다. 탄탄한 기본기를 기반으로 현재 상황을 분석하고, 왜 이 기술이 필요한지 팀을 설득하며, 더 나은 답을 찾아가는 사람으로 성장하고 싶습니다.

마지막으로 제가 좋아하는 문장이 하나 있습니다. 

“어설프게 뛸 바엔 멋지게 걷자.” 

가끔 마음이 급해질 때 스스로를 다잡는 말입니다. 저는 앞으로도 조급함 대신 꾸준함을 선택하며, ‘멋지게 걷는 개발자’로 성장하고 싶습니다. 

열일 하는 현정님의 코딩 화면 

Q. 마지막으로 비전공자나 개발을 막 시작한 분들에게 조언이 있을까요?

저는 무엇보다 ‘본인에게 맞는 공부법을 찾는 것’이 가장 중요하다고 생각합니다. 

개발 공부에는 ‘이론부터 파는 이론파’와 ‘일단 부딪혀보는 실전파’가 있다고 하는데, 저는 완벽한 실전파였어요. 처음 국비지원 학원을 다닐 때는 정말 모든 게 외계어처럼 들렸고, 사실 고등학교 때도 간단한 반복문조차 이해하지 못했던 사람이었습니다. 저는 영어 단어를 하나씩 외우기보다 문장을 통째로 외워서 감을 익히는 스타일인데, 개발도 똑같더라고요. 첫 회사에 가서야 비로소 “배움이 시작됐다”고 말할 수 있을 정도로, 전체 흐름이 잡히고 나니까 이론 공부가 훨씬 더 쉽고 재미있어졌습니다. 그래서 저와 비슷한 유형이라면, 기본적인 문법만 익힌 뒤 너무 고민하지 말고 클론 코딩이든, 강의 따라 치기든, 흥미가 생기는 무언가를 바로 만들어보라고 말하고 싶습니다. 코드와 먼저 친해지는 게 정말 중요하니까요.

그리고 조금 뜬금없지만… 펜을 쥐어보는 것도 큰 도움이 됐어요. 키보드 앞에 앉아 있으면 일단 뭐라도 타이핑해버리게 되는데, 초보일수록 ‘생각하는 시간’이 훨씬 많이 필요하다고 느꼈거든요. 내가 만들 기능, 필요한 로직, 흐름 같은 것들을 노트에 직접 적어 내려가다 보면 생각이 자연스럽게 정리됩니다. 제 성향에도 잘 맞았지만, 많은 분들에게도 도움이 될 거라고 생각해요.

마지막으로, CS 공부는 정말 꼭 필요합니다. 갑자기 모르는 한국어 단어가 나와도 문맥으로 어느 정도 추론할 수 있는 건 우리가 이미 한국어에 대한 배경지식이 있기 때문이잖아요. 개발에서는 그 ‘배경지식’이 바로 CS입니다. 당장 코드가 돌아가게 만드는 게 급해 보여도, 결국 기본기가 탄탄해야 더 멀리 갈 수 있습니다. 제가 좋아하는 문구가 하나 있는데요. 클리앙 커뮤니티에서 ‘빵집 개발자 양병규님이 쓴 글’에 나오는 비유입니다. “한강 바닥에서 벽돌을 쌓는데, 물이 탁해서 보이지도 않고 한 장 더 얹어도 티가 안 나니까 결국 포기한다. 그런데 포기하지 않고 1년, 2년… 계속 쌓다 보면 그 벽돌은 언젠가 반드시 수면 위로 올라온다.” 수심이 사람마다 다를 수는 있지만, 멈추지 않고 계속 쌓으면 언젠가는 꼭 수면 위로 올라옵니다. 

느려 보여도 괜찮고, 돌아가도 괜찮아요. 포기하지 말고, 천천히라도 계속 나아가셨으면 좋겠습니다. 저도 그렇게 하고 있으니까요.

세상의 모든 개발자를 응원하는 현정님 

편집자의 말:

“새로운 기술을 익히는 일은 종종 낯설고, 때로는 두렵기까지 하다. 

정답 없는 길 위에서도 끝내 본인이 가고 싶은 방향을 찾아낸 김현정 님의 이야기는, 개발이라는 직업의 본질을 다시 떠올리게 한다. 배우고, 만들고, 다시 고치며 한 뼘씩 성장해가는 과정. 그 여정의 가치를 믿는 모든 분들께 이 인터뷰가 작은 응원이 되기를 바란다. 

OKKY에서는 개발자들의 진솔한 이야기를 계속 발굴하고 있습니다.
도움이 되거나 참고할 만한 사연을 가진 개발자 분 주변에 계시면 제보 부탁드려요. (자기추천도 좋습니다~)
꼭 들려주고 싶은 이야기가 있는 개발자라면 남녀노소 누구든 좋습니다.
제보는 info@okky.kr 로 부탁드려요!