티스토리 뷰
1년~2년 차 주니어 기준 JAVA 백엔드 개발자 기술면접을 보며, 받았던 질문들을 정리해 보았습니다.
JAVA 백엔드 취업을 준비 중인 분들에게 도움이 되었으면 좋겠습니다.
해당 글들은 제 뇌, Chat GPT, 구글링(망나니개발자님 등)을 참고하여 작성되었습니다.
기술 면접 23년 ver
AOP란?
관점지향 프로그래밍을 의미합니다.
관점지향이란 로직을 핵심적인 관점, 부가적인 관점에서 보며 핵심적/부가적 관점으로 모듈화 하겠다는 것을 의미하며
핵심적 관점으론 비즈니스 로직, 부가적 관점에선 핵심로직을 실행하기 위한 DB연결, 로깅, 파일 입출력 등이 있습니다.
* 모듈화: 공통된 로직이나, 기능을 하나의 단위로 묶는 것
IOC에 대해 설명해 보세요.
제어의 역전이라고 하며, 객체생성, 의존성 관리, 생명주기 관리 등을 스프링 컨테이너가 대신 처리해 주는 디자인 패턴입니다.
애플리케이션의 제어 흐름을 개발자가 아닌 애플리케이션이 담당하여 객체 간의 결합도를 낮추고 유연한 애플리케이션을 구현할 수 있게 합니다.
스프링 IOC는 ApplicationContext를 통해 구현됩니다. ApplicationContext는 스프링 컨테이너의 인스턴스이며,
빈을 생성하고, 관리하며, 빈 간의 의존성과 생명주기를 관리합니다.
스프링 컨테이너에 대해 설명해 보세요.
스프링 프레임워크의 핵심적인 기능 중 하나로, 객체를 생성하고 관리하는 컨테이너를 말합니다.
스프링 컨테이너는 개발자가 직접 객체를 생성하고 관리하지 않아도 되므로, 객체 간의 의존성 관리와 같은 많은
부분을 스프링 프레임워크에 위임할 수 있습니다.
스프링컨테이너는 객체 생성과 관리를 위해 의존성 주입, 라이프사이클 관리 등을 자동으로 처리할 수 있습니다.
* IOC 컨테이너와 스프링 컨테이너는 모두 객체 생성 및 관리를 담당하는 컨테이너로서 기능적으로 매우 유사하지만, 스프링 컨테이너는 스프링 프레임워크에서 제공하는 다양한 기능을 추가로 제공한다는 점에서 차이가 있습니다.
DI에 대해 설명해 보세요.
의존성 주입은 객체 지향프로그래밍에서 객체간의 의존성을 느슨하게 만들기 위한 디자인 패턴 중 하나입니다.
객체간의 결합도가 높아져서, 코드의 유지보수가 어려워지고 테스트하기가 어려워집니다.
이때 의존성 주입은 객체 간의 결합도를 줄이기 위한 방법 중 하나입니다.
의존성 주입을 사용하면 객체가 필요로 하는 다른 객체를 외부에서 생성하고 주입할 수 있습니다.
이렇게하면 직접적으로 다른 객체를 생성하거나, 가져오지 않아도 되므로, 객체 간의 결합도가 낮아져서 코드의 유지보수와 테스트가 용이합니다.
의존성이 낮으면 어떤 이점이 있나요?
의존성이 낮으면 변화에 강점이 있습니다. 즉 재사용성이 높은 코드가 되고, 객체 간 분리하여 테스트 코드 작성에 유리하며, 가독성이 높아집니다. 하지만 의존관계에서 주입할 객체를 계속해서 생성하고 소멸한다면 메모리 관리에서 부담이 됩니다. 그래서 스프링에선 Bean들을 기본적으로 싱글톤을 이용해 관리합니다.
의존성 주입의 방법에 대해 말해보세요.
의존성 주입은 크게 생성자 주입, 필드 주입, 수정자 주입이 있습니다.
스프링 부트에서 공식적으로 생성자 주입 사용에 대해 권고하고 있는데, 그 이유는 다음과 같습니다.
생성자 주입 사용시 순환참조를 방지할 수 있으며, 불변성을 유지할 수 있고, 테스트 코드에 유리합니다.
싱글톤
애플리케이션 전체에서 오직 하나의 인스턴스만을 생성하고, 이를 공유해서 사용하는 디자인 패턴입니다.
즉 여러 번 요청되어도 같은 인스턴스를 반환합니다.
스프링에서는 IoC(Inversion of Control) 컨테이너가 빈을 생성하고, 관리합니다. 기본적으로 빈은 스프링 컨테이너가 생성되면서 인스턴스가 하나만 생성되며, 이 인스턴스는 컨테이너가 종료될 때까지 유지됩니다.
싱글톤 패턴을 적용한 이유는 객체를 여러 번 생성하거나 소멸시키는 등의 불필요한 자원 낭비를 줄이고, 객체의 일관성을 유지하여 안정적인 애플리케이션을 구현하기 위함입니다.
빈
IOC컨테이너가 관리하는 객체를 말합니다.
객체를 빈으로 등록하면, 스프링 컨테이너가 해당 객체의 생명주기: 생성, 소멸등을 관리합니다.
스프링에서 빈은 싱글톤으로 생성되며 스프링 컨테이너가 종료될 때까지 유지됩니다. 따라서 애플리케이션 전체에 동일한 빈 인스턴스를 사용하게 됩니다.
인스턴스란?
객체가 메모리에 할당되었을 때 인스턴스라고 불린다.
Stack과 QUEUE에 대해 설명해 보세요.
스택: 라스트인 퍼스트아웃 구조로 (LIFO)로 마지막에 들어온 값이 먼저 나갑니다. 일상생활에서 엘레베이터를 생각하면 되고,
프로그램에선 브라우저 뒤로가기를 생각하면 됩니다.
큐: 퍼스트인 퍼스트 아웃으로 먼저 들어온 값이 먼저 나갑니다. 일상생활에서는 식당 줄을 생각하면 되고, 프로그램에선 일반적인 컴퓨터 프로세스를 생각하면 됩니다.
자바 메모리에 대해 설명해 보세요.
(모든 스레드 공유: method area, heap)
자바 메모리는 프로그램이 실행될 때 사용되는 메모리를 의미합니다.
- 메소드 영역(Method Area): 메소드 영역은 클래스 정보를 저장하는 공간입니다. 클래스 정보에는 클래스 이름, 메서드 정보, 변수 정보 등이 포함됩니다. 메소드 영역은 JVM이 시작할 때 생성되며, JVM이 종료될 때까지 유지됩니다.
- 힙 영역(Heap Area): new 연산자로 생성된 모든 객체의 인스턴스가 저장 됩니다.힙 영역은 JVM이 관리하는 메모리 공간으로, 객체와 배열 등의 동적 할당에 사용됩니다. 힙 영역은 가비지 컬렉션(Garbage Collection)에 의해 메모리를 관리하며, 객체의 생성 및 소멸을 처리합니다.
- 스택 영역(Stack Area): 스택 영역은 즉 지역변수, 매개변수, 리턴값 등이 저장됩니다. 또한 각 스레드마다 별도로 존재하며,스택은 후입선출(LIFO) 구조로 되어 있으며, 스택 프레임(Stack Frame)이라는 블록으로 구성됩니다.
자바 메모리는 가바지 컬렉터에 의해 관리되는데 가비지 커렉터는 더 이상 사용 되지 않는 객체를 자동으로 삭제하여, 메모리 누수를 방지합니다.
자바 메모리 동작원리에 대해 설명해 보세요.
-작성예정
가비지 컬렉터에 대해 설명해 보세요.
자바의 메모리 관리 방법 중 하나로, JVM의 Heap 영역에서 동적으로 할당했던 메모리 영역 중 사용하지 않는 메모리 영역을 관리하는 프로세스를 말합니다.
C나 C++에서는 가비지컬렉터가 없어 프로그래머가 수동으로 메모리 할당과 해제를 해줘야 하지만,
JAVA는 가비지 컬렉터가 탑재되어 있어 메모리 누수 문제에 대해 완벽하진 않지만 개발에만 집중할 수 있다는 장점이 있습니다.
가비지 컬렉터를 사용하면 메모리 누수에 대해선 고려하지 않아도 되나요?
가비지 컬렉터는 개발자가 개발에 집중할 수 있도록 도와주는 것이지 완벽하게 메모리 관리를 해주지 않습니다.
따라서 메모리 누수가 발생하게 되는데,
가비지 컬렉터는 참조를 기반으로 메모리 누수를 탐지합니다.
어떤 객체가 더 이상 참조되지 않을 때, 해당 객체는 가비지 컬렉터에 의해 제거됩니다.
하지만 객체가 참조되고 있는데도 제거되지 않는다면 이것은 메모리 누수가 발생되었다고 할 수 있습니다.
메모리 누수는 다양하게 발생하는데 그 중 몇가지만 말씀드리면,
불필요한 객체 참조를 하거나(A라는 객체를 참조하고 있는 B객체가 있다면, 참조 변수를 null로 설정하여 해당 객체의 참조를 해제해야함)
컬렉션 클래스 사용시 객체를 제거 하지 않고 계속해서 추가하는 경우,
스레드를 생성하고 실행하는 경우 명시적으로 종료하는 코드를 추가하여 메모리 누수를 해결해야합니다.
스레드란?
프로그램에서 실행되는 하나의 작업 단위로, 하나의 프로세스 내에서 독립적으로 실행되는 작업 단위입니다.
자바에서는 멀티-스레드가 가능해서 여러 작업을 동시에 처리할 수 있습니다.
JVM 동작 방식
컴파일러가 자바 소스코드를 바이트 코드로 컴파일합니다.
Class Loader를 통해 JVM RUNTIME AREA로 로딩합니다.
이때 JVM RUNTIME AREA는 메서드, 힙, 스택 등의 메모리영역들을 말하며
로딩된 바이트 코드들을 Execution Engine을 통해 해석합니다.
Execution Engine에 의해 해석된 바이트 코드들은 RunTime Data Area의 각 영역에 배치되어 수행하며
Execution Engine에 의해 GC의 작동과 스레드의 동기화가 이뤄집니다.\
Spring, Spring framework, Spring MVC, Spring boot 차이점에 대해 설명해 보세요.
스프링 프레임워크 = 스프링은 스프링에서 제공하는 DI, AOP를 기반으로 애플리케이션 개발을 지원하는 프레임워크입니다.
스프링 부트는 내장 서버와 스프링프레임워크에서 제공하는 다양한 기능을 기본제공하며 쉽고 빠르게 개발할 수 있는 프레임워크입니다.
스프링 MVC는 Model View Contoller구조를 사용하여 웹 애플리케이션을 개발하기 위한 모듈입니다.
프레임워크와 라이브러리에 대해서 설명해 보세요.
프레임워크: 특정 문제를 해결하기 위해서 상호 협력하는 클래스와 인터페이스의 집합
라이브러리: 단순 활용이 가능한 기능, 함수를 정의한 도구들의 집합
CORS란?
CORS란 브라우저에서 보안상의 이유로 프로토콜, 호스트, 포트로부터 리소스에 대한 접근을 제한하는 보안 메커니즘입니다. 웹 페이지에서 다른 출처 즉 프로토콜, 호스트, 포트로부터 리소스를 가져오는 것은 보안상의 이유로 제한되고 있습니다. 왜냐하면 A라는 사이트에서 로그인 시 B사이트에서 A사이트에 정보 탈취를 위해 Ajax요청 보내는 것이 가능합니다. 이를 방지하기 위해 리소스를 요청하는 웹 페이지와 리소스를 제공하는 서버가 동일한 출처에 있어야 합니다.
하지만 다른 출처에서 온 리소스도 필요할 때가 있는데 서버 측에서 Access-control-Allow-Origin 헤더를 설정해서, 허용된 출처에만 요청을 받도록 설정이 가능합니다.
디스패처 서블릿에 대해 설명해 보세요.
디스패처 서블릿의 dispatch는 "보내다"라는 뜻을 가지고 있습니다. 그리고 이러한 단어를 포함하는 디스패처 서블릿은 HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해 주는 프런트 컨트롤러(Front Controller)라고 정의할 수 있습니다.
이것을 보다 자세히 설명하자면, 클라이언트로부터 어떠한 요청이 오면 Tomcat(톰캣)과 같은 서블릿 컨테이너가 요청을 받게 됩니다. 그리고 이 모든 요청을 프론트 컨트롤러인 디스패처 서블릿이 가장 먼저 받게 됩니다. 그러면 디스패처 서블릿은 공통적인 작업을 먼저 처리한 후에 해당 요청을 처리해야 하는 컨트롤러를 찾아서 작업을 위임합니다.
여기서 Front Controller(프런트 컨트롤러)라는 용어가 사용되는데, Front Controller는 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서 처리해 주는 컨트롤러로써, MVC 구조에서 함께 사용되는 디자인 패턴입니다.
디스패처 서블릿 장점에 대해 설명해 보세요.
Spring MVC는 디스패처 서블릿이 등장함에 따라 web.xml의 역할을 간소화했습니다. 과거 어는 모든 서블릿을 URL 매핑을 위해 web.xml에 모두 등록해주어야 했지만, 디스패처 서블릿이 해당 애플리케이션으로 들어오는 모든 요청을 핸들링해주고, 공통 작업을 처리하면서서 상당히 편리하게 이용할 수 있게 되었습니다. 현재 스프링에서 Controller만 구현해 두면 디스패처 서블릿이 알아서 적합한 컨트롤러 위임을 해주는 구조가 되었습니다.
디스패처 서블릿으로 모든 요청을 처리할 시 발생할 문제점은 무엇인가요?
정적 자원 처리에서 문제가 발생합니다.
이미지/HTML/CSS/JS등과 같은 정적 파일에 대한 요청마저 모두 가로채는 까닭에 정적 자원을 불러오지 못하는 상황도 발생하곤 합니다. 이러한 문제를 위해 1. 정적자원과 애플리케이션 분리, 2. 애플리케이션 요청을 탐색하고 없으면 정적자원 요청으로 처리하는 방법을 이용할 수 있습니다.
방금 말씀한 정적자원과 애플리케이션의 분리에 대해 설명해 보세요.
java파일에 대한 URL로 접근하면 디스패치 서블릿이 담당하고,
Resources에 대한 URL로 접근하면 디스패치 서블릿이 컨트롤할 수 없으므로 정적자원을 담당하지 않게 설계할 수 있습니다.
하지만 이렇게 정적자원과 애플리케이션의 분리를 한다면 코드가 지저분해지고, 모든 요청에 URL을 붙여야 하므로 직관적이지 않아 다음과 같은 방법을 사용하곤 합니다.
애플리케이션 요청을 탐색하고 없으면 정적 자원 요청으로 처리
두 번째 방법은 Dispatcher Servlet이 요청을 처리할 컨트롤러를 먼저 찾고, 요청에 대한 컨트롤러를 찾을 수 없는 경우에, 2차적으로 설정된 자원(Resource) 경로를 탐색하여 자원을 탐색하는 것입니다. 이렇게 영역을 분리하면 효율적인 리소스 관리를 지원할 뿐 아니라 추후에 확장을 용이하게 해 준다는 장점이 있습니다.
필터 인터셉터 차이에 대해 설명해 보세요.
필터는 Dispatcher Servlet에 요청이 전달되기 전/후에 url 패턴에 맞는 모든 요청에 대해 부가작업을 처리할 수 있는 기능을 제공합니다.
Dispatcher Servlet은 스프링의 가장 앞단에 존재하는 프론트 컨트롤러이므로, 필터는 스프링 범위 밖에서 처리가 되는 것 입니다.
즉 스프링컨테이너가 아닌 톰캣과 같은 웹 컨테이너에 의해 관리가 되는 것이고, 디스패처 서블릿 전/후에 처리하는 것 입니다.
인터셉터는 스프링이 제공하는 기술로써 Dispatcher Servlet이 컨트롤러를 호출하기 전과 후에 요청과 응답을 참조하거나 가공할 수 있는 기능을 제공합니다. 웹 컨테이너에서 동작하는 필터와 달리 인터셉터는 스프링 컨텍스트에서 동작합니다.
DAO / DTO / VO 차이에 대해 설명해 보세요.
DAO는 실제 DB의 data에 접근하기 위한 객체이며, Service 레이어와 DB를 연결하는 Repository의 package가 DAO입니다.
DTO는 계층 간 데이터 교환을 하기 위해 사용하는 데이터 객체입니다.
VO는 getter만 가지고 있어 수정이 불가능한 Read-Only 속성을 가진 객체입니다.
VO는 신뢰성을 기반으로 한 데이터 보존 DTO는 데이터 전달 그릇
Spring Security란 무엇인가요??
애플리케이션의 인증, 권한에 대한 보안을 담당하는 스프링 하위 프레임워크이며 필터의 흐름에 따라 처리하고 있습니다.
GET/POST 차이에 대해 설명해 보세요.
GET은 클라이언트에서 서버로 리소스를 요청하기 위해 사용되는 메서드이다
GET 요청의 URL 끝에는 파라미터가 전송되며 때문에 중요한 정보를 다루면 안 됩니다. 클라이언트에서 GET메서드를 통해 요청을 한다면 백엔드 컨트롤러에서는 @RequestParam으로 해당 값을 받습니다.(멱등성 O)
POST는 클라이언트에서 서버로 리소스를 생성하거나 수정하기 위해 데이터를 보낼 때 사용하는 메서드입니다.
POST데이터 전송 시 Body 부분에 담아서 보내며 외부적으로 드러나지 않아 보안이 필요한 부분이나, 길이에 제한이 없으므로 큰 데이터를 보낼 때 사용합니다. 클라이언트에서 POST 요청을 한다면 백엔드 컨트롤러 단에서 @RequestBody로 받을 수 있습니다. (멱등성 X)
추상클래스와 상속차이에 대해 설명해 보세요.
추상클래스는 일반적인 클래스와 마찬가지로 필드와 메서드를 가지지만 추상 메서드를 포함할 수 있습니다.
추상 메서드는 구현되지 않은 메서드로, 상속받은 클래스에서 반드시 구현되어야 합니다.
상속은 부모클래스의 필드와 메서드를 자식 클래스가 물려 받아 사용할 수 있습니다.
상속을 받은 자식 클래스는 부모클래스의 기능을 그대로 사용하면서, 추가적인 기능을 구현할 수 있습니다.
단일 상속만 지원하며, 하나의 클래스는 하나의 부모 클래스만 가질 수 있습니다.
따라서 추상 클래스는 자식 클래스에서 구현할 메소드를 정의하고, 공통된 기능을 묶어서 상속할 목적으로 사용되며, 상속은 부모 클래스의 기능을 자식 클래스에서 그대로 사용하면서 추가 기능을 구현할 때 사용됩니다.
추상클래스와 인터페이스 차이에 대해 설명해 보세요.
추상클래스는 추상 메소드를 포함하여 일반 메서드도 포함 가능한 클래스입니다. abstract 키워드를 사용하여 정의합니다.
단일 상속만 지원하며, 자식 클래스에서 반드시 추상클래스를 구현해야 합니다.
인터페이스는 추상 메서드와 상수만을 가지며 interface 키워드를 사용하여 정의합니다. 다중 상속을 지원하며, 구현 클래스에서 반드시 구현해야 합니다.
Web Server와 WAS의 차이점
web server는 http 요청에 따른 정적 컨텐츠를 제공한다.
WAS는 http요청에 따른 정적 컨텐츠도 제공할 수 있으며 DB조회나 다양한 로직 처리를 요구하는 동적 컨텐츠를 제공한다.
WAS는 인자값이나 사용자가 달라지면 컨텐츠가 바뀐다.
따로 Web Server를 두셨나요? -> WAS 앞 단에 Web Server를 두지 않은 이유가 뭔가요?
(OOO: WAS가 다 할 수 있는데 Web Server가 왜 있어야 돼?)
WAS 앞단에 Web Server를 구현하면 좋은 점
1. 책임 분할을 통한 서버 부하를 방지한다.
--정적 컨텐츠는 Web Server가 동적 컨텐츠는 WAS가 처리한다.
2. Web Server는 로드밸런싱 기능을 가지고 있습니다.
-- 앞단에서 Web Server를 두고 뒷단에는 여러대의 WAS를 분리하여 처리할 수 있도록 설정할 수 있다.
3. 로드 밸런싱의 health 체크를 할 수 있습니다.
-- Web Server에서 여러대의 WAS서버가 정상 동작을 하는지 서버 상태를 체크한다.
4. 보안적인 이점이 있습니다.
-- WAS 같은 경우는 DB나 로직이 들어있어 외부 노출을 하게 되면 위험한데,
Web Server를 앞단에 주어 외부 노출을 막을 수 있습니다.
트랜잭션이란에 설명해 보고, 사용해 본 경험을 말씀해주세요.
트랜잭션이란 더 이상 나눌 수 없는 최소작업 단위를 의미합니다.
DB 데이터를 수정 중 예외가 발생했다면 DB의 데이터들을 수정하기 전의 상황으로 돌리고 다시 작업이 진행되어야 합니다.
여러 작업을 진행하다가 문제가 생겼을 경우 이전 상태로 롤백하기 위해 사용되는 것이 트랜잭션(Transaction)입니다.
토큰 vs 세션 기반 인증의 차이 장단점에 대해 설명해 보세요.
세션 기반 인증은 서버에 사용자의 정보를 저장해 두고 브라우저를 닫기 전까지 사용자의 정보를 알기 위해선 세션을 유지해야 합니다. 하지만 클라이언트가 서버에 요청을 보낼 때마다 클라이언트의 식별 정보를 확인하게 되고 이 때문에 서버의 RAM 부하나, DB에 부하를 가져다줄 수 있습니다.
1. 확장성 트래픽이 늘어남에 따라 서버를 확장해야 할 경우 세션 분산 시스템 설계가 어렵습니다.
3. CORS 웹 애플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있다. 따라서 여러 도메인에서 쿠리를 관리하기 어렵습니다.
따라서 토큰을 활용한 인증 방법을 사용하게 되었습니다.
토큰인증 방법은 인증받은 사용자에게 토큰을 발급하고, 서버에 요청을 할 때마다 토큰을 보내도록 하여 유효성 검사를 합니다.
따라서 서버에 인증 서버를 구현하거나, 세션을 유지하지 않아도 되는 장점이 있습니다. 또한 로그인/비로그인한 회원에 대해 신경 쓰지 않고 손쉽게 서비스를 확장할 수 있으며 요즘은 JSON WEB TOKEN인 JWT를 사용하고 있습니다.
JWT란 무엇인가요?
JSON 포맷을 활용하여 사용자에 대한 정보를 저장하는 web token을 의미합니다.
자바 버전 몇까지 사용해 봤나? 자바 8에 도입된 문법은?
자바 8 버전까지 사용했으며 Stream, 제네릭, null처리를 할 수 있는 Optional 등 과 같은 문법이 추가되었습니다.
제네릭에 대해 설명해 보세요. 제네릭 장단점과 사용이유는?
클래스나 메서드에서 사용할 데이터 타입을 외부에서 정하는 것을 의미합니다.
이는 컴파일 시 타입 검사를 수행하므로 런타임에서 발생할 수 있는 타입 관련 에러를 미리 방지할 수 있습니다.
제네릭을 사용한다면 타입 안정성을 보장하므로, 재사용성, 유지보수성이 높습니다.
단점으로는 타입이 정확하게 지정되어야 하므로 코드가 길어지거나 복잡해질 수 있습니다.
oop에 대해 설명해 보세요.
객체지향프로그래밍이라고 하며 컴퓨터 중심 사고가 아닌 사람 중심으로 현실세계의 사물과 기능을 객체로 보고 그 객체로부터 개발하고자 하는 애플리케이션의 특징과 기능을 뽑아 객체화한 개념입니다.
OOP의 개념으로 SRP, OCP, LSP, ISP, DIP가 있습니다.
oop의 장점은 ?
재사용성과 유지보수성을 높일 수 있습니다.
GIT FLOW 전략을 사용했는데 설명해주세요.
여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow 입니다.
이상입니다.
여기까지 제가 받았던 면접 질문들과 추가적인 꼬리 질문들을 정리해보았습니다.
꾸준히 업데이트 하겠습니다.
감사합니다.
'✍🏻 > 회고록' 카테고리의 다른 글
영업이익, 공헌이익, JTBD의 연관관계에 대하여 (0) | 2024.05.04 |
---|---|
[EP 08] F-Lab 개발자 멘토링 서비스 후기 (0) | 2023.04.02 |
[EP 07] 홍대에서 두 번째 할로윈을 맞이하며 (0) | 2022.10.28 |
[EP 06] "6개월"간 노코드로 1억 2천만원 수익창출까지!노코드의 미래, 느낀점, 노코드를 활용하여 mvp를 만들고 수익 창출까지 (3) | 2022.05.27 |
[EP 05] "1개월"차 '노코드'로 하나의 웹사이트(굿짹 월드)를 만들기 위한 삽질과정 (0) | 2022.02.01 |
- Total
- Today
- Yesterday