I search a lot but couldn't find any right answer for this question. Some articles define TDD which you can do any sort of test in it. Some articles just said TDD is just about function test, and when it comes to acceptance test it will be BDD not TDD. So...
Is TDD really just unit test?
There's no universally accepted definition of what a unit test is, so it follows that there can't be a universally accepted answer to that question.
Modern-day TDD is an invention (or rediscovery) of Kent Beck. If you read his book Test Driven Development: By Example, you'll see that he uses small deterministic tests without dependencies. This is a common way to do TDD, and seems to fit most people's definition of a unit test.
On the other hand, just because Kent Beck originally used unit tests to demonstrate the TDD technique, it doesn't exclude other types of tests. Another great resource that uses a slightly wider kind of test is Growing Object-Oriented Software, Guided by Tests by Nat Pryce and Steve Freeman. While they don't use Gherkin, you can view that approach as congenial with BDD - at least, I'd call it a sort of outside-in TDD.
I once had the opportunity to talk to Dan North (the inventor of BDD) about the overall purpose of these kinds of techniques, and I think that we agreed that the overall motivation is to get fast feedback. With unit tests, you can run a test suite in mere seconds. That gives you almost immediate feedback on your API design and implementation.
If other types of test can give you similar feedback, it fits into the overall motivational framework of TDD. Exactly what you call the tests is of less importance.
But to answer the explicit question:
Is TDD really just unit test?
No, test-driven development (TDD) is a process in which you write (unit) tests and let the feedback you receive from these tests guide you to figure out what to do next. A common TDD workflow is the red-green-refactor cycle.